核验日期：2026-07-08

内容来源：Anthropic Engineering 官方技术博客。本文先作为 Claude Code 专区后台草稿入库，发布前应由内容人员复核标题、摘要、图片、来源链接与是否需要补充本站实践说明。

构建有效的智能体

我们曾与数十个跨行业构建 LLM 智能体的团队合作。最成功的实现始终使用简单、可组合的模式，而不是复杂框架。

来源：https://www.anthropic.com/engineering/building-effective-agents
发布日期：2024-12-19

过去一年里，我们与数十个跨行业构建大型语言模型（LLM）智能体的团队合作。我们反复看到，最成功的实现并不是依赖复杂框架或专门库。相反，它们采用的是简单、可组合的模式。

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

什么是智能体？

"Agent" 可以有多种定义。一些客户把智能体定义为能够在较长时间内独立运行、使用各种工具完成复杂任务的完全自主系统。另一些客户则用这个词描述更具规定性的实现，也就是遵循预定义工作流的系统。在 Anthropic，我们把所有这些变体都归为智能体式系统，但会在架构上区分工作流和智能体：

• 工作流是指 LLM 和工具通过预定义代码路径被编排起来的系统。
• 智能体则是指 LLM 动态引导自身流程和工具使用，并持续掌控如何完成任务的系统。

下面，我们会详细探讨这两类智能体式系统。在附录 1（“Agents in Practice”）中，我们描述了两个客户发现这类系统尤其有价值的领域。

何时使用智能体，以及何时不要使用

使用 LLM 构建应用时，我们建议尽可能寻找最简单的解决方案，只在确有必要时才提高复杂度。这可能意味着完全不构建智能体式系统。智能体式系统往往用更高的延迟和成本换取更好的任务表现，你需要判断这种权衡在什么时候是合理的。

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

何时以及如何使用框架

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

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

这些框架通过简化标准的底层任务，让你更容易开始，例如调用 LLM、定义和解析工具，以及把多次调用串联起来。不过，它们往往会创建额外的抽象层，遮蔽底层提示词和响应，使调试更困难。它们也可能诱导你在简单设置已经足够时引入复杂度。

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

可以参考我们的 cookbook，其中包含一些示例实现。

构建块、工作流和智能体

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

构建块：增强型 LLM

智能体式系统的基本构建块，是通过检索、工具和记忆等增强能力扩展后的 LLM。我们当前的模型可以主动使用这些能力：生成自己的搜索查询、选择合适工具，并判断需要保留哪些信息。

增强型 LLM

我们建议在实现时关注两个关键方面：根据你的具体用例定制这些能力，并确保它们为 LLM 提供简单、文档完善的接口。实现这些增强能力有很多方式，其中一种是使用我们最近发布的 Model Context Protocol。它允许开发者通过简单的客户端实现，接入不断扩大的第三方工具生态。

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

工作流：提示词链

提示词链会把一个任务分解为一系列步骤，每次 LLM 调用都处理前一次调用的输出。你可以在任意中间步骤加入程序化检查（见下图中的 "gate"），以确保流程仍在正确轨道上。

提示词链工作流

**何时使用这种工作流：**当任务可以轻松、清晰地分解为固定子任务时，这种工作流非常理想。它的主要目标是用延迟换取更高准确率：让每次 LLM 调用都面对一个更容易的任务。

提示词链适用的示例：

• 先生成营销文案，再将其翻译成另一种语言。
• 先撰写文档大纲，检查大纲是否满足特定标准，然后基于大纲撰写文档。

工作流：路由

路由会对输入进行分类，并将其导向专门的后续任务。这种工作流可以实现关注点分离，并构建更专门的提示词。如果没有这种工作流，为某一类输入做优化，可能会损害其他输入上的表现。

路由工作流

**何时使用这种工作流：**当复杂任务中存在明确类别，且不同类别更适合分开处理，同时分类又能由 LLM 或更传统的分类模型/算法准确完成时，路由会很有效。

路由适用的示例：

• 将不同类型的客户服务查询（一般问题、退款请求、技术支持）导向不同的下游流程、提示词和工具。
• 将简单/常见问题路由到 Claude Haiku 4.5 这类更小、更具成本效益的模型，把困难/少见问题路由到 Claude Sonnet 4.5 这类能力更强的模型，以优化整体表现。

工作流：并行化

LLM 有时可以同时处理一个任务，并通过程序汇总它们的输出。这种工作流，也就是并行化，主要表现为两种变体：

• 分段：把任务拆成可并行运行的独立子任务。
• **投票：**多次运行同一任务，以获得多样化输出。

并行化工作流

**何时使用这种工作流：**当拆分出的子任务可以通过并行化提升速度，或者需要多个视角/多次尝试以提高结果置信度时，并行化很有效。对于包含多个考虑因素的复杂任务，通常让每个考虑因素由一次单独的 LLM 调用处理会表现更好，因为这样模型可以集中注意力处理某个具体方面。

并行化适用的示例：

• 分段：
  • 实现护栏：一个模型实例处理用户查询，另一个模型实例筛查是否存在不当内容或请求。这通常比让同一次 LLM 调用同时处理护栏和核心回复效果更好。
  • 自动化评估 LLM 表现的 evals，其中每次 LLM 调用评估模型在给定提示词上的不同表现维度。
• 投票：
  • 审查一段代码是否存在漏洞，由多个不同提示词进行审查，如果发现问题就标记代码。
  • 评估一段内容是否不当，由多个提示词评估不同方面，或要求不同投票阈值，以平衡误报和漏报。

工作流：编排器-工作器

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

编排器-工作器工作流

**何时使用这种工作流：**这种工作流非常适合复杂任务，尤其是你无法预先判断需要哪些子任务时（例如在编码中，需要修改多少文件、每个文件需要怎样修改，往往取决于具体任务）。虽然它在拓扑上与并行化相似，但关键区别在于灵活性：子任务不是预定义的，而是由编排器根据具体输入决定的。

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

• 每次都需要对多个文件做复杂修改的编码产品。
• 需要从多个来源收集并分析信息，以寻找潜在相关信息的搜索任务。

工作流：评估器-优化器

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

评估器-优化器工作流

**何时使用这种工作流：**当我们拥有清晰的评估标准，并且迭代改进能提供可衡量价值时，这种工作流尤其有效。判断它是否适配有两个信号：第一，当人类清楚表达反馈时，LLM 响应可以被明显改进；第二，LLM 本身能够提供这样的反馈。这类似于人类作者在产出一篇打磨完善的文档时经历的迭代写作过程。

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

• 文学翻译：翻译 LLM 起初可能没有捕捉到某些细微差别，但评估 LLM 可以提供有用批评。
• 复杂搜索任务：需要多轮搜索和分析才能收集全面信息，由评估器判断是否有必要继续搜索。

智能体

随着 LLM 在关键能力上逐渐成熟，智能体正在生产环境中出现。这些关键能力包括理解复杂输入、进行推理和规划、可靠使用工具，以及从错误中恢复。智能体会从人类用户的一条命令或一次交互式讨论开始工作。一旦任务清晰，智能体就会独立规划和操作，并可能回到人类那里请求更多信息或判断。执行过程中，智能体必须在每一步从环境中获得「真实反馈」（例如工具调用结果或代码执行结果），以评估自身进展。随后，智能体可以在检查点或遇到阻碍时暂停，等待人类反馈。任务通常会在完成后终止，但加入停止条件（例如最大迭代次数）以保持控制也很常见。

智能体可以处理复杂任务，但其实现往往很直接。它们通常只是基于环境反馈，在循环中使用工具的 LLM。因此，清晰而周到地设计工具集及其文档至关重要。我们会在附录 2（“Prompt Engineering your Tools”）中展开工具开发的最佳实践。

自主智能体

**何时使用智能体：**智能体可用于开放式问题：这类问题很难或不可能预先预测所需步骤数量，也无法硬编码固定路径。LLM 可能会运行很多轮，你也必须对它的决策能力有一定程度的信任。智能体的自主性让它们非常适合在可信环境中扩展任务。

智能体的自主特性意味着更高成本，也意味着错误可能层层累积。我们建议在沙盒环境中进行充分测试，并配备适当护栏。

智能体适用的示例：

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

• 用于解决 SWE-bench 任务的编码智能体，这类任务需要根据任务描述修改多个文件；
• 我们的 “computer use” 参考实现，其中 Claude 使用计算机完成任务。

编码智能体的高层流程

组合和定制这些模式

这些构建块并不是强制规范。它们是常见模式，开发者可以根据不同用例塑造并组合它们。和任何 LLM 功能一样，成功的关键在于衡量表现并迭代实现。再强调一次：你应该只在复杂度能够明显改善结果时才考虑增加复杂度。

总结

在 LLM 领域取得成功，并不在于构建最复杂精巧的系统，而在于为你的需求构建合适的系统。从简单提示词开始，用全面评估优化它们，只有在更简单方案不足时，才加入多步骤智能体式系统。

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

1. 在智能体设计中保持简单。
2. 通过明确展示智能体的规划步骤，优先保证透明性。
3. 通过充分的工具文档和测试，仔细打磨你的智能体-计算机接口（ACI）。

框架可以帮助你快速开始，但当你走向生产环境时，不要犹豫于减少抽象层，并使用基础组件来构建。遵循这些原则，你可以创建出不仅强大，而且可靠、可维护，并能获得用户信任的智能体。

致谢

作者：Erik S. 和 Barry Zhang。本文基于我们在 Anthropic 构建智能体的经验，以及客户分享的宝贵见解；我们对此深表感谢。

附录 1：实践中的智能体

我们与客户的合作揭示了 AI 智能体两个尤其有前景的应用方向，它们展示了上文所讨论模式的实际价值。这两个应用都说明，智能体在同时需要对话和行动、有明确成功标准、能够形成反馈循环，并整合有意义的人类监督的任务中，能提供最大价值。

A. 客户支持

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

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

已有多家公司通过基于用量的定价模型展示了这种方法的可行性：只有成功解决问题才收费，这体现了它们对自家智能体有效性的信心。

B. 编码智能体

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

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

在我们自己的实现中，智能体现在只基于 pull request 描述，就能解决 SWE-bench Verified 基准中的真实 GitHub issue。不过，虽然自动化测试有助于验证功能，人类审查对于确保解决方案符合更广泛的系统需求仍然至关重要。

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

无论你在构建哪种智能体式系统，工具很可能都是智能体的重要组成部分。工具让 Claude 能够与外部服务和 API 交互，方式是在我们的 API 中指定工具的精确结构和定义。当 Claude 响应时，如果它计划调用工具，API 响应中会包含一个工具使用块。工具定义和规格说明应当像整体提示词一样，得到同等程度的提示工程关注。在这个简短附录中，我们会说明如何对工具进行提示工程。

同一个动作通常可以用多种方式指定。例如，你可以通过编写 diff 来指定文件编辑，也可以重写整个文件。对于结构化输出，你可以在 markdown 中返回代码，也可以在 JSON 中返回代码。在软件工程中，这类差异只是表现形式上的，并且可以无损地从一种格式转换成另一种格式。然而，对 LLM 来说，有些格式比其他格式难写得多。编写 diff 需要在写出新代码之前，就知道 chunk header 中有多少行会发生变化。相比 markdown，在 JSON 中编写代码则需要额外转义换行符和引号。

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

• 给模型足够的 token，让它在把自己写进死角之前可以「思考」。
• 让格式尽量接近模型在互联网文本中自然见过的形式。
• 确保没有格式上的「额外负担」，例如必须准确计算数千行代码的行数，或对它写出的任何代码做字符串转义。

一个经验法则是：想想人机接口（HCI）需要投入多少努力，然后计划在创建优秀的智能体-计算机接口（ACI）上投入同等努力。下面是一些做法建议：

• 站在模型的角度思考。仅根据描述和参数，如何使用这个工具是否显而易见，还是你需要仔细思考？如果是后者，那么模型很可能也一样。好的工具定义通常包括示例用法、边界情况、输入格式要求，以及与其他工具的清晰边界。
• 你能否修改参数名称或描述，让事情更显而易见？可以把它看作是在为团队中的初级开发者写一段优秀的 docstring。当使用许多相似工具时，这一点尤其重要。
• 测试模型如何使用你的工具：在我们的 workbench 中运行许多示例输入，观察模型会犯哪些错误，并不断迭代。
• 对工具做 Poka-yoke（防错）设计。调整参数，让出错变得更难。

在为 SWE-bench 构建智能体时，我们实际花在优化工具上的时间，比花在优化整体提示词上的时间更多。例如，我们发现，当智能体离开根目录后，模型在使用相对文件路径的工具时会出错。为了解决这个问题，我们把工具改成始终要求绝对文件路径，并发现模型可以毫无差错地使用这种方法。