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

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

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

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

文章目录

• 从 WorkBuddy 看 Agent 产品化：模型之外，还需要上下文、工具、Harness 和 Loop
• • Agent 产品化不是“模型接工具”这么简单
  • 模型层：LLM 更像无状态函数，不是完整产品
  • Tool、MCP、Skill、Plugin 各自解决什么
  • • 3.1 Tool：模型如何请求执行一个动作
    • 3.2 MCP：外部系统如何标准化接入
    • 3.3 Skill：一类任务应该怎么做
    • 3.4 Plugin：把一组能力打包分发
  • 上下文层：Agent 不是看得越多越好，而是要看得刚好
  • 控制层：Harness 让 Agent 不只会做，还要可控
  • • 5.1 前馈：让 Agent 第一次更可能做对
    • 5.2 反馈：让 Agent 知道哪里错了
    • 5.3 权限：模型不能直接拥有高风险能力
  • 编排层：一次完整任务不是一条 Prompt，而是一条信息流
  • 时间层：Loop 让任务能跨时间继续
  • 落地自查：设计 Agent 产品前先问 12 个问题
  • • 模型和上下文
    • 能力和权限
    • 流程和验证
    • 编排和迭代
  • 总结
  • btw:
  • 参考资料

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

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

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

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

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

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

小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。

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

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

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

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

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

这类流程如果每次都靠模型临场发挥，很容易不稳定。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 这类产品不会把所有资料都一次性塞给模型，而是按任务需要组织上下文。这个观点和长上下文实践中的常识一致：上下文窗口变大，不等于所有内容都应该常驻。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

这里要区分两类反馈：

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

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

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

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

产品侧至少要有：

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

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

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

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

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

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

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

一个完整 Loop 至少需要：

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

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

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

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

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

模型和上下文

能力和权限

流程和验证

编排和迭代

这 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 决定这个能力能否在真实场景里稳定交付。

参考资料

• 原文：微信公众号《腾讯 WorkBuddy 实践：如何把 Agent 做成可用产品》

• 腾讯云：WorkBuddy 产品页

• 腾讯云：WorkBuddy Enterprise 产品页

• 腾讯云文档：WorkBuddy Enterprise 连接器

• 腾讯云开发者社区：如何在 WorkBuddy 中使用 MCP Server？

• WorkBuddy 文档：MCP 指南

• Model Context Protocol：Server Features Overview

• Model Context Protocol：Tools

• OpenAI Help Center：Function Calling in the OpenAI API

• OpenAI：Introducing Structured Outputs in the API

感谢阅读，记得点赞、关注、收藏，欢迎各位评论区交流！！！