Anthropic《Building Effective Agents》精读：我如何把它读成一篇工程方法论

如果我是把 Building Effective Agents 当成一篇“AI 圈热文”来读，我大概率只会记住几个关键词：

• workflow
• routing
• parallelization
• orchestrator-workers
• evaluator-optimizer

然后就结束了。

但我后来越来越觉得，这样读这篇文章其实有点可惜。它最有价值的地方，不是给我列了几个 Agent 模式，而是它把 Anthropic 做 Agent 的一整套工程判断暴露得很直接。换句话说，这篇文章真正值得读的，不是“它介绍了哪些模式”，而是：

• Anthropic 在什么情况下不做 Agent；
• Anthropic 为什么认为很多 Agent 其实是过度设计；
• Anthropic 真正在解决什么生产问题；
• Anthropic 把复杂度、透明性、工具接口和评测放在什么位置。

我这篇精读就按这个方向来拆。

我不会把它读成一篇“论文综述”，因为它本来也不是论文；我更愿意把它读成一篇来自一线团队的工程方法论总结。对我来说，这种材料最重要的价值，不是给我一个标准答案，而是逼我重新问自己：我现在做的 Agent 系统，到底哪些地方是真的需要 Agent，哪些地方只是把复杂度包装成了智能。

我这次读它，其实也是带着我自己当前这条 Agent 主线去读的。过去一段时间，我一直在把注意力放在几件事上：workflow 和 agent 的边界、tool schema 设计、memory 的装配方式、eval 怎么接入真实开发流程、系统最后怎么从 demo 走向生产。也正因为我脑子里带着这几条线，所以我读 Building Effective Agents 时，注意力天然不在“Anthropic 又总结了几个模式”，而在“它到底是怎样给复杂系统定边界的”。

如果只用几句话概括我带着的问题，其实就是这四个：

• 哪些任务其实根本不该做成 Agent；
• 哪些地方看起来像智能，实际只是边界没收好；
• 一个 Agent 系统最先该补的是规划，还是工具接口和环境反馈；
• 当系统开始变复杂时，Anthropic 最先收的到底是哪一类控制权。

一、我先抓这篇文章的总主线#

我第一次认真读这篇文章时，先强迫自己不去记模式名，而是先问一句：

如果整篇文章只允许我带走一句话，我会带走什么？

我最后留下来的主线其实很简单：

Agent 不是目标，可控地完成任务才是目标。

Anthropic 的整篇文章，在我看来都是围绕这句话展开的。

它的逻辑不是“Agent 很重要，所以大家都应该做 Agent”，而更像一条逐步加复杂度的演化链：

简单 prompt
  ↓
单次调用不够
  ↓
加结构
  ↓
workflow
  ↓
workflow 还不够
  ↓
agent
  ↓
agent 容易失控
  ↓
需要评测、透明性、工具治理和停止条件

我很喜欢这条主线，因为它跟我熟悉的后端系统演化逻辑很像。很多系统一开始也不是为了追求“架构先进”才变复杂，而是因为简单方案先顶不住了，才一步步加层。但现实里最大的问题往往不是“复杂度不够”，而是“复杂度加得太快、太早、太不受控”。

这也是我读这篇文章时最强烈的共鸣点。它不是在鼓励我尽快做出一个更自治的 Agent，而是在提醒我：复杂度必须是被证明有价值的，而不是被想象成有价值的。

二、Anthropic 到底把什么定义为 Agent#

这篇文章非常值得反复咀嚼的一点，是它对 workflow 和 agent 做了一个很清楚的区分。

Anthropic 的说法可以概括成两句话：

• workflow：LLM 和工具沿着预定义代码路径被编排
• agent：LLM 动态决定自己的流程和工具使用方式

这两个定义看起来很朴素，但我觉得它真正切中的不是“有没有 tool calling”，而是：

控制权到底在代码手里，还是在模型手里。

这件事对工程师来说特别重要。因为很多团队在讨论 Agent 时，很容易把“LLM + Tool”直接等同于 Agent。可如果路径、步骤、工具顺序、异常分支都还是代码提前写死的，那它更像是一个带 LLM 节点的 workflow，而不是严格意义上的 agent。

我之所以特别在意这层区分，是因为它会直接影响后面的系统设计。

如果我把 workflow 错认成 agent，我就会误判系统复杂度来源；如果我把 agent 说成只是“更会调工具”，我又会低估状态管理、恢复机制和评测的难度。

所以我现在看一个系统是否真的“agentic”，首先不会问它有没有工具、有没有记忆、有没有 planner，而是先问：

• 谁决定下一步动作？
• 这个决策是预定义的，还是模型动态生成的？
• 模型的控制权有没有边界？

这也是我从这篇文章里拿到的第一把标尺。

三、为什么我觉得“先 workflow，再 agent”是全文最重要的结论#

如果让我只选一个最值得带进工程实践的结论，我会选这一句：

尽量先从最简单的 solution 开始，只有在确实需要时才增加 agentic complexity。

Anthropic 说得很克制。它并没有把 Agent 写成默认答案，反而不断强调：

• 很多任务根本不需要 agentic system
• 对很多应用来说，单次 LLM 调用加检索和 in-context examples 往往就够了
• 当复杂度值得增加时，workflow 往往比 agent 更可预测

我很认同这种立场，而且我越做工程越觉得它重要。

因为在实际项目里，复杂度通常不是以“模式名”的形式出现，而是以这些成本的形式出现：

• 更长的时延
• 更高的 token 成本
• 更多的状态中间产物
• 更难定位的问题来源
• 更高的错误复合概率

当 Anthropic 说 workflow 更适合 well-defined tasks 时，我脑子里想到的不是一个抽象定义，而是大量熟悉的系统问题：固定结构的 ETL、可枚举分支的审批链路、明确输入输出的处理流程。这些东西完全可以通过更透明的 workflow 做得很稳。如果我为了“更像 Agent”而把它们交给模型动态决策，本质上是在主动放大不确定性。

我读到这里时，一个很强烈的自我提醒是：

我做系统时，要时刻警惕把“自由度”误判成“能力”。

Anthropic 这篇文章给我的一个收获，就是它帮我把这个提醒说得很明确。它不是反对 Agent，而是反对没有被证明必要性的 Agent。

四、我怎么理解它列出来的五种 workflow 模式#

Anthropic 把常见 agentic systems 里的 composable pattern 总结成几种典型模式。我读这一段时，没有把它当“知识点目录”来背，而是把每一种模式都当成一个工程问题的默认答案。

4.1 Prompt chaining：我把它看成“线性拆解”#

Anthropic 说 prompt chaining 适合那些可以被干净拆成固定子步骤的任务，核心价值是用更高时延换更高准确率。

我对这个模式的理解是：它最适合处理“单次调用太重，但步骤关系仍然清晰”的问题。

比如：

• 先出大纲，再检验大纲，再写正文
• 先抽取结构化字段，再生成结论
• 先做初筛，再做精修

我对 prompt chaining 的个人判断一直比较务实。它不是多智能，但很实用。因为它保留了两个工程上非常关键的优势：

1. 路径仍然是可解释的
2. 每一步都可以插校验点

这一点我特别喜欢。很多时候，我不需要模型“自己想下一步干什么”，我只是需要它不要一次承担太多认知负担。把大任务拆成几个更小、更单纯的子任务，本质上是在给模型减压，也是在给系统加可观测性。

所以如果我手里的任务可以被线性拆解，我通常会先想到 prompt chaining，而不是立刻上 agent loop。这样做的收益很现实：调试成本更低，失败定位更快，质量波动也更小。

4.2 Routing：我把它看成“入口分流”#

Routing 在 Anthropic 的表述里很清楚：先分类输入，再把它送到更适合的后续流程。

我读这一段时最直接的联想不是 Agent，而是后端系统里的流量分发和领域分流。

比如一个支持场景里：

• 一般咨询
• 退款请求
• 技术排障

这三类问题虽然都叫“客服请求”，但后续链路完全不同。用一个大 prompt 硬吃所有情况，往往会把系统做得又贵又混乱。Routing 的价值就是先把不同问题分开，再让各自的 prompt、tool 和 policy 各司其职。

我对 routing 很看重，是因为它常常是“系统开始规模化”之后最容易带来收益的一层结构。尤其当输入类型之间差异足够大时，routing 往往比继续堆大 prompt 更有效。

但我也会提醒自己一个边界：routing 成立的前提是分类本身要足够稳定。如果分类准确率不高，后面所有专门化优化都会被入口错误拖垮。所以我会把 routing 看成一种很值钱的模式，但前提是“分类是可靠的”。

4.3 Parallelization：我把它看成“把复杂性拆开处理”#

Anthropic 把 parallelization 分成两类：

• sectioning：独立子任务并行
• voting：同任务多次执行后聚合

这段我非常认同，因为它触碰到一个我在做系统时很喜欢的原则：

当一个问题包含多个彼此相对独立的考量维度时，不要强迫一次调用同时兼顾所有维度。

这在 guardrails、evals、代码审查这类任务里特别明显。让同一次 LLM 调用既负责回答主问题，又负责检查安全性、格式、合规性和风险，经常不如拆成多个并行视角再汇总。Anthropic 也举了类似例子，比如一个模型处理用户问题，另一个模型专门负责内容筛查。

我从这一段得到的收获，不是“并行很高级”，而是“复杂考虑项最好拆开”。这和我写后端系统时的思路很像。多个目标混在一起处理，经常会让每个目标都做不好；把目标拆开，各自专注，最后再聚合，通常更稳。

当然，parallelization 的代价也很清楚：成本和延迟会一起涨。如果没有真正独立的维度，或者聚合逻辑本身不可靠，并行化就可能只是把复杂度翻倍。所以我会把它理解成一个非常强的模式，但必须建立在任务可拆和收益明确的前提上。

4.4 Orchestrator-workers：我把它看成“动态拆任务”#

这一段是我觉得最容易被误读成“多 Agent 很高级”的地方。

Anthropic 说 orchestrator-workers 适合那些子任务无法预先枚举的复杂任务，例如 coding products 需要改多少文件、改哪些文件，要看输入任务本身。

我特别喜欢它和 parallelization 的区别描述。两者从拓扑上看可能很像，但本质差异在于：

• parallelization：子任务是预定义的
• orchestrator-workers：子任务是动态决定的

这条区分对我非常重要。它让我更愿意把 orchestrator-workers 看成“动态任务分解器”，而不是笼统的“多 Agent 架构”。

我对这个模式的感受也比较复杂。一方面，它确实很适合代码修改、复杂检索、跨多源分析这种任务；另一方面，它也极容易失控。因为一旦任务拆分是动态的，系统复杂度的核心来源就不再只是调用模型，而是：

• 子任务怎么生成；
• 子任务边界是否清楚；
• worker 的产出怎么汇总；
• orchestrator 怎么判断还需不需要继续拆；
• 什么时候停。

所以我读这一段时，最大的共鸣不是“这很强”，而是“这很贵”。它很值钱，但它不是默认答案。只有当任务真的复杂到预定义子任务不现实，而且任务收益足够高时，我才会认真考虑这种模式。

4.5 Evaluator-optimizer：我把它看成“显式迭代”#

Anthropic 把 evaluator-optimizer 定义成：一个 LLM 负责生成，另一个负责评价与反馈，形成一个循环。

我很喜欢这个模式，因为它其实把很多人在项目里模糊做的事情显式化了。

很多时候，我们说“让模型再优化一次”“再想一遍”“再改一下”，但这些话如果没有明确评价标准，其实很容易退化成无意义的多轮消耗。Anthropic 这里给了一个很重要的适用条件：要有清晰的评估标准，而且迭代优化必须能带来可衡量收益。

我对这个模式最大的工程感受是：它不是为了让系统更像人在反思，而是为了让“改进”这件事变成一条显式链路。

这件事对我很有启发。因为它提醒我，凡是想要做 evaluator-optimizer 的地方，我都必须先回答：

• evaluator 依据什么打分；
• feedback 如何组织；
• 什么时候停止；
• 多一轮优化带来的收益是否大于成本。

如果这些问题说不清，我宁愿少做一层循环。因为没有明确评价标准的迭代，通常只会把成本和随机性一起抬高。

五、Anthropic 说到 Agents 本体时，我最在意什么#

这篇文章真正进入 Agents 一节后，我反而会放慢速度读，因为这里最容易被兴奋情绪带偏。

Anthropic 对 agent 的描述我会总结成四个关键点：

1. 任务清楚后，agent 可以独立规划和执行；
2. 每一步必须从环境拿到 ground truth；
3. 需要 checkpoints、blockers 处理和 stopping conditions；
4. 代理本质上仍然只是“使用工具并根据环境反馈循环的 LLM”。

我最在意的是第二点和第三点。

5.1 Ground truth 比“更强的推理”重要#

Anthropic 明确强调，agent 在执行过程中必须不断从环境拿到 ground truth，比如工具结果、代码执行结果、测试结果。这句话我觉得特别重要，因为它把 agent 的可靠性锚定在了环境反馈上，而不是锚定在“模型多想了几步”上。

这跟我自己的工程直觉非常一致。做系统时，真正能降低风险的，通常不是让模型多猜，而是让系统更早、更频繁地接触可验证反馈。

比如 coding agent 之所以有价值，很大原因不是“它会写代码”，而是它写完之后能跑测试、看错误、再调整。这个闭环里最值钱的不是推理本身，而是测试结果提供的外部真值。

我读到这里时，对自己的一个提醒是：以后只要做 agent loop，我都应该优先去找环境反馈点，而不是优先去想怎么让 prompt 更长。

5.2 停止条件和 checkpoints 是“控制权回收机制”#

Anthropic 提到 stopping conditions，我觉得这不是一个小细节，而是 agent 系统里非常关键的控制机制。

因为一旦 LLM 动态控制流程，系统最危险的事情之一就是它一直继续。继续检索、继续尝试、继续调用工具、继续修正，看起来都像是在努力工作，但工程上它已经开始越过成本边界和稳定性边界。

所以我很喜欢把 stopping conditions 理解成“控制权回收机制”。系统在必要的时候把主导权收回来，强制结束、强制确认或者强制交给人类决策。

我之所以特别强调这一点，是因为很多人谈 Agent 时更关注 autonomy，却很少谈“如何让 autonomy 及时停下”。而在我看来，后者才是系统能不能进生产的关键条件之一。

六、为什么我觉得 Appendix 2 其实是全文最值钱的部分之一#

很多人读 Building Effective Agents，主文看完就走了。但我自己会特别认真看 Appendix 2，也就是 Prompt engineering your tools。

原因很简单：这里其实暴露了 Anthropic 在真实工程里最朴素也最有杀伤力的经验。

它反复强调几件事：

• 工具定义要像写给初级工程师看的 docstring 一样清楚；
• 参数命名和描述要降低误用概率；
• 工具格式要贴近模型自然见过的文本分布；
• 要尽量减少格式负担；
• 要大量测试模型如何真实使用这些工具；
• 要像做 HCI 一样认真做 ACI。

我读到这里时最大的感受是，Anthropic 其实在说一件很“反魔法”的事情：

Agent 不是先靠抽象框架变强，而是先靠接口设计变稳。

这和我自己的很多实践感受完全一致。系统里最容易被低估的，往往不是模型，而是接口。工具名是不是清楚，参数是不是容易误解，返回结构是不是稳定，危险操作是不是可确认，这些决定了模型是在一个清晰动作空间里工作，还是在一个模糊动作空间里乱撞。

Anthropic 提到他们在 SWE-bench agent 里花在工具优化上的时间比花在总 prompt 上还多，我一点也不意外。甚至我觉得这应该成为很多 Agent 项目的默认预期：当系统从 demo 走向工程，tool design 往往比继续打磨总 prompt 更值钱。

这一段对我自己的收获非常直接。它让我更坚定地把 tool registry、tool schema、tool description、tool safety 和 tool eval 放在核心位置，而不是把它们当作“实现细节”。

七、我从这篇文章里提炼出的三条方法论#

如果我不复述模式，只把这篇文章留下来的工程方法论压成三条，我会留下这三句。

7.1 先证明简单方案不够，再增加复杂度#

这是我觉得最重要的一条。

Anthropic 整篇文章都在反复强调：从简单开始，只有当更复杂的结构被证明有收益时，才增加复杂度。

我把这条原则拿回自己的系统里，会自然变成一些很具体的提问：

• 单次调用真的不够吗？
• 能不能先用 workflow？
• 当前问题是灵活性不够，还是只是 prompt 不够清晰？
• 我加这一层 agentic behavior，到底解决了什么问题？

它带给我的收获，是我在架构演进上会更克制，也更有证据意识。

7.2 Agent 的复杂度核心来自状态，而不是 prompt#

如果只看表面，很多人会以为 Agent 难是因为 prompt 难。但我自己读完整篇文章后更确定一件事：agent 复杂度的真正来源，是状态。

因为一旦进入多轮执行，系统要管理的东西会迅速膨胀：

• 当前进展
• 工具结果
• 中间产物
• 下一步计划
• 失败原因
• 是否重试
• 是否停止

我从这篇文章里得到的收获之一，就是以后再看一个 Agent 系统，我不会先去看 prompt 多长，而会先去看它的状态机是不是清楚。

7.3 工具接口是 Agent 的地基#

这条其实是我最想拿去反复讲的一条。

Anthropic 讲 workflow、agent、pattern，最后都落回到了工具接口和环境反馈上。这对我来说特别有说服力。因为它说明真正能决定系统能不能稳定工作的，不只是模型，而是模型与环境接触的方式。

这条判断也会直接影响我后面的工程取舍：如果工具接口还很粗糙，我不会急着上更复杂的 agent pattern。因为地基没打好，往上加结构只会放大噪声。

八、我会怎么把这篇文章映射回自己的 Agent 项目#

对我来说，精读的意义不是“读完”，而是“映射回手上的系统”。如果我把这篇文章映射到自己的项目里，我通常会问自己这些问题：

8.1 哪些地方应该退化成 workflow#

这是我读完之后最先会反思的问题。

很多系统里被叫做“Agent”的模块，其实只是路径没写清楚、边界没收住。Anthropic 的文章会逼我把这些东西重新拆一遍：到底哪些步骤是固定的，哪些步骤真需要模型动态决定。

8.2 哪些复杂度是真有价值的#

我会用这篇文章去过滤掉一些“听起来很酷”的结构。

比如：

• 我是不是其实不需要多 Agent，只需要 routing + prompt chaining；
• 我是不是不需要 agent loop，只需要 evaluator-optimizer；
• 我是不是先把 tools 做对，比继续上 planner 更重要。

8.3 我有没有足够好的 environment feedback#

只要某个 agent loop 没有稳定真值反馈，我现在就会天然更警惕。因为 Anthropic 这篇文章很明确地让我意识到，没有 ground truth 的 agent autonomy 很容易变成带着自信的漂移。

8.4 我有没有真正做好 ACI#

这一点我现在会特别主动检查：

• 工具名清不清楚；
• description 有没有歧义；
• 参数是不是容易误填；
• 返回结果对模型是不是足够友好；
• 危险工具是不是有确认和限制。

这类检查以前我可能会放在实现后面，现在我会更早做。

九、结语：我为什么觉得这篇文章值得反复读#

Building Effective Agents 最打动我的地方，不是它列出了多少模式，而是它始终站在一个非常工程化的位置上说话。

它没有把 Agent 讲成一个更浪漫的未来，也没有鼓励大家尽快把系统做得更自治。相反，它不断提醒我：

• 简单比复杂更值钱；
• 可控比炫技更重要；
• 透明性不是附属品，而是系统能力的一部分；
• 工具接口和环境反馈，很多时候比“更强模型”更早决定上限。

我很喜欢这种克制。因为它让我在追前沿的时候，不会只被“新模式”吸引，而会更在意：这个模式到底解决了什么生产问题，它带来的复杂度值不值得。

如果要把这篇文章留成一句我会长期带着走的提醒，那大概就是：

我做 Agent 时，不应该先问“怎样更像 Agent”，而应该先问“怎样更可靠地完成任务”。

这也是为什么我觉得，这篇文章虽然不是论文，但非常值得精读。它真正给我的，不是一个新名词表，而是一套更稳的工程判断方式。

对我自己来说，这种收获不是停留在阅读感受上的。它会直接反过来影响我后面做系统时的优先级排序。我会更早检查 workflow 能不能先顶住，更早检查 tool schema 和 tool feedback 是否足够清楚，更早给 loop 设计 stopping conditions，也更早把“这层复杂度到底换来了什么”拿出来问自己。换句话说，我读这篇文章最大的价值，不是学会了几个 pattern，而是把自己的 Agent 工程直觉重新校准了一次。

参考#

1. Anthropic, Building Effective Agents
2. Anthropic, Writing Effective Tools for Agents
3. OpenAI, Agents SDK Documentation