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

一、Anthropic 的核心洞察

过去一年，Anthropic 与数十个团队合作，帮助他们在不同行业构建 LLM Agent。他们发现一个反直觉的事实：

最成功的实现，不是依靠复杂的框架或专门的库，而是基于简单、可组合的模式。

这篇文章总结了 Anthropic 在构建 Agent 过程中积累的方法论，以及给开发者的实用工程建议。

二、第一性原理：Workflow vs Agent

在 Anthropic 的分类体系中，所有 LLM 增强系统都被称为 agentic systems，但有一个关键的架构区分：

核心原则：如无必要，不要构建 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 的第一性原理

核心原则

成功公式

成功 = 正确的系统，而非最复杂的系统

1. 从简单提示词开始
2. 用全面评估优化
3. 只有简单方案真的不够时，才引入多步 agentic 系统

关键洞察

• Workflow = 预定义路径，开发者控制，适合明确任务
• Agent = 动态路径，模型控制，适合开放问题
• 工具设计 比提示词工程更重要
• 评估和迭代 是成功的关键

八、实际应用案例

AI 客服

为什么适合 Agent：

• 天然对话流程 + 需要访问外部信息
• 可集成工具获取客户数据、订单历史
• 行动（退款、更新工单）可程序化处理
• 成功可明确衡量（用户定义的问题解决）

一些公司采用按成功付费模式：只在 Agent 成功解决时才收费，显示出对效果的信心。

Coding Agent

为什么适合 Agent：

• 代码解决方案可通过自动化测试验证
• Agent 可用测试结果作为反馈迭代
• 问题空间定义明确、结构化
• 输出质量可客观衡量

Anthropic 的 Agent 已能解决真实 GitHub 问题（SWE-bench Verified），但人类审查仍对确保方案符合系统需求至关重要。

---

参考

• 原文：Building Effective Agents
• 作者：Erik Schluntz, Barry Zhang (Anthropic)
• 发布时间：2024年12月19日

---

你在构建 Agent 时遵循了哪些原则？遇到过什么坑？欢迎在评论区分享。