原文：腾讯技术工程《腾讯 WorkBuddy 实践：如何把 Agent 做成可用产品》，作者 Anne（WorkBuddy 策略产品经理）。 这篇笔记把原文的产品视角重新整理成更通用的技术叙事，保留核心观点，并引用了原文配图。

一个常见误区：模型好，Agent 就一定好用？

很多人一开始会把 Agent 的成败押在模型上：换更强的模型、写更长的提示词、加更多的 few-shot 例子。体验 demo 时确实有效，但一进入真实业务场景，模型往往会暴露三个硬伤：

• 它是无状态的。上一秒聊过的内容、用户的偏好、任务的进度，模型自己不会记着。
• 它的知识有截止日期。训练之后发生的事，它只能“猜”，不能“查”。
• 它只能生成文字，不能直接操作外部世界。读文件、查数据库、发邮件、调用 API，这些动作模型本身做不了。

所以 Agent 要真正可用，光靠模型不够。产品侧必须给模型配上工具、上下文、执行环境、权限边界、验证机制和反馈闭环。换句话说：模型决定能力上限，上下文（Context）和马具（Harness）决定这个上限能不能稳定落地。

01 先把模型看成一个无状态函数

对工程同学来说，可以把一次模型调用抽象成一个函数：

输出 = 模型(系统提示词 + 可用工具 + 会话历史 + 其他上下文 + 用户指令)

这个抽象里有两条关键约束：

1. 模型无状态，但产品可以有状态。对话历史、记忆、工作进度，都是产品在外部维护好，再按需塞进这次输入的。
2. 模型的知识截止到训练日期。实时信息、私有数据、外部动作，都需要通过工具查询后再交给模型。

理解这一点，就不会再问“为什么模型不知道今天的新闻”——它本来就不该知道。知道，是工具的事；把知道的结果用对，是上下文工程的事。

02 用户能感知到的四个概念：Function Call、MCP、Skill、Plugin

要让 Agent 能干实事，得先让它能调用外部能力。这里最容易混淆的是四个概念，它们的关注点完全不同。

2.1 工具调用：模型怎么请求执行动作

工具调用（Function Call / Tool Call）是模型和外部系统之间的结构化协议。模型只负责生成调用请求，真正执行的是 Agent Host。

完整流程一般是这五步：

1. 产品把可用工具的名称、用途、参数 schema 告诉模型；
2. 模型根据用户目标，输出一个结构化的调用请求；
3. Agent 校验参数、检查权限，然后执行 API、脚本或本地函数；
4. 执行结果作为 Tool Result 放回上下文；
5. 模型读取结果，决定直接回答，还是继续调用下一个工具。

注意一个关键点：真正持有 API Key、发起网络请求、修改数据的是 Agent，不是模型。所以权限、审批、参数校验、审计日志，必须由模型外部的工程机制来保证。

2.2 MCP：外部系统怎么标准化接入

MCP（Model Context Protocol）是 Anthropic 在 2024 年底提出的开放协议，目的是让外部系统用一种统一的方式接入 Agent。

MCP Server 向 Agent 提供三种原语：

• Resources（资源）：只读内容，有 URI 标识，比如一份文档、一段日志。
• Tools（工具）：模型可以调用的动作或函数。
• Prompts（提示模板）：Server 预先组织好的一组可复用消息。

MCP 解决的是“外部系统怎么接进来”。但接进来之后，什么时候调用、按什么流程调用、失败了怎么办，还需要另一层定义——这就是 Skill。

2.3 Skill：一类任务该按什么流程做

Tool 定义一个动作，Skill 定义一类任务的做法。

比如“提交 PR”可以做成一个 Skill，里面规定：先读贡献规范，再检查 git status，再看 diff，跑相关测试，生成 PR 描述，最后确认用户授权再 push。它不只是让 Agent 知道“有个 create_pr 工具”，而是告诉 Agent“做这件事的完整流程和判断标准”。

一句话区分三者：

• MCP：外部系统怎么标准化接入。
• Skill：这类任务应该怎么做。
• Plugin：一组相关能力怎么打包、安装和分发。

2.4 Plugin：一组能力怎么打包分发

Plugin 是产品层的打包概念。一个 Plugin 可以包含 MCP 连接、Skills、规则文件、Hooks、模板和资源。

比如一个“团队研发工作流”Plugin 可能包括：读写 Issue/MR 的 MCP、/create-pr /debug-ci 等 Skills、分支与 commit 规范、提交前跑测试的 Hook、PR 模板和架构图资源。它让能力从“散落的脚本”变成“可安装、可复用、可版本化的模块”。

03 全景视图：一次完整任务到底怎么跑起来

把这些概念串起来，一次真实任务的信息流大致如下：

1. 用户提出目标；
2. Agent 查看 Workspace、读取 Memory、查找相关 Skill；
3. 连接内部数据源，查询背景资料；
4. 把大任务拆成子任务，分配给 Sub-agent 并行处理；
5. Sub-agent 返回结果，主 Agent 汇总、补缺口、验证；
6. 最终生成输出并保存。

这是一个典型的 ReAct 循环（Reasoning → Acting → Observing）：判断当前状态、选择下一步行动、观察执行结果、再判断。多轮之后，一个复杂目标才被逐步完成。

04 Context Engineering：模型这一刻该看到什么

Context Engineering 是 Agent 产品里最容易被低估、又最影响稳定性的环节。它的核心问题是：在一次模型决策前，设计哪些信息进入上下文、以什么形式进入、放在什么位置、什么时候更新或移出。

通常有五类动作：

1. 写入（Write）：把目标、规则、环境、任务状态显式写进上下文。
2. 选择（Select）：从已有信息里只挑当前这一步需要的，避免信息过载。
3. 检索（Retrieve）：当前不在上下文里的信息，从历史、资料库、工具目录里按需拉取。
4. 压缩（Compress）：长内容外置到文件，只留结论和证据位置，清理过期或重复内容。
5. 隔离（Isolate）：用独立会话或 Sub-agent 处理旁支任务，只把结果带回主线。

Context Engineering 的目标不是堆更多 token，而是让上下文相关、准确、及时。

Prompt Cache：上下文管理的第一要义

一个工程技巧是把稳定的内容放在前面，动态内容放在后面。系统提示词、基础工具定义、长期规则尽量保持稳定；对话历史追加在后面；工具/Skill 按需加载。这样相同前缀可以复用缓存，只计算新增部分，既省成本也减少模型困惑。

渐进式加载：别让长结果和大工具集撑爆上下文

当工具返回 1000 条记录时，一次性全塞进上下文是灾难。分页、截断、写文件，是当前只加载摘要。当工具定义太多时，可以先做能力发现：按意图分类 → 搜索候选 → 只加载选中工具的 schema。Skill 也可以类似地先看名称描述，再按需读 SKILL.md。

05 Memory：让正确的过去，在正确的时候重现

Agent 要长期可用，必须会“记”。但记忆不是把所有历史对话都塞进上下文，而是做准入判断：哪些信息值得记住、放在哪个作用域、什么时候注入。

WorkBuddy 长期记忆的五类信息

为什么不要把“程序性记忆”放进长期记忆

陈述性记忆（事实、偏好）适合放进 Memory；程序性记忆（比如“遇到 bug 先重启服务”）不适合直接记忆化。原因是局部经验容易被错误上升为通用策略，导致机械复用历史步骤、干扰推理、降低泛化能力。WorkBuddy 的做法是：用户事实进 Memory，验证过的方法存为 Skill。

记忆的作用域分层

记忆可以分多层：当前轮、会话/Thread、Workspace、用户级、团队/组织级。作用范围越大，写入和晋升门槛越高。注入时机也分阶段：会话开始、理解请求、执行中回查、任务收尾提取。

06 Harness Engineering：引导、约束与整合

如果把 Agent 比作一匹有潜力的马，Harness 就是驾驭它的全套装备：缰绳引导方向、安全带限制危险动作、马鞍承载状态和工具。

Harness Engineering 包含三类能力：

1. 驾驭（Steer）：System Prompt、Skills、Task/Todo、自我纠正提示，定义执行方向。
2. 约束（Constrain）：权限边界、Sandbox、Approval Gate、Allowlist/Denylist、测试、回滚、审计，限制操作范围。
3. 整合（Integrate）：执行能力、状态承载、协作机制、自动化，让系统组件协同工作。

业界实践给我们的启发

• OpenAI Codex：3 人小组 5 个月产出约 100 万行代码、1500+ 个 PR，证明了大规模代码生产的可能性，但也说明业务正确性验证仍是缺口。
• Anthropic：长任务失败后，用“初始化 Agent + Coding Agent”跨会话交接，把任务拆成 200+ 条 JSON 清单；后来又提出 Planner / Generator / Evaluator 三角色对抗评估，让执行和验收尽量分离。
• LangChain：直接提出 Agent = Model + Harness，强调评估的是“模型 + Harness”的组合，而不只是模型本身。

WorkBuddy 的五层 Harness

从下到上：

1. 运行环境层：文件系统、Shell、Sandbox、Browser、MCP、权限边界。
2. 引导层（Feedforward）：项目上下文、环境上下文、规则与风格、Skills。
3. 反馈层（Feedback）：工具结果纠正、编辑前时间戳校验、外部验证信号、Audit Log。
4. 编排层：渐进式加载、意图识别、多模型路由、Teams。
5. 迭代层：随着模型能力演进，持续精简上下文、增加约束、适配工具、补充机制。

这五个层次共同回答两个问题：执行前知道什么（提高首次正确率），执行后怎么知道错了（提供反馈闭环）。

07 Loop Engineering：从单次 Prompt 到长期任务循环

前面几层主要解决“单次任务怎么做好”，但真实业务里很多任务是周期性或长期运行的：每天 9 点检查依赖安全更新、每周汇总项目进度、持续监控某个指标。

Loop Engineering 把工程对象从单次 Prompt 扩展到可长期运行的任务循环。

可以把 Agent 工程分成四层：

注意：Goal 不等于 Loop。你可以定义“每天检查依赖安全更新”这个目标，但 Loop 不会自动解决“什么叫正确目标、什么叫验收通过、出事了谁负责”。这些仍然需要人来定义。

08 还没解决的问题：Agent 不是银弹

即使有了完整的 Context、Harness、Loop 体系，Agent 仍然面对一些结构性难题：

业务正确性验证的缺口

PRD 很难覆盖所有组合行为；实现和测试可能共享同一个误解；核心业务缺少可计算的验收标准；错误的代价可能很高。所以 AI 的自治度应该分级：一次性脚本可以高度自治，核心业务逻辑必须保持低自治、强验证。

代码库的 Harnessability

老系统结构不清、历史违例多、复杂度高、可观测弱，会让 Harness 的建设异常困难。Agent 能跑多稳，很大程度上取决于底层代码库本身是否“可被驾驭”。

人的责任不会消失

OpenAI 有一句话被原文反复引用：“this isn't something you can jump into for quick results.” Agent 系统需要持续投入。最终，人负责选择方向、定义标准并承担责任；Agent 负责执行、验证和加速迭代。

结语：五个要点

把 Agent 从模型能力推进到可用产品能力，核心可以总结为五点：

1. 模型是核心推理引擎，但它无状态、不自动联网、不自动执行。
2. Function Call / MCP / Skill / Plugin 构成 Agent 的能力层，分别解决“动作怎么请求”“外部系统怎么接”“任务怎么做”“能力怎么打包”。
3. Context Engineering 决定模型当前能看到什么；Memory 决定过去如何正确重现。
4. Harness Engineering 是可信系统的关键，通过引导、约束、整合让 Agent 稳定可控。
5. Loop Engineering 把时间维度加进来，让 Agent 能处理长期、周期性的任务。

最后的结论也很朴素：模型决定能力上限，上下文和 Harness 决定上限能不能稳定落地。在这场人机协作里，Agent 是强力的执行者，但方向、标准和最终责任，仍然在人手里。

注：文中架构图均引用自腾讯技术工程公众号原文《腾讯 WorkBuddy 实践：如何把 Agent 做成可用产品》。