Building Effective Agents
Anthropic 官方技术博客（2024 年 12 月 19 日发布），基于与数十个团队跨行业构建 LLM Agent 的第一手经验总结。这不是一篇 API 文档，而是一套设计哲学 + 实操指南。全文反复强调的核心信息只有一个：从最简单的东西开始，只在确实需要时才加复杂度。
一句话摘要
最成功的 Agent 实现使用的不是复杂框架或专用库，而是简单、可组合的模式。从增强版 LLM（LLM + 检索 + 工具 + 记忆）出发，先穷尽单次调用的优化空间，仅在简单方案不够时才引入多步 Agent 系统。
核心概念：Workflow 与 Agent 的本质区别
Anthropic 把所有涉及 LLM 的系统统称为 agentic systems，但在架构层面做了关键区分：
| Workflow（工作流） | Agent（智能体） | |
|---|---|---|
| 控制方式 | LLM 和工具按预设代码路径编排 | LLM 动态指导自身流程和工具使用 |
| 适用场景 | 步骤可预测的任务 | 开放性问题，无法预知需要多少步 |
| 特点 | 延迟和成本可控，路径确定 | 灵活但需要信任模型判断 |
| 本质 | 人在设计流程，LLM 在流程里干活 | LLM 在设计流程 |
这个区分对实际工程决策至关重要。很多团队一上来就选 Agent 方案，但后来发现绝大多数业务场景用 Workflow 就够了，Agent 的灵活性反而带来了不可预测的延迟和成本。
“增强版 LLM”：Agent 的基本构建块
在讨论 Workflow 和 Agent 之前，Anthropic 引入了一个更基础的概念：Augmented LLM（增强版 LLM）。
增强版 LLM = LLM + 检索 + 工具 + 记忆
这四个组件是 Agent 的基本”积木”：
- 检索（Retrieval）：往上下文里注入相关信息，RAG 是最常见形式
- 工具（Tools）：让模型能调用外部服务——搜索 API、数据库查询、代码执行等
- 记忆（Memory）：跨轮次保存状态，可以是短期（对话历史）或长期（向量数据库）
Anthropic 的建议是：先从增强版 LLM 开始，调好这个基础层，再往上叠 Workflow 或 Agent 逻辑。 很多问题其实在增强版 LLM 这层就已经被解决了，不需要更复杂的编排。
五种 Workflow 模式（按复杂度递增）
1. Prompt Chaining（提示词链）
最简单的工作流模式——A 的输出成为 B 的输入。适合可以分解为固定子任务的场景：先翻译再润色、先大纲再正文、先检索再总结。
关键优势：每一步可独立评估和缓存。 如果上游没变，下游不需要重新跑。而且可以在任意一步插入人工审核（gate）。
2. Routing（路由）
一个分类器 LLM 先把输入分到不同的处理通道。适合不同输入需要不同处理策略的场景：客服问题路由到不同部门、用户意图分到不同的模型。
关键优势：专业化。 通用模型处理所有问题不如专门优化过的分支效果好，而且每个分支的提示词可以针对该类型输入单独优化。
3. Parallelization（并行化）
两个维度：
- 分片（Sectioning）：一个任务拆成多个独立子任务同时跑（如同时检索多路数据源）
- 投票（Voting）：同一个任务跑多次，取多数结果（如检测不当内容——多次判断取多数）
关键优势：速度（分片）和可信度（投票）。
4. Orchestrator-Workers（编排-工作者）
一个中枢 LLM 动态分解任务、分发给多个 worker LLM 执行、汇总结果。适合无法预先知道所有子任务是什么的复杂场景——比如”帮我迁移这个代码库”。
中枢不是硬编码的分发逻辑，而是 LLM 自己判断”这个任务需要拆成哪些子任务、交给谁做”。每个 worker 只拿到自己需要的那段上下文。
5. Evaluator-Optimizer（评估-优化）
一个 LLM 产出初稿，另一个 LLM 评估质量并给出改进建议，循环直到满意。适合有明确评估标准但生成方案需要迭代优化的任务：文案润色、代码 review、翻译校对。
关键洞察：评估比生成容易。 让一个模型判断”这个好不好”比让它一次生成完美的结果更可靠。这与 Harness工程 中”多轮迭代优于一步到位”的哲学一致。
什么时候用 Agent，什么时候不用
Anthropic 给出了明确的工作量递增路径：
增强版 LLM（单次调用）
→ 不够？加 Prompt Chaining
→ 还不够？加 Routing / Parallelization
→ 还是不够？考虑 Orchestrator-Workers
→ 最后最后：Autonomous Agent
每条线都”不够”的评判标准应该是基准测试结果，不是直觉。 如果你没做过基准测试就跳过增强版 LLM 直接上 Orchestrator，就是在没有数据支撑的情况下增加了复杂性。
三个核心原则
1. 保持设计简洁（Keep your design simple）
“在 LLM 领域成功的关键不是构建最复杂的系统，而是为你的需求构建合适的系统。“——Antropic 原文
复杂系统的问题不在于”复杂”本身，而在于每个额外的组件都是新的故障点。每加一层路由、一个 worker、一轮评估循环，就多了一个可能出错的地方——而且排查成本随层级数指数增长。
2. 显式展示规划步骤（Make the planning steps transparent）
不要让 Agent 在内部悄悄规划——把规划步骤写在输出里。好处是：(a) 你可以看到模型在做什么决策 (b) 出问题时可以定位是规划错了还是执行错了 (c) 符合 上下文工程 中”可见即可控”的原则。
一个简单的做法是：在 system prompt 里要求模型先写 PLAN: 再执行，而不是默默决策。
3. 精心设计 ACI（Agent-Computer Interface）
ACI 指的是 Agent 和外部工具/计算机之间的接口契约。Anthropic 的实践团队发现：花在优化工具定义（tool definitions）上的时间，不少于花在优化系统提示词上的时间。
具体建议：
- 每个工具的描述要精确定义”这个工具做什么”以及”什么情况下用”
- 参数命名要足够自解释
- 工具数量越少越好——每个额外的工具都增加模型选错的风险
- 工具返回的错误信息要有可操作性（“X 失败了”没用，“X 失败了因为 Y，建议尝试 Z”有用）
与其他笔记概念的关联
这篇指南中提出的设计原则与 vault 中多个概念笔记高度重合：
- Harness工程：从”最小可行”出发、每次只加一个概念、可见即可控——Anthropic 的 “start simple, add complexity only when needed” 是同一哲学
- 上下文工程：ACI 的设计本质上是上下文工程——精确控制 Agent 看到的工具信息和错误反馈
- Agent：Anthropic 对 Workflow vs Agent 的区分直接定义了 vault 中 Agent 概念笔记的边界条件
- Agent Skill：增强版 LLM 的”工具”组件与 Skill 的渐进式暴露模型一一对应
- MCP 模型上下文协议：ACI 的实现层——MCP 就是 Anthropic 对”精心设计的 Agent-Computer 接口”给出的协议级答案
- pi-coding-agent：完美践行了”保持设计简洁”——4 个工具、<1000 tokens 的 system prompt，在简洁的赛道上跑赢了复杂方案
重要引用
“Success in the LLM space isn’t about building the most sophisticated system. It’s about building the right system for your needs.”
在 LLM 领域取得成功，关键不是造出最复杂的系统，而是造出适合你自己需求的系统。
“Start with simple prompts, optimize them with comprehensive evaluation, and add multi-step agentic systems only when simpler solutions fall short.”
从简单的提示词开始，用完善的评测去优化它；只有当简单方案确实不够用时，才去加多步智能体系统。
“We actually spent more time optimizing our tools than the overall prompt.”
我们花在优化工具上的时间，实际上比花在优化提示词上的时间还多。