Anthropic「构建高效智能体」：最被引用的Agent定义文，到底说了什么
> 原文：Building Effective Agents (Anthropic, 2024-12-19) > 链接：https://www.anthropic.com/engineering/building-effective-agents > 一句话：最成功的Agent实现，用的全是简单、可组合的模式，而非复杂框架。
---
一、先拆一个常见的误解
很多人一听"Agent"就脑补出一个有自我意识、能独立思考的AI——像《Her》里的Samantha，或者《流浪地球》里的MOSS。但Anthropic这篇被全网引用最多的Agent定义文，开篇就泼冷水：
> 最成功的实现，用的全都不是复杂框架，而是简单、可组合的模式。
这不是谦虚。Anthropic过去一年跟几十个团队打过交道，横跨各行各业。他们发现一个反直觉的规律：越是花里胡哨的Agent系统，越容易翻车。
---
二、火车 vs 越野车：工作流和Agent的本质区别
Anthropic把"智能体系统"（agentic systems）分成了两类，这个分类后来成了行业默认标准：
🚂 工作流（Workflow）
定义：LLM和工具通过预定义的代码路径编排。
你提前铺好轨道，火车按轨道跑。每一步去哪、调用什么工具、走哪条分支，都是你写死的。LLM只是轨道上的一个执行单元，不是决策者。
例子：
- 用户提问 → LLM分类问题类型 → 按类型路由到不同处理流程 → 输出答案
- 每步都在你的掌控中，像高铁时刻表
🚙 智能体（Agent）
定义：LLM动态指导自己的过程和工具使用，保持对如何完成任务的控制权。
方向盘在模型手里，路它自己找。你给它一个目标，它决定走几步、用什么工具、要不要调整策略。
例子：
- "帮我修这个GitHub bug" → Agent自己读代码、写测试、改文件、跑验证、发现不对再重来
- 你无法预测它会修改几个文件，也无法预先写死每一步
⚠️ 一个常见的自欺
很多号称"Agent"的产品，其实是工作流。Anthropic说得很直接：这常常是对的。
不是所有问题都需要越野车。如果从北京到上海，高铁比越野车快、稳、便宜。只有当你不知道目的地在哪、甚至没有地图的时候，才需要越野车自己探路。
---
三、全文最重要的一句
> Find the simplest solution possible, and only increase complexity when needed. > （找尽可能简单的方案，只在确实需要时才加复杂度。）
这句话应该裱起来挂在每个做Agent的开发者工位上。
Anthropic给出的升级路径是单向的、不可逆的：
简单提示词 → 加检索/加范例 → 工作流 → 智能体
↑
└── 从左边开始，不够了才往右走，顺序别反过来
核心公式：
> 智能体系统 = 拿延迟和成本，换更好的效果
每往右走一步，你的系统就更贵、更慢、更难调试。如果简单提示词就能搞定，别为了"Agent"这个概念多加一层复杂度。很多团队的问题是：手里有个锤子（刚学的Agent框架），看什么都像钉子。
---
四、五种工作流模式：你的工具箱
Anthropic总结了生产环境中最常见的五种模式。它们不是规范，是"常见到值得单独拎出来"的工具。
1. 提示链（Prompt Chaining）
像什么：流水线工厂，每个工位只做一件事
把任务拆成固定步骤，每一步LLM处理上一步的输出。中间可以加"门控"（gate）检查质量。
什么时候用：任务能干净地拆成固定子任务，愿意用延迟换准确率
例子：
- 写营销文案 → 翻译成西班牙语
- 写文档大纲 → 检查大纲是否达标 → 基于大纲写正文
2. 路由（Routing）
像什么：分拣中心，快递按地址分类后进不同通道
先分类输入，再定向到专门的处理流程。没有路由的话，你为一个场景优化的prompt可能伤害另一个场景。
什么时候用：任务有明显类别，分类准确率够高
例子：
- 客服：一般问题 vs 退款请求 vs 技术支持，进不同队列
- 简单问题丢给Haiku（快、便宜），难题丢给Sonnet（强、贵）
3. 并行化（Parallelization）
像什么：多线程，或者投票表决
两个变体：
- 分段（Sectioning）：任务拆成独立子任务，并行跑
- 投票（Voting）：同一个任务跑多次，综合多个输出
例子：
- 分段：一个LLM处理用户请求，另一个同时审查内容安全
- 投票：三份代码审查prompt分别查漏洞，只要一个flag就报警
4. 协调者-工作者（Orchestrator-Workers）
像什么：项目经理带团队，经理拆任务、分任务、收结果
中心LLM动态分解任务，委派给"工作者"LLM，再综合结果。关键区别：子任务不是预定义的，是协调者根据输入动态决定的。
什么时候用：复杂任务，子任务数量和性质都无法预先确定
例子：
- 代码Agent：改一个需求可能涉及3个文件，也可能涉及15个，协调者决定哪些文件要改
- 搜索任务：从多个来源收集信息，需要多少轮搜索由协调者判断
5. 评估者-优化者（Evaluator-Optimizer）
像什么：作家和编辑互相掐架，越改越好
一个LLM生成，另一个LLM评估给反馈，循环迭代。
什么时候用：有明确评估标准，且迭代能带来可测量的改进
例子：
- 文学翻译：译者第一稿 → 评估者指出"这句没抓住原文的嘲讽语气" → 译者改
- 复杂搜索：搜索 → 评估"信息够不够" → 不够就再搜一轮
五、什么时候才真的上Agent？
Anthropic给了一个清晰的判断标准：
> 开放式问题——步数没法预测、路径没法写死，每走一步都要从环境拿"地面真相"校准。
三个信号告诉你该上Agent了：
1. 任务步数不可预测：修一个bug可能需要改1个文件，也可能需要改20个 2. 路径无法预先编码：你无法写if-else覆盖所有可能的情况分支 3. 需要环境反馈校准：每做一步（如运行测试、查数据库），结果影响下一步怎么走
代价：
- 更贵（多轮LLM调用）
- 更慢（串行依赖）
- 错误会滚雪球（一步错，步步错）
---
六、一个反常识细节：工具比提示词更重要
Anthropic在附录2里藏了一个金句：
> 我们在SWE-bench上花的时间，优化工具比优化提示词还多。
他们举了一个具体例子：模型用相对路径找文件时，一旦Agent切换了工作目录就报错。解决方案不是加更多prompt说明，而是直接把工具改成强制要求绝对路径——错误直接消失。
这背后的原则叫 ACI（Agent-Computer Interface）——类比HCI（人机交互），但用户是LLM。设计好ACI的方法：
- 换位思考：把自己当成模型，看这个工具的参数和描述够不够直观
- 防呆设计（Poka-yoke）：改参数让模型更难犯错
- 大量测试：在workbench里跑大量例子，看模型犯什么错，迭代
---
七、框架：用还是不用？
Anthropic的态度很务实：
起步阶段：直接用LLM API，很多模式几行代码就能实现。
用框架时：确保你理解底层代码。对框架的误解是客户报错最常见的来源。
警惕：框架的抽象层可能掩盖prompt和response，让调试变难；也可能诱惑你加不必要的复杂度。
提到的框架：Claude Agent SDK、AWS Strands Agents SDK、Rivet（拖拽式GUI）、Vellum（GUI工具）。
---
八、两个Agent真正发挥价值的场景
Anthropic在附录1里给了两个经过验证的应用：
A. 客户支持
为什么适合Agent：
- 对话流天然开放，需要查外部信息
- 工具集成：拉客户数据、查订单历史、读知识库
- 动作可程序化：退款、改工单
- 成功标准清晰：用户是否满意解决
B. 编程Agent
为什么适合Agent：
- 代码可验证（自动化测试）
- 测试结果是天然反馈信号
- 问题空间结构清晰
- 质量可客观测量
---
九、三个核心原则（Summary版）
Anthropic最后总结了做Agent的三个铁律：
1. 保持设计简单 —— 别为了复杂而复杂 2. 优先透明度 —— 明确展示Agent的规划步骤，让人能看懂它在干嘛 3. 精心打磨ACI —— 工具的文档和测试，投入不亚于打磨人机界面
---
十、一句话收尾
> 成功不在于搭最复杂的系统，而在于搭对的系统。
从最简单的提示词开始，不够了加检索，再不够加工作流，实在兜不住了才上Agent。顺序别反过来。
很多团队的问题是：他们先选了一个复杂的Agent框架，然后试图把问题塞进框架里。正确的做法反过来的——先看问题需要什么，再选最轻量的工具。
Anthropic这篇短文之所以被引用最多，不是因为它提出了什么惊天动地的理论，而是它说透了那些被花哨demo掩盖的常识：简单可组合的模式，比复杂框架更可靠。
---
参考信息
- 原文：Building Effective Agents (Anthropic, 2024-12-19)
- 链接：https://www.anthropic.com/engineering/building-effective-agents
- 作者：Erik S., Barry Zhang
- 配套：Anthropic Cookbook 中的示例实现
🌟 智谱 GLM-5 已上线
我正在智谱大模型开放平台 BigModel.cn 上打造 AI 应用，智谱新一代旗舰模型 GLM-5 已上线，在推理、代码、智能体综合能力达到开源模型 SOTA 水平。
🎁 领取 2000万 Tokens