构建高效的 Agent
Anthropic 一年内陪过几十个团队搭 LLM agent。最成功的实现几乎都不用什么花哨的框架或专用库 —— 只是把简单、可组合的模式拼起来。
这篇是他们从客户案例和自己实践里总结的经验，给开发者讲清楚两件事：什么是 agent，以及什么时候该用、什么时候别用。
一、Agent 到底指什么
「Agent」这个词被滥用了。有人指完全自主、长时间独立运行、靠各种工具完成复杂任务的系统；也有人用来描述按预定流程走的实现。
Anthropic 把这些统称 agentic systems（代理式系统），并刻意区分两个子类：
| 类型 | 控制流由谁掌握 |
|---|---|
| Workflow | 预定义代码路径编排 LLM 与工具 |
| Agent | LLM 动态决定自己的流程和工具调用，自己掌控如何完成任务 |
一句话差别：workflow 的路径是硬编码的，agent 的路径是模型现想的。
二、什么时候该用 agent（什么时候别用）⭐
默认结论：能简单就简单。Agentic 系统通常用延迟和成本换性能，要先想清楚这个 trade-off 划不划算。
| 场景 | 用什么 |
|---|---|
| 单 LLM 调用 + retrieval（检索） + few-shot 示例就够 | 不要上 agentic 系统 |
| 任务边界清晰、可预测 | Workflow（可预测、稳定） |
| 任务开放、需要模型自己决策 | Agent（灵活、可规模化） |
大多数应用其实根本不需要 agent。别为了用而用。
三、什么时候用框架
常见的几个：
- Claude Agent SDK
- Strands Agents SDK（AWS）
- Rivet（拖拽 GUI）
- Vellum（GUI 复杂工作流）
框架的确帮你省了 LLM 调用、tool 解析、链式调用这些底层活。但代价是：
- 多一层抽象，遮住了 prompt 和 response，难 debug
- 诱导你做复杂方案，其实底下一个简单结构就够了
建议：先用 LLM API 裸写。很多模式十几行代码就实现了。要用框架，至少要把它底下做了什么搞清楚 —— 错误假设是最常见的翻车原因。
四、五种模式：从简到繁
从最基础的「单个 augmented LLM（增强的 LLM）」出发，逐层加复杂度。
模式 0：Augmented LLM
最基础的积木：一个 LLM 加上 retrieval + tools + memory。现代模型自己会生成检索 query、选合适的工具、决定记什么。
实现要点：
- 这些能力要为你的具体场景定制
- 给 LLM 一个清晰、文档化的接口
想接外部工具，可以走 MCP（Model Context Protocol），能简单接入一个不断扩张的第三方工具生态
后面所有讨论都假设每次 LLM 调用都已经具备这些能力。
模式 1：Prompt Chaining（提示链）
把任务拆成一串步骤，每个 LLM 调用处理上一步的输出。中间可以加程序化的 gate（检查点） 确保流程没跑偏。
何时用：任务能干净地拆成固定子任务。用延迟换准确率 —— 让每一步都简单。
| 例子 | 怎么链 |
|---|---|
| 营销文案生成 | 先写文案 → 再翻译成目标语言 |
| 长文档生成 | 写大纲 → 检查大纲符合标准 → 按大纲写正文 |
模式 2：Routing（路由）
把输入分类，分别交给特化的下游处理。让「为某类输入优化」不会伤到其他类输入。
何时用：任务有明确的几类、各类适合分开处理，且分类本身能做准（LLM 或传统分类器都行）。
| 例子 | 怎么分流 |
|---|---|
| 客服查询 | 一般问题 / 退款 / 技术支持 → 各自走不同流程、prompt、工具 |
| 性能/成本平衡 | 简单常见问题 → Claude Haiku 4.5；难题/异常 → Claude Sonnet 4.5 |
模式 3：Parallelization（并行化）
多个 LLM 同时干，结果程序化聚合。两个变体：
| 变体 | 做法 |
|---|---|
| Sectioning（分段） | 任务切成独立子任务并行跑 |
| Voting（投票） | 同一任务跑多次拿不同结果再投票 |
何时用：子任务能并行（提速），或需要多视角/多次尝试（提置信度）。
经验：让每个 LLM 调用只关注一个维度，比一个调用同时管多件事效果好。
| 例子 | 类型 |
|---|---|
| Guardrail：一个模型处理用户问题，另一个并行筛查不当内容 | Sectioning |
| 自动 eval：一次 LLM 调用评一个性能维度 | Sectioning |
| 代码漏洞 review：多个不同 prompt 各自看一遍 | Voting |
| 内容是否违规：多 prompt 评不同方面、调投票阈值平衡误报漏报 | Voting |
模式 4：Orchestrator-Workers（编排者-工人）
中央 LLM 动态拆分任务，分发给 worker LLM，再综合结果。
和 Parallelization 的关键区别：子任务不是预定义的，是 orchestrator 看输入临时定的。
何时用：任务复杂、子任务数量和性质事先不可知。典型如：改代码 —— 涉及几个文件、每个改什么，都得看任务定。
例子：
- 在多个文件做复杂改动的编程产品
- 多源搜索：需要从不同来源收集分析
模式 5：Evaluator-Optimizer（评估-优化）
一个 LLM 出结果，另一个 LLM 评估给反馈，循环迭代直到达标。
何时用：有清晰的评估标准 + 迭代真的能带来可衡量的提升。两个适配信号：
- 人给反馈后，LLM 输出能明显变好
- LLM 自己能给出这种反馈
像人类作家打磨稿子的过程。
例子：
- 文学翻译：第一遍 LLM 可能漏掉微妙处，由 evaluator 提建议改
- 复杂搜索：多轮搜集分析，evaluator 决定还要不要继续搜
五、Agent ⭐
到这里讨论的都是 workflow。真正的 agent 是 LLM 在循环里基于环境反馈使用工具。
随着模型成熟到能理解复杂输入、推理规划、可靠用工具、从错误恢复，agent 才在生产环境里冒头。
典型流程：
- 用户给指令或交互式讨论
- 任务明确后 agent 独立规划、执行
- 每一步从环境拿 ground truth（工具结果、代码执行结果）评估进度
- 必要时回到人类那里要信息或做判断
- 任务完成、或触发停止条件（如最大迭代次数）
实现常常很直接：就是 LLM + tools + loop。所以工具集和工具文档怎么设计，至关重要（详见后文 Appendix 2）。
何时用 agent：
- 开放性问题、步骤数事先无法预测
- 你不能写死一条固定路径
- 你对模型的决策有一定信任
代价：
- 成本更高
- 错误会累积放大
- 强烈建议在 sandbox 里大量测试，加 guardrail
Anthropic 自己用 agent 的两个例子：
- 解 SWE-bench 任务的 coding agent
- 「computer use」参考实现，让 Claude 操作电脑完成任务
六、模式可以拼，但不要为拼而拼
这些模式不是金科玉律，而是积木 —— 看场景拼组合、改。
唯一的核心原则：只在能可衡量地改善结果时才加复杂度。
七、总结：三条核心原则
LLM 应用的成功不在于谁系统最复杂，而在于谁建对了。先用简单 prompt，配上完整 eval；只有当简单方案兜不住时，才考虑上 multi-step agentic 系统。
实现 agent 时三条原则：
- ⭐ 保持设计简洁 —— 抽象别太厚
- ⭐ 透明 —— 显式展示 agent 的规划步骤
- ⭐ 认真打磨 ACI（agent-computer interface） —— 工具文档和测试要做透
框架能帮你起步快，但进生产前别犹豫，剥掉抽象层、用基础组件重写。
Appendix 1：实践中的两个高价值场景
Anthropic 在客户那里看到 agent 最值钱的两个场景。共同点：对话 + 行动并存、有明确成功标准、有反馈循环、有人在关键节点把关。
A. 客服
天然适合 agent：
- 对话流程自然 + 需要访问外部信息和执行操作
- 可以接客户数据、订单历史、知识库
- 退款、改单都能程序化处理
- 成功有明确指标（用户认为解决了）
几家公司甚至按「成功解决」收费，可见他们对 agent 效果的信心
B. 编程
LLM 应用里最有潜力的方向，从代码补全演进到自主解题：
- 代码可以用自动化测试验证
- agent 可以用测试结果当反馈迭代
- 问题空间结构清晰
- 输出质量能客观衡量
Anthropic 自己的 agent 已经能仅凭 PR 描述就在 SWE-bench Verified 上解真实 GitHub issue。但自动化测试只能验证功能正确，更宏观的需求对齐还得靠人 review。
Appendix 2：给工具做 prompt engineering ⭐
任何 agentic 系统里，工具都是关键。工具的定义和说明，该投入的 prompt engineering 精力不比主 prompt 少。
同一动作有多种表达，挑模型最容易出对的
| 例子 | 格式 A | 格式 B |
|---|---|---|
| 改文件 | 写 diff | 重写全文 |
| 结构化输出 | Markdown 里夹代码 | JSON 里夹代码 |
软件工程视角这些都等价、可无损转换。但对 LLM 难度差很大：
- 写 diff 要在 chunk header 里准确数变更行数
- JSON 里写代码要额外转义换行和引号
选格式的三个建议
- 给模型够多 token 让它「想」 —— 别让它一上来就写自己进死胡同
- 格式要接近模型在互联网上见过的自然写法
- 别有「格式开销」 —— 比如要它准确数几千行代码、给写的代码做字符串转义
ACI：像设计 HCI 一样认真
类比：业界为 HCI（human-computer interface）投入多少精力，就该为 ACI（agent-computer interface）投入多少。怎么做：
- ⭐ 换位思考 —— 看着工具描述和参数，你第一眼能确定怎么用吗？看不出，模型也大概率看不出。好的工具定义里通常有：示例用法、边界情况、输入格式要求、与其他工具的清晰边界
- ⭐ 改参数名/描述让一切更明显 —— 就当给一个新人写 docstring。工具多的时候尤其重要
- ⭐ 测它怎么用 —— 在 workbench 里跑大量样例，看它犯什么错，迭代
- ⭐ 防呆（poka-yoke） —— 改参数让出错更难
Anthropic 给 SWE-bench 做 agent 时，优化工具花的时间比优化主 prompt 还多。比如他们发现 agent 离开根目录后用相对路径会出错 —— 索性把工具改成强制要求绝对路径，模型立刻一次没错过
总结：直觉
搭 agent 不是搭复杂度比赛。
- 大多数任务里，augmented LLM 单调用 + 检索 + few-shot 就够 —— 别上 workflow
- 边界清晰的复杂任务用 workflow —— 可预测性是它的卖点
- 边界开放、需要模型自己决定路径的任务才用 agent —— 代价是成本与错误累积
如果你必须做 agent，把 90% 的精力花在两件事：
- 让 agent 的规划过程透明可观察
- 把 ACI 当 HCI 一样雕
把这两件事做好，剩下的复杂度多半根本不用上。