从 WorkBuddy 看 Agent 产品化：模型之外，还需要上下文、工具、Harness 和 Loop

zzz_2368

489人浏览 · 2026-08-06 15:05:11

zzz_2368 · 2026-08-06 15:05:11 发布

从 WorkBuddy 看 Agent 产品化：模型之外，还需要上下文、工具、Harness 和 Loop

很多 Agent demo 看起来已经很强：能理解自然语言，能拆任务，能调用工具，甚至能生成一份看起来完整的交付物。

但从 demo 到可用产品，中间还隔着一层更现实的问题：它能不能稳定地在权限边界内完成任务？能不能知道该看什么上下文？能不能判断工具结果是否可靠？能不能在失败后留下可诊断证据？能不能把一次任务延展成长期循环，而不是每次都从头开始？

文章目录

从 WorkBuddy 看 Agent 产品化：模型之外，还需要上下文、工具、Harness 和 Loop

这篇文章基于我新读到的《腾讯 WorkBuddy 实践：如何把 Agent 做成可用产品》整理和延展。为避免把原文观点直接写成事实，下面会明确区分三类内容：

已确认事实：来自腾讯云 WorkBuddy 官方页面、WorkBuddy 连接器文档、MCP 官方规范、OpenAI Function Calling 文档等公开资料。
原文观点：来自用户提供的文章附件，主要用于理解 WorkBuddy 团队如何组织 Agent 产品化问题。
本文判断：我基于这些资料提炼出的工程框架。

Agent 产品化不是“模型接工具”这么简单

腾讯云 WorkBuddy 官网把 WorkBuddy 定位为腾讯出品的全场景 AI 办公工作台，覆盖日常办公、代码开发与设计创意；官方页面还强调自然语言任务、自主拆解、规划执行、工具调用、本地文件处理和可验收结果。

这说明一个 Agent 产品的目标，不只是“回答问题”，而是“完成工作”。一旦目标从回答变成交付，系统复杂度就变了。

可以把 Agent 产品化拆成五层：

层次	核心问题	典型组件
模型层	模型如何理解、推理、生成下一步？	LLM、System Prompt、工具调用请求
能力层	外部系统和任务流程如何接入？	Tool、MCP、Skill、Plugin
上下文层	本次决策前模型该看什么？	文件、历史、规则、Memory、检索结果
控制层	如何约束、验证、纠错和审计？	Harness、权限、门禁、测试、日志
时间层	任务如何持续触发、交接和停止？	Loop、定时器、状态、预算、停止条件

在这里插入图片描述

小z个人认为：Agent 产品的核心能力，不是某一层单独强，而是这五层能否配合起来，把不稳定的模型输出转化为可控流程。

模型层：LLM 更像无状态函数，不是完整产品

原文把模型抽象成一个函数：

输出 = 模型（系统提示词 + 工具定义 + 会话历史 + 其他上下文 + 用户指令）

这个抽象很有用，因为它能帮我们避免一个常见误解：模型本身不等于产品。

从产品视角看，模型至少有两个边界：

状态边界：模型调用本身不自动持久化任务状态。历史对话、项目进度、用户偏好、文件内容，需要产品侧保存，再按需注入。
外部世界边界：训练后发生的信息、当前文件、业务系统、数据库、会议纪要、工单状态，都需要通过工具或数据源获取。

所以真正的 Agent 产品，一定要在模型外部提供状态、工具、权限和验证机制。

这不是说模型不重要。模型决定理解和推理上限，但如果产品不给它正确上下文、不限制危险动作、不验证执行结果，再强的模型也可能在复杂任务里出错。

在这里插入图片描述

Tool、MCP、Skill、Plugin 各自解决什么

原文用了较大篇幅解释 Tool / MCP / Skill / Plugin。这里我按“解决的问题”重新整理。

3.1 Tool：模型如何请求执行一个动作

OpenAI Function Calling 文档说明，Function calling 可以把模型连接到外部工具和系统，常见用途包括查询数据、执行动作、做计算和构建工作流。OpenAI 的 Structured Outputs 还支持通过 strict: true 让函数调用参数匹配给定 JSON Schema。

但这里有一个关键边界：模型只是生成调用请求，真正持有 API Key、执行请求、写数据库、发邮件、删文件的是 Agent 产品侧。

所以 Tool 的产品设计不能只写“工具叫什么”，还要回答：

什么时候应该调用？
参数 schema 是否足够明确？
结果是否结构化？
失败时如何反馈给模型？
高风险动作是否需要用户确认？
调用日志是否可追踪？

3.2 MCP：外部系统如何标准化接入

MCP 官方规范把 Server 能提供的能力分成三类基础原语：Prompts、Resources、Tools。

MCP 原语	控制主体	典型用途
Prompts	用户控制	斜杠命令、预设模板、交互式任务入口
Resources	应用控制	文件内容、Git 历史、数据库记录、上下文数据
Tools	模型控制	API 请求、文件写入、外部动作

腾讯云开发者社区文章也说明，WorkBuddy 的连接器功能基于 MCP 协议实现；WorkBuddy Enterprise 连接器文档则把连接器描述为 WorkBuddy 与外部服务之间的桥梁，技术形态包括 MCP + CLI 和 Skill + CLI。

这意味着 MCP 不只是“工具市场”。它真正解决的是 Agent 与外部系统之间的连接协议问题：外部系统如何暴露能力，Agent 如何发现、授权、调用和处理结果。

3.3 Skill：一类任务应该怎么做

Tool 解决“一个动作怎么执行”，Skill 解决“一类任务怎么完成”。

例如“创建 PR”不是一个 API 调用，而是一套流程：

读取仓库规则。
查看当前 diff。
判断改动范围和风险。
运行相关测试。
生成 PR 标题和正文。
标注未验证项。
用户授权后再发布。

这类流程如果每次都靠模型临场发挥，很容易不稳定。Skill 的价值就是把经过验证的做法沉淀下来，让 Agent 在遇到同类任务时按规范执行。

3.4 Plugin：把一组能力打包分发

Plugin 更像产品侧的能力包。一个插件可以包含 MCP 连接、Skills、Rules、Hooks、模板和资产。

比如一个团队研发插件可能包含：

team-dev-workflow
├─ MCP：Issue、MR、构建结果、内部文档
├─ Skills：创建 PR、排查 CI、写发布说明
├─ Rules：分支规范、Commit 规范、安全规范
├─ Hooks：提交前测试、危险命令确认
└─ Templates：PR 模板、变更说明模板

个人认为：Agent 产品的能力层不能只按“能不能接入”来设计，还要按复用方式、权限风险、上下文成本和维护边界来设计。

在这里插入图片描述

上下文层：Agent 不是看得越多越好，而是要看得刚好

Context Engineering 的核心问题是：这一步决策前，模型到底应该看到什么？

原文中一个重要观点是：WorkBuddy 这类产品不会把所有资料都一次性塞给模型，而是按任务需要组织上下文。这个观点和长上下文实践中的常识一致：上下文窗口变大，不等于所有内容都应该常驻。

上下文至少可以分成几类：

上下文类型	示例	风险
系统上下文	当前时间、系统、Shell、工作目录	过期或不准确会导致命令错误
项目上下文	目录结构、规则文件、依赖、测试方式	过多会挤占窗口，过少会误改文件
任务上下文	用户目标、验收标准、阶段状态	缺失会导致过早宣布完成
历史上下文	对话历史、Memory、上次执行结果	检索错会引入旧结论
工具结果	API 返回、日志、测试输出	原样塞入会污染上下文

小Z建议的上下文策略是：稳定信息放规则文件，任务状态落到结构化文件，外部资料按需读取，工具结果先清洗再进入模型。

这其实是一个预算问题。模型上下文不是无限草稿纸，而是一次决策的输入面。产品要做的不是“尽量多给”，而是“给当前步骤最需要、最可信、最可验证的信息”。

控制层：Harness 让 Agent 不只会做，还要可控

原文把 Harness Engineering 放在产品化核心位置，我认为这是这篇文章最有价值的部分。

可以把 Harness 理解成 Agent 的控制系统：

行动前，用前馈提供目标、规则、上下文和可用能力。
行动中，用权限和沙箱限制可执行动作。
行动后，用测试、审查、日志和反馈发现错误。
出错时，把失败原因返回给 Agent，或交给人处理。

5.1 前馈：让 Agent 第一次更可能做对

前馈包括 System Prompt、规则文件、Skill、工具描述、项目结构、环境信息和用户偏好。

它解决的问题是：Agent 开始前到底知道什么。

但前馈不能无限堆。规则越多，上下文成本越高，冲突概率也越高。因此更好的做法是分层：

所有任务都适用的规则常驻。
项目规范放在工作区规则文件。
某类任务的步骤放 Skill。
当前任务材料动态注入。

5.2 反馈：让 Agent 知道哪里错了

反馈包括工具错误、编译失败、测试结果、权限拒绝、代码审查、端到端验证和用户反馈。

这里要区分两类反馈：

类型	适合什么	例子
计算型反馈	可重复、低成本、确定性问题	lint、类型检查、单测、构建、schema 校验
推断型反馈	需要语义判断的问题	架构审查、需求一致性、设计质量、业务合理性

能用计算型反馈解决的问题，不应该优先交给模型自评。比如 JSON 是否符合 schema、测试是否通过、文件是否存在，这些都应该由确定性程序判断。

5.3 权限：模型不能直接拥有高风险能力

MCP Tools 规范也强调，涉及工具调用时，应用应该让用户清楚看到哪些工具暴露给模型，并在需要时提供确认机制。

这点在企业场景尤其重要。发送邮件、发布内容、修改生产数据、删除文件、创建订单、变更权限，这些都不能只靠模型“判断应该做”。

产品侧至少要有：

allowlist / denylist；
操作前确认；
参数校验；
审计日志；
可回滚策略；
对敏感数据的最小暴露。

在这里插入图片描述

编排层：一次完整任务不是一条 Prompt，而是一条信息流

以“调研一个技术主题并输出带引用的大纲”为例，一个 WorkBuddy 类 Agent 大致会经历：

读取当前 Workspace，确认已有资料和保存位置。
读取相关 Memory 和写作规则。
判断是否需要调用搜索、文档、知识库或代码工具。
把调研对象拆分给多个子 Agent。
汇总每个子 Agent 的结论、来源和边界。
检查缺口，补充一手资料。
输出结构化大纲或成稿。

这里最重要的不是“用了几个 Agent”，而是每一步有没有明确输入、输出、状态和验收标准。

如果没有这些结构，多 Agent 只会变成多段对话；如果有这些结构，多 Agent 才能成为可观察、可恢复、可复用的工作流。

在这里插入图片描述

时间层：Loop 让任务能跨时间继续

Loop Engineering 关注的不是一次调用，而是任务如何在时间维度上持续运行。

一个完整 Loop 至少需要：

Trigger：什么时候触发；
Workspace：在哪里执行；
Skill：按什么流程做；
Tools / MCP：调用哪些外部能力；
State：进度和中间产物保存在哪里；
Sensors / Evals：如何判断结果；
Stop Conditions：什么时候停止；
Human Approval：什么风险必须交给人。

比如“每天检查依赖安全更新”：

每天 09:00 触发。
创建独立工作区。
读取仓库规则和依赖更新 Skill。
查询可用更新和漏洞信息。
选择一个可独立验证的更新。
修改 lockfile。
运行安装、类型检查、单测、构建和漏洞扫描。
失败则在限定轮数内修复，仍失败则输出诊断报告。
通过则生成 PR 草稿和风险摘要。
等待人审批。

Loop 的风险也很明确：目标错了，它只会更稳定地朝错误方向前进；验收标准错了，它会把错误做成闭环。因此 Loop 必须依赖 Harness 的权限、验证和停止条件。

在这里插入图片描述

落地自查：设计 Agent 产品前先问 12 个问题

如果要把 Agent 做成产品，而不是一次 demo，可以先问这 12 个问题。

模型和上下文

模型每一步需要哪些上下文？哪些不该进入上下文？
历史状态保存在哪里？能否跨会话恢复？
工具结果是原样进入模型，还是先清洗、摘要、结构化？

能力和权限

Tool 的 schema 是否足够明确？
MCP / Connector 背后的权限边界在哪里？
高风险动作是否有确认、审计和回滚？

流程和验证

一类任务是否应该沉淀成 Skill？
哪些验证可以用确定性程序完成？
哪些验证必须交给审查 Agent 或人？

编排和迭代

多 Agent 之间如何交接产物？
Loop 的触发、预算和停止条件是什么？
Harness 自身如何根据失败案例持续迭代？

这 12 个问题比“换哪个模型”更接近产品化实际。模型升级会提高上限，但这些问题决定上限能否稳定落地。

总结

从 WorkBuddy 这类 Agent 产品可以看到一个趋势：Agent 产品化正在从“调用更强模型”转向“建设更完整的执行系统”。

这个系统至少包括：

模型：负责理解、推理和生成；
Tool / MCP：负责连接外部能力；
Skill / Plugin：负责沉淀流程和分发能力；
Context：负责组织当前决策所需信息；
Harness：负责权限、验证、反馈和审计；
Loop：负责长期触发、交接和停止。

如果只接工具，没有上下文管理，Agent 会乱用能力；如果只有上下文，没有 Harness，Agent 会缺少约束；如果只有 Harness，没有 Loop，任务难以持续；如果有 Loop 但没有停止条件，风险会被放大。

所以，Agent 产品化最关键的问题不是“模型会不会做”，而是：

系统能不能让它在正确上下文里、用正确工具、遵守正确权限、经过正确验证，持续交付可验收结果。

btw:

需要诚实说明三点。
第一，本文没有证明 WorkBuddy 内部真实架构完全等同于上面的五层图。五层图是基于原文、公开资料和本文分析整理出的理解框架。
第二，本文没有证明 MCP、Skill、Harness、Loop 适用于所有 Agent 产品。它们是当前比较实用的一组分析维度。
第三，本文没有证明模型能力不重要。更强模型仍然重要，只是产品化不能只依赖模型。

更准确的结论是：模型提供能力上限，上下文、工具、Harness 和 Loop 决定这个能力能否在真实场景里稳定交付。