构建有效智能体：Anthropic 的实践总结与指南

在人工智能不断发展的进程中，Anthropic 在 2024 年对智能体（Agents）的研究与实践成果斐然。随着技术的逐步成熟，构建智能体系统已成为当下的重要趋势。Anthropic 通过与众多跨行业团队合作，深入探索了大型语言模型（LLM）智能体的构建，积累了丰富经验，并在其官方博客分享了 “构建有效智能体” 的见解。

一、智能体的定义与架构差异

智能体的定义在不同场景下有所不同。部分客户眼中的智能体是能够长期独立运行、运用各种工具完成复杂任务的完全自主系统；而另一些则将其视为遵循预定义工作流程的规范性实现。Anthropic 将这些概念统一归类为 Agent 系统，但着重区分了工作流程与智能体的架构：工作流是通过预设代码路径协调 LLM 和工具的系统；智能体则是 LLM 能够动态掌控自身流程和工具使用，自主决定任务完成方式的系统。在后续内容中，我们将详细探讨这两类 Agent 系统。

二、智能体的使用时机与考量

2.1 简单至上原则

使用 LLM 构建应用程序时，建议优先寻求最简单的解决方案。很多时候，可能根本无需构建 Agent 系统。Agent 系统在提升任务性能的同时，往往会牺牲延迟并增加成本，因此需谨慎权衡这种取舍是否合理。

2.2 复杂任务应对策略

当任务确实需要更高复杂性时，工作流可为明确的任务提供稳定的可预测性和一致性；而在大规模任务中需要灵活性以及模型驱动决策时，智能体则是更好的选择。不过，对于大多数应用程序而言，通过检索和上下文示例优化单个 LLM 调用通常就能满足需求。

2.3 框架的合理运用

众多框架为构建智能体系统提供了便利，例如 LangChain 的 LangGraph、Amazon Bedrock 的 AI Agent 框架、Rivet（拖放式 GUI LLM 工作流构建器）以及 Vellum（用于构建和测试复杂工作流程的 GUI 工具）等。这些框架简化了诸如调用 LLM、定义和解析工具以及链接调用等基础任务，使开发者能够快速上手。然而，它们也带来了一些问题，比如增加了抽象层，使得底层的提示和响应变得模糊，增加了调试难度。并且，在简单设置足以满足需求时，可能会诱使开发者过度增加复杂性。因此，Anthropic 建议开发者直接使用 LLM API，许多模式用几行代码就能实现。若选择使用框架，则务必深入理解底层代码，避免因对底层原理的错误假设而导致客户错误。

三、构建块、工作流与智能体详解

3.1 增强型 LLM：构建基石

智能体系统的基础构建块是经过增强的 LLM，其具备检索、工具使用和记忆等能力。Anthropic 当前的模型能够主动运用这些能力，如生成搜索查询、选择合适工具并确定保留信息。在实施过程中，有两个关键方面需要关注：一是根据具体用例定制这些功能；二是确保为 LLM 提供简单且文档完备的接口。近期发布的模型上下文协议为开发者提供了一种途径，通过简单的客户端实施即可与不断扩展的第三方工具生态系统集成。在本文后续部分，我们默认每个 LLM 调用都具备这些增强功能。

3.2 工作流类型与应用场景

3.2.1 Prompt chaining

此工作流将任务分解为一系列步骤，每个 LLM 调用处理前一步骤的输出，并可在中间步骤添加程序检查（如 “门” 机制），以确保流程按计划进行。这种工作流适用于任务能清晰分解为固定子任务的情况，其主要目的是以牺牲一定延迟为代价换取更高的准确性，使每个 LLM 调用处理更简单的任务。例如，先生成营销文案，再将其翻译成不同语言；或者先撰写文档大纲，检查大纲是否符合特定标准，然后根据大纲撰写文档。

3.2.2 路由

路由工作流将输入分类并导向专门的后续任务，有助于分离关注点，构建更具针对性的提示。若没有路由，针对某类输入的优化可能会影响其他输入的处理效果。该工作流适用于复杂任务，特别是存在不同类别且需要分别处理，并且能够通过 LLM 或传统分类模型 / 算法准确分类的情况。比如，将不同类型的客户服务查询（如一般问题、退款请求、技术支持）引导至不同的下游流程、提示和工具中；或者根据问题的难易程度，将简单 / 常见问题路由到较小的模型（如 Claude 3.5 Haiku），将困难 / 不寻常问题路由到更强大的模型（如 Claude 3.5 Sonnet），以优化成本和速度。

3.2.3 并行化

LLM 有时可同时处理一项任务，并通过编程方式汇总输出。并行化工作流主要有两种形式：分段（将任务分解为并行运行的独立子任务）和投票（多次运行相同任务以获取不同输出）。当子任务可并行执行以提高速度，或者需要多个视角或多次尝试以获得更可靠结果时，并行化工作流非常有效。对于具有多个考虑因素的复杂任务，每个考虑因素由单独的 LLM 调用处理，能使 LLM 更专注于每个特定方面，从而提升性能。例如，在实施防护措施时，一个模型实例处理用户查询，另一个实例筛选不当内容或请求，这种方式通常比同一 LLM 调用同时处理防护和核心响应效果更好；在自动评估 LLM 性能时，每个 LLM 调用可评估模型在给定提示下性能的不同方面；在审查代码漏洞时，多个不同提示可对代码进行审查，发现问题则标记；在评估内容是否不当时，使用多个提示从不同角度评估或设置不同投票阈值以平衡误报和漏报。

3.2.4 Orchestrator-workers

在这种工作流中，中央 LLM 动态分解任务，将其分配给多个 worker LLM，并汇总结果。此工作流适用于无法预先确定所需子任务的复杂任务，如在编码中，每次需要更改的文件数量和每个文件中的更改性质可能因任务而异。尽管与并行化在拓扑结构上相似，但其关键区别在于灵活性 —— 子任务不是预先定义的，而是由编排器根据特定输入确定。例如，每次对多个文件进行复杂更改的编码产品，或者涉及从多个来源收集和分析信息以获取可能相关信息的搜索任务。

3.2.5 评估器 - 优化器

此工作流中，一个 LLM 调用生成响应，另一个调用在循环中提供评估和反馈。当有明确的评估标准，且迭代改进能够带来显著价值时，该工作流尤为有效。良好适配的两个标志是：首先，当人类提供反馈时，LLM 的响应能够明显改善；其次，LLM 本身能够提供这样的反馈。这类似于人类作家创作高质量文档时的迭代写作过程。例如，在文学翻译中，译者 LLM 最初可能无法捕捉到某些细微差别，但评估者 LLM 可以提供有价值的批评；在复杂的搜索任务中，需要多轮搜索和分析才能收集全面信息，然后由评估者决定是否需要进一步搜索。

四、智能体的特性与应用

随着 LLM 在理解复杂输入、推理规划、可靠使用工具和错误恢复等关键能力上的不断成熟，智能体已逐渐投入实际生产。智能体通过接收人类用户的命令或与其互动讨论启动任务，一旦任务明确，便独立规划和执行操作，期间还可能返回向人类获取更多信息或判断。在执行过程中，智能体必须从每个步骤（如工具调用结果或代码执行）的环境中获取 “真实情况” 以评估进度，并且可以在检查点或遇到阻碍时暂停等待人类反馈。任务通常在完成后结束，但一般也会设置停止条件（如最大迭代次数）以确保可控性。

智能体虽然能够处理复杂任务，但其实现方式通常较为简洁，本质上就是基于环境反馈循环使用工具的 LLM。因此，清晰且精心设计工具集及其文档至关重要。智能体适用于开放式问题，即难以预测所需步骤数量且无法硬编码固定路径的场景。此时，LLM 可能需要多次运行，并且开发者必须对其决策有一定程度的信任。智能体的自主性使其成为在受信任环境中扩展任务的理想选择，但同时也伴随着更高的成本和出现复合错误的可能性。因此，建议在沙盒环境中进行广泛测试，并设置适当的防护措施。例如，Anthropic 自己实现的编码智能体可根据任务描述解决 SWE-bench 任务中涉及的多个文件编辑问题；还有 Claude 使用计算机完成任务的 “计算机使用” 参考实现。

说明

上述构建块并非一成不变的规则，而是开发者可根据不同用例灵活塑造和组合的常见模式。与任何 LLM 功能一样，成功的关键在于衡量性能并持续迭代实现。再次强调：只有当复杂性的增加能够显著改善结果时，才应考虑引入。

五、实施智能体的核心原则

5.1 保持设计简洁性

避免过度复杂的设计，确保智能体的架构和功能易于理解和维护。

5.2 确保透明度

通过明确展示智能体的规划步骤，让用户和开发者能够清晰了解其决策过程。

5.3 精心打造接口

通过全面的工具文档和严格的测试，精心设计智能体与计算机之间的接口（ACI），确保交互的顺畅与可靠。

框架在项目初期有助于快速启动，但在进入生产阶段时，不要犹豫减少抽象层，直接使用基本组件构建，这样可以更好地掌控系统性能和稳定性。遵循这些原则，开发者能够创建出不仅功能强大，而且可靠、易于维护且受用户信任的智能体。

六、附录

6.1 实践中的智能体应用

6.1.1 客户支持

通过工具集成，客户支持将常见的聊天机器人界面与增强功能相结合，非常适合更开放的智能体应用。因为支持交互自然遵循对话流程，同时需要访问外部信息和执行操作；可以集成工具提取客户数据、订单历史记录和知识库文章；诸如退款或更新机票等操作可以通过编程实现；并且成功与否可通过用户定义的分辨率清晰衡量。多家公司已通过基于使用情况的定价模式证明了该方法的可行性，这种模式仅对成功解决的问题收费，显示出对其智能体效率的信心。

6.1.2 编码智能体

在软件开发领域，LLM 的功能从代码完成发展到自主解决问题，智能体在此发挥了重要作用。编码智能体特别有效，原因在于代码解决方案可通过自动化测试进行验证；智能体可以利用测试结果作为反馈来迭代改进解决方案；问题空间定义明确且结构清晰；输出质量能够客观衡量。在 Anthropic 的实际实现中，智能体现在可以仅根据拉取请求描述解决 SWE-bench Verified 基准中的真实 GitHub 问题。然而，尽管自动化测试有助于验证功能，但人工审核对于确保解决方案符合更广泛的系统要求仍然不可或缺。

6.2 工具设计优化要点

无论构建何种智能体系统，工具都是智能体的重要组成部分。通过在 API 中指定外部服务和 API 的确切结构和定义，工具使 Claude 能够与外部服务和 API 进行交互。当 Claude 响应时，如果计划调用工具，会在 API 响应中包含一个工具使用块。工具定义和规范应像整体提示一样受到及时工程的关注。

通常有多种方式指定相同操作，例如文件编辑可以通过编写差异（diff）或重写整个文件来实现；对于结构化输出，可以在 markdown 或 JSON 中返回代码。在软件工程中，这些格式差异可能并不重要，且可以无损转换。但对于 LLM 而言，某些格式编写难度较大。比如编写 diff 需要在编写新代码前知道块头中有多少行发生了变化；在 JSON 中编写代码（与 markdown 相比）需要额外转义换行符和引号。

Anthropic 关于决定工具格式的建议如下：

1. 在模型陷入困境前，给予足够的标记让其 “思考”。
2. 保持格式与模型在互联网文本中自然遇到的格式相近。
3. 避免格式化 “开销”，如无需精确计数数千行代码或对编写的代码进行字符串转义。

一个经验法则是考虑在人机界面（HCI）上投入的精力，并计划在创建良好的智能体 - 计算机界面（ACI）上投入同样多的精力。具体可从以下方面入手：站在模型角度思考，根据描述和参数判断工具使用方法是否显而易见；优化参数名称和描述，使其更清晰，如同为团队中的初级开发人员编写优秀的文档字符串；在工作台中运行大量示例输入，测试模型使用工具的情况，发现错误后进行迭代；采用防错法，调整参数以减少错误发生的可能性。例如，在为 SWE-bench 构建智能体时，Anthropic 在优化工具上花费的时间实际上比优化整体提示的时间更多。如发现智能体移出根目录后，模型在使用相对文件路径的工具时会出错，将工具更改为始终需要绝对文件路径后，模型就能完美使用该方法。

Anthropic 在 2024 年的研究与实践为智能体的构建提供了全面且深入的指导，从理论概念到实际应用，从构建模块到工作流程，再到实施原则和工具设计，都为人工智能领域的开发者和研究者提供了宝贵的参考和借鉴，有助于推动智能体技术在更多领域的有效应用和发展。

原文：https://www.anthropic.com/research/building-effective-agentscookbook：https://github.com/anthropics/anthropic-cookbook/tree/main/patterns/agents