Anthopic:构建有效的Agent

本文译自Anthropic发布的Building effective Agents（需要魔法)。在研究Agents的过程中将之与Google、OpenAI等关于Agent的文章一起进行比较，学习业界对Agents的不同定位。

在过去一年中，我们与数十个团队合作，在各行各业构建大型语言模型（LLM）智能体。我们发现，最成功的实现方案并非依赖复杂的框架或专用库，而是采用了简单、可组合的模式。

在这篇文章中，我们将分享我们从与客户合作以及自行构建智能体中学到的经验，并为开发者提供构建高效智能体的实用建议。

什么是智能体？

“智能体”一词有多种定义。有些客户将智能体定义为完全自主运行的系统，它们能在长时间内独立运作，并利用各种工具完成复杂任务。另一些客户则用该术语描述更具规范性的实现，它们遵循预定义的工作流。在 Anthropic，我们将所有这些变体都归类为智能体系统，但在架构上，我们对工作流和智能体进行了重要区分：

• • 工作流是指LLM和工具通过预定义的代码路径进行编排的系统。
• • 智能体则是指LLM能够动态地指导自身流程和工具使用，并掌控任务完成方式的系统。

下文我们将详细探讨这两种智能体系统。在附录1（“实践中的智能体”）中，我们描述了客户在使用这些系统时发现特别有价值的两个领域。

何时（以及何时不）使用智能体

在构建LLM应用时，我们建议寻找最简单的解决方案，并仅在必要时增加复杂性。这可能意味着根本不需要构建智能体系统。智能体系统通常以牺牲延迟和成本为代价，换取更好的任务性能，因此您应该考虑这种权衡何时是合理的。

当需要更多复杂性时，工作流为明确定义的任务提供了可预测性和一致性，而智能体则在需要灵活性和模型驱动的决策时是更好的选择。然而，对于许多应用来说，通常通过检索和上下文示例优化单次LLM调用就已足够。

何时以及如何使用框架

有许多框架可以简化智能体系统的实现，包括：

• • LangChain 的 LangGraph；
• • Amazon Bedrock 的 AI Agent 框架；
• • Rivet，一个拖放式GUI LLM工作流构建器；以及
• • Vellum，另一个用于构建和测试复杂工作流的GUI工具。

这些框架通过简化调用LLM、定义和解析工具以及将调用串联起来等标准底层任务，使开发者能够轻松上手。然而，它们通常会创建额外的抽象层，这可能会模糊底层提示和响应，从而增加调试难度。它们还可能诱使您在简单的设置足以满足需求时增加不必要的复杂性。

我们建议开发者从直接使用LLM API开始：许多模式只需几行代码即可实现。如果您确实使用了框架，请确保您理解其底层代码。对底层机制的错误假设是导致客户出错的常见原因。

请参阅我们的指南以获取一些示例实现。

构建块、工作流和智能体

在本节中，我们将探讨我们在生产环境中常见的智能体系统模式。我们将从我们的基础构建块——增强型LLM开始，并逐步增加复杂性，从简单的组合工作流到自主智能体。

构建块：增强型LLM

智能体系统的基本构建块是经过检索、工具和记忆等增强功能的LLM。我们目前的模型可以主动使用这些能力——生成自己的搜索查询、选择合适的工具以及决定保留哪些信息。

我们建议关注实现的两个关键方面：根据您的特定用例定制这些功能，并确保它们为您的LLM提供一个简单、文档完善的接口。虽然有多种方法可以实现这些增强功能，但其中一种方法是通过我们最近发布的模型上下文协议(MCP)，它允许开发者通过简单的客户端实现与不断增长的第三方工具生态系统集成。

在本文的其余部分，我们将假设每次LLM调用都能够访问这些增强功能。

工作流：提示链

提示链将任务分解为一系列步骤，其中每次LLM调用都处理前一次调用的输出。您可以在任何中间步骤添加程序化检查（参见下图中的“门控”），以确保流程仍在正轨上。

何时使用此工作流： 此工作流非常适合任务可以轻松、清晰地分解为固定子任务的情况。主要目标是通过使每次LLM调用成为更简单的任务，以延迟换取更高的准确性。

提示链有用的示例：

• • 生成营销文案，然后将其翻译成不同的语言。
• • 撰写文档大纲，检查大纲是否符合特定标准，然后根据大纲撰写文档。

工作流：路由

路由对输入进行分类，并将其导向专门的后续任务。此工作流允许关注点分离，并构建更专业的提示。如果没有此工作流，优化一种输入可能会损害其他输入的性能。

何时使用此工作流： 路由适用于复杂的任务，其中存在需要单独处理的不同类别，并且分类可以由LLM或更传统的分类模型/算法准确处理。

路由有用的示例：

• • 将不同类型的客户服务查询（一般问题、退款请求、技术支持）导向不同的下游流程、提示和工具。
• • 将简单/常见问题路由到像 Claude 3.5 Haiku 这样的小型模型，将困难/不常见问题路由到像 Claude 3.5 Sonnet 这样更强大的模型，以优化成本和速度。

工作流：并行化

LLM有时可以同时处理一项任务，并以程序化方式聚合其输出。这种并行化工作流有两种主要变体：

• • 分段：将任务分解为独立运行的子任务。
• • 投票：多次运行相同的任务以获得多样化的输出。

何时使用此工作流： 当分解后的子任务可以并行化以提高速度，或者需要多角度或多次尝试以获得更高置信度的结果时，并行化是有效的。对于具有多重考虑的复杂任务，LLM在每次考虑都由单独的LLM调用处理时通常表现更好，从而可以集中精力处理每个特定方面。

并行化有用的示例：

• • 分段：
• • 实施护栏，其中一个模型实例处理用户查询，而另一个实例筛选不当内容或请求。这往往比让同一个LLM调用同时处理护栏和核心响应表现更好。
• • 自动化LLM性能评估，其中每次LLM调用评估模型在给定提示下的不同性能方面。
• • 投票：
• • 审查一段代码是否存在漏洞，其中几个不同的提示审查代码并在发现问题时进行标记。
• • 评估给定内容是否不当，多个提示评估不同方面或需要不同的投票阈值来平衡误报和漏报。

工作流：编排器-工作器

在编排器-工作器工作流中，一个中央LLM动态地分解任务，将其委派给工作器LLM，并综合它们的结果。

何时使用此工作流： 此工作流非常适合复杂的任务，其中您无法预测所需的子任务数量（例如，在编码中，需要更改的文件数量以及每个文件中更改的性质可能取决于任务）。尽管它在拓扑上相似，但与并行化的关键区别在于其灵活性——子任务不是预定义的，而是由编排器根据特定输入确定的。

编排器-工作器有用的示例：

• • 每次对多个文件进行复杂更改的编码产品。
• • 涉及从多个来源收集和分析信息以获取可能相关信息的搜索任务。

工作流：评估器-优化器

在评估器-优化器工作流中，一个LLM调用生成响应，而另一个LLM调用在循环中提供评估和反馈。

何时使用此工作流： 当我们有明确的评估标准，并且迭代优化能带来可衡量的价值时，此工作流尤其有效。适合此工作流的两个迹象是：首先，当人类明确表达反馈时，LLM的响应可以显著提升；其次，LLM能够提供此类反馈。这类似于人类作者在撰写精良文档时可能经历的迭代写作过程。

评估器-优化器有用的示例：

• • 文学翻译，其中翻译LLM最初可能无法捕捉到细微之处，但评估器LLM可以提供有用的批评。
• • 需要多轮搜索和分析以收集全面信息的复杂搜索任务，其中评估器决定是否需要进一步搜索。

智能体

随着LLM在理解复杂输入、进行推理和规划、可靠使用工具以及从错误中恢复等关键能力上日趋成熟，智能体正在生产环境中崭露头角。智能体通过人类用户的命令或互动讨论开始工作。一旦任务明确，智能体便独立规划和操作，并可能返回给人类以获取更多信息或判断。在执行过程中，智能体在每一步（例如工具调用结果或代码执行）从环境中获取“真实情况”以评估其进展至关重要。智能体随后可以在检查点或遇到障碍时暂停以获取人类反馈。任务通常在完成后终止，但通常也会包含停止条件（例如最大迭代次数）以保持控制。

智能体可以处理复杂的任务，但其实现通常很简单。它们通常只是LLM在循环中根据环境反馈使用工具。因此，清晰周到地设计工具集及其文档至关重要。我们在附录2（“提示工程您的工具”）中详细阐述了工具开发的最佳实践。

何时使用智能体： 智能体可用于开放式问题，其中难以或不可能预测所需的步骤数量，并且您无法硬编码固定路径。LLM可能会运行许多轮次，您必须对其决策能力有一定程度的信任。智能体的自主性使其成为在受信任环境中扩展任务的理想选择。

智能体的自主性意味着更高的成本以及累积错误的潜力。我们建议在沙盒环境中进行广泛测试，并设置适当的护栏。

智能体有用的示例：

以下示例来自我们自己的实现：

• • 一个用于解决 SWE-bench 任务的编码智能体，这些任务涉及根据任务描述对多个文件进行编辑；
• • 我们的“计算机使用”参考实现，其中 Claude 使用计算机完成任务。

组合和定制这些模式

这些构建块并非规定性的。它们是开发者可以根据不同用例进行塑造和组合的常见模式。成功的关键，与任何LLM功能一样，在于衡量性能并迭代实现。重申一遍：您应该仅在它能显著改善结果时才考虑增加复杂性。

总结

在LLM领域取得成功并非在于构建最复杂的系统，而在于构建最适合您需求的系统。从简单的提示开始，通过全面的评估进行优化，并仅在更简单的解决方案不足时才添加多步骤的智能体系统。

在实现智能体时，我们尝试遵循三个核心原则：

1. 1. 在智能体设计中保持简洁性。
2. 2. 通过明确展示智能体的规划步骤来优先考虑透明度。
3. 3. 通过全面的工具文档和测试，精心设计你的智能体-计算机接口（ACI）。

框架可以帮助您快速入门，但当您转向生产环境时，请不要犹豫减少抽象层并使用基本组件进行构建。通过遵循这些原则，您可以创建不仅强大而且可靠、可维护并受到用户信任的智能体。

致谢

由 Erik Schluntz 和 Barry Zhang 撰写。这项工作借鉴了我们在 Anthropic 构建智能体的经验以及客户分享的宝贵见解，对此我们深表感谢。

附录1：实践中的智能体

我们与客户的合作揭示了AI智能体两个特别有前景的应用，它们展示了上述模式的实际价值。这两个应用都说明了智能体如何为需要对话和行动、有明确成功标准、支持反馈循环并整合有意义的人工监督的任务带来最大价值。

A. 客户支持

客户支持将熟悉的聊天机器人界面与通过工具集成增强的功能相结合。这非常适合更开放的智能体，因为：

• • 支持交互自然地遵循对话流程，同时需要访问外部信息和操作；
• • 可以集成工具来拉取客户数据、订单历史和知识库文章；
• • 退款或更新工单等操作可以通过程序化方式处理；以及
• • 成功可以通过用户定义的解决方案清晰衡量。

几家公司通过基于使用量的定价模式（仅对成功解决的问题收费）证明了这种方法的可行性，显示出他们对智能体有效性的信心。

B. 编码智能体

软件开发领域已显示出LLM功能的巨大潜力，其能力从代码补全发展到自主问题解决。智能体尤其有效，因为：

• • 代码解决方案可以通过自动化测试进行验证；
• • 智能体可以使用测试结果作为反馈来迭代解决方案；
• • 问题空间定义明确且结构化；以及
• • 输出质量可以客观衡量。

在我们自己的实现中，智能体现在可以仅根据拉取请求描述解决 SWE-bench Verified 基准测试中的真实 GitHub 问题。然而，尽管自动化测试有助于验证功能，但人工审查对于确保解决方案符合更广泛的系统要求仍然至关重要。

附录2：对工具进行提示词工程处理

无论您正在构建哪种智能体系统，工具都可能是您智能体的重要组成部分。工具通过在我们的API中指定其确切结构和定义，使Claude能够与外部服务和API交互。当Claude响应时，如果它计划调用工具，它将在API响应中包含一个工具使用块。工具定义和规范应像您的整体提示一样，给予同等的提示工程关注。在这个简短的附录中，我们将描述如何对您的工具进行提示工程。

通常有几种方法可以指定相同的操作。例如，您可以通过编写差异（diff）来指定文件编辑，或者通过重写整个文件。对于结构化输出，您可以将代码放在Markdown中或JSON中。在软件工程中，这些差异是表面上的，可以无损地相互转换。然而，有些格式对于LLM来说比其他格式更难编写。编写差异需要知道在新代码写入之前，块头中有多少行正在更改。将代码写入JSON（与Markdown相比）需要对换行符和引号进行额外的转义。

我们对工具格式选择的建议如下：

• • 给模型足够的令牌来“思考”，以免它把自己写进死胡同。
• • 保持格式接近模型在互联网上自然文本中看到的内容。
• • 确保没有格式化“开销”，例如必须准确计算数千行代码，或对它编写的任何代码进行字符串转义。

一个经验法则是思考人机交互界面（HCI）需要投入多少精力，并计划在创建良好的智能体-计算机接口（ACI）上投入同样多的精力。以下是一些关于如何做到这一点的思考：

• • 设身处地为模型着想。根据描述和参数，使用这个工具是否显而易见，还是需要仔细思考？如果是这样，那么对于模型来说可能也是如此。一个好的工具定义通常包括示例用法、边缘情况、输入格式要求以及与其他工具的清晰边界。
• • 您如何更改参数名称或描述以使其更明显？将其视为为团队中的初级开发者编写一份出色的文档字符串。当使用许多相似的工具时，这一点尤其重要。
• • 测试模型如何使用您的工具：在我们的工作台中运行许多示例输入，查看模型犯了哪些错误，并进行迭代。
• • 对您的工具进行防错法（Poka-yoke）。更改参数，使其更难犯错。

在为 SWE-bench 构建智能体时，我们实际上在优化工具上花费的时间比优化整体提示的时间更多。例如，我们发现当智能体移出根目录后，模型在使用相对文件路径的工具时会犯错。为了解决这个问题，我们将工具更改为始终要求绝对文件路径——我们发现模型完美地使用了这种方法。

请注意：原文中的一些链接可能需要魔法。