Anthropic官方实战分享 - 如何构建高效的智能体(Agent)系统
引言：最新这篇来自Anthropic的关于如何构建智能体的文章很有实战意义，因此将全文及其图片都精翻了一下，推荐在考虑构建LLM应用的技术方向朋友们都可以看看。其中印象最深刻的地方应该是官方在文中至少强调了四五次 - 不要过度构建，能用简单方法解决的就不要额外添加复杂性！尤其不要因为看到有个方便的智能体系统开发框架就忍不住直接上~
过去一年里，我们与数十个团队合作，帮助他们在各个行业中构建大语言模型(LLM)智能体。有趣的是，最成功的实现往往不是使用复杂的框架或专门的库，而是采用简单、可组合的模式。
在这篇文章中，我们将分享从客户合作和自身构建智能体的过程中获得的经验，并为开发者提供构建高效智能体的实用建议。
什么是智能体？
“智能体”可以有多种定义方式。有些客户将智能体定义为能够长期独立运行的完全自主系统，能通过使用各种工具来完成复杂任务；也有客户用这个术语来描述更具规范性的实现，即遵循预定义工作流程的系统。在Anthropic，我们将这些变体都归类为**智能体系统(agentic systems)**，但在架构上我们是这样区分工作流和智能体的：
- 工作流(workflows)是通过预定义代码路径来编排LLM和工具的系统；
- 智能体则是由LLM动态指导自身流程和工具使用的系统，它们能够自主控制完成任务的方式；
接下来，我们将详细探讨这两种智能体系统。在附录1（”智能体最佳实践”）中，我们描述了客户在使用这些系统时特别有价值的两个领域。
何时（以及何时不）应该使用智能体
在构建LLM应用时，我们建议寻找最简单的解决方案，只在必要时增加复杂性。这可能意味着完全不构建智能体系统。智能体系统通常会用延迟和成本来换取更好的任务表现，你需要考虑这种权衡是否合理。
当需要更复杂的解决方案时，工作流能为明确定义的任务提供可预测性和一致性，而智能体则更适合需要灵活性和模型驱动决策的大规模场景。不过，对于许多应用来说，用检索增强和上下文范例来优化单个LLM调用通常就足够了。
何时以及如何使用框架(frameworks)
市面上有许多框架可以简化智能体系统的实现，包括：
这些框架通过简化标准的底层任务（如调用LLM、定义和解析工具、链接调用等）使入门变得容易。然而，它们往往会创建额外的抽象层，这可能会掩盖底层的提示和响应，使调试变得更困难。它们也可能会诱使人在简单设置就足够的情况下增加不必要的复杂性。
我们建议开发者直接从使用LLM API开始：许多模式只需几行代码就能实现。如果你确实要使用框架，请确保你理解底层代码。对底层实现的错误假设是我们看到的客户常见错误来源。
可以查看我们的cookbook获取一些范例实现。
构建模块、工作流和智能体
让我们探索在生产环境中常见的智能体系统模式。我们将从基础构建模块——增强型LLM开始，逐步提升复杂度，从简单的组合工作流到自主智能体。
基础构建模块：增强型LLM
智能体系统的基本构建模块是经过增强的LLM，这种增强包括检索、工具和记忆等能力。我们当前的模型可以主动使用这些功能——生成自己的搜索查询、选择合适的工具，并决定保留哪些信息。
增强型LLM示意图
我们建议关注实现的两个关键方面：根据具体用例定制这些功能，并确保为LLM提供简单、文档完善的接口。虽然有多种方式可以实现这些增强功能，但一种方法是通过我们最近发布的模型上下文协议(Model Context Protocol)，它允许开发者通过简单的客户端实现与不断发展的第三方工具生态系统集成。
在本文的其余部分中，我们假设每个LLM调用都能访问这些增强功能。
工作流：提示链
提示链将任务分解为一系列步骤，每个LLM调用都会处理前一个调用的输出。你可以在任何中间步骤添加程序化检查（见下图中的”检查点”），以确保流程仍在正轨上。
提示链工作流示意图
何时使用此工作流：
这种工作流最适合那些可以轻松且清晰地分解为固定子任务的情况。主要目标是通过拆解每个LLM调用成为更简单的子任务，来用延迟换取更高的准确性。
提示链的实用场景：
- 生成营销文案，然后将其翻译成不同语言；
- 写出文档大纲，检查大纲是否满足特定标准，然后基于大纲撰写文档；
工作流：路由
路由会对输入进行分类并将其引导到专门的后续任务。这种工作流允许关注点分离，并构建更专门化的提示。如果没有这种工作流，针对某一类输入的优化可能会损害其他输入的性能。
路由工作流示意图
何时使用此工作流：
路由适用于有明显不同类别需要分别处理的复杂任务，且分类可以被LLM或传统分类模型/算法准确处理的情况。
路由的实用场景：
- 将不同类型的客服查询（一般问题、退款请求、技术支持）引导到不同的下游流程、提示和工具；
- 将简单/常见问题路由到较小的模型（如Claude 3.5 Haiku），将困难/罕见问题路由到更强大的模型（如Claude 3.5 Sonnet），以优化成本和速度；
工作流：并行化
LLM有时可以同时处理任务，并通过程序化方式汇总它们的输出。这种并行化工作流主要有两种关键变体：
- 分段处理：将任务拆分成可以并行运行的独立子任务；
- 投票机制：多次运行相同任务以获得多样化的输出；
并行化工作流示意图
何时使用并行化：
当任务可以分解为并行子任务以提升速度时，或当需要多个视角或尝试来获得更高置信度的结果时，并行化特别有效。对于需要考虑多个方面的复杂任务，让每个LLM调用专注处理特定方面通常会表现更好，因为这允许模型将注意力集中在每个具体方面上。
并行化的实用场景：
分段处理：
- 实现安全护栏，其中一个模型实例处理用户查询，而另一个筛查不当内容或请求。这种方式往往比让同一个LLM同时处理安全护栏和核心响应表现更好；
- 自动化评估LLM性能，每个LLM调用评估模型在给定提示上的不同方面表现；
投票机制：
- 检查代码漏洞，让多个不同的提示审查代码并在发现问题时标记；
- 评估内容是否不当，让多个提示评估不同方面，或者通过不同的投票阈值来平衡假阳性和假阴性；
工作流：编排者-工作者模式
在编排者-工作者工作流中，一个中央LLM动态地分解任务，将它们分配给工作者LLM，并整合它们的结果。
编排者-工作者工作流示意图
何时使用编排者-工作者模式：
这种工作流非常适合那些无法预测所需子任务的复杂任务。比如在编程中，需要更改的文件数量和每个文件中更改的性质往往取决于具体任务。虽然在拓扑结构上与并行化类似，但关键区别在于其灵活性——子任务不是预定义的，而是由编排者根据具体输入来确定的。
编排者-工作者模式的实用场景：
- 需要对多个文件进行复杂更改的编程产品；
- 涉及从多个来源收集和分析信息以寻找可能相关信息的搜索任务；
工作流：评估者-优化者模式
在评估者-优化者工作流中，一个LLM生成响应，而另一个在循环中提供评估和反馈。
评估者-优化者工作流示意图
何时使用评估者-优化者模式：
当我们有明确的评估标准，且迭代改进能带来可衡量的价值时，这种工作流特别有效。判断是否适合使用这种模式有两个信号：首先，当人类表达反馈时，LLM的响应能够得到明显改善；其次，LLM能够提供这样的反馈。这类似于人类作者在创作高质量文档时会经历的迭代写作过程。
评估者-优化者的实用范例：
- 文学翻译，其中译者LLM可能最初没有捕捉到的细微差别可以通过评估者LLM的有用批评得到改进；
- 需要多轮搜索和分析才能收集全面信息的复杂搜索任务，评估者决定是否需要进行进一步搜索；
智能体
随着LLM在几个关键能力上日趋成熟，智能体正在生产环境中崭露头角。这些关键能力包括：理解复杂输入、进行推理和规划、可靠地使用工具，以及从错误中恢复。智能体开始工作时，要么是接收来自人类用户的指令，要么是通过互动对话来明确任务。一旦任务明确，智能体就会独立规划和运作，必要时会回到人类这里寻求更多信息或判断。
在执行过程中，智能体需要在每一步都从环境中获取”基本事实”（比如工具调用的结果或代码执行情况）来评估其进展。智能体可以在检查点或遇到障碍时暂停等待人类反馈。任务通常在完成后终止，但也常常会包含停止条件（比如最大迭代次数）以保持控制。
虽然智能体可以处理复杂的任务，但它们的实现往往出奇地简单。本质上，它们就是在一个循环中基于环境反馈使用工具的LLM。因此，清晰而深思熟虑地设计工具集及其文档至关重要。我们在附录2（”工具的提示工程”）中详细探讨了工具开发的最佳实践。
智能体示意图
何时使用智能体：
智能体适用于那些难以或无法预测所需步骤数量的开放性问题，以及无法硬编码固定路径的场景。LLM可能需要运行多个回合，因此你必须对其决策能力有一定程度的信任。智能体的自主性使其特别适合在可信环境中扩展任务。
但要注意，智能体的自主特性意味着更高的成本，并且可能出现错误累积。我们建议在沙盒环境中进行广泛测试，并配备适当的安全护栏。
智能体的实用场景：
- 一个用于解决SWE-bench任务的编码智能体，它可以根据任务描述对多个文件进行修改；
- 我们的“计算机使用(computer use)”参考实现，让Claude使用计算机来完成任务；
编码智能体的高层流程图
组合和定制这些模式
这些构建模块并非一成不变的规范，而是开发者可以根据不同用例塑造和组合的常见模式。如同任何LLM功能一样，成功的关键在于衡量性能并迭代实现。再次强调：只有在确实能改善结果的情况下，才考虑增加复杂性。
总结
在LLM领域，成功不在于构建最复杂的系统，而在于构建最适合你需求的系统。从简单的提示开始，通过全面的评估来优化它们，只有当更简单的解决方案不足以满足需求时，才添加多步骤的智能体系统。
在实现智能体时，我们遵循三个核心原则：
- 保持智能体设计的简单性；
- 通过明确展示智能体的规划步骤来保持透明度；
- 通过彻底的工具文档和测试来精心打造智能体-计算机接口（ACI）；
框架可以帮助你快速入门，但当需要部署到实际生产环境时，你应该果断简化系统中的抽象层，直接使用基础组件进行构建。只要严格遵循这些原则，你就能开发出既具有强大功能，又具备可靠性和可维护性的 AI 智能体，从而赢得用户的信任。
致谢
本文由Erik Schluntz和Barry Zhang撰写。这项工作源于我们在Anthropic构建智能体的经验，以及我们客户分享的宝贵见解，对此我们深表感谢。
附录1：智能体最佳实践
通过与客户的合作，我们发现了两个特别有前景的AI智能体应用场景，它们很好地展示了前文讨论的模式的实践价值。这两个应用都说明了智能体在什么情况下能创造最大价值：需要对话和行动相结合、有明确的成功标准、能形成反馈循环，并且包含有意义的人类监督的任务。
A. 客户支持
客户支持将熟悉的聊天机器人界面与通过工具集成实现的增强功能相结合。这非常适合更开放式的智能体，原因如下：
- 支持互动自然地遵循对话流程，同时需要访问外部信息和执行操作；
- 可以集成工具来获取客户数据、订单历史和知识库文章；
- 可以通过程序处理发放退款或更新工单等操作；
- 可以通过用户定义的解决方案清晰地衡量成功；
多家公司通过基于使用量的定价模式证明了这种方法的可行性，他们只对成功解决的案例收费，这显示了他们对智能体效能的信心。
B. 编码智能体
在软件开发这一领域，LLM 的应用展现出了巨大潜力，其功能已经从简单的代码补全进化到了自主解决问题的水平。AI 智能体在这一领域特别有效，原因在于：
- 代码解决方案可以通过自动化测试验证；
- 智能体可以使用测试结果作为反馈来迭代解决方案；
- 问题领域具有明确的边界和结构化的特点；
- 输出质量可以客观衡量；
在我们自己的实现中，智能体现在可以仅基于拉取请求描述就解决SWE-bench验证基准中的真实GitHub问题。不过，虽然自动化测试有助于验证功能，但人工审查仍然对确保解决方案符合更广泛的系统要求至关重要。
附录2：为你的工具进行提示词工程设计
无论你正在开发哪种 AI 智能体系统，工具都将是其中的关键组成部分。通过在我们的 API 中明确定义工具的结构和规范，Claude 就能够与外部服务和 API 进行交互。当 Claude 需要调用工具时，它会在 API 响应中生成相应的工具调用代码块。
在进行提示词工程设计时，工具的定义和规范与整体提示词同样重要，都需要投入同等的精力去优化。在这个简短的附录中，我们将介绍如何为你的工具进行提示词工程设计。
指定同一个动作通常有多种方式。例如，你可以通过编写差异（diff）或重写整个文件来指定文件编辑。对于结构化输出，你可以在markdown或JSON中返回代码。在软件工程中，这些差异是表面的，可以无损地从一种转换为另一种。然而，某些格式对LLM来说要困难得多。编写差异需要在写新代码之前知道区块头部中有多少行在变化。在JSON中编写代码（相比markdown）需要额外转义换行符和引号。
关于如何决定工具格式，我们的建议如下：
- 给模型足够的token来”思考”，避免它把自己写进死角；
- 保持格式接近模型在互联网上自然遇到的文本；
- 确保没有格式”开销”，比如必须保持准确计数数千行代码，或者必须转义它写的任何代码；
有一个实用的参考标准：在开发时要参考人机交互界面（Human-Computer Interface，HCI）的投入力度，并在设计 AI 智能体与计算机的交互界面（Agent-Computer Interface，ACI）时，投入相当的精力和资源。下面我们来探讨一下具体的实现方法：
- 站在模型的角度思考。基于描述和参数，使用这个工具是否显而易见，还是需要仔细思考？如果是后者，那么对模型来说可能也是如此。好的工具定义通常包括使用范例、边缘情况、输入格式要求，以及与其他工具的明确界限；
- 如何更改参数名称或描述使事情更显而易见？把这想象成为团队中的初级开发人员写一个很棒的文档字符串。这在使用多个相似工具时尤其重要；
- 测试模型如何使用你的工具：在我们的工作台中运行许多范例输入，看看模型会犯什么错误，然后迭代改进；
- 对你的工具进行防错设计。更改参数使其更难犯错；
在构建我们的SWE-bench智能体时，我们实际上花在优化工具上的时间比花在整体提示上的时间还多。例如，我们发现当智能体移出根目录后，模型在使用相对文件路径的工具时会出错。为了解决这个问题，我们更改了工具，始终要求使用绝对文件路径——我们发现模型完美地使用了这种方法。