构建高效代理

2024 年 12 月 19 日发布

过去一年多，我们与金融、医疗、法律、软件等行业的数十支团队合作，基于大语言模型（LLM）构建「Agent」。

最令我们惊讶的结论是：
最成功的落地往往不是用了复杂框架或专用库，而是用了简单、可组合的范式。

本文把我们从客户实践和自身研发中总结的经验整理成一份实用指南，供开发者参考。

什么是智能体“Agent”？

业界对 “Agent” 的定义并不统一：
• 有人认为它是全自主系统，长期独立运行，调用多种工具完成复杂任务；
• 有人把它当作遵循预设流程的脚本化实现。

在 Anthropic，我们把上述所有形态统称为 Agentic System （智能体系统），但会在架构上区分 Workflow（工作流） 与 Agent（自主体） ：

类型	控制方式	适用场景
Workflow	代码预先编排 LLM 与工具的调用路径	任务步骤可枚举、结果可预期
Agent	LLM 自主决定每一步骤与工具的使用	任务步骤不可枚举，需要动态决策

下文会逐一展开。附录 1 给出了两个行业落地示例。

什么时候该用（或不该用）Agent？

能不用就不用。
先用最简单的 LLM 调用（可配合检索、示例）把效果做到可用；只有当单轮调用无法满足需求时，再逐步引入多步骤的 Workflow 或 Agent。
Agent 会带来延迟与成本上升，务必确认「性能提升 > 成本增加」。

需求特征	推荐方案
任务步骤固定、结果可预期	Workflow
步骤无法预先枚举，需要模型自主决策	Agent
单轮 LLM + 检索即可满足	直接调用 LLM API

何时、如何使用框架？

常见框架：LangGraph、Amazon Bedrock Agent、Rivet、Vellum 等。
它们把「调 LLM、定义工具、链式调用」封装成了低代码/无代码组件，上手快；但也带来两个问题：

1. 抽象层让 prompt/response 难以调试；
2. 容易「为了框架而框架」，引入不必要的复杂度。

建议：
• 先用 LLM API 裸写，验证思路；
• 真要上框架，一定读源码，弄清底层到底干了什么。
我们的 cookbook 里给出了不少「十几行代码即可实现」的示例。

构建模块、工作流和代理

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

构建模块：增强型 LLM

LLM 调用里统一提供检索、工具调用、记忆三项增强能力。模型能够主动使用这些功能生成自己的搜索查询、选择合适的工具，并确定要保留哪些信息。

实际使用时，关注两个关键方面：

1. 根据具体用例定制功能(Tool)，并确保它们为 LLM 提供简单、文档完善的接口。
2. 虽然实现增强功能的方法有很多，但一种方法是通过我们最近发布的模型上下文协议Model Context protocol，该协议允许开发人员通过简单的客户端实现与不断增长的三方工具生态系统集成。

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

Workflow 1：提示链（Prompt Chaining）

把任务拆成一串步骤，每一步 LLM 拿到上一步的结果继续加工，可在中间部分插入代码校验分支(Gate)

何时使用此工作流：任务天然可拆，且子任务顺序固定。主要目标是通过将每个 LLM 调用作为一个更简单的任务，牺牲部分延迟以换取更高的准确性。

提示链有用的例子：

• 生成营销文案，然后将其翻译成另一种语言。
• 撰写文档提纲，检查提纲是否符合特定标准，然后根据提纲撰写文档。

Workflow 2：路由（Routing）

对输入做分类，路由到专门的后续流程。这种工作流程允许关注点的分离，并构建更专业的提示。没有这种工作流程，针对一种输入的优化可能会损害其他输入的性能。

何时使用此工作流：路由适用于复杂任务，其中存在不同的类别，这些类别更适合分别处理，并且分类可以由 LLM 或更传统的分类模型/算法准确处理。

路由有用的示例：

• 客服机器人把「退款」「技术支持」「一般咨询」引导至不同的子流程、提示和工具。
• 将简单/常见问题路由至 Claude 3.5 Haiku 等较小模型，将困难/不常见问题路由至 Claude 3.5 Sonnet 等更强大的模型，以优化成本和速度。

Workflow 3：并行化（Parallelization）

LLMs 有时可以同时处理一个任务，并且可以程序性地聚合它们的输出。这种工作流，即并行化，表现为两种关键变体：

• Sectioning（分段）：把任务横向切成独立子任务并发跑；
• Voting（投票）：同一任务多跑几遍，投票或择优。

何时使用此工作流程：子任务可并行加速，或需要多个视角结果。
对于具有多个考量/考察点的复杂任务，当每个考量都由单独的 LLM 调用处理时，LLMs 通常表现更好，这允许专注于每个特定方面。

并行化有用的例子：

• 分段：
  

  • 实现护栏(guardrails)，其中一个模型实例处理用户查询，而另一个模型筛选不适当的内容或请求。这通常比让同一个 LLM 调用处理护栏和核心响应表现得更好。
  • 自动化评估 LLM 性能的评估，其中每个 LLM 调用评估模型在给定提示下性能的不同方面。

• 投票：
  

  • 审查一段代码以查找漏洞，其中 多个不同的提示 会检查代码并在发现问题时进行标记。
  • 评估某项内容是否不当，通过多个提示来评估不同方面或要求不同的投票阈值以平衡假阳性和假阴性。

Workflow 4：协调器-工作者（主从）（Orchestrator-Workers）

一个「主 LLM」动态拆任务，派发给「子 LLM」，再汇总。

何时使用此工作流：此工作流适用于复杂任务，这种任务难以预测子任务的复杂程度（例如在编程中，需要改多少个文件以及每个文件改什么，取决于用户要求）。与并行模式不同点：子任务不是固定的，由主 LLM 视输入而定。

一个 orchestrator-workers 有用的例子：

• 每次对多个文件进行复杂更改的编码产品。
• 寻找相关信息的搜索需求，因为涉及从多个来源收集和分析信息。

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

在评估器-优化器工作流程中，一个 LLM 调用生成响应，而另一个提供评估和反馈，形成循环。

何时使用此工作流：当我们有明确的评估标准，并且迭代优化能带来可衡量的价值时，此工作流特别有效。良好的有2个适合场景：

1. 首先，当用户清晰表达反馈时，LLM 的响应能被明显改进；
2. 其次，LLM 能够提供此类反馈。这类似于人类作家在撰写一份精心打磨的文档时可能经历的迭代写作过程。

评估者-优化者有用的例子：

• 文学翻译中存在一些细微之处，翻译用的 LLM 可能最初无法捕捉，但评估用的 LLM 可以提供有用的评论。
• 复杂的搜索任务需要多轮搜索和分析来收集全面信息，评估用的 LLM 决定是否需要进一步搜索。

代理/自主体（Agent）

运作流程：

1. 用户给出指令或与 Agent 对话；
2. Agent 制定计划，自主循环「思考→调用工具→再思考」；
3. 每一步根据环境返回的「真值」（工具结果、代码执行输出）评估进度；
4. 可在关键节点或遇到阻碍时请求人类确认；
5. 任务完成或达到最大迭代次数后结束。

我们在附录 2（《为你的工具进行提示工程》）中详细阐述了工具开发的最佳实践。

何时使用代理：代理可用于开放式问题，如：

• 步骤数量无法预估；
• 需要模型持续自主决策；
• 对LLM的决策有一定程度的信任/安全控制（如沙盒环境）

代理的自主性意味着更高的成本，以及复合错误的潜在风险。我们建议在沙盒环境中进行广泛测试，并配合适当的防护措施。

代理有用的例子：

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

• 一个用于解决 SWE-bench 任务的编程代理，它根据任务描述对多个文件进行编辑；
• 我们的「Computer Use」参考实现，其中 Claude 使用电脑完成任务。

编码代理的高级流程

结合和定制这些模式

上述模式不是非此即彼，可以像乐高一样自由组合。与任何 LLM 功能一样，成功的关键在于衡量性能并在实现上进行迭代。重复一遍：只有当它明显改善结果时，你才应该考虑增加复杂性。（再次强调： 只有数据证明「加复杂度确实带来收益」时才加。）

摘要

在 LLM 领域取得成功在于构建适合需求的系统，而不在于复杂的系统。

从简单的提示开始，通过全面的评估进行优化，只有当简单的解决方案不够用时，才添加多步骤的智能代理系统。

在实现智能体（Agentic System）时，我们尽量遵循三个核心原则：

1. 保持智能体设计的简洁性。
2. 通过明确展示智能体的规划步骤来优先考虑透明度。
3. 通过详尽的工具文档与测试来精心设计智能体-计算机接口/界面（ACI）（agent-computer interface）

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

致谢

由 Erik Schluntz 和 Barry Zhang 撰写。这项工作基于我们在 Anthropic 构建代理的经验，以及我们客户分享的宝贵见解，对此我们深表感激。

附录 1：实践中的智能体

我们的客户工作揭示了两种特别有前景的 AI 代理应用，这些应用展示了上述模式的实际价值。这两种应用都说明了代理如何在需要对话和行动的任务中增加最大价值，具有明确的成功标准，能够实现反馈循环，并整合有意义的人类监督。

A. 客户支持（客服员工工具）

客服员工工具 将 聊天界面 与 通过工具集成增强的功能相结合。这对于更开放式的代理来说是一个自然的选择，因为：

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

几家公司在基于使用量的定价模式中证明了这种方法的可行性，这些模式仅对成功的解决方案收费，显示出对它们代理有效性的信心。

B. 编码代理

软件开发领域在 LLM 功能方面展现出显著潜力，其能力已从代码补全发展到自主问题解决。代理特别有效，因为：

• 代码正确性可用自动化测试验证；
• 测试失败 → Agent 迭代修复；
• 问题空间已明确定义且结构化；
• 输出质量可以客观衡量。

在我们的实现中，我们的内部 Agent 在 SWE-bench Verified 数据集上已能独立解决真实 GitHub issue。然而，自动化测试只保证功能，仍需人工 review 保证架构一致。

附录 2：为你的工具进行提示工程

工具是代理系统的关键组成部分，能让Claude与外部服务和API交互。工具定义需要与整体提示一样精心设计。

选择工具格式时，建议：

• 给模型足够的"思考"空间
• 保持格式与模型常见的自然文本形式相近
• 避免格式"开销"，如复杂计算（准确统计数千行代码）或字符串转义

优化工具的方法：

• 自己站在模型角度思考，确保工具使用直观明了。（一个好的工具定义通常包括示例用法、边缘情况、输入格式要求以及与其他工具的清晰界限。）
• 改进参数名称和描述，使其更加明确
• 测试模型使用工具的情况，运行各种示例输入，观察错误并迭代改进
• 进行防错设计，调整参数使错误更难发生

实际案例：在构建SWE-bench代理时，我们发现模型使用相对文件路径会出错。修改为要求绝对文件路径后，模型就能完美使用了。