【系统学AI】论文导读 ③：Building Effective Agents——Anthropic 的 Agent 设计圣经
本文是「AI 学习计划」系列第 29 篇，模块 07 论文导读第 3 篇。
这不是一篇学术论文，而是 Anthropic 2024 年 12 月发布的工程指南——但它对 Agent 工业实践的影响，超过了大多数学术论文。
基本信息
| 项 | 内容 |
|---|---|
| 标题 | Building Effective Agents |
| 作者 | Erik Schluntz, Barry Zhang（Anthropic Applied AI Team） |
| 发表 | 2024.12.19（Anthropic Research Blog） |
| 类型 | 工程指南/最佳实践（非学术论文） |
| 链接 | https://www.anthropic.com/research/building-effective-agents |
| 影响 | 被 LangChain、CrewAI、Dify、Coze 等所有 Agent 框架引用为设计参考 |
一句话总结
Agent ≠ 复杂框架。大多数场景用"增强型 LLM + 简单工作流"就够了。只有当任务需要模型自主决策执行路径时，才需要真正的自主 Agent。Anthropic 定义了 5+1 种 Agent 设计模式，从简到繁递进选择。
核心观点一：Agent 的定义要"窄"不要"宽"
Anthropic 首先做了一个关键区分：
| 概念 | 定义 | 控制流 |
|---|---|---|
| Workflow（工作流） | 预定义路径的 LLM 编排系统 | 代码控制（deterministic） |
| Agent（自主智能体） | LLM 自己决定做什么、做几步 | LLM 控制（dynamic） |
💡核心原则：不要一上来就用 Agent。先试 Workflow，不够再升级。
核心观点二：6 种设计模式（从简到繁）
模式 1：Augmented LLM（增强型 LLM）
用户 → LLM + [检索] + [工具] + [记忆] → 输出- 不是 Agent，就是一个带工具的 LLM
- 适合 80% 的场景
- 例子：ChatGPT + 搜索 + 代码执行
模式 2：Prompt Chaining（提示链）
输入 → LLM₁ → Gate → LLM₂ → Gate → LLM₃ → 输出- 把复杂任务分成多步，每步一个 LLM 调用
- 中间有 Gate（检查点）：如果上一步结果不合格就回退
- 适合：文档生成（先写大纲→再写正文→再校验）
模式 3：Routing（路由分发）
输入 → [分类器/LLM] → 路由 A（简单问题→小模型） → 路由 B（复杂问题→大模型） → 路由 C（专业问题→专用工具）- 一个"调度员"决定把任务分给谁
- 适合：客服系统（判断是退货？投诉？咨询？→分别处理）
模式 4：Parallelization（并行化）
输入 → [拆分] → LLM₁ ─┐ → LLM₂ ─┼→ [聚合] → 输出 → LLM₃ ─┘两种子模式：
- Sectioning：大任务拆成独立子任务并行处理
- Voting：同一任务跑多次取多数/最优结果
适合：代码审查（安全/性能/风格并行检查）、内容审核
模式 5：Orchestrator-Workers（编排-工作者）
用户 → Orchestrator LLM → 动态分配子任务 → Worker₁ → Worker₂ → Worker₃ ← 收集结果 ← ←←←←←←- Orchestrator 根据情况动态决定需要几个 Worker、做什么
- 和 Parallelization 的区别：并行是预定义的，编排是动态的
- 适合：复杂编程任务（先分析→决定改几个文件→分别改→测试）
模式 6：Autonomous Agent（自主 Agent）
用户目标 → Agent Loop: → Think（推理下一步） → Act（调用工具/执行动作） → Observe（获取结果） → Think（是否完成？需要调整？） → ... 循环直到完成或放弃- LLM 自主决定做什么、做几步、何时停止
- 人类只提供目标+工具，不规定路径
- 适合：开放性任务（“帮我研究 X 并写报告”）、Computer Use
- 风险最高：复合错误、无限循环、过度消耗
核心观点三：何时用哪种模式？
Anthropic 给出了一个选型决策框架：
你的任务需要模型自主决定路径吗？ ├─ 不需要（路径固定）→ Prompt Chaining / Routing / Parallelization └─ 需要 → 你能容忍不确定性和更高成本吗？ ├─ 能 → Autonomous Agent └─ 不能 → Orchestrator-Workers（有限自主）关键建议：
❗ 「在 agentic 系统中，用更简单的方案往往比用复杂框架效果更好。关键不是框架有多强大，而是你的 prompt、工具描述、和约束条件设计得多好。」
核心观点四：让 Agent 可靠的 3 个工程原则
原则 1：工具设计 > Agent 设计
「Agent 的好坏取决于工具的好坏。花在工具文档上的时间，比花在 Agent 框架上的时间回报更高。」
好的工具设计：
- 名字要清晰（
get_weather_forecast而不是tool_7） - 参数要有类型和说明
- 错误信息要对 LLM 友好（不是 stack trace，而是"找不到该城市"）
- 功能要原子化（一个工具做一件事）
原则 2：保持简单，抵抗抽象
「不要因为框架提供了复杂能力就使用它。我们见过最好的 Agent，大多建立在简单的循环+清晰的 prompt 之上。」
原则 3：错误处理决定可靠性
Agent 会出错，关键是出错后能否恢复：
- 每步都有checkpoint（可以回退）
- 关键操作前要confirmation（人在环里）
- 长期运行要有timeout + 优雅退出
- 日志要让人能debug（每步的 Thought 是关键）
核心观点五：Computer Use——第 6 种模式
2024.10 Anthropic 发布 Claude Computer Use，这是一种新的 Agent 模式：
用户目标 → Agent 循环: → 看屏幕截图（视觉输入） → 思考下一步操作 → 执行操作（点击/输入/滚动） → 再看屏幕截图 → ... 循环与传统 Agent 的区别：
- 工具不是 API，而是屏幕本身
- 观察不是文本，而是截图
- 动作不是 JSON，而是鼠标/键盘操作
适合：测试自动化、遗留系统操作、任何没有 API 的操作
核心观点六：失败模式与避坑
Anthropic 总结了 Agent 系统最常见的失败原因：
| 失败模式 | 原因 | 解法 |
|---|---|---|
| 无限循环 | Agent 陷入重复动作 | 设置 max_steps + 检测重复 |
| 过度自信 | Agent 不说"我不知道" | 在 prompt 里明确允许说"不确定" |
| 工具滥用 | 不该用工具的时候用了 | 工具描述里写清"何时不该用" |
| 目标偏移 | 做着做着偏离了原始目标 | 每 N 步回顾原始目标 |
| 错误复合 | 前面错了→后面全错 | Checkpoint + 回退机制 |
为什么这篇指南如此重要？
- 统一了 Agent 的分类语言：所有后续讨论都用这 5+1 种模式作为共同词汇
- "先简后繁"的哲学：对抗了行业"什么都用 Agent"的过度宣传
- 工具设计 > 框架选型：把注意力拉回到最基本的工程质量上
- 来自实战而非理论：Anthropic 内部大量 Claude 应用的经验总结
- 定义了 Computer Use 的范式：打开了 Agent 的操作空间
和前两篇论文的关系
Transformer (2017) → LLM 的"引擎" ReAct (2022) → Agent 的"思考-行动循环" DPO (2023) → 让 Agent 说话"像人" GraphRAG (2024) → 让 Agent "找到好信息" Building Agents (2024) → 把以上所有组装成"工业级 Agent 系统"的方法论这篇指南是"集大成者"——不是发明新东西，而是告诉你如何把所有组件组装好。
读这篇文章的正确姿势
- 先看开头的定义区分（Workflow vs Agent）——这决定了你后面的选型
- 对照自己的项目，看 6 种模式中哪个最适合
- 重点看"工具设计"那一节——这是最容易被忽略但影响最大的
- 把 Computer Use 当新范式理解——不只是一个 feature
- 收藏为 Agent 项目的"设计规范文档"——每次开始新项目前翻一遍
📚 延伸阅读
- Anthropic 原文 — 必读原文
- Claude Computer Use 文档 — 实操指南
- LangGraph 文档 — 用代码实现这 6 种模式
- OpenAI Agents SDK — OpenAI 的 Agent 实现
- Anthropic Agent SDK (Claude Code) — Anthropic 自己的实现
路易乔布斯 © 2026｜ 「AI 学习计划」系列第 29 篇 ｜ 模块 07 论文导读 3/3