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

本文为上文的译文（包括图片汉化）  译者：小七姐

过去一年，我们与多个行业的团队合作，协助他们构建大语言模型(Large Language Model, LLM)智能体。我们发现，最成功的实践并非依赖复杂的框架或专门的代码库，而是采用简单、可组合的模式。

本文将分享我们通过与客户合作以及自主构建智能体所获得的经验，并为开发者提供实用的建议。

什么是智能体？ 

"智能体"(Agent)可以有多种定义。一些客户将智能体定义为能够长期独立运行的全自动系统，它们可以使用各种工具来完成复杂任务。另一些则用这个术语描述更具规范性的实现，即遵循预定义工作流程的系统。

在 Anthropic，我们将这些变体统称为智能系统(Agentic Systems)，但在架构上区分为工作流(Workflows)和智能体(Agents)两种类型：

• 工作流是通过预定义代码路径来编排LLM和工具的系统。
• 智能体则是由LLM动态指导自身流程和工具使用的系统，能够自主控制任务完成方式。

下文将详细探讨这两种智能系统。在附录1（"智能体的实践应用"）中，我们将介绍客户在使用这类系统时发现特别有价值的两个领域。

什么时候使用（或不使用）智能体 

在构建基于LLM的应用时，我们建议先寻找最简单的解决方案，只在必要时增加复杂度。这可能意味着完全不使用智能系统。智能系统通常会以延迟和成本为代价来换取更好的任务表现，开发者需要考虑这种权衡是否合理。

当需要更复杂的解决方案时，工作流适合需要可预测性和一致性的明确任务，而智能体则更适合需要灵活性和模型驱动决策的大规模场景。然而，对于许多应用来说，优化单个LLM调用（配合检索和上下文示例）通常就足够了。

什么时候以及如何使用框架 

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

• LangChain的LangGraph
• 亚马逊Bedrock的AI Agent框架
• Rivet（一个拖放式GUI的LLM工作流构建器）
• Vellum（另一个用于构建和测试复杂工作流的GUI工具）

这些框架通过简化标准的底层任务（如调用LLM、定义和解析工具、链接调用等）使入门变得容易。但它们往往会创建额外的抽象层，这可能会使底层提示词和响应变得难以调试。它们也可能诱使开发者在简单设置就足够的情况下增加不必要的复杂性。

我们建议开发者先直接使用LLM API：许多模式只需要几行代码就能实现。如果确实要使用框架，请确保理解底层代码。对底层机制的错误假设是客户常见的错误来源。

详细示例请参考我们的实践指南。https://github.com/anthropics/anthropic-cookbook/tree/main/patterns/agents

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

在这一部分，我们将探讨我们在生产环境中观察到的智能系统常用模式。我们将从基础构建模块 —— 增强型LLM开始，逐步增加复杂度，从简单的组合工作流到自主智能体。

构建模块：增强型 LLM

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

图：增强型 LLM

我们建议在实施过程中重点关注两个方面：

针对具体使用场景定制这些功能，并确保为LLM提供简单且文档完备的接口。虽然实现这些增强功能的方法有很多，一个可行的方案是通过我们最近发布的模型上下文协议（Model Context Protocol）来实现。该协议允许开发者通过简单的客户端实现，与不断发展的第三方工具生态系统进行集成。

在本文的后续部分，我们将假设每个LLM调用都能够访问这些增强功能。

工作流：提示链（Prompt Chaining）

提示链将任务分解为一系列步骤，每个LLM调用都会处理前一个步骤的输出。您可以在任何中间步骤上添加程序化检查（请参见下图中的"门控"），以确保流程仍在正确轨道上。

图：提示链工作流

何时使用这种工作流：

这种工作流最适合那些可以轻松且清晰地分解为固定子任务的场景。其主要目标是通过使每个LLM调用成为更简单的任务，以延迟为代价换取更高的准确性。

提示链的实用案例：

• 生成营销文案，然后将其翻译成其他语言
• 撰写文档大纲，检查大纲是否符合特定标准，然后基于大纲撰写文档

工作流：路由（Routing）

路由会对输入进行分类，并将其引导至专门的后续任务。这种工作流允许关注点分离，并构建更专业化的提示。如果不采用这种工作流，为某一类型输入优化可能会影响其他输入的性能。

图：路由工作流

使用场景分析：

路由工作流（Routing Workflow）在处理以下场景时展现出特殊价值：当任务具有明显的类别区分，且这些类别需要独立处理时；同时，分类过程可以通过大语言模型或传统分类模型/算法准确完成。这种工作流体现了任务分流的智能化处理思维。

实践应用案例：

• 客户服务查询分类导向：将不同类型的客户服务需求（如一般咨询、退款请求、技术支持等）引导至相应的下游处理流程、特定提示模板和工具集。这种分流机制能够确保每类问题都获得最适合的处理方式。
• 模型能力匹配优化：基于问题复杂度进行智能分流。将简单或常见问题交由 Claude 3.5 Haiku（轻量级模型）处理，而将复杂或非常规问题引导至 Claude 3.5 Sonnet（高性能模型）这样的更具综合能力的模型处理。这种分层处理策略既优化了成本效益，也提升了响应速度。

工作流：并行化（Parallelization）机制

在大语言模型（Large Language Models, LLMs）的应用实践中，并行化工作流展现了一种独特的任务处理范式：通过程序化方式同时处理任务并整合输出。这种工作流主要体现为两种核心变体：

• 分段处理（Sectioning）：将一个复杂任务分解为可并行执行的独立子任务，体现了"分而治之"的智慧。
• 多重投票（Voting）：通过多次运行同一任务获取多样化输出，实现群体智慧的聚合。

图：并行化工作流

应用场景：

并行化策略在两类场景中展现出特殊价值：

1. 当子任务可以并行处理以提升效率时
2. 当需要多角度视角或多次尝试以提高结果可信度时

值得注意的是，在处理多维度考量的复杂任务时，让每个LLM调用专注于特定方面往往能带来更优的表现。这种"专注式处理"（Focused Processing）的理念与人类认知中的注意力分配机制不谋而合。

实践应用案例解析：

• 分段处理的典型应用：
• 针对给定提示词，不同的LLM调用负责评估模型性能的不同维度，实现全方位的性能度量。
• 通过模型实例的分工协作，一个处理用户查询的核心任务，另一个专注于内容审核，筛查不当内容或请求。这种分离处理相比单一模型同时处理两种任务展现出更优的性能表现。
• 安全防护机制（Guardrails）的实现：
• LLM性能评估自动化（Automated Evaluation）：
• 多重投票的应用场景：
• 代码安全审查（Code Security Review）：通过多个不同的提示模板对代码进行审查，若发现问题则进行标记，形成一个多重保障机制。
• 内容适当性评估（Content Appropriateness Evaluation）：采用多个提示词评估不同维度，或设置不同的投票阈值，以平衡假阳性（False Positives）和假阴性（False Negatives）的权衡问题。

工作流：协调者-工作者模式 Orchestrator-workers Workflow

在这种工作流模式中，核心设计理念是建立一个智能化的任务分解与整合机制：由中央大语言模型（Central LLM）担任"协调者"角色，灵活地将任务分解成子任务，委派给"工作者"模型（Worker LLMs）执行，最后综合各个工作者的成果。

图：协调-合成工作流

应用场景： 这种工作流特别适合那些子任务无法预先确定的复杂场景。以软件开发为例，每个任务可能涉及的文件数量和具体修改内容都是动态的、依赖具体情境的。虽然表面上看与并行化（Parallelization）工作流相似，但其核心优势在于灵活性——子任务不是预先定义的，而是由协调者根据具体输入动态决定的。

实践应用示例：

• 多文件复杂代码修改：处理需要在多个文件中进行复杂更改的编程任务
• 多源信息检索与分析：执行需要从多个来源收集和分析相关信息的搜索任务

工作流：评估-优化模式

Evaluator-optimizer Workflow

这是一种基于反馈循环的优化机制：一个LLM负责生成响应，而另一个则在循环中提供评估和反馈，形成一个持续改进的闭环系统。

图：评估-反馈工作流

使用场景：

当我们具有明确的评估标准，且迭代优化能带来可衡量的价值提升时，这种工作流特别有效。判断是否适合采用此模式有两个关键指标：

1. LLM的输出质量能够通过人类反馈显著提升
2. LLM能够提供类似人类的有效反馈

这个过程类似于一个作家在创作文档时的迭代修改过程，通过不断的自我审视和改进来提升作品质量。

典型应用场景：

• 文学翻译优化：处理译者LLM可能初期未能完全把握的细微差别，由评估者LLM提供建设性的改进建议
• 深度信息搜索：执行需要多轮搜索和分析来收集全面信息的复杂搜索任务，由评估者判断是否需要进行进一步搜索

智能体（Agents）

随着LLM在几个关键能力上的成熟——理解复杂输入、进行推理和规划、可靠使用工具以及从错误中恢复,智能体开始在生产环境中涌现。智能体通过与人类用户的命令或交互式对话开始工作。一旦任务明确,智能体就会独立进行规划和操作,必要时会向人类寻求更多信息或判断。

在执行过程中,智能体需要在每个步骤从环境中获取"基准事实"（如工具调用结果或代码执行情况）以评估其进展。智能体可以在检查点或遇到障碍时暂停等待人类反馈。任务通常在完成时终止,但也常常包含停止条件（如最大迭代次数）以保持控制。

智能体虽然可以处理复杂任务,但其实现往往很直接。它们通常只是基于环境反馈在循环中使用工具的LLM。因此,清晰而深思熟虑地设计工具集及其文档至关重要。我们在附录2（"工具的提示工程"）中详细探讨了工具开发的最佳实践。

图：自主智能体

使用场景：

智能体适用于难以或无法预测所需步骤数量的开放性问题,且无法硬编码固定路径的场景。LLM可能需要运行多个回合,您必须对其决策能力有一定信任。智能体的自主性使其非常适合在可信环境中扩展任务。

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

实用案例：

以下是我们自己的实践案例：

• 用于解决SWE-bench任务的编码智能体,根据任务描述对多个文件进行编辑：https://www.anthropic.com/research/swe-bench-sonnet
• 我们的"计算机使用"参考实现,让Claude使用计算机完成任务：https://github.com/anthropics/anthropic-quickstarts/tree/main/computer-use-demo

图：编程智能体高级流程

组合和定制这些模式 

这些构建模块并非强制性的规范。它们是开发者可以根据不同用例进行调整和组合的常见模式。与任何LLM功能一样,成功的关键在于衡量性能并迭代实现。重申一点：只有在能够明确改善成果时,才应考虑增加复杂性。

总结 

在LLM领域取得成功并不在于构建最复杂的系统,而在于为您的需求构建正确的系统。从简单的提示开始,通过全面评估进行优化,只有在更简单的解决方案不足时才添加多步骤的智能系统。

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

1. 保持智能体设计的简单性
2. 通过明确展示智能体的规划步骤来确保透明度
3. 通过全面的工具文档和测试来精心设计智能体-计算机接口（ACI）

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

致谢 

本文由Erik Schluntz和Barry Zhang撰写。本文的内容源自我们在Anthropic构建智能体的经验,以及客户分享的宝贵见解,对此我们深表感谢。

附录1：智能体的实践应用 

我们与客户的合作揭示了AI智能体的两个特别有前景的应用,展示了上述模式的实践价值。这两个应用都说明了智能体在以下场景中最能增加价值：需要对话和行动相结合、有明确的成功标准、支持反馈循环,并集成有意义的人工监督。

A. 客户支持

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

• 支持互动自然遵循对话流程,同时需要访问外部信息和执行操作
• 可以集成工具来获取客户数据、订单历史和知识库文章
• 可以通过程序处理退款或更新工单等操作
• 可以通过用户定义的解决方案清晰衡量成功

多家公司通过基于使用的定价模型（仅对成功解决的案例收费）证明了这种方法的可行性,显示了他们对智能体效能的信心。

B. 编码智能体

软件开发领域展现了LLM功能的巨大潜力,从代码补全发展到自主问题解决。智能体特别有效,因为：

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

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

https://www.anthropic.com/research/swe-bench-sonnet

附录2：工具的提示工程 

无论您构建哪种智能系统,工具都可能是您的智能体的重要组成部分。工具使Claude能够通过在我们的API中指定其确切结构和定义来与外部服务和API交互。当Claude响应时,如果它计划调用工具,它将在API响应中包含工具使用块。工具定义和规范应该得到与整体提示词同等的提示工程关注。在这个简短的附录中,我们描述如何对工具进行提示工程。

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

我们对决定工具格式的建议如下：

• 给模型足够的词元（token）来"思考",避免陷入困境
• 保持格式接近模型在互联网文本中自然见到的形式
• 确保没有格式"开销",比如需要保持准确计数数千行代码,或对所写代码进行字符串转义

一个经验法则是考虑人机界面（HCI）研究投入了多少努力,并计划在创建良好的智能体-计算机界面（ACI）上投入同样的努力。以下是一些具体建议：

• 站在模型的角度思考。基于描述和参数,使用这个工具是否显而易见,还是需要仔细思考？如果是后者,那么对模型来说可能也是如此。一个好的工具定义通常包括使用示例、边缘案例、输入格式要求,以及与其他工具的明确界限
• 如何更改参数名称或描述以使事情更明显？将此视为为团队中的初级开发人员编写出色的文档说明。这在使用多个类似工具时特别重要
• 测试模型如何使用您的工具：在工作台中运行多个示例输入,查看模型犯什么错误,并进行迭代：https://console.anthropic.com/workbench
• 对您的工具进行防错设计。更改参数以减少出错的可能性：https://en.wikipedia.org/wiki/Poka-yoke

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

译文：https://vxc3hj17dym.feishu.cn/wiki/OKXFwZeCkiCJSikYPmzcV5tfnAe