构建高效的Agent（Building Effective Agents）
原文链接：www.anthropic.com/engineering…
发布日期：2024年12月19日
摘要： 在过去一年里，我们与数十个跨行业构建LLM Agent的团队合作。最成功的实现始终使用简单、可组合的模式，而非复杂的框架。
引言
在过去一年里，我们与数十个跨行业构建大语言模型（LLM）Agent的团队合作。最成功的实现并没有使用复杂的框架或专门的库。相反，它们使用简单、可组合的模式来构建。
在本文中，我们分享从与客户合作以及自己构建Agent中学到的经验，并为开发者提供构建高效Agent的实用建议。
什么是Agent？
"Agent"可以有多种定义方式。一些客户将Agent定义为完全自主的系统，能够在较长时间内独立运行，使用各种工具完成复杂任务。另一些人则用这个术语来描述遵循预定义工作流的更规范的实现。在Anthropic，我们将所有这些变体归类为Agent系统（agentic systems），但在**工作流（workflows）和Agent（agents）**之间做出重要的架构区分：
- 工作流是通过预定义代码路径编排LLM和工具的系统。
- Agent则是LLM动态指导自身流程和工具使用的系统，保持对如何完成任务的控制。
下面，我们将详细探讨这两种类型的Agent系统。在附录1（"Agent实践"）中，我们描述了客户发现这类系统特别有价值的两个领域。
何时（以及何时不）使用Agent
在使用LLM构建应用程序时，我们建议找到尽可能简单的解决方案，只在需要时才增加复杂性。这可能意味着根本不构建Agent系统。Agent系统通常以延迟和成本换取更好的任务性能，您应该考虑这种权衡何时有意义。
当需要更多复杂性时，工作流为定义明确的任务提供可预测性和一致性，而当需要大规模的灵活性和模型驱动的决策时，Agent是更好的选择。然而，对于许多应用程序，使用检索和上下文示例优化单个LLM调用通常就足够了。
何时以及如何使用框架
有许多框架可以使Agent系统更容易实现，包括：
- Claude Agent SDK；
- AWS的Strands Agents SDK；
- Rivet，一个拖放式GUI LLM工作流构建器；以及
- Vellum，另一个用于构建和测试复杂工作流的GUI工具。
这些框架通过简化标准的底层任务（如调用LLM、定义和解析工具以及链接调用）使入门变得容易。然而，它们通常会创建额外的抽象层，可能会掩盖底层的提示和响应，使调试变得更加困难。它们还可能诱使人们在更简单的设置就足够的情况下增加复杂性。
我们建议开发者从直接使用LLM API开始：许多模式只需几行代码就可以实现。如果您确实使用框架，请确保您理解底层代码。对底层实现的错误假设是客户错误的常见来源。
请参阅我们的cookbook获取一些示例实现。
构建块、工作流和Agent
在本节中，我们将探索我们在生产中看到的Agent系统的常见模式。我们将从基础构建块——增强型LLM——开始，逐步增加复杂性，从简单的组合工作流到自主Agent。
构建块：增强型LLM
Agent系统的基本构建块是通过检索、工具和记忆等增强功能增强的LLM。我们当前的模型可以主动使用这些能力——生成自己的搜索查询、选择适当的工具，并确定要保留哪些信息。
我们建议关注实现的两个关键方面：根据您的特定用例定制这些能力，并确保它们为您的LLM提供简单、文档齐全的接口。虽然有多种方式可以实现这些增强功能，但一种方法是通过我们最近发布的模型上下文协议（Model Context Protocol），它允许开发者通过简单的客户端实现与不断增长的第三方工具生态系统集成。
在本文的其余部分，我们将假设每次LLM调用都可以访问这些增强功能。
工作流：提示链（Prompt Chaining）
提示链将任务分解为一系列步骤，其中每个LLM调用处理前一个的输出。您可以在任何中间步骤添加程序化检查（见下图中的"门"）以确保流程仍在正轨上。
何时使用此工作流： 此工作流适用于任务可以轻松、清晰地分解为固定子任务的情况。主要目标是通过使每个LLM调用成为更简单的任务来以延迟换取更高的准确性。
提示链有用的示例：
- 生成营销文案，然后将其翻译成不同的语言。
- 编写文档大纲，检查大纲是否满足某些标准，然后根据大纲编写文档。
工作流：路由（Routing）
路由对输入进行分类并将其定向到专门的后续任务。此工作流允许关注点分离，并构建更专门的提示。如果没有此工作流，针对一种输入的优化可能会损害其他输入的性能。
何时使用此工作流： 路由适用于存在不同类别且这些类别最好分别处理的复杂任务，并且分类可以由LLM或更传统的分类模型/算法准确处理。
路由有用的示例：
- 将不同类型的客户服务查询（一般问题、退款请求、技术支持）定向到不同的下游流程、提示和工具。
- 将简单/常见问题路由到较小的、成本效益高的模型（如Claude Haiku 4.5），将困难/不寻常的问题路由到更强大的模型（如Claude Sonnet 4.5）以优化最佳性能。
工作流：并行化（Parallelization）
LLM有时可以同时处理一个任务，并以编程方式聚合其输出。这种工作流——并行化——表现为两种关键变体：
- 分段（Sectioning）： 将任务分解为并行运行的独立子任务。
- 投票（Voting）： 多次运行相同任务以获得多样化的输出。
何时使用此工作流： 并行化在划分的子任务可以并行处理以提高速度时有效，或者当需要多个视角或尝试以获得更高置信度的结果时有效。对于具有多个考虑因素的复杂任务，当每个考虑因素由单独的LLM调用处理时，LLM通常表现更好，允许对每个特定方面给予集中关注。
并行化有用的示例：
- 分段：
- 实现护栏，其中一个模型实例处理用户查询，而另一个筛选它们是否有不当内容或请求。这往往比让同一个LLM调用同时处理护栏和核心响应表现更好。
- 自动化评估以评估LLM性能，其中每个LLM调用评估模型在给定提示上的不同方面的表现。
- 投票：
- 审查一段代码的漏洞，其中几个不同的提示审查代码并在发现问题时标记。
- 评估给定内容是否不当，多个提示评估不同方面或需要不同的投票阈值以平衡误报和漏报。
工作流：编排器-工作者（Orchestrator-workers）
在编排器-工作者工作流中，一个中央LLM动态分解任务，将它们委派给工作者LLM，并综合它们的结果。
何时使用此工作流： 此工作流非常适合您无法预测所需子任务的复杂任务（例如，在编码中，需要更改的文件数量以及每个文件中更改的性质可能取决于任务）。虽然拓扑结构相似，但与并行化的关键区别在于其灵活性——子任务不是预定义的，而是由编排器根据特定输入确定的。
编排器-工作者有用的示例：
- 每次对多个文件进行复杂更改的编码产品。
- 涉及从多个来源收集和分析可能相关信息的搜索任务。
工作流：评估器-优化器（Evaluator-optimizer）
在评估器-优化器工作流中，一个LLM调用生成响应，而另一个在循环中提供评估和反馈。
何时使用此工作流： 当我们有明确的评估标准，并且迭代改进提供可衡量的价值时，此工作流特别有效。良好适配的两个迹象是：首先，当人类表达反馈时，LLM响应可以明显改善；其次，LLM可以提供这样的反馈。这类似于人类作家在制作精美文档时可能经历的迭代写作过程。
评估器-优化器有用的示例：
- 文学翻译，其中有翻译器LLM最初可能无法捕捉到的细微差别，但评估器LLM可以提供有用的批评。
- 需要多轮搜索和分析以收集全面信息的复杂搜索任务，其中评估器决定是否需要进一步搜索。
Agent（Agents）
随着LLM在关键能力方面的成熟——理解复杂输入、参与推理和规划、可靠地使用工具以及从错误中恢复——Agent正在生产中出现。Agent通过来自人类用户的命令或与其的交互讨论开始工作。一旦任务明确，Agent就会独立规划和操作，可能会返回人类获取更多信息或判断。在执行过程中，Agent在每一步从环境中获取"基本事实"（如工具调用结果或代码执行）以评估其进度至关重要。然后Agent可以在检查点或遇到阻碍时暂停以获取人类反馈。任务通常在完成时终止，但也常见包含停止条件（如最大迭代次数）以保持控制。
Agent可以处理复杂的任务，但其实现通常很简单。它们通常只是在循环中基于环境反馈使用工具的LLM。因此，清晰和周到地设计工具集及其文档至关重要。我们在附录2（"工具的提示工程"）中扩展了工具开发的最佳实践。
何时使用Agent： Agent可用于难以或无法预测所需步骤数量的开放式问题，以及您无法硬编码固定路径的情况。LLM可能会运行多轮，您必须对其决策有一定程度的信任。Agent的自主性使它们成为在可信环境中扩展任务的理想选择。
Agent的自主性意味着更高的成本，以及错误复合的可能性。我们建议在沙箱环境中进行广泛测试，以及适当的护栏。
Agent有用的示例：
以下示例来自我们自己的实现：
- 用于解决SWE-bench任务的编码Agent，这涉及根据任务描述对多个文件进行编辑；
- 我们的"计算机使用"参考实现，其中Claude使用计算机完成任务。
组合和自定义这些模式
这些构建块不是规定性的。它们是开发者可以塑造和组合以适应不同用例的常见模式。成功的关键，与任何LLM功能一样，是衡量性能并迭代实现。重申一下：只有在明显改善结果时才应考虑增加复杂性。
总结
在LLM领域的成功不在于构建最复杂的系统。而在于为您的需求构建正确的系统。从简单的提示开始，通过全面评估优化它们，只有在更简单的解决方案不足时才添加多步Agent系统。
在实现Agent时，我们尝试遵循三个核心原则：
- 在Agent设计中保持简单性。
- 通过明确显示Agent的规划步骤来优先考虑透明度。
- 通过彻底的工具文档和测试精心设计您的Agent-计算机接口（ACI）。
框架可以帮助您快速入门，但在转向生产时不要犹豫减少抽象层并使用基本组件构建。通过遵循这些原则，您可以创建不仅强大而且可靠、可维护且受用户信任的Agent。
致谢
由Erik Schluntz和Barry Zhang撰写。这项工作借鉴了我们在Anthropic构建Agent的经验以及客户分享的宝贵见解，对此我们深表感谢。
附录1：Agent实践
我们与客户的工作揭示了AIAgent的两个特别有前途的应用，展示了上述讨论的模式的实际价值。这两个应用都说明了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需要在编写新代码之前知道块头中有多少行正在更改。在JSON中编写代码（与markdown相比）需要对换行符和引号进行额外转义。
我们对决定工具格式的建议如下：
- 给模型足够的token来"思考"，以免它把自己写进死角。
- 保持格式接近模型在互联网上自然看到的文本。
- 确保没有格式"开销"，例如必须保持数千行代码的准确计数，或对其编写的任何代码进行字符串转义。
一个经验法则是考虑在人机交互接口（HCI）上投入了多少努力，并计划在创建良好的Agent-计算机接口（ACI）上投入同样多的努力。以下是一些关于如何做到这一点的想法：
- 站在模型的角度思考。根据描述和参数，如何使用此工具是否明显，还是您需要仔细考虑？如果是这样，那么对模型来说可能也是如此。好的工具定义通常包括示例用法、边缘情况、输入格式要求以及与其他工具的明确界限。
- 您如何更改参数名称或描述以使事情更明显？把这想象成为团队中的初级开发人员编写出色的文档字符串。当使用许多类似的工具时，这一点尤为重要。
- 测试模型如何使用您的工具：在我们的工作台中运行许多示例输入，查看模型犯了什么错误，并迭代。
- 对您的工具进行防错设计（Poka-yoke）。更改参数，使其更难犯错误。
在为SWE-bench构建我们的Agent时，我们实际上在优化工具上花费的时间比在整体提示上更多。例如，我们发现在Agent移出根目录后，模型会在使用相对文件路径的工具上犯错误。为了解决这个问题，我们将工具更改为始终需要绝对文件路径——我们发现模型完美地使用了这种方法。
