Anthropic如何打造高效智能体

本文翻译自Anthropic 团队博客，毋容置疑，从 claude 的效果看，该团队在如何构建 AI 智能体上，无论是理论还是实践上，已经是全球首屈一指的存在。关注这个领域的朋友，可以细读一下。今天的译文，可能跟设计师的距离有点远，但是技多不压身，多了解一些还是非常有用的~😎

2024 年 12 月 20 日

过去一年，我们与各行各业的数十个团队合作，构建大型语言模型（LLM）智能体。我们发现，最成功的实践并非依赖复杂的框架或专门的库，而是采用简单且易于组合的模式。

本文中，我们将分享与客户合作以及自身构建智能体的经验，为开发者提供构建高效智能体的实用建议。

什么是智能体？

“智能体”的定义多种多样。部分客户将智能体定义为完全自主的系统，它们在较长时间内独立运行，利用各种工具完成复杂任务。也有人将其用来描述遵循预定义工作流的、更具指导性的实现方案。在 Anthropic，我们将所有这些变体都归类为“智能体系统”，但同时在架构上区分“工作流程”和“智能体”：

工作流程是指 LLM 和工具通过预先设定的代码路径进行协调的系统。
智能体，则是由 LLM 动态地控制自身流程和工具使用，并主导任务完成方式的系统。

接下来，我们将深入探讨这两种智能体系统。在附录 1（“实践中的智能体”）中，我们将介绍客户在使用这些系统时发现的两个特别有价值的应用领域。

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

使用 LLM 构建应用时，我们建议优先选择最简单的方案，仅在必要时增加复杂性。这可能意味着根本不需要构建智能体系统。智能体系统通常会牺牲延迟和成本来换取更好的任务性能，您需要考虑这种权衡是否值得。

对于需要更高复杂性的场景，工作流程能为定义明确的任务提供可预测性和一致性；而当需要在规模上实现灵活性和模型驱动的决策时，智能体是更好的选择。但是，对于许多应用而言，仅通过检索和上下文示例优化单个 LLM 调用通常就足够了。

何时以及如何使用框架

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

LangChain 的 LangGraph；
Amazon Bedrock 的 AI 智能体框架；
Rivet，一款拖放式 GUI LLM 工作流程构建器；以及
Vellum，另一款用于构建和测试复杂工作流程的 GUI 工具。

这些框架简化了调用 LLM、定义和解析工具以及将调用串联等标准底层任务，从而降低了入门门槛。然而，它们通常会引入额外的抽象层，从而模糊底层的提示和响应，增加了调试难度。当简单设置就足够时，它们也可能导致不必要的复杂性。

我们建议开发者首先直接使用 LLM API：许多模式只需几行代码即可实现。如果您选择使用框架，务必确保您理解其底层代码。对底层原理的误解是导致客户出现错误的常见原因。

请参阅我们的示例以获取一些实现示例。

构建模块、工作流程和智能体

本节将介绍我们在生产环境中观察到的智能体系统的常见模式。我们将从基础构建模块——增强型 LLM 入手，逐步增加复杂性，从简单的组合工作流程过渡到自主智能体。

构建模块：增强型 LLM

智能体系统的基本构建模块是经过检索、工具和记忆等增强的 LLM。我们目前的模型能够积极使用这些功能，例如生成搜索查询、选择合适的工具以及确定需要保留的信息。

增强型 LLM

我们建议关注实现过程中的两个关键方面：一是根据您的具体用例定制这些功能，二是确保它们为您的 LLM 提供一个简单易用、文档完善的接口。虽然有多种方式实现这些增强功能，但一种方法是使用我们最近发布的模型上下文协议，该协议允许开发者通过简单的客户端实现与不断增长的第三方工具生态系统集成。

在本文的剩余部分，我们将假设每次 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 可以提供有用的评论。
复杂的搜索任务，需要多轮搜索和分析才能收集全面的信息，其中评估器决定是否需要进一步搜索。

智能体

随着 LLM 在理解复杂输入、推理规划、可靠使用工具和错误恢复等关键能力上的成熟，智能体正逐步在生产环境中得到应用。智能体的工作通常始于人类用户的命令或交互式对话。一旦任务明确，智能体便会独立进行计划和执行，并可能在需要时返回给人类用户以获取更多信息或判断。在执行过程中，智能体需要从环境中获取每一步的“真实情况”（例如工具调用结果或代码执行）来评估其进度，这一点至关重要。智能体可以在检查点或遇到障碍时暂停，以获取人类的反馈。任务通常在完成时终止，但也通常包括停止条件（例如最大迭代次数）以保持控制。

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

自主智能体

何时使用智能体： 智能体适用于开放性问题，即难以或不可能预测所需的步骤数量，并且无法硬编码固定路径。LLM 可能会运行很多轮次，您必须对其决策制定具有一定程度的信任。智能体的自主性使其非常适合在受信任的环境中扩展任务。

智能体的自主性意味着更高的成本和潜在的错误累积风险。我们建议在沙盒环境中进行广泛的测试，并采取适当的保护措施。

智能体的适用场景：

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

用于解决 SWE-bench 任务的编码智能体，该任务涉及基于任务描述编辑多个文件；
我们的 “计算机使用”参考实现，其中 Claude 使用计算机来完成任务。

编码智能体的高级流程

组合和自定义这些模式

这些构建模块并非强制性的，而是开发人员可以根据不同的用例进行调整和组合的常见模式。与任何 LLM 功能一样，成功的关键在于衡量性能并迭代改进。再次强调，只有在它能明显改善结果时，才考虑增加复杂性。

总结

在 LLM 领域取得成功的关键不在于构建最复杂的系统，而在于构建最符合您需求的系统。从简单的提示开始，通过全面的评估进行优化，仅在简单方案无法满足需求时再考虑引入多步骤智能体系统。

在实施智能体时，我们尝试遵循三个核心原则：

在智能体设计中保持简洁性。
优先考虑透明度，明确展示智能体的计划步骤。
通过完善的工具文档和测试，精心设计您的智能体-计算机接口 (ACI)。

框架可以帮助您快速入门，但当您转向生产环境时，请毫不犹豫地减少抽象层并使用基本组件进行构建。遵循这些原则，您可以创建不仅强大而且可靠、可维护且受用户信任的智能体。

致谢

由 Erik Schluntz 和 Barry Zhang 撰写。这项工作借鉴了我们在 Anthropic 构建智能体的经验以及我们客户分享的宝贵见解，对此我们深表感谢。

附录 1：实践中的智能体

我们与客户的合作揭示了人工智能智能体的两个特别有前景的应用，它们充分体现了上述模式的实际价值。这两个应用都表明，对于需要对话和操作、有明确的成功标准、能够启用反馈循环以及需要整合有效的人工监督的任务，智能体能够发挥最大的价值。

A. 客户支持

客户支持通过工具集成，将熟悉的聊天机器人界面与增强的功能结合起来。这非常适合更开放的智能体，因为：

支持交互自然地遵循对话流程，同时需要访问外部信息和操作；
可以集成工具来提取客户数据、订单历史记录和知识库文章；
可以以编程方式处理诸如发放退款或更新工单之类的操作；并且
可以通过用户定义的解决方案清楚地衡量成功。

一些公司通过基于使用量的定价模式证明了该方法的可行性，他们只对成功的解决方案收费，这表明了他们对智能体有效性的信心。

B. 编码智能体

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

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

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

附录 2：提示工程您的工具

无论您构建哪种智能体系统，工具都可能是智能体的重要组成部分。工具使 Claude 能够通过在我们 API 中指定其确切结构和定义来与外部服务和 API 进行交互。当 Claude 响应时，如果它计划调用工具，它将在 API 响应中包含一个工具使用块。工具定义和规范应与整体提示一样，受到提示工程的重视。在本附录中，我们将介绍如何对工具进行提示工程。

通常，有多种方式可以指定相同的操作。例如，您可以通过编写差异来指定文件编辑，也可以通过重写整个文件来指定文件编辑。对于结构化输出，您可以在 Markdown 或 JSON 中返回代码。在软件工程中，这些差异是表面上的，可以从一种无损地转换为另一种。但是，某些格式对于 LLM 来说比其他格式更难编写。编写差异需要知道在编写新代码之前块头中有多少行正在更改。在 JSON 中编写代码（与 Markdown 相比）需要额外转义换行符和引号。

关于如何选择工具格式，我们有以下建议：

在模型陷入困境之前，给予其足够的令牌进行“思考”。
保持格式与模型在互联网文本中自然看到的格式接近。
确保没有格式上的“额外负担”，例如必须精确计算数千行代码，或者对它编写的代码进行字符串转义。

一个经验法则是，考虑到人机界面 (HCI) 所需的投入，并计划投入相同程度的精力来创建良好的智能体-计算机界面 (ACI)。以下是一些关于如何做到这一点的建议：

设身处地为模型着想。根据描述和参数，如何使用此工具是否显而易见，或者您是否需要仔细考虑？如果是这样，那么对于模型来说可能也是如此。一个好的工具定义通常包括示例用法、边缘案例、输入格式要求以及与其他工具的明确界限。
如何更改参数名称或描述以使事情更清楚？将此视为为团队中的初级开发人员编写一个很棒的文档字符串。当使用许多类似的工具时，这一点尤其重要。
测试模型如何使用您的工具：在我们的工作台中运行多个示例输入，观察模型犯了哪些错误，并进行迭代改进。
对您的工具进行防错设计，修改参数以降低出错的可能性。

在为 SWE-bench 构建我们的智能体时，我们实际上花费了更多的时间来优化工具，而不是整体提示。例如，我们发现模型在使用相对文件路径的工具后，在智能体移出根目录后会出现错误。为了解决这个问题，我们更改了该工具，使其始终要求绝对文件路径——我们发现该模型完美地使用了这种方法。

原文地址：https://www.anthropic.com/research/building-effective-agents

更多 AI 辅助设计和设计灵感趋势，请关注公众号（设计小站）：sjxz 00。