构建高效 Agent¶

原文链接: English Original

Anthropic 工程博客

构建高效 Agent¶

发布于 2024年12月19日

我们与数十个跨行业的团队合作，构建 LLM Agent。我们发现，最成功的实现始终使用简单、可组合的模式，而非复杂的框架。过去一年中，我们与数十个跨行业的团队合作，构建大语言模型（LLM）Agent。最成功的实现都没有使用复杂的框架或专用库。相反，他们使用简单、可组合的模式进行构建。

在这篇文章中，我们分享从与客户合作以及自己构建 Agent 中获得的经验，并为开发者提供构建高效 Agent 的实用建议。

什么是 Agent？¶

"Agent" 可以有多种定义方式。一些客户将 Agent 定义为在较长时间内独立运行的完全自治系统，使用各种工具来完成复杂任务。另一些客户则用这个术语来描述遵循预定义工作流的更规范化的实现。在 Anthropic，我们将所有这些变体归类为 Agent 系统，但在架构上做出一个重要区分：workflow（工作流）和 agent（智能体）：

Workflow（工作流） 是通过预定义代码路径编排 LLM 和工具的系统。
Agent（智能体） 则是 LLM 动态指导自身流程和工具使用的系统，自主掌控如何完成任务。

下面，我们将详细探讨这两种 Agent 系统。在附录1（"Agent 实践"）中，我们描述了客户在使用这类系统时发现特别有价值的两个领域。

何时使用（以及何时不使用）Agent¶

在使用 LLM 构建应用时，我们建议找到尽可能简单的解决方案，只有在需要时才增加复杂性。这可能意味着根本不需要构建 Agent 系统。Agent 系统通常以延迟和成本换取更好的任务性能，你应该考虑这种权衡在何时是合理的。

当确实需要更多复杂性时，workflow 为明确定义的任务提供可预测性和一致性，而 agent 则在需要灵活性和模型驱动决策的场景下是更好的选择。然而，对于许多应用来说，通过检索和上下文示例优化单次 LLM 调用通常就足够了。

何时以及如何使用框架¶

有许多框架使 Agent 系统更容易实现，包括： - Claude Agent SDK - AWS 的 Strands Agents SDK - Rivet，一个拖拽式 GUI LLM workflow 构建器 - Vellum，另一个用于构建和测试复杂 workflow 的 GUI 工具

这些框架通过简化调用 LLM、定义和解析工具、串联调用等标准底层任务，使入门变得容易。然而，它们通常创建额外的抽象层，可能会遮蔽底层的 prompt 和响应，使调试变得更加困难。它们还可能诱使你在简单设置就足够的情况下增加复杂性。

我们建议开发者首先直接使用 LLM API：许多模式可以用几行代码实现。如果你确实使用框架，请确保理解底层代码。对底层实现的不正确假设是客户错误的常见来源。

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

构建模块、Workflow 和 Agent¶

在本节中，我们将探讨在生产环境中看到的 Agent 系统的常见模式。我们将从基础构建模块——增强型 LLM——开始，逐步增加复杂性，从简单的组合 workflow 到自治 Agent。

构建模块：增强型 LLM¶

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

我们建议关注实现中的两个关键方面：将这些能力定制到你的特定用例，以及确保它们为 LLM 提供简单、文档完善的接口。虽然有多种方式实现这些增强，一种方法是通过我们最近发布的 Model Context Protocol（MCP），它允许开发者通过简单的客户端实现与不断增长的第三方工具生态系统集成。

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

Workflow：Prompt 链式调用（Prompt Chaining）¶

Prompt 链式调用将任务分解为一系列步骤，每个 LLM 调用处理上一个的输出。你可以在任何中间步骤添加程序化检查（参见下图中的"gate"），以确保过程仍然在正确的轨道上。

何时使用此 workflow： 此 workflow 适用于任务可以轻松清晰地分解为固定子任务的情况。主要目标是通过使每个 LLM 调用成为更简单的任务，以延迟换取更高的准确性。

Prompt 链式调用有用的示例： - 生成营销文案，然后将其翻译成不同语言。 - 编写文档大纲，检查大纲是否符合某些标准，然后基于大纲编写文档。

Workflow：路由（Routing）¶

路由对输入进行分类，并将其引导到专门的后续任务。此 workflow 实现了关注点分离，并构建更专业的 prompt。没有此 workflow，针对一种输入的优化可能会损害其他输入的性能。

何时使用此 workflow： 路由适用于有不同类别需要分别处理的复杂任务，且分类可以由 LLM 或更传统的分类模型/算法准确处理的情况。

路由有用的示例： - 将不同类型的客户服务查询（一般问题、退款请求、技术支持）引导到不同的下游流程、prompt 和工具。 - 将简单/常见问题路由到更小、更经济的模型如 Claude Haiku 4.5，将困难/罕见问题路由到更强大的模型如 Claude Sonnet 4.5，以优化最佳性能。

Workflow：并行化（Parallelization）¶

LLM 有时可以同时处理一个任务，并通过程序化方式聚合其输出。此 workflow——并行化——有两种关键变体： - 分段（Sectioning）： 将任务分解为并行运行的独立子任务。 - 投票（Voting）： 多次运行相同任务以获得多样化的输出。

何时使用此 workflow： 当分解的子任务可以并行化以提高速度，或者需要多个视角或尝试以获得更高置信度的结果时，并行化是有效的。对于有多个考量因素的复杂任务，LLM 通常在每个考量因素由单独的 LLM 调用处理时表现更好，从而允许对每个特定方面进行专注处理。

并行化有用的示例： - 分段： 实现护栏，一个模型实例处理用户查询，而另一个检查不适当的内容或请求。这通常比同一个 LLM 调用同时处理护栏和核心响应表现更好。 - 自动化评估，评估 LLM 性能，每个 LLM 调用评估模型在给定 prompt 上性能的不同方面。 - 投票： 审查代码中的漏洞，几个不同的 prompt 审查代码并在发现问题时标记。 - 评估给定内容是否不当，多个 prompt 评估不同方面或需要不同的投票阈值以平衡误报和漏报。

Workflow：编排器-工作者（Orchestrator-Workers）¶

在编排器-工作者 workflow 中，一个中央 LLM 动态分解任务，将其委托给工作者 LLM，并综合他们的结果。

何时使用此 workflow： 此 workflow 适用于无法预测所需子任务的复杂任务（例如，在编码中，需要更改的文件数量和每个文件中更改的性质可能取决于任务）。虽然在拓扑结构上相似，但与并行化的关键区别在于其灵活性——子任务不是预定义的，而是由编排器根据特定输入确定的。

编排器-工作者有用的示例： - 每次对多个文件进行复杂更改的编码产品。 - 涉及从多个来源收集和分析信息以查找可能相关信息的搜索任务。

Workflow：评估器-优化器（Evaluator-Optimizer）¶

在评估器-优化器 workflow 中，一个 LLM 调用生成响应，另一个在循环中提供评估和反馈。

何时使用此 workflow： 此 workflow 在我们有明确评估标准且迭代改进提供可衡量的价值时特别有效。两个良好适配的标志是：首先，当人类表达反馈时 LLM 的响应可以被证明有所改善；其次，LLM 能够提供这样的反馈。这类似于人类作家在制作精炼文档时可能经历的迭代写作过程。

评估器-优化器有用的示例： - 文学翻译，其中翻译 LLM 可能最初无法捕捉到一些细微差别，但评估器 LLM 可以提供有用的批评。 - 需要多轮搜索和分析以收集全面信息的复杂搜索任务，其中评估器决定是否需要进一步搜索。

Agent¶

随着 LLM 在关键能力上的成熟——理解复杂输入、进行推理和规划、可靠使用工具以及从错误中恢复——Agent 正在生产中崭露头角。Agent 从人类用户的命令或交互式对话开始工作。一旦任务明确，Agent 就独立规划和操作，可能返回人类以获取更多信息或判断。在执行过程中，Agent 在每个步骤从环境获取"真实信息"（如工具调用结果或代码执行结果）以评估其进度至关重要。Agent 可以在检查点或遇到阻碍时暂停以获取人类反馈。任务通常在完成时终止，但也很常见的是包含停止条件（如最大迭代次数）以保持控制。

Agent 可以处理复杂的任务，但其实现通常很简单。它们通常只是基于环境反馈在循环中使用工具的 LLM。因此，精心设计工具集及其文档至关重要。我们在附录2（"为你的工具做 Prompt Engineering"）中扩展了工具开发的最佳实践。

何时使用 Agent： Agent 可以用于开放性问题，其中预测所需步骤数是困难或不可能的，且无法硬编码固定路径。LLM 可能会运行很多轮，你必须对其决策有一定程度的信任。Agent 的自主性使其成为在受信任环境中扩展任务的理想选择。

Agent 的自治性质意味着更高的成本，以及错误累积的潜在可能性。我们建议在沙盒环境中进行广泛测试，并配合适当的护栏。

Agent 有用的示例：

以下示例来自我们自己的实现： - 一个编码 Agent，用于解决 SWE-bench 任务，涉及根据任务描述编辑多个文件。 - 我们的"computer use"参考实现，其中 Claude 使用计算机完成任务。

组合和定制这些模式¶

这些构建模块并非规范性的。它们是开发者可以塑造和组合以适应不同用例的常见模式。成功的关键与任何 LLM 功能一样，是衡量性能并迭代实现。重申：只有在可证明能改善结果时才应考虑增加复杂性。

总结¶

在 LLM 领域的成功不在于构建最复杂的系统。而在于为你的需求构建合适的系统。从简单的 prompt 开始，通过全面评估进行优化，只有在更简单的解决方案不足时才添加多步骤 Agent 系统。

在实现 Agent 时，我们尝试遵循三个核心原则： - 保持 Agent 设计的简洁性。 - 通过明确展示 Agent 的规划步骤来优先考虑透明度。 - 通过全面的工具文档和测试来精心设计你的 agent-computer interface（ACI）。

框架可以帮助你快速入门，但在进入生产时不要犹豫减少抽象层并使用基本组件构建。通过遵循这些原则，你可以创建不仅强大而且可靠、可维护且受用户信任的 Agent。

致谢¶

由 Erik S. 和 Barry Zhang 撰写。本文基于我们在 Anthropic 构建 Agent 的经验以及客户分享的宝贵见解，对此我们深表感谢。

附录1：Agent 实践¶

我们与客户的合作揭示了 AI Agent 两个特别有前景的应用，展示了上述讨论模式的实际价值。这两个应用都说明了 Agent 在需要对话和行动、有明确成功标准、支持反馈循环以及集成有意义的人类监督的任务中如何产生最大价值。

A. 客户支持¶

客户支持将熟悉的聊天机器人界面与通过工具集成增强的功能相结合。这自然适合更开放的 Agent，因为： - 支持交互自然遵循对话流程，同时需要访问外部信息和操作。 - 可以集成工具来拉取客户数据、订单历史和知识库文章。 - 发放退款或更新工单等操作可以通过程序化方式处理。 - 成功可以通过用户定义的解决方案清晰衡量。

几家公司通过基于使用量计费的定价模型展示了这种方法的有效性，仅对成功解决的案例收费，显示出对其 Agent 有效性的信心。

B. 编码 Agent¶

软件开发领域显示出 LLM 功能的巨大潜力，能力从代码补全发展到自主解决问题。Agent 特别有效，因为： - 代码解决方案可以通过自动化测试验证。 - Agent 可以使用测试结果作为反馈来迭代解决方案。 - 问题空间定义良好且结构化。 - 输出质量可以客观衡量。

在我们自己的实现中，Agent 现在可以仅基于 pull request 描述解决 SWE-bench Verified 基准测试中的真实 GitHub 问题。然而，自动化测试有助于验证功能，但人工审查对于确保解决方案符合更广泛的系统需求仍然至关重要。

附录2：为你的工具做 Prompt Engineering¶

无论你构建哪种 Agent 系统，工具都可能是你的 Agent 的重要组成部分。工具通过在我们的 API 中指定其精确结构和定义，使 Claude 能够与外部服务和 API 交互。当 Claude 响应时，如果它计划调用工具，将在 API 响应中包含一个工具使用块。工具定义和规范应该获得与整体 prompt 同等程度的 prompt engineering 关注。在这个简短的附录中，我们描述如何为工具做 prompt engineering。

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

我们关于决定工具格式的建议如下： - 给模型足够的 token 在把自己逼入死角之前"思考"。 - 保持格式接近模型在互联网文本中自然看到的内容。 - 确保没有格式"开销"，例如需要准确计算数千行代码的行数，或对编写的任何代码进行字符串转义。

一个经验法则是考虑在人类-计算机界面（HCI）上投入了多少精力，并计划在创建良好的 agent-computer interface（ACI）上投入同等的精力。以下是一些关于如何做到这一点的思考： - 站在模型的角度。根据描述和参数，如何使用这个工具是否明显？还是需要仔细思考？如果是后者，那么对模型来说可能也是如此。一个好的工具定义通常包括示例用法、边缘情况、输入格式要求以及与其他工具的清晰边界。 - 如何更改参数名称或描述使事情更明显？将其视为为团队中的初级开发者编写优秀的 docstring。这在同时使用许多相似工具时尤其重要。 - 测试模型如何使用你的工具：在我们的工作台中运行许多示例输入，看看模型犯了什么错误，并进行迭代。 - 对你的工具进行防错（Poka-yoke）。更改参数使错误更难发生。

在为 SWE-bench 构建 Agent 时，我们实际上花在优化工具上的时间比整体 prompt 更多。例如，我们发现模型在 Agent 移出根目录后会犯使用相对文件路径的错误。为了解决这个问题，我们将工具更改为始终要求绝对文件路径——我们发现模型使用此方法完美无瑕。