跳到主要内容

原文：01-building-effective-agents.md 来源：https://www.anthropic.com/engineering/building-effective-agents

如何构建有效的 AI Agent

发布于 2024 年 12 月 19 日

我们与数十个跨行业的 LLM Agent 开发团队合作过，发现最成功的实现几乎无一例外地采用了简单、可组合的模式，而非复杂的框架。

过去一年里，我们与大量团队深度合作，帮助他们构建大语言模型（LLM）Agent。观察下来，最成功的实现既没有使用复杂框架，也没有引入专门的第三方库。它们共同的特点是：基于简单、可组合的模式进行构建。

本文分享我们在与客户合作以及自主构建 Agent 过程中积累的经验，为开发者提供构建有效 Agent 的实用建议。

什么是 Agent？​

"Agent"有多种定义方式。一些客户将 Agent 理解为能在较长时间内独立运作、借助各类工具完成复杂任务的全自主系统；另一些则用这个词来描述遵循预定流程的、更具规划性的实现方式。

在 Anthropic，我们将所有这些变体统称为智能体系统（Agentic Systems），但在架构层面区分了两个重要概念：

  • 工作流（Workflow）：LLM 和工具通过预先编写的代码路径进行编排的系统。
  • Agent：LLM 自主决定自身的执行过程和工具使用方式，掌控任务完成策略的系统。

下文将分别详细介绍这两类系统。附录 1（"Agent 实战"）介绍了两个客户发现特别有价值的应用场景。

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

基于 LLM 构建应用时，我们建议从最简单的方案入手，仅在必要时才增加复杂度——有时这意味着根本不需要构建智能体系统。智能体系统通常以更高的延迟和成本换取更好的任务表现，这个权衡是否值得，需要认真考量。

  • 当任务有较高复杂度时，工作流适合处理定义明确、需要可预测性和一致性的任务；而当需要灵活性和模型驱动的大规模决策时，Agent 更合适。
  • 对于很多应用场景，优化单次 LLM 调用（结合检索和上下文示例）通常已经足够。

何时以及如何使用框架​

有许多框架能简化智能体系统的实现，例如：

  • Claude Agent SDK
  • AWS 的 Strands Agents SDK
  • Rivet（拖拽式 LLM 工作流构建工具）
  • Vellum（另一款用于构建和测试复杂工作流的 GUI 工具）

这些框架通过简化底层任务（调用 LLM、定义和解析工具、串联调用链）来降低上手门槛。但它们往往引入额外的抽象层，使底层的提示词和响应变得难以观察，调试也更困难。它们还可能诱使开发者在其实更简单的方案就够用时，过度增加复杂性。

我们建议开发者先直接使用 LLM API：大多数模式只需几行代码就能实现。如果确实需要使用框架，请务必理解其底层逻辑。对框架内部机制的错误假设，是客户遇到错误的常见根源。

构建模块、工作流与 Agent​

基础构建模块：增强型 LLM​

智能体系统的基础构建模块，是一个经过检索、工具和记忆能力增强的 LLM。当前模型能够主动使用这些能力——自主生成搜索查询、选择合适的工具、决定需要保留哪些信息。

在实现时，我们建议重点关注两点：

  1. 将这些能力裁剪适配到你的具体使用场景
  2. 确保它们为 LLM 提供清晰、文档完善的接口

一种实现方式是通过我们最近发布的模型上下文协议（MCP），该协议允许开发者通过简单的客户端实现，接入不断扩展的第三方工具生态。

工作流一：提示词链（Prompt Chaining）​

提示词链将一个任务分解为一系列步骤，每次 LLM 调用处理上一步的输出。可以在任意中间步骤添加程序化检查（即"门控"），确保流程不跑偏。

适用场景：任务可以清晰地分解为固定子任务。核心目标是用延迟换准确率——让每次 LLM 调用都处理一个更简单的子问题。

典型示例：

  • 先生成营销文案，再翻译为另一种语言
  • 先撰写文档大纲，检验大纲是否满足要求，再基于大纲撰写完整文档

工作流二：路由（Routing）​

路由对输入进行分类，并将其导向对应的专门化后续任务，实现关注点分离，构建更具针对性的提示词。若没有路由，为某类输入优化往往会损害其他类型输入的表现。

适用场景：任务存在截然不同的类别，适合分别处理；且分类本身可以准确完成（无论通过 LLM 还是传统分类模型/算法）。

典型示例：

  • 将不同类型的客户服务请求（一般咨询、退款申请、技术支持）分流到不同的处理流程、提示词和工具
  • 将简单/常见问题路由到轻量高效的小模型（如 Claude Haiku 4.5），将复杂/罕见问题路由到更强大的模型（如 Claude Sonnet 4.5），以实现性能最优

工作流三：并行化（Parallelization）​

LLM 有时可以同时处理一个任务的多个部分，结果再通过程序进行聚合。并行化主要有两种形式：

  • 分段（Sectioning）：将任务拆分为可并行执行的独立子任务
  • 投票（Voting）：对同一任务运行多次，获得多样化输出

适用场景：子任务可并行以提升速度，或需要多视角/多次尝试来提高置信度。对于存在多个考量维度的复杂任务，让每个维度由独立的 LLM 调用专注处理，效果通常更好。

典型示例：

  • 分段：实现安全防护——一个模型实例处理用户请求，另一个同时审查是否包含不当内容
  • 自动化评估 LLM 性能，每次调用评估模型在特定提示下的不同维度
  • 投票：多个提示词分别审查代码漏洞，任意一个发现问题即标记
  • 评估内容是否不当，多个提示词从不同角度评估，或设置不同投票阈值来平衡误报和漏报

工作流四：编排者-工作者（Orchestrator-Workers）​

由一个中央 LLM 动态分解任务、分配给工作者 LLM，并整合其结果。

适用场景：无法预先确定子任务的复杂任务（例如编程任务中，需要修改的文件数量和每个文件的改动性质，取决于具体任务）。与并行化的拓扑结构类似，但关键区别在于灵活性——子任务不是预定义的，而是由编排者根据具体输入动态确定。

典型示例：

  • 每次需要跨多个文件进行复杂改动的编程产品
  • 需要从多个来源收集和分析信息的搜索任务

工作流五：评估者-优化者（Evaluator-Optimizer）​

一个 LLM 调用生成响应，另一个提供评估和反馈，形成循环迭代。

适用场景：有清晰评估标准、且迭代优化能带来可量化价值的任务。两个判断指标：一是当人类用语言表达反馈时，LLM 的输出能得到明显改善；二是 LLM 能够提供这样的反馈。这类似于人类作者打磨文章的迭代过程。

典型示例：

  • 文学翻译——翻译 LLM 可能无法初次捕捉所有细微之处，但评估 LLM 可以提供有价值的批评
  • 复杂搜索任务——需要多轮搜索和分析才能收集全面信息，评估者决定是否需要进一步搜索

Agent​

随着 LLM 在关键能力上的持续成熟——理解复杂输入、推理和规划、可靠使用工具、从错误中恢复——Agent 正在生产环境中逐步落地。

Agent 从用户的指令或交互式对话开始工作。任务明确后，Agent 独立规划和执行，并在需要时返回人类寻求进一步信息或判断。执行过程中，Agent 在每一步从环境中获取"真实反馈"（如工具调用结果或代码执行结果）来评估进展，并可在检查点或遇到阻碍时暂停等待人类反馈。任务通常在完成后终止，但也常见停止条件（如最大迭代次数）来保持控制。

Agent 虽然能处理复杂任务，但实现往往很直接——本质上就是 LLM 在循环中根据环境反馈使用工具。因此，工具集的设计和文档的清晰度至关重要（详见附录 2）。

适用场景：开放性问题，无法预测所需步骤数，也无法硬编码固定路径。LLM 可能需要运行很多轮，必须对其决策有一定信任度。Agent 的自主性使其适合在受信任环境中扩展任务。

注意：Agent 的自主特性意味着更高成本和错误叠加的风险，建议在沙箱环境中进行大量测试，并配备适当的防护机制。

典型示例：

  • 用于解决 SWE-bench 任务的编程 Agent——根据任务描述对多个文件进行编辑
  • "计算机使用"参考实现——Claude 使用计算机完成任务

组合与定制这些模式​

以上构建模块并非规定性的，而是开发者可以根据不同场景塑造和组合的通用模式。成功的关键与所有 LLM 功能一样：衡量性能，持续迭代。只有当复杂性能可量化地改善结果时，才值得引入。

总结​

在 LLM 领域取得成功，不在于构建最复杂的系统，而在于为你的需求构建正确的系统。从简单的提示词开始，通过全面评估进行优化，只有在更简单的方案不够用时，才引入多步骤的智能体系统。

构建 Agent 时，我们遵循三条核心原则：

  • 保持 Agent 设计的简洁性
  • 通过明确展示 Agent 的规划步骤来保证透明性
  • 通过充分的工具文档和测试精心打磨 Agent-计算机接口（ACI）

框架能帮你快速上手，但在转向生产环境时，不要犹豫——减少抽象层，用基础组件直接构建。遵循这些原则，你能构建出不仅强大，而且可靠、易于维护、值得用户信赖的 Agent。

附录 1：Agent 实战​

A. 客户支持​

客户支持是 Agent 的天然应用场景，因为：

  • 支持交互天然以对话形式展开，同时需要访问外部信息和执行操作
  • 工具可集成客户数据、订单历史和知识库
  • 退款、更新工单等操作可程序化处理
  • 成功可通过用户定义的解决率清晰衡量

一些公司已通过按结果计费（仅对成功解决的案例收费）的定价模式，验证了这一方案的可行性。

B. 编程 Agent​

软件开发领域展示了 LLM 的巨大潜力，能力从代码补全演进到自主解决问题：

  • 代码方案可通过自动化测试验证
  • Agent 可利用测试结果作为反馈迭代优化方案
  • 问题空间定义清晰、结构化
  • 输出质量可客观衡量

在我们自己的实现中，Agent 已能仅凭 Pull Request 描述解决 SWE-bench Verified 基准测试中的真实 GitHub 问题。自动化测试有助于验证功能，但人工审查对于确保方案符合更广泛的系统要求仍不可或缺。

附录 2：为工具做提示词工程​

无论构建哪种智能体系统，工具都可能是 Agent 的重要组成部分。工具让 Claude 能够通过在 API 中精确定义其结构和规范，与外部服务和 API 进行交互。工具定义和规范值得投入与整体提示词同等程度的工程关注。

关于工具格式的建议：

  • 给模型足够的 token 空间在"写死"之前先"思考"
  • 保持格式接近模型在互联网文本中自然见过的样式
  • 确保没有格式"开销"（如需要精确计数数千行代码，或对代码进行字符串转义）

一个经验法则：思考人们在设计人机界面（HCI）时投入了多少精力，并计划在创建**Agent-计算机接口（ACI）**时投入同等精力。具体建议：

  • 换位思考：仅凭描述和参数，你是否能直观地知道如何使用这个工具？如果你需要仔细思考，模型大概率也需要。优秀的工具定义通常包含使用示例、边界情况、输入格式要求，以及与其他工具的清晰边界。
  • 优化参数名和描述：把它当作为团队新成员写优秀文档注释。当工具相似度较高时尤为重要。
  • 测试模型使用工具的方式：在 Workbench 中运行大量示例输入，观察模型会犯哪些错误，持续迭代。
  • 防错设计：修改参数设计，让错误更难发生。

在为 SWE-bench 构建 Agent 时，我们在优化工具上花的时间实际上超过了优化整体提示词。例如，我们发现模型在 Agent 离开根目录后会在使用相对路径时出错，于是将工具改为始终要求绝对路径——此后模型的使用完全无误。