构建有效智能体：从最小复杂度到可控自治

精读对象：Building effective agents
作者：Erik Schluntz、Barry Zhang
发布机构：Anthropic
发布日期：2024 年 12 月 19 日
报告日期：2026 年 9 月 18 日
文章类型：工程经验总结与架构模式指南
适合读者：LLM 应用开发者、智能体架构师、平台工程师、技术负责人

1.核心结论

这篇文章最重要的观点不是“如何搭建一个更复杂的智能体”，而是：先找到能够完成任务的最简单系统，只有在评测证明简单方案不足时，才增加多步骤编排或自治能力。

文章把 LLM 应用放在一条复杂度阶梯上：

单次 LLM 调用
→ 带检索、工具和记忆的增强型 LLM
→ 预先编排的工作流
→ 由模型动态规划和使用工具的智能体

复杂度越高，系统通常能处理越开放、越难预先分解的任务，但也会增加调用次数、延迟、成本、状态管理和错误累积风险。作者的建议不是拒绝智能体，而是让复杂度服务于可测量的任务改进。

文章还提出一个容易被忽视的区分：

• 工作流（workflow）：LLM 和工具沿开发者预先规定的代码路径运行。
• 智能体（agent）：LLM 根据任务和环境反馈，动态决定下一步、使用哪些工具以及何时结束。

因此，“是否调用了多个模型”不是区分工作流和智能体的标准。关键在于控制流由代码预先确定，还是由模型在运行时决定。

这是一篇工程经验文章，不是对不同架构进行随机对照的研究。Anthropic 称其结论来自与数十个团队合作及内部实践，但没有公开样本、任务分布、对照实现、成本数据或统计分析。文章适合用作架构选择框架，不足以证明某种模式在所有场景中更优。

2.文章建立的概念框架

2.1 “智能体系统”是上位概念

“智能体”在业界没有统一定义。有人用它指能长时间独立行动的自治系统，也有人把固定的多步提示链称为智能体。Anthropic 用“agentic systems”统称这些系统，再把它们分为工作流与智能体。

这个划分的价值在于，它把讨论从产品标签转向了控制结构。开发者可以明确回答：

1. 哪些步骤由代码决定？
2. 哪些步骤由模型决定？
3. 模型能否改变计划和选择工具？
4. 系统依据什么环境反馈判断进展？
5. 谁负责停止、重试和升级给人类？

只有回答这些问题，才能讨论系统的可预测性、测试方式和风险边界。

2.2 复杂度不是能力的同义词

原文反复强调，许多应用只需要单次调用，再配合检索和上下文示例。工作流适合路径清楚、要求稳定的任务；智能体适合步骤难以预先确定、需要模型动态决策的任务。

这背后是三个不同目标：

• 任务效果：输出能否达到质量标准。
• 资源效率：需要多少模型调用、Token、工具执行和等待时间。
• 运行可控性：系统是否容易测试、解释、恢复和限制权限。

智能体可能提高复杂任务的完成率，但这种收益必须覆盖额外成本与风险。不能仅凭“系统更自主”推断它更有效。

3.共同基础：增强型 LLM

文章把带有检索、工具和记忆能力的 LLM 视为所有智能体系统的基础组件：

• 检索为模型提供任务相关的外部知识；
• 工具让模型执行查询、写文件、调用 API 或操作环境；
• 记忆保存当前上下文之外仍需复用的信息。

作者认为，实现时应重点关注两件事：能力是否针对具体任务，以及模型能否通过清晰、文档充分的接口使用这些能力。文章提到 Model Context Protocol（MCP）作为一种集成工具的方式，但核心原则不依赖 MCP：工具对模型而言也是一种用户界面。

增强能力不会自动带来更好结果。检索可能返回无关或过期信息，工具可能暴露过宽权限，记忆可能保留错误状态。每一种增强都要有独立评测和失败处理，而不是把更多上下文和更多工具一次性交给模型。

4.五种工作流模式

4.1 提示链：把困难任务拆成固定步骤

提示链让前一个模型调用的输出成为下一个调用的输入。开发者可以在中间加入程序化门禁，阻止不合格结果继续流入下游。

适用条件是任务能够干净地分成固定子步骤。例如：先生成提纲，再检查提纲，最后写正文；或先生成营销文案，再翻译。

它用更多延迟和调用成本换取更小、更聚焦的单步任务。主要风险包括：

• 上游错误被后续步骤继承；
• 中间结果过早丢失信息；
• 步骤边界看似清楚，实际存在反复依赖；
• 每一步单独通过，但最终组合不符合目标。

因此，门禁不能只检查格式，还应检查对后续任务真正重要的语义条件。

4.2 路由：先分类，再进入专用路径

路由先判断输入属于哪一类，再调用对应的提示、模型或工具。例如把客服请求分成一般咨询、退款和技术支持，或把常见问题交给成本更低的模型，把异常问题交给能力更强的模型。

适用前提是类别具有稳定差异，而且分类器的准确率足够高。路由的收益来自关注点分离：每条路径可以针对一种输入优化，不必让同一个提示同时处理互相冲突的任务。

文章没有展开的关键风险是错路由。一旦入口分类错误，后续专用流程可能非常自信地处理错误问题。生产系统应单独评估路由混淆矩阵，设置低置信度回退路径，并允许下游发现不匹配后重新路由。

4.3 并行化：拆分任务或增加判断样本

文章把并行化分为两类：

• 分区（sectioning）：把彼此独立的子任务并行执行，再合并结果。
• 投票（voting）：对同一问题进行多次尝试或从多个角度评估，再聚合判断。

分区适合能够真正独立处理的任务，例如分别审查性能、安全性和可维护性。投票适合单次判断不稳定、需要控制误报和漏报的场景。

并行不必然提高可信度。如果多个调用使用相同模型、相同上下文和相似提示，它们的错误可能高度相关，不能当作独立样本。聚合器本身也可能遗漏少数但关键的发现。使用投票时，应明确多样性来自哪里，以及什么证据可以推翻多数意见。

4.4 编排器—执行器：运行时动态分解任务

该模式由一个中央 LLM 分析输入、动态拆分子任务、委派给多个执行器，再综合结果。它与固定并行化的主要区别是：子任务不能提前完全确定，而是由编排器根据当前任务生成。

适合场景包括多文件代码修改和需要从多个来源搜索、筛选、综合信息的研究任务。其优势是灵活，主要风险则集中在编排器：

• 分解遗漏关键子任务；
• 子任务重叠，重复消耗资源；
• 执行器收到的信息不足或边界不清；
• 综合阶段丢失冲突和不确定性；
• 编排器无法判断何时已经收集足够证据。

因此，编排器不仅需要“会分工”，还要能跟踪覆盖范围、依赖关系、预算和完成条件。

4.5 评估器—优化器：根据反馈迭代改进

该模式让一个模型生成答案，另一个模型根据明确标准提供反馈，并循环修订。原文认为它在两个条件同时成立时最有效：人工反馈确实能稳定改善结果，而且模型能够产生同类有用反馈。

文学翻译、复杂研究和需要多轮完善的内容任务可能适合这种模式。它不适合没有明确评价标准的问题，也不适合只会让文本变长、却不能提高正确性的循环。

如果生成器与评估器共享相同盲点，循环可能反复强化错误。可靠的停止条件应来自可观察指标、外部测试或人类判断，而不是“评估器终于满意”。

5.何时需要真正的智能体

5.1 适用任务的特征

原文认为，智能体适合步骤数量和顺序难以预先确定的开放任务。任务通常具有以下特征：

• 需要在运行时探索环境；
• 后续动作依赖工具返回的结果；
• 失败后可以根据反馈改变方法；
• 成功标准能够被环境、测试或用户确认；
• 系统被允许在一定范围内自行决定路径。

编码任务是典型例子。智能体需要查看仓库、复现问题、定位文件、修改代码、运行测试，并根据失败结果继续迭代。开发者很难预先写出适用于所有问题的固定路径，但测试可以持续提供反馈。

5.2 智能体循环的真实结构

文章把智能体实现概括为“LLM 根据环境反馈反复使用工具”。完整结构可以写成：

理解目标
→ 形成当前计划
→ 选择并调用工具
→ 读取环境结果
→ 判断是否取得进展
→ 更新计划、请求人类信息或停止

这里最关键的不是模型的内部计划，而是每一步能否从环境获得可核查的反馈。代码测试、数据库查询结果、文件差异和 API 响应属于相对可靠的外部反馈；模型对自己答案的主观评价不等同于真实进展。

5.3 必须存在停止条件

长循环会放大成本和错误。原文建议设置最大迭代次数等停止条件，并允许系统在检查点或遇到阻塞时请求人类判断。实际系统还应限制：

• 总 Token、调用和执行预算；
• 单个工具及整体任务的超时时间；
• 连续无进展或重复动作次数；
• 可写入、可删除和可发送数据的范围；
• 必须获得人工批准的高风险动作；
• 失败后的回滚和恢复路径。

停止不是异常兜底，而是智能体架构的一部分。

6.框架：降低起步成本，也可能隐藏关键行为

文章承认框架可以封装模型调用、工具定义、结果解析和调用链，因此适合快速起步。但额外抽象层也可能隐藏真实提示、模型响应和状态变化，增加调试难度，并诱使团队在没有必要时使用复杂编排。

作者建议先理解直接调用 LLM API 的实现，再决定是否引入框架。这个建议的重点不是“永远手写”，而是团队必须知道框架替自己决定了什么：

• 提示如何拼接；
• 工具结果如何写回上下文；
• 失败如何重试；
• 状态保存在哪里；
• Token 和并发预算如何控制；
• 模型或工具升级会改变哪些行为。

原文当前页面已经加入提示：自 2024 年 12 月以来，工具生态发生了较大变化，并引导读者查看 Claude Managed Agents。框架名称和产品接口会过时，但“不要让抽象层遮住运行机制”的原则仍然有效。

7.工具设计就是智能体的接口设计

文章在附录中提出 ACI（agent-computer interface，智能体—计算机接口）概念，与 HCI（人机交互）对应。它认为，团队应像设计人类界面一样认真设计模型使用的工具。

7.1 让正确操作容易生成

不同工具格式对程序而言可能等价，对模型却不一定等价。例如，生成带行号计数的 diff、在 JSON 中转义大段代码，通常比直接生成自然代码结构更容易出错。工具格式应尽量接近模型熟悉的自然表示，减少与任务无关的格式负担。

7.2 工具说明要覆盖边界和失败模式

良好的工具定义至少应说明：

• 工具解决什么问题、不解决什么问题；
• 参数的含义、格式、单位和默认值；
• 与相似工具的区别；
• 典型示例和边界情况；
• 成功、失败和部分成功的返回结构；
• 是否有外部副作用以及如何撤销。

原文建议把工具说明写得像给初级开发者看的高质量 docstring，并通过大量样例观察模型真实会犯什么错误。

7.3 用接口约束预防错误

文章举例称，Anthropic 在 SWE-bench 智能体中发现模型离开仓库根目录后容易错误使用相对路径，于是让文件工具强制要求绝对路径。这个改动不是提醒模型“小心”，而是从接口上消除歧义。

这是全文最可迁移的工程思想之一：**优先修改接口，使错误难以发生，而不是只在提示词中增加警告。**同样的做法包括使用枚举代替自由文本、把危险操作拆成预览与确认两步、让写操作返回可验证的结果，以及为重复调用设计幂等语义。

8.客户支持与编码智能体为何适合自治

文章选取客户支持和软件开发作为两个代表场景。它们共同具有“对话加行动”的结构，并且可以建立反馈闭环。

8.1 客户支持

客服智能体可以读取客户资料、订单历史和知识库，再执行退款或更新工单。适配点在于：对话提供目标和补充信息，工具执行真实动作，工单是否解决可以作为结果指标。

但原文没有深入讨论错误退款、身份验证、权限分级和投诉升级等风险。生产系统不能因为“解决率可测”就允许模型无条件执行动作；需要把可逆性、金额、账户权限和政策例外纳入批准规则。

8.2 编码智能体

代码可以通过测试获得快速反馈，仓库结构也给智能体提供了明确环境。文章引用 SWE-bench 说明智能体能够根据真实 GitHub 问题修改多文件代码。

SWE-bench 原始论文包含 12 个 Python 仓库中的 2,294 个问题；之后推出的 SWE-bench Verified 是经过人工筛选的 500 个样本。它们衡量的是代理在给定问题描述和代码仓库后生成补丁、通过指定测试的能力，不等同于完整的软件工程质量。

这个限制在 2026 年更加明显。OpenAI 已公开表示 SWE-bench Verified 不再适合单独衡量前沿编码能力，并在失败样本审计中发现测试可能拒绝功能上正确的方案。因此，原文用它说明“编码任务具有环境反馈”仍然合理，但不能把某个分数直接解释为真实项目中的自主开发成功率。

9.文章证据强度与主要局限

9.1 经验来源有价值，但不可复算

Anthropic 表示其建议来自与数十个团队合作以及内部构建经验。这为模式总结提供了实践基础，但文章没有公开各团队的任务、失败率、延迟、成本和对照方案。读者无法复算“简单模式更成功”的程度，也无法判断样本是否偏向 Claude 擅长的场景。

因此，文章中的“适合”“表现更好”和“通常足够”应理解为工程启发式，而不是统计结论。

9.2 模式之间并不互斥

真实系统可以先路由，再对某一路径使用提示链；智能体也可以把并行执行器作为工具。文章明确允许组合模式，但图示的阶梯结构容易让读者误以为必须选择唯一架构。

更准确的做法是先找出当前失败模式，再选择最小的补偿机制：分类错误用路由评测解决，信息覆盖不足用并行分区解决，需要动态探索时才引入编排器或智能体。

9.3 缺少完整的安全模型

原文提到沙箱、护栏和人工检查点，却没有系统讨论提示注入、凭证泄露、最小权限、数据外传、供应链工具和跨会话状态污染。这在 2024 年的概念指南中可以理解，但不足以作为生产安全设计。

Anthropic 2026 年的 Managed Agents 架构已经补充了部分内容：将会话、harness 和沙箱分离，把凭证保存在沙箱之外，并通过代理调用工具。这个变化说明，简单的模型—工具循环只是逻辑核心，生产部署还需要持久化、隔离和故障恢复设施。

9.4 “展示规划步骤”需要谨慎解释

原文把透明性概括为显式展示智能体的规划步骤。实践中，更可靠的可观察对象是计划摘要、工具调用、输入输出、状态变化和决策理由，而不是要求系统暴露模型的隐藏推理过程。

对用户有用的透明性应回答“系统准备做什么、做了什么、依据什么结果改变计划、哪里需要批准”，而不是展示冗长且未必忠实的内部思维文本。

9.5 缺少基准线与停止规则的具体评测方法

文章建议测量效果并迭代，却没有给出统一指标。团队至少需要同时记录：任务成功率、质量缺陷、人工接管率、端到端延迟、模型与工具成本、重复循环率、不可恢复失败率和高风险动作拦截率。

如果只测最终答案质量，多调用系统通常有机会获得更高分，却可能在成本和延迟上不可接受；如果只测平均成本，又可能掩盖少数长尾任务的失控循环。

10.从 2024 年原则到 2026 年生产架构

截至 2026 年 9 月，Anthropic 已在原文顶部增加说明，提醒读者 2024 年描述的工具生态已经变化，并引导到 Managed Agents。新架构没有否定原文的“简单、可组合模式”，而是把长期运行需要的基础设施显式化。

Managed Agents 将系统分成三个可替换部分：

• Session：追加式事件日志，持久记录发生过的事情；
• Harness：调用模型并把工具调用路由到执行环境的控制循环；
• Sandbox：运行代码和修改文件的隔离环境。

分离后，harness 或沙箱失败时可以替换，而会话记录仍然存在；凭证可以保存在沙箱不可访问的保险库中；上下文窗口也不再等同于完整会话历史。Anthropic 报告，在其具体架构中，按需配置容器后，首次输出 Token 的 p50 延迟下降约 60%，p95 下降超过 90%。这是 Managed Agents 系统的内部结果，不能直接外推到其他实现。

这次演进补充了原文没有展开的生产要求：

2024 年文章强调的逻辑	2026 年生产系统补充的基础设施
模型根据环境反馈循环	持久事件日志支持失败后恢复
工具接口应清晰	工具代理与凭证保险库隔离敏感信息
沙箱中测试智能体	沙箱可替换、按需配置，并与 harness 解耦
设置人工检查点和停止条件	会话预算、事件流和异步运行成为平台能力
逐步增加复杂度	harness 可随模型能力变化而替换，避免旧假设固化

长期有效的不是某个框架名称，而是控制复杂度、保留环境反馈、设计清晰接口和用评测决定架构的原则。

11.架构选择表

任务形态	推荐起点	主要收益	主要失败方式	必须测量的内容
单次、边界清楚、上下文可一次提供	单次 LLM 调用，加检索或示例	成本低、延迟小、容易调试	信息不足、提示泛化差	成功率、引用正确率、延迟、成本
可稳定拆成顺序步骤	提示链	每一步更聚焦，可设门禁	上游错误传播、信息损失	各步骤通过率、端到端成功率
输入存在稳定类别	路由	专用提示和模型更容易优化	错路由、低置信度输入无处可去	混淆矩阵、回退率、分类成本
子任务独立或需要多角度检查	并行化	缩短墙钟时间或扩大覆盖	相关错误、聚合遗漏、成本增加	覆盖率、意见相关性、聚合错误
子任务无法预先确定，但可以集中协调	编排器—执行器	动态分工、适应复杂输入	分解遗漏、重复工作、综合失真	子任务覆盖、预算、冲突保留率
有明确评价标准且反馈能改善结果	评估器—优化器	可迭代提高特定质量指标	同源盲点、无效循环、过度润色	每轮增益、停止轮数、外部质量指标
步骤开放、需要持续操作环境	智能体	能探索、纠错并改变计划	成本失控、权限风险、复合错误	任务成功率、接管率、循环长度、风险事件

12.可直接执行的设计流程

12.1 先定义成功，而不是先选择框架

写清任务输入、允许动作、结果标准、最大预算和必须人工批准的操作。没有可验证成功标准时，自治只会让系统更难判断是否完成。

12.2 建立最简单基线

先测试单次调用加必要检索或工具能达到什么结果。记录失败样本，而不是凭直觉认为任务“需要智能体”。

12.3 按失败模式增加一个结构

• 固定任务太难：拆成提示链；
• 输入类型互相干扰：增加路由；
• 多个独立方面被遗漏：增加并行分区；
• 结果可以依据明确标准改进：增加评估循环；
• 子任务只能运行时发现：采用编排器或智能体。

一次只增加一个主要机制，才能知道改进来自哪里。

12.4 用端到端指标比较

新架构只有在目标指标改善，并且成本、延迟和风险仍可接受时才保留。模型调用次数不是价值，智能体运行时长也不是进展。

12.5 为失败和恢复设计

明确工具超时、返回空结果、权限不足、环境崩溃、上下文压缩和人类未响应时如何处理。长期任务应将会话状态保存在可恢复位置，而不是只依赖当前上下文窗口或单个执行容器。

13.生产前检查清单

13.1 任务与评测

• 是否有可判定的成功条件和代表性失败样本？
• 单次调用基线是多少？复杂架构改善了哪个指标？
• 是否同时测量质量、成本、延迟和人工接管？
• 评测是否覆盖长尾输入，而不只是演示样例？

13.2 控制流与状态

• 哪些步骤由代码决定，哪些由模型决定？
• 动态计划、任务状态和工具结果保存在哪里？
• 系统崩溃后能否从持久状态恢复？
• 是否存在最大循环次数、预算和无进展停止条件？

13.3 工具与环境

• 工具名称、参数、边界和返回错误是否清楚？
• 是否用接口约束消除了常见错误，而不只是添加提示警告？
• 工具调用是否幂等，或至少能够检测重复执行？
• 模型能否获得足够的环境反馈验证动作结果？

13.4 权限与安全

• 沙箱是否与凭证和生产数据隔离？
• 工具是否遵循最小权限，并限制可读、可写和可发送范围？
• 高风险动作是否需要人工确认？
• 是否测试了提示注入、恶意工具输出和数据外传路径？

13.5 可观察性

• 是否记录计划摘要、工具调用、结果、重试、预算和停止原因？
• 用户能否看到系统做了什么，而不依赖隐藏推理文本？
• 失败能否定位到模型、工具、环境、编排或权限层？
• 模型、提示或框架升级后是否自动运行回归评测？

14.总体评价

《Building effective agents》最有价值的地方，是在智能体热潮中提出了一条克制的工程原则：从简单方案开始，用评测证明复杂度的必要性。它给出的五种工作流模式和自治智能体结构，为团队提供了一套共同语言，也明确指出工作流与智能体的区别在于运行时控制权，而不在于模型调用数量。

文章的局限同样明确：它主要依赖 Anthropic 与客户的经验，没有公布可复算的横向实验；对安全、持久状态和故障恢复的讨论较薄；引用的编码评测也受时代和基准局限影响。2026 年 Managed Agents 的演进说明，逻辑上的“简单循环”并不等于生产系统可以简单。长时间自治需要持久会话、隔离执行、凭证保护、预算控制和可恢复基础设施。

因此，这篇文章不应被读成一套固定的智能体模板，而应被读成一个决策规则：

先建立最简单的可测基线；识别它真正失败的地方；只加入能够针对该失败、并通过端到端评测证明有价值的复杂度。

15.参考资料

1. Anthropic：Building effective agents，发布于 2024 年 12 月 19 日，访问于 2026 年 9 月 18 日。
2. Anthropic：Scaling Managed Agents: Decoupling the brain from the hands，发布于 2026 年 4 月 8 日，访问于 2026 年 9 月 18 日。
3. Claude Platform Docs：Claude Managed Agents overview，访问于 2026 年 9 月 18 日。
4. Anthropic Claude Cookbook：Basic workflows，访问于 2026 年 9 月 18 日。
5. Jimenez 等：SWE-bench: Can Language Models Resolve Real-world GitHub Issues?，ICLR 2024。
6. OpenAI：Introducing SWE-bench Verified，发布于 2024 年 8 月 13 日，2025 年 2 月 24 日更新。
7. OpenAI：Why SWE-bench Verified no longer measures frontier coding capabilities，访问于 2026 年 9 月 18 日。