译：Building effective agents

最近《Building effective agents》这篇文章高频的出现在我的feed流中，因此我决定翻译一下这篇文章。

原文地址：anthropic/building-effective-agents

在过去的一年中，我们和多个团队合作，一起构建了跨行业的 LLMs 的 Agents 。 我们发现那些最成功的智能体的实现，并没使用了复杂的架构或者专用的代码库。 相反，他们仅仅使用了简单的可组合模式进行构建。

这篇文章中，我们将分享与客户合作中和我们自己在构建智能体中的经验总结，并为开发人员提供了构建高效智能体的实用建议。

什么是 Agents ？ ​

「Agents」的定义存在多种解释。部分客户将 Agents 定义为完全自主的系统，这些系统能长期独立运行，通过各种工具完成复杂任务。也有人用 Agents 这个术语来描述，遵循预定义工作流的规范性实现。在我司 Anthropic 的定义中，我们将所有变体统称为「Agentic System(注：以下译为智能体系统)」，但会强调 「Workflows(注：以下译为工作流)」 和 「Agent(注：以下译为智能体)」 在架构上的核心区别：

• 工作流：通过预定义的代码路径，编排 LLMs 和工具的系统。

• 智能体：LLMs动态主导自身流程和工具使用，并保持任务执行控制权的系统。

下面我们将详细探讨这2种智能体系统。本文末尾附录1《智能体技术实践图谱》，我们将描述客户已验证显著价值的2个应用领域。

什么时候[不/使]用智能体？ ​

使用 LLMs 构建应用程序时，我们建议优先选择最简单的解决方案，仅在必要时增加复杂性。这意味着有时应完全避免构建智能体系统。智能体系统通常以更高的延迟和更高的成本为代价，换取任务效果，需仔细权衡利弊。

若需增加复杂性时：

• 工作流适用于明确定义的任务，提供可预测性和一致性。

• 智能体则更适合那些需要大规模灵活性和模型驱动决策的场景。

但对多数应用而言，仅仅通过“检索(retrieval)”和“上下文示例(in-context examples)”，优化单次 LLM 调用通常就已足够了。

何时/如何使用框架？ ​

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

• LangChain 的 LangGraph；

• Amazon Bedrock 的 AI Agent framework；

• Rivet, 拖拽式 GUI LLM 工作流构建器；

• Vellum，另一款构建和测试复杂工作流的 GUI 工具。

这些框架通过封装 LLM 调用、工具定义/解析、链式调用等底层任务降低入门门槛。但需注意 2 点：

1. 框架的抽象层，可能掩盖底层的提示词（prompts）和响应内容，增加调试难度。

2. 易诱使开发者对简单场景过度设计。

建议开发人员优先直接调用 LLM API ：许多模式仅需几行代码即可实现。 若使用了框架，也请确保理解其底层逻辑的实现–对封装代码的错误假设，这是客户常见的问题来源。

有关部分示例的实现，参考我们的操作手册。

构建块，工作流和智能体 ​

在本节中，我们将探讨我们在生产中看到的智能体系统的常见范式。我们将从我们的基础构建块（即：增强型 LLM ）开始，并逐渐增加复杂性，从简单的组合式工作流到自主智能体 autonomous agents。

构建块：增强型 LLM | The augmented LLM ​

智能体系统的基本构建块就是增强型 LLM ，增强功能包括检索，工具和记忆（参考示图）。 我们当前的模型可以主动使用这些功能：生成它自己的搜索查询、选择适当的工具以及确定要保留的信息。

在实现构建块时有两个关注重点：

1. 根据我们的特定用例场景，量身定制这些功能。

2. 确保这些功能给 LLM 提供一个简单且文档齐备的接口。

实现这些增强型 LLM 有很多方式，我们最近发布了一种实现方式模型上下文协议， 它允许开发人员通过简单的客户端，与不断增长的第三方工具的生态系统集成。

本文的其余部分，我们将假设每个 LLM 都可以调用这些增强功能。

工作流：提示链模式 | Prompt chaining ​

提示链模式将任务分解为一系列步骤，每次 LLM 调用都处理前一次 LLM 的输出。 我们可以在任何中间步骤上添加程序化检查（参阅示图中的“Gate”），以确保该过程仍运行在正轨上。

适用场景：此工作流非常适合可以轻松、明确地分解为固定子任务的情况。主要通过增加延迟的代价，使每次 LLM 调用变成更简单的任务，来提高的整体准确率。

实际案例：

• 生成营销文案，然后将其翻译成不同的语言。

• 撰写文档的大纲，检查大纲是否符合某些特定标准，然后根据大纲续写文档。

工作流：路由模式 | Routing ​

路由模式对输入进行分类，并将其定向到专门且更具针对性的后续 LLM 任务中。此工作流允许将关注点分离，并构建专业且更具针对性的提示词。如果没有此工作流，那么我们针对一种输入的优化，可能会损害其他输入的性能。

适用场景：路由模式非常适用存在明显类别，且最好单独处理的复杂任务，并且可以通过 LLM 或传统的分类模型/算法进行准确分类。

实际案例：

将不同类型的客户服务查询（一般问题，退款请求，技术支持）定向到不同的下游流程，提示和工具。

将简单/常见的问题路由到 Claude 3.5 Haiku 等较小参数的模型，而将困难/罕见的问题路由到 Claude 3.5 Sonnet 这样的更强大的模型，借此来优化成本和速度。

工作流：并行模式 | Parallelization ​

LLM 有时可以同时处理一项任务，并以编程方式聚合它们的输出，这种工作流称为并行模式。其具备两个关键变体：

• 分段 Sectioning : 将任务分解为并行运行的独立子任务。

• 投票 Voting ：多次运行同一任务，以获取到多样化的输出。

适用场景：当拆分的子任务可以并行执行以提高速度时，或需要多个视角或多次尝试，以获取更高置信度的结果时。面对具有多种考虑因素的复杂任务时，LLM通常在每种考虑因素由单独的 LLM 调用处理时，表现的更好。这种做法能使LLM的注意力集中在某个特定方面。

实际案例：

• 分段 Sectioning：
  • 实现安全防护(guardrails)，其中一个模型实例处理用户查询，而另一个模型则筛选不当的内容或请求。这往往比让同一个 LLM 同时处理安全防护和核心响应，效果要好。
  • 自动化评估(evals) 以评估 LLM 性能，每次 LLM 调用都会评估模型，给出当前提示词下，各个方面的表现评估。
• 投票 Voting：
  • 审查一段代码是否存在漏洞，采用不同的提示词，从多个维度审查代码，如果发现问题则标记代码。
  • 评估给定内容是否合规，多个提示词中评估不同视角，或需要不同的投票阈值以平衡误报和漏报。

工作流：协调者-工作者模式 | Orchestrator-Workers ​

在协调者-工作者模式中，一个中央协调者 LLM 动态分解任务，将其委派给工作者 LLM，并综合它们的结果。

适用场景：此工作流非常适合那些无法预测所需子任务的复杂任务（例如，在编码中，需要更改的文件数量和性质，取决于任务本身）。尽管在结构上它与并行模式工作流类似，其关键区别在于它的灵活性-- 子任务并非预先定义的，而是由协调者根据具体输入动态决定的。

协调者-工作者模式的例子：

• 每次对多个文件进行复杂更改的编码产品。
• 搜索任务，涉及多个来源的收集和分析，以获取可能的相关信息。

工作流：评估者-优化者模式 | Evaluator-optimizer ​

在评估者-优化者模式中，调用一个 LLM 生成响应内容，而另一个 LLM 在循环中提供评估和反馈，直到评估被接受通过。

适用场景：当我们有明确的评估标准，且迭代优化能产生可衡量的价值提升时，评估者-优化者模式尤为有效。适合这种模式的两个标志是：第一，当人类能够明确表达反馈的意见时，LLM 的响应质量可获得显著改善；第二，LLM 自身能提供此类反馈时。这种模式本质上模拟了人类作家通过"草稿-反馈-修订"的循环过程，逐步打磨文本的创作过程。

实际案例：

• 文学翻译：作为翻译员的 LLM 最初可能无法捕捉翻译结果和原文中的细微差别，而作为评估者的 LLM 可以提供有用的反馈和改进建议。

• 复杂搜索任务：需要进行多轮搜索和分析，以收集更全面信息，再由评估者 LLM 决定是否需要进一步搜索。

智能体 | Agents ​

智能体的生产化应用正随着大语言模型核心能力的成熟而加速落地——这些关键能力包括：复杂指令解析、推理规划能力、工具调用可靠性以及错误恢复机制。

智能体的工作流程始于两种触发模式：

1. 接收人类用户的明确指令，或通过对话交互澄清任务需求。在明确任务目标后，智能体将进入自主规划与执行阶段，过程中可能根据需求返回请求额外信息或决策支持。执行环节的关键在于，智能体必须在每个操作步骤获取环境反馈的"真实数据锚点"（如工具调用结果或代码执行输出），以此校准任务进程。

2. 系统可设置检查点机制触发人工干预，或在遭遇执行障碍时主动暂停。任务通常以目标达成为终止条件，但实践中普遍会设置熔断机制（如最大迭代次数限制）来确保系统可控性。

智能体虽能处理高阶任务，但其底层实现往往基于大语言模型（LLM）的循环工具调用机制。核心架构可简化为：智能体通过环境反馈，持续优化工具选择与调用策略。因此，工具集的设计规范与接口文档的清晰度会直接决定系统效能（详见本文末尾附录2《工具提示词工程实践指南》）。

适用场景：该方案特别适用于具有开放式任务场景（无法预判所需执行步骤数量）且无法预置固定执行路径的复杂问题领域。其应用前提是：需要大语言模型（LLM）具备多轮次自主决策能力，且系统设计者对模型的决策逻辑具备基础信任度。智能体的自主特性使其在可信环境（如企业内部系统）中展现出显著的规模化任务处理优势。

智能体自主特性带来的双重挑战：其运行会产生显著增加成本压力，且存在错误链式传导风险。我们建议采取双重保障策略——在沙盒测试环境中进行压力测试；同时部署多层防护栏（如执行路径校验机制、结果审核流程等）。

实际案例（基于实践案例）：

• 编程智能体：应用于 SWE-bench 软件工程基准测试任务（根据任务描述对多文件进行代码级修改）

• 我们的计算机操作参考实现：展示 Claude 大模型如何通过计算机操作完成复杂任务（涵盖 GUI 界面交互与系统级操作）

组合和定制这些模式 ​

这些构建块并非强制规范，而是可灵活组合的通用范式。开发者应根据具体场景需求进行架构裁剪与模式重组（如同软件开发中的设计模式）。 与大语言模型所有功能特性相同，成功的关键在于建立量化评估体系并持续实施迭代优化。

重点强调：系统复杂度的提升必须严格遵循实证导向原则——仅当明确观测到关键指标提升时，方可引入更复杂的架构层级。

总结 ​

大语言模型应用成功法则：技术架构的先进性并非成功关键，需求适配性才是核心。建议采用渐进式实施路径：基础提示词工程起步，优先优化单轮交互质量；系统化评估驱动，建立全维度评估体系持续迭代；审慎引入智能体，仅在基础方案无法满足需求时启动多级系统架构。

智能体系统设计三原则：

1. 架构极简主义：在满足功能需求前提下保持最小复杂度（参考KISS原则）

2. 过程可观测性：通过思维链可视化技术显性化智能体决策路径

3. 接口工程化设计：严格实施工具接口规范（包含版本控制、异常处理协议）

框架使用指南，虽可借助开发框架快速原型验证，但我们建议在生产部署时：

• 抽象层解构：剥离非必要中间件，回归基础组件构建

• 渐进式增强：按业务需求逐步添加模块

遵循该原则体系，可打造出兼具技术效能（处理能力）与工程品质（可靠性/可维护性）的智能体系统，最终赢得用户认知信任与行为依赖。

附录1：智能体技术实践图谱 ​

基于我们与客户的合作实践揭示了两大标杆应用场景，充分展示了前文技术范式的商业价值。这两种应用都说明了智能体技术在对话-行动复合型任务中的独特优势，其要素包括：清晰的成功标准、可闭环的反馈机制、有效的人机协同设计。

A.智能客服系统升级 ​

传统聊天机器人向工具增强型智能体的演进路径：

• 核心价值：在保持自然对话体验的同时，实现业务系统深度集成
• 技术实现：
  1. 对话流引擎：支持多轮上下文管理（含意图识别与槽位填充）
  2. 工具集成层：
  3. 客户画像实时查询接口
  4. 订单历史追踪系统对接
  5. 知识图谱检索API
  6. 业务动作执行器：
  7. 自动化退款流程引擎
  8. 工单状态更新接口
• 效果度量：
  • 核心指标：用户定义问题解决率（First-Contact Resolution）
  • 商业模式创新：多家企业采用按解决效果计费模型（仅对成功解决案例收费）

B. 编程智能体演进 ​

软件工程领域的LLM能力进化路径：代码补全 → 问题自主解决

• 技术优势：
  1. 验证机制：通过单元测试/集成测试构建自动化验证管道
  2. 迭代能力：基于测试反馈的代码自优化循环（见图4：调试迭代流程图）
  3. 问题结构化：GitHub Issue 特征提取与任务分解框架
  4. 质量评估：代码规范符合度、测试覆盖率等客观指标
• 实践突破：
  • 当前能力：仅凭Pull Request描述文档即可解决 SWE-bench Verified 基准测试中的真实 GitHub 问题
  • 人机协同：自动化测试验证功能正确性，人工审核确保方案与系统架构兼容性（见案例研究《金融核心系统智能体代码审核流程》）

场景共性技术架构： ​

1. 状态感知层：实时捕获环境信号（用户输入/系统日志/测试结果）
2. 决策引擎：基于强化学习的动作选择策略
3. 执行监控：操作原子化与回滚机制设计
4. 审计追踪：完整记录智能体思维链与操作轨迹

附录2：工具提示词工程实践指南 ​

无论你构建的是哪种 Agentic 系统，工具都是你的 Agent 中的重要组成部分。 LLM 能通过我们在 API 中明确清晰定义的工具，来与外部服务和 API 进行交互。当 LLM 响应时，如果它计划调用工具，它将在 API 响应中包含一个工具使用区块 (tool use block)。工具的定义和规范，应该跟 Prompt 一样，受到足够的 Prompt Engineering 重视。在本附录中，我们将描述如何进行工具的 Prompt 工程化。

殊途同归。例如，编辑一个指定的文件，可以通过 diff 修改局部，也可以重写整个文件。对于结构化的返回结果，你可以将返回的代码，放在 Markdown 或 JSON 中。在软件工程中，这些差异不大，可以无损地从一种形式转换为另一种形式。但是，对于 LLM 来说，某些格式比其他格式更难续写。续写 diff 需要在续写新代码之前，知道 Chunk header 前文中有多少行在变化。与 Markdown 相比，在 JSON 中编写代码需要对换行符和引号进行额外的转义。

因此我们对工具的格式给出如下的建议：

• 给模型足够的 Token 来 “思考”，在它把自己逼入死角之前。
• 保持格式，靠近模型在互联网的文本中常见的格式。
• 确保格式上没有的过高 “开销”，例如必须准确地记住数千行代码，或对它编写的任何代码进行字符串转义。

一个经验法则是：我们考虑一下，在人机界面 (Human-Computer Interface) 上花费了多少精力，我们需要投入同样多的精力来创建良好的 Agent-计算机界面 (Agent-Computer Interface)。以下是一些关于如何做到这一点的想法：

• 把自己放在模型的角度来思考。基于描述和参数，使用这个工具是否显而易见，还是你需要仔细考虑一下？如果是后者，那么对于模型来说可能也是如此。一个好的工具定义通常包括示例用法、边缘情况、输入格式要求，以及与其他工具的明确边界。

• 你如何更改参数命名或描述，让事情更加明显易懂？把它视为为团队中的初级开发人员，为他编写一个出色的文档介绍。当使用很多相似的工具时，这一点尤为重要。

• 测试模型如何使用你的工具：多次运行准备的 Workbench 中的示例输入，查看模型犯了哪些错误，并进行迭代。

• 做好工具防错 (Poka-yoke)。调整多个参数校验，让其更难出错。

在我们给 SWE-bench 构建 Agent 时，我们花费在优化我们的工具的时间，比整体 Prompt 更多。例如，我们发现模型在使用相对文件路径的工具时会出错，尤其是在 Agent 移出根目录后。为了解决这个问题，我们更改了工具以始终需要绝对文件路径，并发现该模型完美地使用了此方法。