[译] Anthropic - 构建高效的智能体
在过去的一年里，我们与数十个行业的团队合作，共同构建大型语言模型（LLM）智能体。我们发现，最成功的实现并非使用复杂的框架或专门的库，而是采用简单、可组合的模式。
在这篇文章中，我们分享了与客户合作以及我们自己构建智能体所学到的经验，并为开发者提供了构建高效智能体的实用建议。
什么是智能体？
“智能体”可以有多种定义。一些客户将智能体定义为完全自主的系统，能够在长时间内独立运行，使用各种工具完成复杂任务。另一些客户则用这个术语来描述遵循预定义工作流程、更具规定性的实现。在 Anthropic，我们将所有这些变体归类为智能体系统，但在工作流程和智能体之间做出了一个重要的架构区分：
- 工作流程是指 LLM 和工具通过预定义的代码路径进行编排的系统。
- 智能体则是指 LLM 动态指导其自身流程和工具使用，并保持对任务完成方式控制的系统。
下面，我们将详细探讨这两种类型的智能体系统。在“附录 1：智能体实践”中，我们描述了两个领域，在这些领域中客户发现使用这类系统具有特殊价值。
何时（以及何时不）使用智能体
在使用 LLM 构建应用程序时，我们建议寻找尽可能简单的解决方案，仅在需要时才增加复杂性。这可能意味着根本不构建智能体系统。智能体系统通常以延迟和成本换取更好的任务性能，您应该考虑这种权衡在何时是合理的。
当需要更高的复杂性时，工作流程为定义明确的任务提供了可预测性和一致性，而当需要大规模的灵活性和模型驱动的决策时，智能体是更好的选择。然而，对于许多应用程序来说，通过检索和上下文示例优化单个 LLM 调用通常就足够了。
何时以及如何使用框架
有许多框架可以使智能体系统的实现变得更容易，包括：
- LangChain 的 LangGraph；
- 亚马逊 Bedrock 的 AI 智能体框架；
- Rivet，一个拖放式 GUI LLM 工作流程构建器；
- Vellum，另一个用于构建和测试复杂工作流程的 GUI 工具。
这些框架通过简化标准的底层任务（如调用 LLM、定义和解析工具以及将调用链接在一起）使入门变得容易。然而，它们通常会创建额外的抽象层，可能会掩盖底层的提示和响应，使其更难调试。在简单的设置就足够的情况下，它们也可能诱使人增加复杂性。
我们建议开发者从直接使用 LLM API 开始：许多模式可以用几行代码实现。如果您确实使用框架，请确保您了解其底层代码。对底层机制的错误假设是客户出错的常见原因。
请参阅我们的 Cookbook 获取一些示例实现。
构建模块、工作流程和智能体
在本节中，我们将探讨我们在生产环境中看到的智能体系统的常见模式。我们将从我们的基础构建模块 “增强型 LLM” 开始，并逐步增加复杂性，从简单的组合式工作流程到自主智能体。
构建模块：增强型 LLM
智能体系统的基本构建模块是一个通过检索、工具和记忆等增强功能改进的 LLM。我们目前的模型可以主动使用这些功能 — 生成自己的搜索查询、选择合适的工具以及确定要保留哪些信息。
我们建议关注实现的两个关键方面：根据您的特定用例定制这些功能，并确保它们为您的 LLM 提供一个简单、文档齐全的接口。虽然实现这些增强功能的方法有很多，但其中一种方法是通过我们最近发布的 Model Context Protocol，它允许开发者通过简单的客户端实现与不断增长的第三方工具生态系统集成。
在本文的其余部分，我们将假设每次 LLM 调用都可以访问这些增强功能。
工作流程：提示链
提示链将任务分解为一系列步骤，其中每个 LLM 调用会处理前一个调用的输出。您可以在任何中间步骤上添加程序化检查（参见下图中的 “Gate”），以确保流程仍在正轨上。
何时使用此工作流程： 此工作流程非常适用于任务可以轻松、清晰地分解为固定子任务的情况。其主要目标是通过使每个 LLM 调用成为一个更容易的任务，来用延迟换取更高的准确性。
提示链有用的示例：
- 生成营销文案，然后将其翻译成另一种语言。
- 编写文档大纲，检查大纲是否符合某些标准，然后根据大纲编写文档。
工作流程：路由
路由对输入进行分类，并将其导向专门的后续任务。此工作流程允许关注点分离，并构建更专门的提示。如果没有此工作流程，针对一种输入的优化可能会损害在其他输入上的性能。
何时使用此工作流程： 路由适用于存在不同类别且更适合分开处理的复杂任务，以及能够通过 LLM 或更传统的分类模型/算法准确进行分类的任务。
路由有用的示例：
- 将不同类型的客户服务查询（一般问题、退款请求、技术支持）引导到不同的下游流程、提示和工具中。
- 将简单/常见问题路由到像 Claude 3.5 Haiku 这样较小的模型，将困难/不寻常的问题路由到像 Claude 3.5 Sonnet 这样功能更强大的模型，以优化成本和速度。
工作流程：并行化
LLM 有时可以同时处理一个任务，并以编程方式聚合它们的输出。这种工作流程，即并行化，表现为两种主要变体：
- 分段：将任务分解为并行运行的独立子任务。
- 投票：多次运行相同的任务以获得多样化的输出。
何时使用此工作流程： 当被划分的子任务可以并行处理以提升速度，或者需要从多个角度尝试以获得更高置信度的结果时，并行化方法会十分有效。对于需要综合多方面因素考量的复杂任务，通常每个因素由独立的 LLM 调用处理会取得更好效果，这样能让模型专注于每个具体维度的分析。
并行化有用的示例：
- 分段：
- 实施防护机制，即由一个模型实例处理用户查询，而另一个模型实例对查询中的不当内容或请求进行筛查。这种方式往往比让同一个 LLM 调用同时处理防护机制和核心响应的效果更好。
- 自动化评估 LLM 的性能，即每次 LLM 调用都会针对给定提示评估模型性能的不同方面。
- 投票：
- 审查一段代码是否存在漏洞，其中多个不同的提示会对代码进行审查，若发现问题则会标记出来。
- 评估给定内容是否不当，通过多个提示分别评估不同方面，或设置不同投票阈值来平衡误报和漏报。
工作流程：协调器-工作者
在协调器-工作者工作流程中，一个中央 LLM 动态地分解任务，将它们委派给工作者 LLM，并综合它们的结果。
何时使用此工作流程： 这种工作流程非常适合处理无法预先预测所需子任务的复杂任务（例如在编码场景中，需要修改的文件数量以及每个文件的修改性质很可能取决于具体任务）。尽管它在架构上与并行化类似，但二者的关键区别在于其灵活性 — 子任务并非预先定义，而是由协调器根据特定输入动态确定。
协调器-工作者有用的示例：
- 每次都对多个文件进行复杂更改的编码产品。
- 涉及从多个来源收集和分析信息以获取可能相关信息的搜索任务。
工作流程：评估器-优化器
在评估器-优化器工作流程中，一个 LLM 调用生成响应，而另一个 LLM 在循环中提供评估和反馈。
何时使用此工作流程： 当我们拥有明确的评估标准，且迭代优化能够带来可衡量的价值时，这种工作流程尤为有效。适用这种流程的两个显著标志是：首先，当人类清晰表达反馈时，大语言模型（LLM）的响应能够被明显改进；其次，大语言模型本身能够提供此类反馈。这类似于人类作家在创作一篇精炼文档时所经历的迭代写作过程。
评估器-优化器有用的示例：
- 文学翻译，其中存在翻译器 LLM 最初可能无法捕捉到的细微差别，但评估器 LLM 可以提供有用的评论。
- 需要多轮搜索和分析以收集全面信息的复杂搜索任务，其中评估器决定是否需要进一步搜索。
智能体
随着 LLM 在理解复杂输入、进行推理规划、可靠使用工具以及从错误中恢复等关键能力上的成熟，智能体正逐步应用于实际生产场景。智能体的工作始于人类用户的指令或与之进行的交互讨论。一旦任务明确，智能体便会独立规划并执行操作，可能会返回到人类用户处从而获取进一步信息或判断。在执行过程中，智能体在每一步从环境中获取 “真实数据”（如工具调用结果或代码执行结果）以评估进展至关重要。然后，智能体可在检查点或遇到障碍时暂停以获取人类反馈。任务通常在完成时终止，但为保持控制，设置停止条件（如最大迭代次数）也很常见。
智能体可以处理复杂的任务，但它们的实现通常很简单。它们通常只是在循环中根据环境反馈使用工具的 LLM。因此，清晰周到地设计工具集及其文档至关重要。我们在“附录 2：提示工程化您的工具”中详细阐述了工具开发的最佳实践。
何时使用智能体： 智能体可用于开放式问题，在这些问题中，很难或不可能预测所需的步骤数，并且您无法硬编码固定的路径。LLM 可能会运行多轮，您必须对其决策有一定程度的信任。智能体的自主性使其成为在受信任环境中扩展任务的理想选择。
智能体的自主性意味着更高的成本和潜在的复合错误。我们建议在沙盒环境中进行广泛测试，并配备适当的防护机制。
智能体有用的示例：
以下示例来自我们自己的实现：
- 一个用于解决 SWE-bench 任务 的编码智能体，这些任务涉及根据任务描述对许多文件进行编辑；
- 我们的 “计算机使用”参考实现，其中 Claude 使用计算机来完成任务。
组合和定制这些模式
这些构建模块不是规定性的。它们是开发者可以根据不同用例塑造和组合的常见模式。与任何 LLM 功能一样，成功的关键在于衡量性能并对实现方式进行迭代。再次强调：仅当增加复杂性能显著改善结果时，才应考虑这样做。
总结
在 LLM 领域取得成功，关键不在于构建最复杂的系统，而在于构建适合您需求的系统。从简单的提示开始，通过全面的评估对其进行优化，并且仅在更简单的解决方案不足时才添加多步智能体系统。
在实施智能体时，我们尝试遵循三个核心原则：
- 在您的智能体设计中保持简单性。
- 通过明确显示智能体的规划步骤来优先考虑透明度。
- 通过彻底的工具文档和测试，精心打造您的智能体-计算机接口（ACI）。
框架可以帮助您快速入门，但在转向生产环境时，不要犹豫，减少抽象层并使用基本组件进行构建。通过遵循这些原则，您可以创建不仅功能强大，而且可靠、可维护并受其用户信任的智能体。
致谢
由 Erik Schluntz 和 Barry Zhang 撰写。这项工作借鉴了我们在 Anthropic 构建智能体的经验以及我们客户分享的宝贵见解，对此我们深表感谢。
附录 1：智能体实践
我们与客户的合作实践揭示了 AI 智能体的两个特别有前景的应用场景，这些场景充分展现了上述模式的实用价值。这两类应用均表明，当任务同时需要对话交互与实际行动、具备明确的成功评判标准、支持反馈循环机制，并且融入了有意义的人类监督时，智能体能够发挥最大价值。
A. 客户支持
客户支持将熟悉的聊天机器人界面与通过工具集成增强的功能相结合。这对于更开放式的智能体来说是天作之合，因为：
- 支持互动自然地遵循对话流程，同时需要访问外部信息和操作；
- 可以集成工具来提取客户数据、订单历史和知识库文章；
- 诸如发放退款或更新工单之类的操作可以以编程方式处理；以及
- 成功与否可通过用户定义的解决方案清晰衡量。
多家公司已通过基于使用量的定价模式证明了这种方法的可行性，该模式仅对成功解决的问题收费，彰显了其对智能体效能的信心。
B. 编码智能体
软件开发领域在 LLM 功能方面显示出巨大的潜力，其能力从代码补全发展到自主解决问题。智能体特别有效，因为：
- 代码解决方案可通过自动化测试进行验证；
- 智能体可以使用测试结果作为反馈来迭代解决方案；
- 问题空间定义明确且结构化；以及
- 输出质量可以客观衡量。
在我们自己的实现中，智能体现在可以仅根据 pull request 描述解决 SWE-bench Verified 基准测试中的真实 GitHub 问题。然而，尽管自动化测试有助于验证功能，但人工审查对于确保解决方案符合更广泛的系统要求仍然至关重要。
附录 2：提示工程化您的工具
无论您正在构建哪种智能体系统，工具都可能是您智能体的重要组成部分。工具使 Claude 能够通过在我们的 API 中指定其确切的结构和定义来与外部服务和 API 交互。当 Claude 响应时，如果它计划调用工具，它将在 API 响应中包含一个工具使用块。工具定义和规范应与您的整体提示一样受到同等的提示工程关注。在这个简短的附录中，我们描述了如何对您的工具进行提示工程。
通常有多种方法可以指定相同的操作。例如，您可以通过编写差异（diff）或重写整个文件来指定文件编辑。对于结构化输出，您可以在 Markdown 或 JSON 中返回代码。在软件工程中，这些差异是表面上的，可以无损地相互转换。然而，某些格式对于 LLM 来说比其他格式更难编写。编写差异需要知道在编写新代码之前块头中有多少行正在更改。在 JSON 中编写代码（与 Markdown 相比）需要额外转义换行符和引号。
我们关于决定工具格式的建议如下：
- 给模型足够的 Token 来“思考”，以免它把自己写进死胡同。
- 保持格式接近模型在互联网上自然看到的文本格式。
- 确保没有格式化“开销”，例如必须保持数千行代码的准确计数，或对其编写的任何代码进行字符串转义。
一个经验法则是，思考一下投入到人机界面（HCI）中的精力，并计划投入同样多的精力来创建良好的智能体-计算机接口（ACI）。以下是一些关于如何做到这一点的想法：
- 设身处地为模型着想。根据描述和参数，使用这个工具是否显而易见，还是您需要仔细思考？如果是这样，那么对于模型来说可能也是如此。一个好的工具定义通常包括用法示例、边缘情况、输入格式要求以及与其他工具的明确界限。
- 您如何更改参数名称或描述以使事情更明显？可以把这看作是为团队中的初级开发人员编写一个出色的文档字符串。在使用许多相似工具时，这一点尤其重要。
- 测试模型如何使用您的工具：在我们的工作台中运行许多示例输入，看看模型会犯什么错误，然后进行迭代。
- 防错您的工具。更改参数，使其更难出错。
在为 SWE-bench 构建我们的智能体时，我们实际上花了更多时间优化我们的工具，而不是整体提示。例如，我们发现当智能体移出根目录后，模型会使用相对文件路径的工具出错。为了解决这个问题，我们将工具更改为始终需要绝对文件路径 — 我们发现模型完美地使用了这种方法。