构建高效的智能体

说明:本文描述的工具生态自 2024 年 12 月以来已有很大变化。关于我们当前的做法,请参阅 我们如何构建 Claude Managed Agents 与 Managed Agents 文档。过去一年中,我们与几十个团队合作,在多个行业构建大语言模型(LLM)智能体。始终一致的发现是:最成功的实现并没有使用复杂的框架或专用库,而是用简单、可组合的模式来构建。

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

什么是智能体?

“智能体”(agent)可以有多种定义。有些客户把智能体定义为完全自主的系统,它们能长时间独立运作,借助多种工具完成复杂任务;另一些人则用这个词描述遵循预定工作流、更具指令性的实现。在 Anthropic,我们把所有这些变体统称为智能体系统(agentic system),但在架构上对工作流(workflow)与智能体(agent)做了重要区分:

工作流是通过预定义代码路径来编排 LLM 与工具的系统。
而智能体是由 LLM 动态主导自身流程与工具使用的系统,自主掌控如何完成任务。

下面我们将详细探讨这两类智能体系统。在附录 1(“实践中的智能体”)中,我们描述了两个客户在应用这类系统时发现其特别价值的领域。

何时(以及何时不)使用智能体

用 LLM 构建应用时,我们建议找到尽可能最简单的方案,只在确有必要时才增加复杂度。这可能意味着根本不构建智能体系统。智能体系统常常以延迟与成本换取更好的任务表现,你需要想清楚这种取舍在什么时候是划算的。

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

何时以及如何使用框架

有许多框架能让智能体系统的实现更简单,包括:

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

这些框架通过简化调用 LLM、定义与解析工具、串联多次调用等标准底层任务,让你能轻松上手。但它们往往也会增加额外的抽象层,遮蔽底层的提示词与响应,使其更难调试。它们还可能诱使你在一套更简单的设置就能胜任时引入复杂度。

我们建议开发者从直接使用 LLM API 开始:许多模式用几行代码就能实现。如果确实要用框架,请确保自己理解底层代码。对内部机制的错误假设是客户出错的一个常见来源。

一些示例实现可参见我们的cookbook。

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

在本节中,我们将探讨在生产中见到的智能体系统的常见模式。先从基础构建模块——增强型 LLM 说起,再逐步增加复杂度,从简单的组合式工作流一路到自主智能体。

构建模块:增强型 LLM

智能体系统的基本构建模块,是加入了检索、工具与记忆等增强能力的 LLM。我们当前的模型能够主动使用这些能力——自己生成搜索查询、选择合适的工具,并决定要保留哪些信息。

图 1

增强型 LLM

在实现上,我们建议聚焦两个关键方面:让这些能力贴合你的具体用例,并确保它们为你的 LLM 提供一个易用且文档良好的接口。实现这些增强能力的方式有很多,其中一种就是通过我们近期发布的模型上下文协议(Model Context Protocol),它让开发者能通过一个简单的客户端实现接入日益壮大的第三方工具生态。

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

工作流:提示链

提示链(prompt chaining)把任务分解成一系列步骤,其中每次 LLM 调用都处理上一步的输出。你可以在任何中间步骤上加入程序化检查(见下图中的“闸门”),以确保流程仍在正轨上。

图 2

提示链工作流

何时使用该工作流: 当任务可以清晰、干净地分解为若干固定子任务时,这种工作流是理想之选。其主要目标是通过让每次 LLM 调用都变成一个更简单的任务,用延迟换取更高准确率。

提示链适用的示例:

生成营销文案,然后把它翻译成另一种语言。
先写出文档大纲,检查大纲是否满足某些标准,再基于大纲撰写文档。

工作流:路由

路由(routing)对输入进行分类,并将其导向专门的后续任务。这种工作流支持关注点分离,并构建更专门的提示词。没有它,针对某一类输入做优化可能会损害其他输入的表现。

图 3

路由工作流

何时使用该工作流: 路由适合复杂任务,这类任务中存在更适合分开处理的清晰类别,并且分类可以被准确完成——无论用 LLM 还是更传统的分类模型/算法。

路由适用的示例:

把不同类型的客服查询(一般问题、退款请求、技术支持)分流到不同的下游流程、提示词与工具。
把简单/常见的问题路由到 Claude Haiku 4.5 这类更小、更经济的模型,把困难/罕见的问题路由到 Claude Sonnet 4.5 这类更强的模型,以优化整体表现。

工作流:并行化

LLM 有时可以同时处理一个任务,其输出再通过程序化方式聚合。这种工作流称为并行化(parallelization),主要有两种变体:

切分(Sectioning):把任务拆成相互独立的子任务并行运行。
投票(Voting):多次运行同一任务以获得多样化的输出。

图 4

并行化工作流

何时使用该工作流: 当拆分出的子任务可以并行以提速,或需要多种视角/多次尝试来获得更高置信度的结果时,并行化是有效的。对于要考虑多个方面的复杂任务,让每个方面由一次独立的 LLM 调用处理,LLM 通常表现更好,因为每次调用可以聚焦于特定方面。

并行化适用的示例:

切分:实现护栏(guardrails),让一个模型实例处理用户查询、另一个实例筛查其中是否有不当内容或请求。这通常比让同一次 LLM 调用既承担护栏又承担核心响应表现更好。自动化 LLM 表现评估,让每次 LLM 调用针对给定提示上模型表现的不同方面打分。
投票:审查一段代码的漏洞,用多个不同提示词去审查,发现问题就标记该代码。判断一段内容是否不当,用多个提示词评估不同方面,或要求不同的投票阈值以平衡误报与漏报。
实现护栏,让一个模型实例处理用户查询、另一个实例筛查其中是否有不当内容或请求。这通常比让同一次 LLM 调用既承担护栏又承担核心响应表现更好。
自动化 LLM 表现评估,让每次 LLM 调用针对给定提示上模型表现的不同方面打分。
审查一段代码的漏洞,用多个不同提示词去审查,发现问题就标记该代码。
判断一段内容是否不当,用多个提示词评估不同方面,或要求不同的投票阈值以平衡误报与漏报。

工作流:编排者-工作者

在编排者-工作者(orchestrator-workers)工作流中,一个中心 LLM 动态分解任务,把子任务分派给多个工作者 LLM,并综合它们的结果。

图 5

编排者-工作者工作流

何时使用该工作流: 这种工作流适合无法预先预测所需子任务的复杂任务(例如在编码中,需要改动多少文件、每个文件改什么,很可能取决于具体任务)。虽然它在拓扑上与并行化相似,但关键区别在于灵活性——子任务不是预定义的,而是由编排者根据具体输入动态决定。

编排者-工作者适用的示例:

每次都需要对多个文件做复杂改动的编码产品。
需要从多个来源收集与分析信息、寻找可能有价值内容的搜索任务。

工作流:评估者-优化者

在评估者-优化者(evaluator-optimizer)工作流中,一次 LLM 调用生成响应,另一次调用则在一个循环中提供评估与反馈。

图 6

评估者-优化者工作流

何时使用该工作流: 当我们有清晰的评估标准、且迭代式打磨能带来可衡量的价值时,这种工作流特别有效。两个适配信号是:其一,当人类阐明反馈后,LLM 的响应确实能被显著改进;其二,LLM 能够提供这种反馈。这类似于人类作者在打磨一篇文稿时可能经历的迭代写作过程。

评估者-优化者适用的示例:

文学翻译——译者 LLM 最初可能捕捉不到某些微妙之处,而评估者 LLM 能给出有用的批评。
需要多轮搜索与分析以收集全面信息的复杂搜索任务,由评估者决定是否还有必要继续搜索。

智能体

图 7

随着 LLM 在几项关键能力上的成熟——理解复杂输入、进行推理与规划、可靠地使用工具、从错误中恢复——智能体正陆续走向生产。智能体以人类用户的命令或与其的互动讨论开始工作。任务一旦明确,智能体便自主规划与运作,并可能回头向人类寻求更多信息或判断。在执行过程中,智能体每一步都要从环境获取“地面真值”(ground truth,如工具调用结果或代码执行结果)以评估自身进展,这一点至关重要。随后,智能体可以在检查点或遇到阻碍时暂停并等待人类反馈。任务通常在完成时终止,但也很常见的是加入停止条件(例如最大迭代次数)以保持可控。

智能体能处理复杂的任务,但其实现往往很直接——它们通常只是在一个循环里基于环境反馈使用工具的 LLM。因此,精心设计工具集及其文档至关重要。关于工具开发的最佳实践,我们在附录 2(“为你的工具做提示工程”)中有更详细的阐述。

自主智能体

何时使用智能体: 智能体适用于开放式问题——难以或无法预估所需步骤数、也无法硬编码固定路径的场景。LLM 可能会运行很多轮,你必须对其决策能力有一定信任。智能体的自主性使其非常适合在可信环境中规模化地执行任务。

智能体的自主性也意味着更高的成本,以及错误累积放大的可能。我们建议在沙箱环境中进行大量测试,并配上恰当的护栏。

智能体适用的示例:

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

一个解决 SWE-bench 任务的编码智能体,这类任务需要根据一段任务描述对多个文件进行修改;
我们的“计算机操作”(computer use)参考实现,Claude 在其中用计算机完成任务。

图 8

编码智能体的高层流程

组合与定制这些模式

这些构建模块并不是规定性的。它们是开发者可以按不同用例塑形与组合的常见模式。与任何 LLM 功能一样,成功的关键在于衡量表现并迭代实现。再强调一次:只有在确实能改进结果时,才应考虑增加复杂度。

总结

在 LLM 领域取得成功,不在于构建最复杂的系统,而在于为你的需求构建正确的系统。从简单的提示词开始,用全面的评估去优化它,只有当更简单的方案力有不逮时,再加入多步骤的智能体系统。

在实现智能体时,我们遵循三条核心原则:

让智能体的设计保持简洁。
通过显式展示智能体的规划步骤来优先保证透明性。
通过透彻的工具文档与测试,精心打磨智能体-计算机接口(ACI)。

框架能帮你快速起步,但进入生产时,不要犹豫去减少抽象层、用基础组件来构建。遵循这些原则,你就能创造出不仅强大,而且可靠、可维护、被用户信任的智能体。

致谢

作者:Erik S. 与 Barry Zhang。这项工作借鉴了我们在 Anthropic 构建智能体的经验,以及客户分享的宝贵洞见,对此我们深表感激。

附录 1:实践中的智能体

我们与客户的合作揭示了 AI 智能体两个特别有前景的应用方向,它们展示了上文所讨论模式的实际价值。这两个应用都说明:对于既需要对话又需要行动、有清晰成功标准、能形成反馈回路、并纳入有意义的人类监督的任务,智能体能带来最大价值。

A. 客户支持

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

支持类交互天生遵循对话流程,同时需要访问外部信息并采取行动;
可以集成工具来拉取客户数据、订单历史与知识库文章;
退款、更新工单等操作可以通过程序化方式处理;并且
成功与否可以通过用户定义的解决结果被清晰衡量。

一些公司已通过“按成功解决计费”的用量定价模式证明了这种做法的可行性——这本身也显示出他们对自己智能体的效果有信心。

B. 编码智能体

软件开发领域已展现出 LLM 功能惊人的潜力,其能力从代码补全一路演进到自主问题求解。智能体之所以特别有效,是因为:

代码方案可以通过自动化测试验证;
智能体可以借助测试结果作为反馈来迭代方案;
问题空间定义明确、结构清晰;并且
输出质量可以被客观衡量。

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

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

无论你在构建哪种智能体系统,工具都很可能是智能体的重要组成部分。工具通过在我们的 API 中指定其精确结构与定义,让 Claude 能够与外部服务和 API 交互。当 Claude 计划调用某个工具时,它会在 API 响应中包含一个工具使用块。工具定义与说明,应当获得与你整体提示词同等的提示工程关注。在这个简短的附录里,我们介绍如何为你的工具做提示工程。

同一个动作往往有多种指定方式。例如,你可以通过写 diff 来指定文件编辑,也可以整体重写整个文件。对于结构化输出,你可以在 markdown 或 JSON 里返回代码。在软件工程中,这类差异只是表面功夫,可以无损地在两者之间转换。但对 LLM 而言,某些格式比另一些难写得多。写 diff 需要在新代码写出前就知道块头(chunk header)中要改多少行;在 JSON(相比 markdown)里写代码,需要对换行与引号做额外转义。

关于如何确定工具格式,我们的建议如下:

给模型足够多的 token 去“思考”,免得把自己写进死胡同。
让格式尽量贴近模型在互联网文本中常见的形式。
确保没有“格式开销”,例如需要精确记录数千行代码的行数,或对它写出的代码做字符串转义。

一条经验法则是:想想人们在人机交互界面(HCI)上投入了多少精力,然后规划在构建良好的智能体-计算机接口(ACI)上投入同等的精力。以下是一些做法供参考:

设身处地站在模型的角度想。根据描述与参数,这个工具该如何使用是一目了然,还是需要仔细琢磨?如果是后者,那对模型来说很可能也一样。一个好的工具定义通常包含示例用法、边界情况、输入格式要求,以及与其他工具的清晰界限。
如何通过修改参数名或描述让事情更显然?把这当作给你团队里初级开发者写一份绝佳 docstring。当有多个相似工具时,这一点尤其重要。
测试模型如何使用你的工具:在我们的 workbench 里跑大量示例输入,看模型会犯什么错,然后迭代。
给你的工具做防错(poka-yoke)设计:调整参数,让犯错更难发生。

在为 SWE-bench 构建智能体时,我们实际花在优化工具上的时间比优化整体提示词还多。例如,我们发现模型在智能体离开根目录后,会在使用相对文件路径的工具上出错。为解决这个问题,我们把工具改成始终要求绝对路径——结果模型用起这个方法万无一失。