[译文]构建高效的智能体

在过去的一年里，我们与多个团队合作，构建了各种行业的大型语言模型（LLM）智能体。成功的实现案例中，最有效的实现方式并不是使用复杂的框架或专门的库，而是使用简单且可组合的模式来构建。

在本文中，我们分享了与客户合作并自行构建智能体的经验，并为开发者提供了构建高效智能体的实用建议。

什么是智能体？

"智能体" 这个词可以有多种定义。部分客户将智能体定义为能够独立运作的完全自主系统，能够在较长时间内使用各种工具完成复杂任务。而其他人则将其用来描述遵循预定义工作流的更具指令性的实现方式。在Anthropic，我们将这些变体统称为智能系统，但在架构上做出重要的区分：工作流和智能体。

• 工作流是通过预定义的代码路径来协调LLM和工具的系统。
• 智能体则是让LLM根据自己的决策动态地指引自身的流程和工具使用，并控制完成任务的方式。

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

何时使用智能体，何时不使用

在构建LLM应用时，我们建议找到最简单的解决方案，仅在必要时增加复杂性。这可能意味着根本不需要构建智能体系统。智能体系统通常需要在更高的任务性能和延迟、成本之间进行权衡，因此你需要考虑这种权衡是否合适。

在需要更多复杂性的情况下，工作流适用于那些任务明确且可预测的场景，而智能体则更适合需要灵活性和基于模型的决策的大规模任务。但对于许多应用，优化单一的LLM调用，通过检索和上下文示例，通常已经足够了。

何时以及如何使用框架

有许多框架可以帮助实现智能体系统，包括：

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

这些框架通过简化调用LLM、定义和解析工具、以及将调用链式连接起来，帮助开发者快速入门。然而，它们通常会增加额外的抽象层，这可能会使底层的提示和响应变得不那么清晰，从而更难调试。它们也可能会让人产生一种复杂化的诱惑，而实际上简单的设置就足够了。

我们建议开发者先直接使用LLM的API：很多模式可以通过几行代码实现。如果你选择使用框架，确保你理解底层的代码。对底层代码的错误假设是客户出错的常见原因。

请参阅我们的食谱，了解一些示例实现。

构建块、工作流和智能体

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

构建块：增强型LLM

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

我们建议重点关注实现的两个关键方面：根据你的特定用例定制这些功能，并确保它们为LLM提供一个易于使用、良好文档化的接口。尽管有许多方式实现这些增强功能，但一种方法是通过我们最近发布的模型上下文协议，它允许开发者通过简单的客户端实现与第三方工具生态系统的集成。

在本文的其余部分，我们假设每次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领域取得成功并不是构建最复杂的系统，而是构建最适合自己需求的系统。首先使用简单的提示，利用全面的评估进行优化，只有在更简单的解决方案不足时才添加多步骤的智能体系统。

在实现智能体时，我们尽量遵循以下三个核心原则：

• 保持智能体设计的简洁性；
• 优先确保透明性，明确显示智能体的规划步骤；
• 通过深入的工具文档和测试精心设计智能体与计算机的接口（ACI）。

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

致谢

本文由Erik Schluntz和Barry Zhang编写。本工作借鉴了我们在Anthropic构建智能体的经验，并感谢客户分享的宝贵见解。

附录1：智能体的实践

我们与客户的合作揭示了两个特别有前景的智能体应用场景，展示了上述模式在实践中的价值。两者都说明了智能体在需要对话和行动、具有明确成功标准、允许反馈循环，并集成有意义的人类监督的任务中能够带来最大价值。

1. 客户支持
   客户支持结合了传统的聊天机器人界面与增强的工具集成能力。这自然适合更开放的智能体，因为：

• 支持交互本身遵循对话流，同时需要访问外部信息和执行动作；
• 工具可以集成以提取客户数据、订单历史、知识库文章；
• 诸如发放退款或更新工单之类的操作可以通过编程处理；
• 成功可以通过用户定义的解决方案来清晰度量。

几家公司通过基于使用量的定价模型展示了这种方法的可行性，这种模型仅对成功的解决方案收费，显示出它们对智能体效果的信心。

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

• 代码解决方案可以通过自动化测试来验证；
• 智能体可以利用测试结果作为反馈，反复优化解决方案；
• 问题空间清晰且结构化；
• 输出质量可以通过客观的方式衡量。

在我们的实施中，智能体现在能够仅凭拉取请求描述解决实际的GitHub问题。然而，尽管自动化测试帮助验证功能，人工审查仍然至关重要，以确保解决方案符合更广泛的系统需求。

附录2：提示工程化你的工具

无论你在构建哪种智能体系统，工具都可能是其中的重要部分。工具使得Claude能够通过指定其结构和定义与外部服务和API进行交互。当Claude响应时，如果它计划调用工具，将在API响应中包含工具使用块。工具的定义和规格应该像整体提示一样，得到足够的提示工程化关注。