Anthropic 官方指南：构建高效的 AI 智能体

在过去一年里，我们与跨行业的数十支团队合作，构建基于大语言模型（LLM）的智能体。我们一致观察到：最成功的实现并没有使用复杂的框架或专门的库，而是用简单、可组合的模式来构建。

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

什么是智能体？¶

“智能体（Agent）”可以有多种定义。一些客户把智能体定义为完全自主的系统，能够长时间独立运行，使用各种工具完成复杂任务。另一些客户则用这一术语描述更具规约性的实现，按预定义的工作流执行。在 Anthropic，我们把所有这些不同形态都归为智能体系统（agentic systems），但在架构上对工作流（workflows）和智能体（agents）做出重要区分：

工作流是指通过预定义代码路径来编排 LLM 和工具的系统。
智能体则是指由 LLM 动态指挥自身流程和工具使用、对如何完成任务保持控制权的系统。

下面我们将详细探讨这两种智能体系统。在附录 1: 智能体实践中，我们描述了客户从这类系统中获得特别价值的两个领域。

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

在使用 LLM 构建应用时，我们建议先寻找最简单可行的解决方案，仅在必要时增加复杂性。这甚至可能意味着完全不构建智能体系统。智能体系统通常以延迟和成本为代价换取更好的任务表现，你应当判断这种取舍是否合理。

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

何时以及如何使用框架¶

有许多框架可以让智能体系统更易实现，包括：

Claude Agent SDK；
AWS 推出的 Strands Agents SDK；
Rivet，一个拖拽式的 GUI LLM 工作流构建器；以及
Vellum，另一款用于构建和测试复杂工作流的 GUI 工具。

这些框架通过简化诸如调用 LLM、定义和解析工具、串联调用等标准底层任务，使开发更容易上手。但它们经常会引入额外的抽象层，掩盖底层的提示词与响应，让调试更困难。它们也容易诱使开发者在更简单的方案就足够时引入不必要的复杂性。

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

可以参考我们的 cookbook 中的示例实现。

构建模块、工作流与智能体¶

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

构建模块：增强型 LLM¶

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

我们建议在实现时聚焦两个关键方面：让这些能力贴合你的具体用例，并确保它们为你的 LLM 提供易用且文档完善的接口。实现这些增强的方法有很多，其中之一是我们最近发布的 Model Context Protocol，它让开发者可以通过简单的客户端实现，与日益丰富的第三方工具生态进行集成。

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

工作流：提示链¶

提示链（Prompt chaining）将一个任务分解成一系列步骤，每次 LLM 调用都处理上一次的输出。你可以在任意中间步骤上加入程序化检查（即下图中的“gate”），以确保流程仍在正轨上。

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

提示链有用的示例：

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

工作流：路由¶

路由（Routing）对输入进行分类，并将其分发到专门的后续任务。该工作流支持关注点分离，并允许构建更专门化的提示词。如果没有这种工作流，针对某类输入做优化可能会损害其他输入的表现。

何时使用此工作流：路由适用于存在不同类别且更适合分开处理的复杂任务，以及能够通过 LLM 或更传统的分类模型/算法准确进行分类的任务。

路由有用的示例：

将不同类型的客户服务请求（一般问题、退款请求、技术支持）分发到不同的下游流程、提示词和工具。
将简单 / 常见问题路由到更小、性价比更高的模型（如 Claude Haiku 4.5），将困难 / 不寻常问题路由到能力更强的模型（如 Claude Sonnet 4.5），以获得最佳综合表现。

工作流：并行化¶

LLM 有时可以同时处理一个任务，并通过程序化的方式聚合输出。这种并行化（Parallelization）工作流主要有两种变体：

分块（Sectioning）：将任务拆成可并行运行的独立子任务。
投票（Voting）：多次运行同一任务以获得多样化的输出。

何时使用此工作流：当划分的子任务可以并行化以提高速度，或者当需要多个视角或尝试以获得更高置信度的结果时，并行化是有效的。对于具有多个考量因素的复杂任务，如果每个考量因素都由一个单独的 LLM 调用来处理，从而允许专注于每个具体方面，LLM 通常表现得更好。

并行化有用的示例：

分块：
- 实现护栏机制——一个模型实例处理用户查询，另一个则筛查不当内容或请求。这通常比让同一次 LLM 调用兼顾护栏机制与核心回复表现更好。
- 自动化评估 LLM 表现，每次 LLM 调用评估给定提示词上模型表现的不同侧面。
投票：
- 审查一段代码以发现漏洞——多个不同的提示词分别审查并标记发现的问题。
- 评估一段内容是否不当——多个提示词评估不同方面，或要求不同的投票阈值，以平衡误报和漏报。

工作流：协调器—工作者¶

在协调器—工作者（Orchestrator-workers）工作流中，一个中央 LLM 动态地拆分任务，将其委派给工作者 LLM，并对它们的结果进行整合。

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

协调器—工作者有用的示例：

每次都需要对多个文件做复杂改动的编程产品。
涉及从多个来源收集和分析信息以获取可能相关信息的搜索任务。

工作流：评估器—优化器¶

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

何时使用此工作流程：当我们拥有明确的评估标准，且迭代优化能够带来可衡量的价值时，这种工作流程尤为有效。适用这种流程的两个显著标志是：首先，当人类清晰表达反馈时，LLM 的响应能够被明显改进；其次，LLM 本身能够提供此类反馈。这类似于人类作家在创作一篇精炼文档时所经历的迭代写作过程。

适用场景： 当我们有清晰的评估标准，并且迭代式改进能带来可衡量价值时，这种工作流尤为有效。两个明显的契合信号是：第一，当人类清楚表达反馈时，LLM 的回答能够明显得到改进；第二，LLM 自己也能给出这种反馈。这类似于人类作家在创作一份精良文档时可能经历的迭代写作过程。

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

文学翻译——翻译器 LLM 一开始可能捕捉不到某些细微差别，而评估器 LLM 可以提供有用的批评论。
需要多轮搜索和分析以收集全面信息的复杂搜索任务，其中评估器决定是否需要进一步搜索。

智能体¶

随着 LLM 在理解复杂输入、进行推理规划、可靠地使用工具以及从错误中恢复等关键能力上的成熟，智能体正逐步应用于实际生产场景。智能体的工作始于人类用户的指令或与之进行的交互讨论。一旦任务明确，智能体便会独立规划并执行操作，可能会返回到人类用户处从而获取进一步信息或判断。在执行过程中，智能体在每一步从环境中获取 “真实数据（ground truth）”（如工具调用结果或代码执行结果）以评估进展至关重要。然后，智能体可在检查点或遇到障碍时暂停以获取人类反馈。任务通常在完成时终止，但为保持控制，设置停止条件（如最大迭代次数）也很常见。

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

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

智能体的自主性也意味着更高的成本，以及错误累积（compounding errors）的可能。我们建议在沙盒环境中进行充分测试，并配套合适的护栏机制。

智能体有用的示例：

下面的例子来自我们自己的实现：

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

组合和定制这些模式¶

这些构建模块并非教条。它们是常见模式，开发者可以根据不同用例对其进行塑造和组合。与所有 LLM 功能一样，成功的关键在于衡量性能并对实现方式进行迭代。再强调一遍：你应当_仅在能够明显改善结果时_才增加复杂性。

总结¶

在 LLM 领域，成功不是构建最复杂的系统，而是构建最_合适_你需求的系统。先从简单的提示词开始，通过全面的评估来优化它们，仅当更简单的方案不够用时再加入多步骤的智能体系统。

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

让智能体设计保持简洁。
通过显式展示智能体的规划步骤来优先保证透明性。
通过完善的工具文档与测试精心设计你的智能体—计算机接口（ACI）。

框架可以帮助你快速入门，但在转向生产时，不要犹豫去减少抽象层、用基础组件进行构建。通过遵循这些原则，你可以打造出不仅功能强大，而且可靠、可维护并受用户信任的智能体。

致谢¶

本文由 Erik S. 与 Barry Zhang 撰写。本文借鉴了我们在 Anthropic 构建智能体的经验，以及客户分享的宝贵见解，对此我们深表感谢。

附录 1：智能体实践¶

我们与客户的合作实践揭示了 AI 智能体的两个特别有前景的应用场景，这些场景充分展现了上述模式的实用价值。这两类应用均表明，当任务同时需要对话交互与实际行动、具备明确的成功评判标准、支持反馈循环机制，并且融入了有意义的人类监督时，智能体能够发挥最大价值。

A. 客户支持¶

客户支持把熟悉的聊天机器人界面与通过工具集成获得的增强能力结合起来。它天然适合更开放式的智能体，因为：

支持类交互天然遵循对话流程，同时需要访问外部信息和执行操作；
可以集成工具来拉取客户数据、订单历史和知识库文章；
退款发起或工单更新等操作可以通过程序化方式完成；并且
成功标准可以通过用户认可的解决结果清晰衡量。

客户支持将熟悉的聊天机器人界面与通过工具集成增强的功能相结合。这对于更开放式的智能体来说是天作之合，因为：

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

多家公司已通过基于使用量的定价模式证明了这种方法的可行性，该模式仅对成功解决的问题收费，彰显了其对智能体效能的信心。

B. 编码智能体¶

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

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

在我们自己的实现中，智能体如今已能够仅依据 PR 描述来解决 SWE-bench Verified 基准中的真实 GitHub issue。然而，尽管自动化测试有助于验证功能，人类评审在确保方案契合更广泛的系统要求方面仍然不可或缺。

附录 2：为你的工具做提示词工程¶

无论你构建哪种智能体系统，工具都可能是其中重要组成部分。工具允许 Claude 通过在我们的 API 精确地指定它们的结构和定义来与外部服务和 API 交互。当 Claude 给出响应时，如果它打算调用某个工具，API 响应中会包含一个工具使用块（tool use block）。工具的定义和规范应当与你整体的提示词获得同等程度的提示词工程关注。在这篇简短的附录中，我们描述如何为你的工具做提示词工程。

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

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

给模型足够的 token 让它“思考”，避免它把自己写进死胡同。
让格式尽量贴近模型在互联网文本中自然见到的样子。
确保不存在格式上的“开销”，比如要求精确统计成千上万行代码，或对它写出的代码做字符串转义。

一个经验法则是：想想人们花了多少精力在人机交互（human-computer interfaces，简写HCI）上，就计划在打造好的 智能体—计算机接口（agent-computer interfaces ，简写ACI） 上投入同等精力。下面是一些建议：

把自己代入模型的位置。从工具的描述和参数来看，怎么用这个工具是否一目了然，还是你也需要仔细思考？如果是后者，那么对模型来说很可能也是如此。一个好的工具定义通常包含示例用法、边界情况、输入格式要求，以及与其他工具的清晰边界。
你能否通过修改参数名或描述让事情更清晰？把这看作是给团队里一位初级开发者写一份出色的文档字符串（docstring）。在使用许多相似工具时，这一点尤其重要。
测试模型如何使用你的工具：在我们的 workbench 中跑大量示例输入，观察模型会犯哪些错误，然后迭代。
给你的工具做 Poka-yoke（防呆）。修改参数，让出错变得更难。

在为 SWE-bench 构建智能体的过程中，我们实际上花在优化工具上的时间比花在整体提示词上的还多。例如，我们发现当智能体离开根目录后，模型在使用相对路径的工具时容易出错。为修复这一点，我们改成始终要求绝对路径——结果发现模型完美地用对了这种方式。