Building Effective Agents · 策展笔记

Anthropic 的工程博客在 2024 年 12 月挂出一篇讲怎么搭 Agent 系统的长文，署名 Erik S. 与 Barry Zhang，都是一线带 Agent 项目的工程师。文章没有跑任何实验，通篇是工程经验，却被业内当 Agent 入门第一课反复引用。

页面到今天还在维护。路由示例里的模型名已经写成 Haiku 4.5 与 Sonnet 4.5，这两个名字在文章发布当天还不存在，可见它被当活文档养着，发出来不算完。

全篇主张可以用原文立住：

“We recommend finding the simplest solution possible, and only increasing complexity when needed.”

翻译过来就是：能不加复杂度就不加。很多时候单次模型调用加检索加几个示例就够了，工作流次之，智能体最后才轮到。

文章把各类做法统称 agentic systems，底下分两类。工作流 (workflow) 是 LLM 和工具被预先写死的代码路径编排；智能体 (agent) 是 LLM 自己动态决定流程和工具用法，一路掌控到任务完成。这两个词先分清。

地基只有一块积木：增强型 LLM (augmented LLM)，给模型外挂检索、工具和记忆，让它自己决定搜什么、调哪个工具、记什么。文章建议按具体场景裁剪，工具接口做成有文档的标准形式，原文顺带点名了 MCP 这个协议选项。

工作流部分给了五种模式，每种都配适用条件和代价提醒。子任务能干净拆开的才值得上模式，拆不开就回去改提示词。

提示词链 (prompt chaining)：任务拆成串行步骤，前一步喂后一步，中间可加程序化门控，不达标就地终止。例子是先生成营销文案再翻译、先出大纲校验通过再写全文。代价是拿延迟换准确率。
路由 (routing)：先把输入分类，再派给专门的下游提示词。客服工单可拆成一般咨询、退款、技术支持三条管线各用各的提示词；也可按难度分流，简单问题给 Haiku、难题给 Sonnet，成本直接砍下来。
并行化 (parallelization)：两个变体。分段 (sectioning) 是独立子任务同时跑，比如一个实例回答用户、另一个同时查违规，自动评测一次调用只评一个维度；投票 (voting) 是同一任务多路跑再投票，多组提示词同时查代码漏洞，内容审核靠票数阈值调假阳假阴。
编排者 - 工人 (orchestrator-workers)：中央 LLM 动态拆解任务、派给工人模型、再汇总结果。适合子任务写不死的场景：跨多文件的代码改动、要从多个来源汇总信息的搜索。
评估者 - 优化者 (evaluator-optimizer)：一个模型生成、另一个批评、循环打磨。适合评判标准清晰、迭代确有增益的任务，例子是文学翻译和多轮才能收窄的复杂检索。

智能体的定义原文给得很朴素：

“They are typically just LLMs using tools based on environmental feedback in a loop.”

其实就是 LLM 在循环里用工具，靠环境反馈纠偏。每一步都要从环境拿真值 (ground truth)，工具返回、代码执行结果都算，才能判断进展。可以在检查点暂停找人要信息，也得配停止条件，最常见的是最大迭代数。

自主的代价原文写得很直白：成本更高，错误会复合。所以建议放沙盒里充分测试，配上护栏再上线。

客服被点名为智能体的天然场景：对话天然多轮，工具一接就能查订单、查知识库、办退款，成功标准是用户认定的问题解决。有厂商干脆按结果计费，只对成功解决的工单收钱。把可验证的解决当计价单位，这笔商业账很聪明。

编码是另一个被点名的场景：方案能用自动测试验证，模型可以对着测试反馈迭代。他们的 agent 在 SWE-bench Verified 上只凭 PR 描述就解决了真实的 GitHub issue，原文随即补了一句人工审查仍然关键。

文章把人机交互 (HCI) 的概念挪过来造了 ACI (agent-computer interface)，主张工具接口值得像用户界面一样认真设计。

具体纪律一串：参数说明当给初级工程师的文档写，用法、边界、坑例都写清；给模型留思考空间再动手；格式贴近自然文本，别把 token 浪费在花哨结构上；再做防呆设计 (poka-yoke)，让错误难以发生。

有一句自述分量很重：做 SWE-bench 这个项目时，他们花在优化工具上的时间比优化提示词还多。坑也很具体。模型离开工程根目录后会被相对路径绊倒，改成强制绝对路径，此后就再没错过。

框架部分今天读别有意味：清单里是 Claude Agent SDK、AWS 的 Strands、拖拽画布的 Rivet 和 Vellum。态度是帮你起步可以，但抽象层会挡住提示词与响应，出问题更难查。建议直接用 API 起步；用了框架就务必读懂底层代码。

收尾的态度贯穿全篇：

“Success in the LLM space isn’t about building the most sophisticated system.”

后半句是造对你需要的系统。复杂度只在可证明改善结果时才加，模式清单也只是起点，量测性能、按证据迭代。

个人以为这篇的稀缺处在于立场。卖 token 的公司劝你少烧 token：智能体形态的调用量远高于工作流，文章却反复强调先问要不要。这种克制比任何模式图都值钱。

最可迁移的一条是工具文档优先于提示词调优。如果我的管线要做多文件代码改动，第一笔时间该花在把每个工具说明写到初级工程师能照着用的程度，第二笔才轮到提示词。

什么别当真也要说清：全篇没有一个对照实验，量化证据只有 SWE-bench 那句自述，性质是经验谈。模式图当菜单翻就好，别当施工图。原文自己也交代了模式不具规定性，量测了再上。

大陆访问 anthropic.com 要代理。但选型纪律和工具工程跟用哪家模型无关，国产模型的管线照搬同样成立。

这篇适合两类人：刚开始搭的当地图，搭了一年的当体检表。读一遍二十分钟，省的试错不止二十小时。