Anthropic 构建有效 Agent 指南：第一性原理与工程实践

## 一、Anthropic 的核心洞察 过去一年，Anthropic 与数十个团队合作，帮助他们在不同行业构建 LLM Agent。他们发现一个反直觉的事实： **最成功的实现，不是依靠复杂的框架或专门的库，而是基于简单、可组合的模式。** 这篇文章总结了 Anthropic 在构建 Agent 过程中积累的方法论，以及给开发者的实用工程建议。 ## 二、第一性原理：Workflow vs Agent 在 Anthropic 的分类体系中，所有 LLM 增强系统都被称为 **agentic systems**，但有一个关键的架构区分： | 类型 | 定义 | 控制方式 | |------|------|---------| | **Workflow** | 通过**预定义的代码路径**编排 LLM 和工具 | 开发者控制流程 | | **Agent** | LLM **动态决定**自己的流程和工具使用 | 模型自主控制 | **核心原则：如无必要，不要构建 Agent/Workflow** Agentic 系统通常以延迟和成本换取更好的任务性能。在构建应用时，应该： 1. 寻找最简单的解决方案 2. 只有在必要时才增加复杂性 3. 优化单次 LLM 调用（RAG、in-context examples）通常已足够 ## 三、何时使用 Workflow 当任务可以明确定义、需要可预测性和一致性时，使用 Workflow。 ### 1. 提示链（Prompt Chaining） 将任务分解为顺序子任务，每个 LLM 调用处理前一个的输出。 ``` 输入 → [LLM 1] → 检查点 → [LLM 2] → 检查点 → [LLM 3] → 输出 ``` **适用场景：** 任务可以干净地分解为固定子任务，用延迟换取更高准确性。 **例子：** - 生成营销文案 → 翻译成不同语言 - 编写大纲 → 检查大纲 → 根据大纲写文档 ### 2. 路由（Routing） 对输入分类，转发到专门的后续任务。 ``` 输入 → [分类器] → 路径 A / 路径 B / 路径 C ``` **适用场景：** 复杂任务有明确类别，分开处理效果更好。 **例子：** - 客服：一般问题 → 退款请求 → 技术支持 - 大小模型路由：简单问题用 Haiku，困难问题用 Sonnet ### 3. 并行化（Parallelization） 多个任务同时进行，输出聚合处理。 **分段（Sectioning）：** MapReduce 模式，分解为独立子任务并行运行。 **投票（Voting）：** 相同任务并行执行多次，获得多样化输出。 **适用场景：** 需要加速完成，或需要多视角对比取最优结果。 **例子：** - 分段：一个模型处理查询，另一个筛选不当内容 - 投票：多个提示审查代码漏洞，多个评估判断内容是否恰当 ### 4. 编排者-工作者（Orchestrator-Workers） 中心 LLM 动态分解任务，委托给 worker LLM，汇总结果。 **适用场景：** 无法预测所需子任务的复杂任务。 **关键区别：** 与并行化拓扑相似，但子任务**不是预定义的**，由编排者根据输入动态确定。 **例子：** - 编程：每次对多个文件（数量不确定）进行修改 - 搜索：从多个来源收集和分析信息 ### 5. 评估者-优化者（Evaluator-Optimizer） 一个 LLM 生成响应，另一个提供评估和反馈，形成闭环。 ``` [生成器] → 输出 → [评估器] → 反馈 → [生成器] → ... ``` **适用场景：** 有明确评估标准，迭代改进确实有效。 **两个标志：** 1. 人类给出明确反馈时，LLM 响应可以明显改进 2. LLM 自己也能提供此类反馈 **例子：** - 文学翻译：评估者捕捉译者遗漏的细微差别 - 复杂搜索：评估者决定是否需要进一步搜索 ## 四、何时使用 Agent Agent 适用于**开放式问题**，难以或无法预测所需步骤，无法硬编码固定路径。 **关键前提：** - 对大模型的决策有一定程度的信任 - 适合在受信任的环境中执行 - 成本更高，有潜在错误累积风险 - 需要沙箱测试和适当保护措施 **Agent 的本质：** > "Agent 只是一些'在一个循环中，基于环境反馈来选择合适的工具，最终完成其任务'的大模型。" 实现通常很简单：LLM 使用工具，基于环境反馈循环。 **例子：** - 解决 SWE-bench 任务的 Coding Agent - "computer use" 参考实现：Claude 使用计算机完成任务 ## 五、Agent 设计三原则 ### 1. 保持简洁 Agent 设计要简单。不要过度工程化。 ### 2. 保持透明 明确显示 Agent 的规划和步骤。让用户知道发生了什么。 ### 3. 精心设计 ACI（Agent-Computer Interface） 通过完善的工具文档和测试，精心设计 Agent 与计算机的接口。 **工具设计的最佳实践：** - **给模型足够的"思考"空间**，避免把自己逼入死角 - **格式贴近模型在互联网上自然见过的文本** - **避免格式开销**：不要让它数几千行代码，或转义字符串 - **站在模型的角度**：工具描述是否清晰？是否需要仔细思考才能使用？ - **像写好的 docstring 一样设计参数名和描述** - **测试模型如何使用工具**：运行大量示例，观察错误，迭代改进 - **防错设计（Poka-yoke）**：改变参数让错误更难发生 **Anthropic 的经验：** 在构建 SWE-bench Agent 时，他们花在优化工具上的时间比优化整体提示词还多。例如，发现模型在使用相对路径的工具时会出错（Agent 已移出根目录），于是改为**始终要求绝对路径**——模型使用这个方法 flawlessly。 ## 六、框架的使用建议 许多框架可以简化 Agentic 系统实现： - Claude Agent SDK - Strands Agents SDK (AWS) - Rivet (GUI workflow builder) - Vellum (GUI tool) **建议：** 1. **首选直接使用 LLM API**：许多模式几行代码就能实现 2. **如果用框架，确保理解底层代码**：错误假设是常见问题来源 3. **不要犹豫减少抽象层**：生产环境尽量使用基本组件 框架的额外抽象层可能： - 掩盖底层提示和响应 - 增加调试难度 - 诱使你添加不必要的复杂性 ## 七、总结：构建有效 Agent 的第一性原理 ### 核心原则 | 原则 | 含义 | |------|------| | **从简单开始** | 不要构建庞大的控制流，提供健壮的原子工具 | | **为删除而构建** | 架构模块化，新模型会取代你的逻辑 | | **性能驱动复杂性** | 只有性能明显改善时才增加复杂性 | | **工具即接口** | 精心设计工具，ACI 与 HCI 同等重要 | ### 成功公式 **成功 = 正确的系统，而非最复杂的系统** 1. 从简单提示词开始 2. 用全面评估优化 3. 只有简单方案真的不够时，才引入多步 agentic 系统 ### 关键洞察 - **Workflow** = 预定义路径，开发者控制，适合明确任务 - **Agent** = 动态路径，模型控制，适合开放问题 - **工具设计** 比提示词工程更重要 - **评估和迭代** 是成功的关键 ## 八、实际应用案例 ### AI 客服 为什么适合 Agent： - 天然对话流程 + 需要访问外部信息 - 可集成工具获取客户数据、订单历史 - 行动（退款、更新工单）可程序化处理 - 成功可明确衡量（用户定义的问题解决） 一些公司采用**按成功付费**模式：只在 Agent 成功解决时才收费，显示出对效果的信心。 ### Coding Agent 为什么适合 Agent： - 代码解决方案可通过自动化测试验证 - Agent 可用测试结果作为反馈迭代 - 问题空间定义明确、结构化 - 输出质量可客观衡量 Anthropic 的 Agent 已能解决真实 GitHub 问题（SWE-bench Verified），但人类审查仍对确保方案符合系统需求至关重要。 --- ## 参考 - 原文：[Building Effective Agents](https://www.anthropic.com/research/building-effective-agents) - 作者：Erik Schluntz, Barry Zhang (Anthropic) - 发布时间：2024年12月19日 --- *你在构建 Agent 时遵循了哪些原则？遇到过什么坑？欢迎在评论区分享。*