构建高效 AI Agent 的完整指南
来源: Anthropic Engineering Blog
作者: Erik Schluntz 和 Barry Zhang
发布日期: 2024 年 12 月 19 日
类型: 技术指南
阅读时间: 约 15 分钟
概述
本文基于 Anthropic 与数十个跨行业团队合作构建 LLM Agent 的实践经验。研究发现，最成功的实现 consistently 采用简单、可组合的模式，而非复杂框架。文章详细介绍了 AI Agent 系统的核心构建模块、工作流模式和自主 Agent 实现，为开发者提供构建高效 Agent 的实用建议和最佳实践。
核心发现包括：
- 简单模式优于复杂框架
- 工作流与 Agent 的架构差异
- 何时使用/不使用 Agent 的决策框架
- 五大核心工作流模式详解
- 实际生产中的两大应用场景
什么是 Agent？
“Agent”可以有多种定义方式。一些客户将 Agent 定义为完全自主的系统，能够在较长时间内独立运行，使用各种工具完成复杂任务。另一些客户则用这个术语描述遵循预定义工作流的更规范性实现。
在 Anthropic，我们将所有这些变体归类为代理系统（agentic systems），但在工作流程和 Agent 之间划清了重要的架构界限：
- 工作流（Workflows）：LLM 和工具通过预定义的代码路径编排的系统
- Agent：LLM 动态指导自己的流程和工具使用，对如何完成任务保持控制的系统
下文将详细探讨这两种代理系统。在附录 1”实践中的 Agent”中，我们描述了客户发现特别有价值的两个应用领域。
何时（以及何时不）使用 Agent
在使用 LLM 构建应用时，我们建议寻找尽可能简单的解决方案，只在必要时增加复杂性。这可能意味着完全不构建 Agent 系统。Agent 系统通常以延迟和成本换取更好的任务性能，您应该考虑这种权衡是否合理。
当需要更复杂的系统时：
- 工作流为定义明确的任务提供可预测性和一致性
- Agent在需要灵活性和模型驱动决策的规模化场景中更优
对于许多应用而言，使用检索和上下文示例优化单个 LLM 调用通常已经足够。
何时以及如何使用框架
有许多框架使 Agent 系统更易于实现，包括：
- Claude Agent SDK：Anthropic 官方的 Agent 开发工具包
- Strands Agents SDK（AWS）：亚马逊云科技提供的 Agent 框架
- Rivet：拖拽式 GUI LLM 工作流构建器
- Vellum：另一个用于构建和测试复杂工作流的 GUI 工具
这些框架通过简化标准底层任务（如调用 LLM、定义和解析工具、链接调用）让入门变得容易。然而，它们往往会创建额外的抽象层，可能掩盖底层的提示和响应，使调试变得困难。它们还可能诱使开发者在不必要时添加复杂性。
我们的建议：开发者应直接使用 LLM API 开始，许多模式只需几行代码即可实现。如果确实使用框架，请确保理解底层代码。对底层机制的错误假设是客户错误的常见来源。
构建模块、工作流和 Agent
在本节中，我们将探讨在生产环境中见过的 Agent 系统常见模式。我们将从基础构建模块开始——增强型 LLM，然后逐步增加复杂性，从简单组合工作流到自主 Agent。
构建模块：增强型 LLM
Agent 系统的基础构建模块是通过增强功能（如检索、工具和记忆）增强的 LLM。我们当前的模型可以积极利用这些能力——生成自己的搜索查询、选择合适的工具并确定要保留的信息。
我们建议关注实现的两个关键方面：
- 针对特定用例定制这些能力
- 确保它们为 LLM 提供简单易用的文档化接口
虽然有许多方法可以实现这些增强，但一种方法是通过我们最近发布的模型上下文协议（MCP），它允许开发者通过简单的客户端实现集成到不断增长的第三方工具生态系统中。
工作流：提示链（Prompt Chaining）
提示链将任务分解为一系列步骤，每个 LLM 调用处理前一个步骤的输出。您可以在任何中间步骤添加程序化检查（见下图中的”门控”）以确保过程正常进行。
何时使用：此工作流非常适合可以清晰分解为固定子任务的情况。主要目标是通过使每个 LLM 调用成为更简单的任务来换取更高的准确性。
适用示例：
- 生成营销文案，然后将其翻译成不同语言
- 编写文档大纲，检查大纲是否符合某些标准，然后根据大纲编写文档
工作流：路由（Routing）
路由对输入进行分类，并将其引导至专门的后续任务。这种工作流实现了职责分离，并支持构建更专业化的提示。如果不使用这种工作流，针对一种输入进行优化可能会损害其他输入的性能。
何时使用：路由非常适合复杂任务，其中存在最好分开处理的不同类别，并且分类可以由 LLM 或更传统的分类模型/算法准确处理。
适用示例：
- 将不同类型的客户服务查询（一般问题、退款请求、技术支持）引导到不同的下游流程、提示和工具
- 将简单/常见问题引导至更小、成本效益更高的模型（如 Claude Haiku），将困难/不常见问题引导至功能更强大的模型（如 Claude Sonnet）以优化性能
工作流：并行化（Parallelization）
LLM 可以同时处理任务并以编程方式聚合输出。这种并行化工作流有两种关键变体：
- 分区（Sectioning）：将任务分解为独立运行的并行子任务
- 投票（Voting）：多次运行相同任务以获得多样化输出
何时使用：当划分后的子任务可以并行化以提高速度，或者需要多个视角或尝试以获得更高置信度结果时，并行化非常有效。对于具有多个考虑的复杂任务，LLM 通常在每个考虑由单独的 LLM 调用处理时表现更好，从而专注于每个特定方面。
适用示例：
- 实施防护措施，一个模型实例处理用户查询，另一个筛选不当内容或请求。这往往比让同一个 LLM 调用同时处理防护和核心响应表现更好
- 自动化评估 LLM 性能，每个 LLM 调用评估模型在给定提示上表现的不同方面
- 审查代码漏洞，多个不同的提示审查并在发现问题时标记代码
- 评估给定内容是否不适当，多个提示评估不同方面或要求不同的投票阈值以平衡假阳性和假阴性
工作流：编排者 - 工作者（Orchestrator-Workers）
在编排者 - 工作者工作流中，中央 LLM 动态分解任务、分配给工作者 LLM 并综合它们的结果。
何时使用：此工作流非常适合无法预测所需子任务的复杂任务（例如编码，需要更改的文件数量和每个文件的更改性质可能取决于任务）。虽然它与并行化在拓扑上相似，但关键区别在于灵活性——子任务不是预定义的，而是由编排者根据具体输入确定。
适用示例：
- 每次对多个文件进行复杂更改的编码产品
- 搜索任务，涉及从多个来源收集和分析可能相关的信息
工作流：评估者 - 优化者（Evaluator-Optimizer）
在评估者 - 优化者工作流中，一个 LLM 调用生成响应，另一个在循环中提供评估和反馈。
何时使用：当有明确的评估标准且迭代优化提供可衡量的价值时，此工作流特别有效。良好适配的两个标志是：
- 当人类清晰表达反馈时，LLM 响应可以明显改进
- LLM 能够提供这种反馈
这类似于人类作者在生成精美文档时可能经历的迭代写作过程。
适用示例：
- 文学翻译，存在翻译 LLM 可能最初无法捕捉的细微差别，但评估者 LLM 可以提供有用的批评
- 复杂搜索任务，需要多轮搜索和分析以收集全面信息，评估者决定是否需要进一步搜索
自主 Agent
随着 LLM 在关键能力（理解复杂输入、参与推理和规划、可靠使用工具以及从错误中恢复）方面成熟，Agent 正在生产中涌现。
Agent 的工作流程：
- 通过人类用户的命令或互动讨论开始工作
- 任务明确后，独立规划和操作
- 可能返回人类寻求更多信息或判断
- 执行期间，关键是从环境获取”地面真相”（如工具调用结果或代码执行）以评估进度
- 在检查点或遇到障碍时暂停以获取人类反馈
- 任务通常在完成时终止，但也包括停止条件（如最大迭代次数）以保持控制
Agent 可以处理复杂任务，但其实现通常很简单。它们通常只是在循环中根据环境反馈使用工具的 LLM。因此，清晰地设计和记录工具集至关重要。
何时使用 Agent：
- 适用于难以或无法预测所需步骤数的开放式问题
- 无法硬编码固定路径的场景
- LLM 将运行多个回合，您必须对其决策有一定程度的信任
- 在可信环境中扩展任务的理想选择
Agent 的自主性质意味着更高的成本和复合错误的潜在风险。我们建议在沙箱环境中进行广泛测试，并配合适当的防护措施。
适用示例：
- 解决 SWE-bench 任务的编码 Agent，涉及根据任务描述编辑多个文件
- 我们的”计算机使用”参考实现，Claude 使用计算机完成任务
组合和定制这些模式
这些构建模块不是规定性的。它们是开发者可以塑造和组合以适应不同用例的常见模式。成功的关键（如同任何 LLM 功能一样）是衡量性能并迭代实现。重申：只有当性能明显提升时才考虑添加复杂性。
在生产中实现 Agent 时，我们遵循三个核心原则：
- 保持设计简洁：避免过度设计的 Agent 架构
- 优先考虑透明度：明确展示 Agent 的规划步骤
- 精心打造 Agent- 计算机接口（ACI）：通过彻底的工具文档和测试
框架可以帮助您快速入门，但在转向生产时不要犹豫减少抽象层并使用基本组件构建。遵循这些原则，您可以创建不仅强大而且可靠、可维护并受用户信任的 Agent。
附录 1：实践中的 Agent
与客户的合作揭示了 AI Agent 的两个特别有前途的应用，展示了上述模式的实际价值。这两个应用都说明了 Agent 在需要对话和行动、具有明确成功标准、支持反馈循环并集成有意义的人类监督的任务中增加最多价值。
A. 客户支持
客户支持结合了熟悉的聊天机器人界面和通过工具集成的增强功能。这自然更适合更开放的 Agent，因为：
- 支持交互自然遵循对话流程，同时需要访问外部信息和操作
- 工具可以集成以获取客户数据、订单历史和知识库文章
- 操作（如发放退款或更新工单）可以以编程方式处理
- 成功可以通过用户定义的解决率清晰衡量
几家公司通过使用定价模式证明了这种方法的可行性，只对成功解决收费，显示了对其 Agent 有效性的信心。
B. 编码 Agent
软件开发领域显示出 LLM 功能的巨大潜力，能力从代码补全发展到自主问题解决。Agent 特别有效，因为：
- 代码解决方案可以通过自动化测试验证
- Agent 可以使用测试结果作为反馈迭代解决方案
- 问题空间定义明确且结构化
- 输出质量可以客观衡量
在我们自己的实现中，Agent 现在可以根据拉取请求描述单独解决 SWE-bench Verified 基准中的真实 GitHub 问题。然而，虽然自动化测试有助于验证功能，但人工审查对于确保解决方案符合更广泛的系统要求仍然至关重要。
附录 2：提示工程您的工具
无论您构建哪种 Agent 系统，工具都可能是您 Agent 的重要组成部分。工具使 Claude 能够通过在我们的 API 中指定确切的结构和定义来与外部服务和 API 交互。当 Claude 响应时，如果计划调用工具，它将包括 API 响应中的工具使用块。
工具定义和规格应该得到与整体提示相同的提示工程关注。在这个简短的附录中，我们描述如何提示工程您的工具。
工具格式决策
通常有几种方法可以指定相同的操作。例如，您可以通过编写 diff 或通过重写整个文件来指定文件编辑。对于结构化输出，您可以在 markdown 或 JSON 中返回代码。在软件工程中，这些差异是装饰性的，可以无损地从一种转换为另一种。然而，有些格式对 LLM 来说更难编写。编写 diff 需要在编写新代码之前知道 chunk 头中有多少行在变化。在 JSON 中编写代码（相比 markdown）需要额外转义换行符和引号。
我们决定工具格式的建议：
- 给模型足够的 token 在陷入困境之前”思考”
- 保持格式接近模型在互联网上自然看到的文本
- 确保没有格式”开销”，如必须准确计算数千行代码，或字符串转义它编写的任何代码
一个经验法则是考虑人机界面（HCI）投入了多少努力，并计划投入同样多的努力创建好的Agent- 计算机接口（ACI）。以下是一些想法：
- 站在模型的立场思考：基于描述和参数，这个工具的使用是否显而易见？您是否需要仔细思考它？如果是，那么对模型也是如此。好的工具定义通常包括示例用法、边缘情况、输入格式要求以及与其他工具的明确界限
- 优化参数名称和描述：使其更明显。将其视为为团队中的初级开发者编写出色的文档字符串。当使用许多相似工具时，这一点尤其重要
- 测试模型如何使用您的工具：在我们的工作台中运行许多示例输入，查看模型犯的错误并迭代
- Poka-yoke（防错）：更改参数使其更难犯错
在构建 SWE-bench 的 Agent 时，我们实际上在工具优化上花费的时间比在整体提示上更多。例如，我们发现当 Agent 移出根目录后，模型会使用相对文件路径的工具犯错。为了解决这个问题，我们将工具更改为始终需要绝对文件路径——我们发现模型可以完美使用这种方法。
关键要点总结
- 简单优于复杂：成功的 Agent 实现使用简单、可组合的模式而非复杂框架
- 工作流 vs Agent：工作流提供可预测性，Agent 提供灵活性
- 五大工作流模式：提示链、路由、并行化、编排者 - 工作者、评估者 - 优化者
- 三大核心原则：保持简洁、优先透明、精心打造 ACI
- 两大应用场景：客户支持和编码 Agent
- 工具工程至关重要：在工具优化上的投入应与整体提示工程相当
个人评价
这篇文章为 AI Agent 开发提供了一份实用且经过实践验证的指南。其价值主要体现在：
优点：
- 实践导向：基于 Anthropic 与数十个客户团队的实际合作经验，而非纯理论
- 层次清晰：从简单到复杂逐步介绍，帮助开发者理解何时需要添加复杂性
- 具体示例：每个模式都配有实际应用场景，便于理解和应用
- 平衡视角：明确指出何时不应使用 Agent，避免过度工程化
- 工具工程洞见：关于 ACI（Agent- 计算机接口）的讨论提供了独特的实践视角
局限性：
- 代码示例有限：虽然提到了 cookbook，但文章本身缺少具体代码实现
- 性能数据不足：没有提供各模式的性能对比数据或基准测试结果
- 框架对比简略：对各个框架的优缺点分析不够深入
总体评价：
这是目前关于 AI Agent 架构设计最实用的指南之一。Anthropic 通过大量客户案例提炼出的模式具有很高的参考价值。特别是关于”简单优于复杂”的核心理念，对于当前业界过度追求复杂 Agent 框架的趋势是一个重要的平衡声音。
对于正在构建 Agent 系统的开发者，建议：
- 从简单提示开始，逐步添加复杂性
- 优先考虑透明度和可调试性
- 在工具设计上投入足够时间
- 根据具体用例选择合适的模式组合
本文内容翻译自 Anthropic Engineering Blog 官方博客，原文标题为”Building effective agents”。