一、前言
我们在过去的一年中，与来自各行各业的数十个团队合作，共同构建大语言模型（LLM）智能体。我们发现，那些最成功的落地实践，并不是依赖复杂的框架或专用库，而是采用了简单、可组合的模式。
在这篇文章中，我们将分享与客户合作以及自身构建智能体的经验总结，并为开发者提供一系列构建高效智能体的实用建议。
二、什么是智能体（Agents）？
“智能体”这个概念有多种定义。一些客户认为，智能体是可以在较长时间内自主运行的系统，它们能调用各种工具来完成复杂任务；而另一些客户则将智能体理解为遵循预设流程的指导性实现。
在 Anthropic，我们将这些不同类型统称为智能体系统（agentic systems），但在架构层面上，我们做出了一个关键区分：
- 工作流（Workflows）：这类系统通过预定义的代码路径来编排 LLM 与外部工具之间的协作。
- 智能体（Agents）：这类系统由 LLM 自主驱动，能够动态决定执行流程和工具使用方式，掌控任务完成的方式与节奏。
在接下来的内容中，我们将深入探讨这两类智能体系统的特性。
在附录一《智能体的实际应用》中，我们还将介绍两个客户实践案例，这些案例展现了智能体系统在特定场景中的显著价值。
三、何时（以及何时不）使用智能体
在使用大语言模型（LLM）构建应用时，我们建议始终优先选择最简单的解决方案，仅在确有必要时再引入复杂机制。这也意味着，很多情况下并不需要构建智能体系统。
智能体系统通常以更高的延迟和成本为代价，换取更强的任务执行能力。因此，你需要谨慎评估这种权衡是否值得。
当应用场景确实需要更高的复杂度时：
- 工作流适用于任务明确、流程稳定的场景，能够提供可预测性和一致性；
- 智能体则更适合需要灵活性和模型主导决策的大规模任务处理。
不过，对于许多应用而言，通过检索增强（RAG）和上下文示例优化单轮 LLM 调用，往往就已足够，无需引入完整的智能体系统。
四、何时以及如何使用框架
目前有许多框架可以帮助简化智能体系统的构建，包括：
- LangGraph（来自 LangChain）
- Amazon Bedrock 的 AI Agent 框架
- Rivet：一个可视化的拖拽式 LLM 工作流构建工具
- Vellum：另一个用于构建和测试复杂工作流的图形化工具
这些框架通过简化底层操作（如调用 LLM、定义与解析工具、管理调用链等）来降低上手门槛，非常适合快速原型开发。然而，它们通常会引入额外的抽象层，可能掩盖底层提示词与响应细节，从而增加调试难度。此外，框架往往也会诱导开发者过度设计本可简单实现的系统。
我们建议开发者优先直接使用 LLM API，因为许多常见模式只需几行代码就能实现。如果你确实选择使用框架，一定要深入理解其底层机制。对内部逻辑的误解，往往是客户出错的主要原因之一。
可参考我们的「Cookbook」示例手册，获取一些典型实现案例。
Cook book：https://github.com/anthropics/anthropic-cookbook/tree/main/patterns/agents
五、构建模块、工作流与智能体
在本节中，我们将介绍在实际生产环境中常见的智能体系统构建模式。从最基础的构建单元——增强型大语言模型（augmented LLM）开始，逐步过渡到更复杂的系统结构，包括组合式工作流与自主型智能体。
构建模块：增强型 LLM（Augmented LLM）
智能体系统的基础构件是经过增强的大语言模型。它通常集成以下能力：
- 检索（Retrieval）：通过检索外部知识库来扩展模型的知识范围；
- 工具使用（Tool Use）：如 API 调用、数据库查询、计算工具等；
- 记忆机制（Memory）：用于保留上下文或历史状态，以便进行长期交互。
目前的大模型已经可以主动调度这些增强能力——它们能够自主生成搜索查询、选择合适的工具，以及判断哪些信息需要长期记忆。这种能力正是构建更复杂智能体系统的基石。
我们建议在实现增强型 LLM 时重点关注两个核心方面：
- 根据具体业务场景定制增强能力；
- 为 LLM 提供清晰、易用、文档完善的接口。
尽管实现这些增强功能的方式有很多种，但我们推荐的一种方法是使用我们近期发布的 模型上下文协议（Model Context Protocol）。该协议支持通过简单的客户端实现，将 LLM 与不断扩展的第三方工具生态系统集成在一起。
模型上下文协议（Model Context Protocol）：https://www.anthropic.com/news/model-context-protocol
客户端实现：https://modelcontextprotocol.io/tutorials/building-a-client#building-mcp-clients
在接下来的内容中，我们将默认每次 LLM 调用都具备这些增强能力。
工作流模式：提示词链（Prompt Chaining）
提示词链（Prompt Chaining）是一种常见的工作流模式，它将复杂任务 拆解为一系列步骤，每一步由 LLM 处理，并将上一步的输出作为当前输入。
这个过程中，你可以在任意中间步骤插入程序化检查点（如下图中的“gate”）以验证流程是否仍在正确轨道上，从而提高整体稳定性与可控性。
这种模式结构清晰、易于调试，非常适合处理多阶段任务、需要局部验证或人机协作的场景。
何时使用提示词链工作流
提示词链工作流适用于可以被清晰拆分为固定子任务的场景。通过将复杂任务分解为多个简单步骤，每次调用 LLM 只需处理较小的子任务，从而以牺牲一定延迟为代价换取更高的准确度。
提示词链的典型应用示例包括：
- 先生成营销文案，再将其翻译成另一种语言。
- 先撰写文档大纲，检查大纲是否符合要求，最后根据大纲完成文档撰写。
工作流模式：路由（Routing）
路由工作流根据输入内容进行分类，并将其引导至针对性的后续任务。该模式有助于实现职责分离，并设计更专业化的提示词策略。
如果没有路由机制，针对某一类输入优化的提示词可能会降低对其他输入类型的处理效果，从而影响整体性能。
何时使用路由工作流
路由工作流适用于任务较为复杂、且存在明显类别划分且可准确分类的场景。分类可以由大语言模型（LLM）或传统的分类模型/算法完成。
路由工作流的典型应用示例包括：
- 将不同类型的客服请求（如常见问题、退款申请、技术支持）引导至不同的后续处理流程、提示词和工具。
- 将简单或常见的问题路由给计算资源较低的小模型（如 Claude 3.5 Haiku），而将复杂或罕见的问题交由更强大的模型（如 Claude 3.5 Sonnet）处理，以优化成本和响应速度。
工作流模式：并行化（Parallelization）
并行化工作流允许 LLM 同时处理任务的不同部分，并通过程序逻辑对结果进行汇总。并行化主要有两种形式：
- 分段处理（Sectioning）：将任务拆分为相互独立的子任务，分别并行执行。
- 投票机制（Voting）：对同一任务多次运行，获取多样化输出，再通过投票或其他聚合方式决定最终结果。
何时使用并行化工作流
当任务可以拆分成可并行处理的子任务以提升速度，或者需要多角度、多次尝试以获得更高置信度的结果时，并行化工作流非常有效。对于包含多重考量的复杂任务，通常将每个考量点通过单独的 LLM 调用来处理，能让模型更专注于每个细节，从而获得更优表现。
并行化工作流的典型应用示例：
分段处理（Sectioning）
- 实现多重安全防护机制：一个模型实例负责处理用户查询，另一个模型实例负责筛查不当内容或请求。相比由同一个 LLM 既处理内容又处理安全检测，这种拆分效果更佳。
- 自动化评估：每次 LLM 调用分别评估模型在某个提示词上的不同性能指标。
投票机制（Voting）
- 代码安全审查：通过多个不同提示词独立审查代码漏洞，若任一提示发现问题则进行标记。
- 不当内容判定：多个提示词从不同维度评估内容是否违规，或设置不同的投票阈值以平衡误判率。
工作流模式：协调器-执行者（Orchestrator-Workers）
在协调器-执行者工作流中，一个中心 LLM 动态地将任务拆解，分派给多个工作者 LLM 执行，最后再对各工作者的结果进行整合和综合。
何时使用协调器-执行者工作流
协调器-执行者工作流特别适合于任务复杂且难以预先确定子任务数量和内容的场景。例如，在编程任务中，所需修改的文件数量和每个文件的具体修改内容往往取决于具体的任务要求，难以事先固定。
虽然其结构上与并行化工作流相似，但协调器-执行者的关键区别在于灵活性——子任务不是预先定义好的，而是由协调器根据具体输入动态决定和分配。
协调器-执行者工作流的典型应用示例：
- 需要对多个文件进行复杂修改的编程产品。
- 涉及从多个信息源收集并分析数据以提取相关信息的搜索任务。
工作流模式：评估器-优化器（Evaluator-Optimizer）
在评估器-优化器工作流中，一次 LLM 调用生成初步响应，另一次调用对该响应进行评估和反馈，二者循环迭代，持续改进输出质量。
何时使用评估器-优化器工作流
当任务具备明确的评估标准，且通过迭代优化能够带来明显效果提升时，评估器-优化器工作流尤为有效。判断该工作流是否适用，有两个重要信号：
- 当人工反馈能够显著提升 LLM 的回答质量；
- LLM 能够生成有效的反馈和评估建议。
这类似于人类作者在撰写过程中反复修改、打磨文稿的迭代流程。
评估器-优化器工作流的典型应用示例：
- 文学翻译任务：初稿可能无法捕捉所有细微差别，但评估器 LLM 能提出建设性批评，促进翻译质量提升。
- 复杂搜索任务：需要多轮搜索与分析以获取全面信息，评估器决定是否需要继续深入搜索。
智能体（Agents）
随着大语言模型关键能力的成熟——如理解复杂输入、推理与规划、可靠使用工具以及从错误中恢复，智能体正逐步进入实际生产应用。
智能体的工作流程通常从人类用户的指令或交互对话开始。当任务明确后，智能体会自主规划并执行任务，必要时会回访人类获取更多信息或决策支持。执行过程中，智能体需不断从环境中获取“真实反馈”（如工具调用结果或代码执行输出），以判断任务进展是否符合预期。
智能体可以在关键节点暂停，等待人类反馈，或者在遇到阻塞时请求帮助。任务执行通常在完成时终止，也常设置最大迭代次数等停止条件，以确保流程可控。
虽然智能体能处理复杂任务，但其实现逻辑通常相对简单：核心是基于环境反馈循环调用 LLM 并使用工具。因此，设计清晰且完善的工具集及其文档至关重要。我们将在附录二《为工具设计提示词工程》（Prompt Engineering your Tools）中详细介绍相关最佳实践。
何时使用智能体
智能体适用于开放性问题，即任务步骤数量难以预测或无法通过硬编码固定流程来完成的场景。此时，LLM 可能需要多轮自主操作，你需要对其决策能力有一定程度的信任。智能体的自主性使其非常适合在可信环境中实现任务的规模化处理。
不过，智能体的自治特性也意味着更高的成本以及潜在的累积错误风险。因此，我们建议在沙盒环境中进行充分测试，并设计合理的安全防护机制（guardrails）。
智能体应用示例（来自我们自身实现）
- 用于解决 SWE-bench 任务的编码智能体，根据任务描述修改多个文件。
- 我们的“计算机使用”参考实现，Claude 模型通过模拟计算机操作来完成各类任务。
组合与定制这些模式
这些构建模块并非死板规范，而是开发者可根据不同需求灵活塑造和组合的常见模式。成功的关键和所有 LLM 功能一样，依赖于对性能的持续度量与实现的迭代。再次强调：只有当增加复杂度明显提升效果时，才值得引入。
总结
在大语言模型领域，成功并非来自打造最复杂的系统，而是构建最适合自身需求的系统。
从简单的提示词开始，结合全面的评估进行优化，仅在简单方案无法满足时，才加入多步智能体系统。
构建智能体时，我们遵循三大核心原则：
- 保持设计简洁，避免不必要的复杂度。
- 强调透明性，明确展示智能体的规划步骤。
- 精心设计智能体与计算机接口（ACI），通过详尽的工具文档与测试保证质量。
框架可助你快速起步，但进入生产阶段时，别犹豫剥离多余抽象，基于基础组件进行构建。遵循这些原则，能打造既强大又可靠、易维护且用户信任的智能体。
致谢
本文作者为 Erik Schluntz 和 Barry Zhang，内容基于我们在 Anthropic 构建智能体的实践经验以及客户分享的宝贵洞见，谨此致谢。
两个客户实践案例
附录1：智能体的实际应用
与客户合作揭示了两大极具潜力的智能体应用场景，充分体现了上述模式的实际价值。两个场景均展示了智能体在兼具对话与行动、明确成功标准、支持反馈闭环以及融入有效人工监管时的最大价值。
A. 客户支持
客户支持结合了熟悉的聊天机器人界面与通过工具集成增强的能力，特别适合更开放式的智能体，因为：
- 支持对话本身遵循自然的会话流程，且需访问外部信息和执行操作；
- 可集成工具以调取客户数据、订单历史和知识库文章；
- 诸如退款发放、工单更新等操作能自动化完成；
- 成功标准可由用户定义且清晰可量化。
多家公司已通过基于成功解决率计费的模式验证了此类方案的可行性，体现了对智能体效果的信心。
B. 编码智能体
软件开发领域展现了 LLM 特性的巨大潜力，能力已从代码补全演进至自主问题解决。智能体尤其适用，因为：
- 代码解决方案可通过自动化测试验证；
- 智能体可基于测试反馈迭代优化方案；
- 问题空间定义明确且结构化；
- 输出质量可客观度量。
在我们的实现中，智能体仅凭拉取请求描述便可解决 SWE-bench Verified 基准中的真实 GitHub 问题。虽自动化测试验证功能有效，但人工评审依然对确保方案符合系统整体要求至关重要。
附录2：为工具设计提示词工程
无论构建何种智能体系统，工具几乎都是关键组成部分。工具让 Claude 能通过 API 与外部服务交互，要求开发者准确指定工具的结构与定义。当 Claude 计划调用工具时，API 响应中会包含工具使用块。
工具定义与规范应和整体提示词一样，得到充分的提示词工程关注。
- 同一动作通常有多种指定方式，比如编辑文件可以通过写差异（diff）或重写整个文件实现。
- 结构化输出可用 markdown 或 JSON 格式返回。
- 在软件工程中，这些差异属于表面格式，且可无损转换，但对 LLM 而言，某些格式写起来更难（如 diff 需要提前知道变更行数，JSON 需要额外转义）。
我们对工具格式的建议：
- 给模型足够的令牌（tokens）“思考”，避免写入死角。
- 保持格式接近模型在互联网上自然见过的文本。
- 避免格式“开销”，如保持数千行代码的精确行数，或对所有字符串转义。
一个经验法则是：人机交互（HCI）投入了多少心力，就应等量投入在智能体-计算机接口（ACI）的设计上。
提升工具设计的几点思考：
- 设身处地为模型考虑：工具描述和参数是否足够清晰？是否需要仔细思考才能使用？优秀的工具定义通常包含示例、边界条件、输入格式要求，以及与其他工具的清晰区分。
- 优化参数名称与描述，确保直观易懂，就像为团队里的初级开发者写文档字符串一样。尤其是当存在多款相似工具时，此点更为重要。
- 测试模型调用工具的表现：使用工作台运行大量示例输入，观察模型错误并反复迭代。
- 设计防错（poka-yoke）机制，调整参数以减少模型误用的可能。
在构建 SWE-bench 智能体时，我们实际上花了比整体提示词更多的时间优化工具。举例来说，模型在智能体切换目录后使用相对路径时容易出错。解决方案是强制工具始终使用绝对路径，结果模型完美执行。
来源
[1] Building effective agents https://www.anthropic.com/engineering/building-effective-agents Published Dec 19, 2024
