在过去的一年里，我们与数十个团队合作，在各个行业构建了很多大型语言模型（LLM）Agent。其中最成功的实现都没有使用复杂的框架或专门的库。相反，构建它们时用的是简单、可组合的一些模式。

在这篇文章中，我们分享了从与客户合作和自己构建 Agent 的经验中学到的知识，并为开发人员提供了构建有效 Agent 的实用建议。

什么是 Agent？ 

“Agent”可以用几种方式来定义。一些客户将 Agent 定义为完全自主的系统，它们在较长时间内独立运行，使用各种工具来完成复杂的任务。其他人使用该术语来描述遵循一些预定义工作流的，更具规范性的实现。在 Anthropic，我们将所有这些变体都归类为 Agentic 系统，但我们在工作流 和 Agent 之间划出了一个重要的架构区别：

• 工作流是通过预定义代码路径编排 LLM 和工具的系统。
• 另一方面，Agent 是由 LLM 动态指导其自身的流程和工具使用的系统，从而控制其完成任务的方式。

下面，我们将详细探讨这两种类型的 Agent 系统。在附录 1（“实践中的 Agent”）中，我们描述了客户发现使用此类系统会特别有价值的两个领域。

何时（以及何时不使用）Agent 

在使用 LLM 构建应用程序时，我们建议找到最简单的解决方案，并且仅在需要时增加复杂性。这可能意味着完全不用构建 Agent 系统。Agent 系统通常会牺牲延迟和成本来换取更好的任务性能，你应该考虑这种权衡何时才是有意义的。

当需要更多复杂性时，工作流可为明确定义的任务提供可预测性和一致性，而当需要大规模灵活性和模型驱动的决策时，Agent 是更好的选择。但对于许多应用程序而言，使用检索和上下文示例来优化单个 LLM 调用通常就足够了。

何时以及如何使用框架 

有许多框架能让 Agent 系统更容易实现，包括：

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

这些框架通过简化标准的低级任务（如调用 LLM、定义和解析工具以及将不同的调用链接在一起）来降低入门门槛。但它们通常会创建额外的抽象层，这些抽象层可能会掩盖底层的提示和响应，使它们更难调试。当更简单的设置就够用时，它们还会让人们倾向于增加复杂性。

我们建议开发人员一开始就直接使用 LLM API：许多模式用几行代码就能实现。如果你确实在使用某个框架，请确保你了解底层代码。对底层内容的错误假设是客户错误的常见来源。

请参阅我们的示例菜谱（https://github.com/anthropics/anthropic-cookbook/tree/main/patterns/agents），了解一些示例实现。

构建块、工作流和 Agent 

在本节中，我们将探讨在生产中看到的一些 Agent 系统的常见模式。我们将从基础构建块（增强型 LLM）开始，并逐步增加复杂性，从简单的组合工作流谈到自主 Agent。

构建块：增强型 LLM 

Agent 系统的基本构建块是增强了检索、工具和记忆等功能的一个 LLM。我们当前的模型可以主动使用这些能力，生成自己的搜索查询、选择合适的工具以及判断要保留哪些信息。

增强型 LLM

对于这种实现，我们建议关注两个关键方面：根据你的特定用例定制这些功能，并确保他们为你的 LLM 提供了简单、有良好文档的界面。有很多方法可以实现这些增强功能，一种方法是通过我们最近发布的模型上下文协议，它允许开发人员通过简单的客户端实现来同不断扩大的第三方工具生态系统集成起来。

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

工作流：提示链 

提示链将单个任务分解为一系列步骤，其中每个 LLM 调用都会处理前一个调用的输出。你可以在任何中间步骤上添加程序检查（参见下图中的“gate”），以确保流程仍在正常进行。

提示链工作流

何时使用这个工作流：该工作流非常适合可以轻松、干净地将任务分解为多个固定子任务的情况。这里的主要目标是让每个 LLM 调用成为更简单的任务，从而以牺牲延迟为代价获得更高的准确性。

适合提示链的示例：

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

工作流：路由 

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

路由工作流

何时使用这种工作流：路由非常适合复杂的任务，这些任务有不同的类别，最好单独处理，并且可以通过 LLM 或更传统的分类模型 / 算法准确分类。

适合路由的示例：

将不同类型的客户服务查询（一般问题、退款请求、技术支持）引导到不同的下游流程、提示和工具中。

将简单 / 常见问题路由到较小的模型（如 Claude 3.5 Haiku），将困难 / 不寻常的问题路由到更强大的模型（如 Claude 3.5 Sonnet），以优化成本和速度。

工作流：并行化 

LLM 有时可以同时处理一项任务，并以编程方式聚合其输出。这种工作流（并行化）有两个关键变体：

分段：将任务分解为多个并行运行的独立子任务。

投票：多次运行同一任务以获得不同的输出。

并行化工作流

何时使用这种工作流：当任务可以并行划分为多个子任务来提高速度，或者任务需要多个视角或尝试以获得更高置信度的结果时，并行化是有效的。对于具有多个考虑因素的复杂任务，当每个考虑因素由单独的 LLM 调用处理时，多个 LLM 通常会表现得更好，这样每个 LLM 可以集中注意力关注某个特定方面。

适合并行化的示例：

分段：

实施护栏，其中一个模型实例处理用户查询，而另一个模型实例则筛选不适当的内容或请求。这往往比让同一个 LLM 调用同时处理护栏和核心响应效果更好。

自动评估 LLM 性能，其中每个 LLM 调用都会评估给定提示下模型性能的不同方面。

投票：

审查一段代码是否存在漏洞，其中几个不同的提示会各自审查代码并在发现问题时标记代码。

评估给定内容是否不合适，多个提示分别评估不同方面，或需要不同的投票阈值来平衡误报和漏报。

工作流：编排器 -  

工作者（Orchestrator-workers） 

在编排器 - 工作者工作流中，中央 LLM 动态分解任务，将其委托给工作者 LLM，并负责综合后者的结果。

编排器 - 工作者工作流

何时使用这种工作流：这种工作流非常适合那种你无法预测需要哪些子任务的复杂任务（例如在编程中，需要更改的文件数量以及每个文件中更改的参数可能要取决于具体的任务）。虽然它在拓扑上很像并行化，但与后者的主要区别在于其灵活性——子任务不是预定义的，而是由编排器根据特定输入来确定的。

适合编排器 - 工作者的示例：

每次要对多个文件进行复杂更改的编程产品。

需要从多个来源收集和分析信息以获取可能的相关信息的搜索任务。

工作流：评估器 - 优化器 

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

评估器 - 优化器工作流

何时使用这种工作流：当我们有明确的评估标准，并且迭代的改进提供了可衡量的价值时，这种工作流特别有用。两个说明它非常合适的标志是：首先，当人类表达反馈时，LLM 的响应可以明显改善；其次，LLM 可以提供这样的反馈。这类似于人类作者在制作精美文档时可能经历的迭代写作过程。

适合评估器 - 优化器的示例：

• 文学翻译，其中存在 LLM 翻译器一开始可能无法捕捉到的细微差别，但 LLM 评估器可以提供有用的批评意见。
• 复杂的搜索任务，其需要多轮搜索和分析才能收集全面的信息，评估者决定是否有必要进行进一步搜索。

Agent 

随着 LLM 在关键能力方面的成熟——这些能力包括了理解复杂输入、参与推理和规划、可靠地使用工具以及从错误中恢复——Agent 正在投入生产环境。Agent 以人类用户的命令或与人类用户的互动讨论为起点开始工作。一旦任务得到明确，Agent 就会独立计划和运作，并可能回来找人类获取更多信息或判断。在执行过程中，Agent 必须从每个步骤（例如工具调用结果或代码执行）的所处环境中获得“基本事实”以评估其进度。然后，Agent 可以在检查点或遇到阻碍时暂停以获得人工反馈。任务通常在完成后终止，但通常也会包含停止条件（例如最大迭代次数）以保持控制。

Agent 可以处理复杂的任务，但它们的实现通常很简单。它们通常只是一些使用了基于环境反馈的工具的 LLM。因此，清晰而周到地设计工具集及其文档是非常重要的。我们在附录 2（“对你的工具做提示工程”）中扩展了工具开发的最佳实践。

自主 Agent

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

Agent 的自主性意味着更高的成本，还可能产生复合错误。我们建议在沙盒环境中进行广泛的测试，并采用适当的防护措施。

适合 Agent 的示例：

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

• 一个用于解决 SWE-bench 任务的编程 Agent，它需要根据任务描述来编辑许多文件；
• 我们的“计算机使用”参考实现，其中 Claude 使用一台计算机来完成任务。

一个编程 Agent 的高级流程

组合和自定义这些模式 

这些构建块不是死板的。它们是开发人员可以用来塑造和组合，以适应不同用例的一些常见模式。与任何 LLM 功能一样，成功的关键在于衡量性能并迭代实现。重复一遍：只有当更多复杂性可以明显改善结果时，才应考虑增加复杂性。

总   结 

在 LLM 领域，取得成功不在于构建最复杂的系统，而在于构建适合你需求的系统。应该从简单的提示开始，通过全面评估来优化它，并且只在更简单的解决方案无法满足要求时才添加多步骤 Agent 系统。

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

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

框架可以帮助你快速入门，但在进入生产阶段时，请果断地减少抽象层并使用基本组件来构建。只要遵循这些原则，你就能创建功能强大且可靠、可维护并受到用户信任的 Agent。

附录 1：实践中的 Agent 

我们与客户的合作揭示了两种特别有前景的 AI Agent 应用，它们展示了上述模式的实际价值。这两种应用都说明了 Agent 如何为那些需要对话和行动、具有明确的成功标准、启用反馈循环并集成良好的人工监督的任务尽可能增加价值。

A. 客户支持 

客户支持通过集成的工具结合了熟悉的聊天机器人界面与一系列增强功能。这自然适合更开放的 Agent，因为：

客户支持交互过程天然地遵循对话流程，同时需要访问外部信息和操作；

可以集成工具来提取客户数据、订单历史记录和知识库文章；

可以通过编程方式处理诸如发放退款或更新票证之类的操作；

可以通过用户定义的解决方案明确衡量成功指标。

几家公司已经通过基于使用率的定价模型证明了这种方法的可行性，这些模型仅对成功的解决方案收费，显示出对其 Agent 效率的信心。

B. 编程 Agent 

软件开发领域已经显示出 LLM 的巨大潜力，其能力已从简单的代码自动完成发展到了自主解决问题。Agent 之所以特别有效，是因为：

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

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

附录 2：对你的工具做提示工程 

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

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

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

• 在模型陷入困境之前，给它足够的 token 来“思考”。
• 让格式与模型在互联网上看到的那些自然出现的内容尽量接近。
• 确保没有格式化“开销”，例如必须准确计算数千行代码，或对编写的任何代码进行字符串转义。

一个经验法则是考虑人机界面（HCI）需要付出多少努力，并计划投入同样多的精力来创建良好的 Agent- 计算机界面（ACI）。以下是一些关于如何做到这一点的建议：

• 把自己放在模型的角度。根据描述和参数，这个工具的用法是显而易见，还是需要仔细考虑？如果是后者，那么对于模型来说可能也是如此。一个好的工具定义通常包括示例用法、边缘情况、输入格式要求以及与其他工具的明确界限。
• 如何更改参数名称或描述来让各种事情更明显？可以把这一步看作是为你团队中的初级开发人员编写出色的文档。在使用许多类似的工具时，这一点尤为重要。
• 测试模型如何使用你的工具：在我们的工作台中运行许多示例输入，以查看模型犯了哪些错误，然后进行迭代。
• 让你的工具减少错误。更改参数，使其更难出错。

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

原文链接：

https://www.anthropic.com/research/building-effective-agents