构建高效的 AI 智能体

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

本文将分享我们在服务客户和亲自构建智能体过程中获得的经验，并为开发者提供构建高效智能体的实用建议。

什么是智能体？

“智能体”可以有多种定义。有些客户把智能体定义为能够在较长时间内独立运行、使用各种工具完成复杂任务的全自主系统；另一些客户则用这个词描述遵循预定义工作流、约束更明确的实现。在 Anthropic，我们把所有这些变体统称为智能体系统，但在架构上明确区分工作流与智能体：

• 工作流是由预定义代码路径编排 LLM 和工具的系统。
• 智能体则是由 LLM 动态指导自身流程和工具使用，并自主决定如何完成任务的系统。

下文将详细探讨这两类智能体系统。在附录 1“智能体的实际应用”中，我们还会介绍两个客户认为这类系统尤其有价值的领域。

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

构建 LLM 应用时，我们建议尽可能寻找最简单的解决方案，只在确有需要时增加复杂度。这甚至可能意味着完全不构建智能体系统。智能体系统往往以更高的延迟和成本换取更好的任务表现，因此你需要判断这种权衡何时合理。

确实需要更高复杂度时，工作流能为定义明确的任务提供可预测性和一致性；而当大规模场景需要灵活性和模型驱动的决策时，智能体更合适。不过，对许多应用而言，通过检索和上下文示例优化一次 LLM 调用通常已经足够。

何时以及如何使用框架

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

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

这些框架简化了调用 LLM、定义和解析工具、串联调用等标准底层任务，让人更容易上手。然而，它们往往会引入额外的抽象层，遮蔽底层提示词和响应，使调试更加困难；它们也容易诱使开发者增加复杂度，即使更简单的方案已经足够。

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

我们的 cookbook 中提供了一些示例实现。

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

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

构建模块：增强型 LLM

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

增强型 LLM

我们建议重点关注实现中的两个方面：根据具体用例调整这些能力，并确保它们为 LLM 提供易于使用且文档完善的接口。实现这些增强能力的方法很多，其中一种是使用我们最近发布的模型上下文协议（Model Context Protocol）。借助简单的客户端实现，开发者可以接入不断壮大的第三方工具生态。

本文余下部分将假定每次 LLM 调用都能使用这些增强能力。

工作流：提示链

提示链把任务分解为一系列步骤，每次 LLM 调用都处理上一步的输出。你可以在任意中间步骤加入程序化检查（见下图中的“门控”），以确保流程仍沿着正确方向推进。

提示链工作流

何时使用这种工作流： 当任务能够轻松、清晰地拆分成固定子任务时，提示链非常理想。它的主要目标是把延迟换成更高的准确率，因为每次 LLM 调用面对的任务都更简单。

适合使用提示链的示例：

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

工作流：路由

路由会对输入分类，并把它导向专门的后续任务。这种工作流有助于分离关注点，并构建更专门化的提示词。没有路由时，针对某一类输入做优化，可能会损害系统处理其他输入的能力。

路由工作流

何时使用这种工作流： 当复杂任务包含界限清晰、适合分别处理的类别，并且可以由 LLM 或更传统的模型/算法准确完成分类时，路由会非常有效。

适合使用路由的示例：

• 把不同类型的客户服务请求（一般问题、退款申请、技术支持）导向不同的下游流程、提示词和工具。
• 把简单或常见问题交给 Claude Haiku 4.5 这类成本较低的小模型，把困难或少见问题交给 Claude Sonnet 4.5 这类能力更强的模型，从而优化整体性能与成本。

工作流：并行化

LLM 有时可以同时处理一项任务，再以程序方式汇总输出。并行化工作流主要有两种形式：

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

并行化工作流

何时使用这种工作流： 当拆分后的子任务能够并行执行以提升速度，或需要从多个视角进行多次尝试来提高置信度时，并行化很有效。对于包含多项考量的复杂任务，让每次 LLM 调用分别关注一个方面，通常能获得更好的表现。

适合使用并行化的示例：

• 分段：
  • 实现防护机制：一个模型实例处理用户请求，另一个实例筛查请求是否包含不当内容。这通常比让同一次 LLM 调用同时负责防护和核心响应效果更好。
    • 自动执行模型性能评测：每次 LLM 调用分别评估模型表现的不同方面。
• 投票：
  • 审查代码漏洞：使用多种不同提示词进行审查，只要发现问题就标记代码。
    • 判断内容是否不当：使用多个提示词从不同角度评估，或采用不同投票阈值，以平衡误报和漏报。

工作流：编排器—工作者

在编排器—工作者工作流中，中央 LLM 会动态拆解任务，把子任务委派给工作者 LLM，再综合它们的结果。

编排器—工作者工作流

何时使用这种工作流： 这种工作流适合无法预先确定所需子任务的复杂任务。例如在编码中，需要修改多少文件、修改的性质是什么，往往取决于具体任务。尽管它在拓扑结构上与并行化相似，但两者的关键区别在于灵活性：子任务并非预先定义，而是由编排器根据具体输入动态决定。

适合使用编排器—工作者的示例：

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

工作流：评估器—优化器

在评估器—优化器工作流中，一次 LLM 调用生成响应，另一次调用负责评估和反馈，二者循环迭代。

评估器—优化器工作流

何时使用这种工作流： 当评估标准清晰，并且迭代改进能带来可衡量的价值时，这种工作流尤其有效。适合它的两个迹象是：第一，当人类明确表达反馈时，LLM 响应能够得到可证明的改进；第二，LLM 能够提供这类反馈。这类似于人类创作精良文档时采用的反复修订过程。

适合使用评估器—优化器的示例：

• 文学翻译：生成译文的 LLM 可能没有捕捉到某些细微含义，但评估 LLM 可以提出有用的批评意见。
• 复杂搜索任务：需要多轮搜索和分析才能全面收集信息，由评估器判断是否还需要进一步搜索。

智能体

随着 LLM 在理解复杂输入、推理与规划、可靠使用工具以及从错误中恢复等关键能力上日益成熟，智能体正在进入生产环境。智能体会从人类给出的命令或与人类的交互式讨论开始工作。任务明确后，智能体会自主规划和行动，并可能在需要更多信息或判断时再次向人类求助。执行期间，智能体必须在每一步从环境中获得“真实依据”（例如工具调用结果或代码执行结果），以评估自身进展。它可以在检查点或遇到阻碍时暂停并征求人类反馈。工作通常会在任务完成时结束，但也经常设置停止条件（例如最大迭代次数）来维持控制。

智能体可以处理复杂任务，但其实现往往很直接。它们通常只是根据环境反馈在循环中使用工具的 LLM。因此，清晰、审慎地设计工具集及其文档至关重要。我们会在附录 2“为工具设计提示词”中进一步介绍工具开发的最佳实践。

自主智能体

何时使用智能体： 智能体适合解决难以或无法预先判断所需步骤数量、也无法硬编码固定路径的开放式问题。LLM 可能需要运行许多轮，因此你必须对它的决策能力具备一定程度的信任。智能体的自主性使其非常适合在可信环境中扩展任务规模。

智能体的自主性意味着更高的成本，以及错误不断累积的可能性。我们建议在沙箱环境中进行充分测试，并配备适当的防护机制。

适合使用智能体的示例：

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

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

编码智能体的高层流程

组合和定制这些模式

这些构建模块并不是硬性规范，而是开发者可以根据用例调整和组合的常见模式。与所有 LLM 功能一样，成功的关键在于衡量表现并不断迭代。再次强调：只有当增加复杂度能够带来可证明的改进时，才应这样做。

总结

在 LLM 领域，成功不在于构建最复杂的系统，而在于构建适合需求的系统。从简单提示词开始，通过全面评测进行优化，只有在简单方案不足时，才加入多步骤智能体系统。

实现智能体时，我们努力遵循三项核心原则：

1. 在智能体设计中保持简单。
2. 明确展示智能体的规划步骤，优先保证透明。
3. 通过完善的工具文档和测试，精心设计智能体—计算机接口（ACI）。

框架可以帮助你快速起步，但随着系统进入生产环境，也不要犹豫是否应该减少抽象层，转而使用基础组件。遵循这些原则，你就能构建不仅强大，而且可靠、可维护、值得信任的智能体。

致谢

本文由 Erik S. 和 Barry Zhang 撰写。文章总结了我们在 Anthropic 构建智能体和与客户合作的经验，感谢客户分享的宝贵见解。

附录 1：智能体的实际应用

我们与客户的合作揭示了 AI 智能体两个尤其有前景的应用方向，它们展示了上述模式的实际价值。这两类应用都说明：对于同时需要对话和行动、拥有明确成功标准、支持反馈循环且包含有意义人类监督的任务，智能体最能发挥价值。

A. 客户支持

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

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

已有多家公司通过按实际使用量计费、且只对成功解决的问题收费，证明了这种方法的可行性，也体现了它们对智能体效果的信心。

B. 编码智能体

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

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

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

附录 2：为工具设计提示词

无论构建哪种智能体系统，工具很可能都是其中的重要组成部分。工具让 Claude 能够通过指定工具的确切结构与定义，与外部服务和 API 交互。如果 Claude 计划调用某个工具，它的响应就会包含一个工具使用块。工具的定义和规范应当得到与整体提示词同等程度的提示工程投入。本附录将简要介绍如何为工具进行提示工程。

同一个操作往往可以用多种方式描述。例如，你可以用 diff 指定文件编辑，也可以重写整个文件；对于结构化输出，可以把代码放在 Markdown 中，也可以放进 JSON。在软件工程中，这些区别只是形式上的，能够无损转换。然而，有些格式对 LLM 来说要难写得多。编写 diff 时，模型必须在写出新代码之前就知道分块头中变化了多少行；与 Markdown 相比，在 JSON 中编写代码还需要额外转义换行符和引号。

关于如何决定工具格式，我们提出以下建议：

• 在模型开始书写、陷入格式困境之前，给它足够的 token 用于“思考”。
• 让格式尽量贴近模型在互联网上自然见过的形式。
• 确保不存在格式上的“额外负担”，例如必须准确计算数千行代码的变化数量，或转义代码中的字符串。

一个经验法则是：思考人们在设计人机界面（HCI）上投入了多少精力，就计划在打造优秀的智能体—计算机接口（ACI）上投入同等精力。下面是一些具体建议：

• 站在模型的角度思考：仅根据工具的描述和参数，工具的使用方式是否显而易见？如果不是，那么模型很可能也需要仔细推敲。优秀的工具定义通常包括示例、边界情况、输入格式要求和清晰的能力边界。
• 怎样修改参数名称或描述，才能让它们更直观？可以把这看作是在为初级开发者编写优秀的文档字符串。当你同时使用许多相似工具时，这一点尤其重要。
• 测试模型如何使用工具：在我们的 workbench 中运行大量示例，观察模型会犯哪些错误并持续迭代。
• 对工具进行防错设计，调整工具参数，使错误更难发生。

在为 SWE-bench 构建智能体时，我们花在优化工具上的时间甚至超过了优化整体提示词。例如，我们发现，当智能体离开仓库根目录后，使用相对文件路径的工具会让 Claude 出错。为此，我们改为要求工具始终使用绝对文件路径，并发现这种方法效果非常可靠。