在过去一年里，我们与来自各行各业的几十个团队深度合作，一起搭建大语言模型（LLM）Agent 系统。在这个过程中，我们观察到一个高度一致的现象：真正跑得最稳、落地最成功的系统，往往都没有使用复杂笨重的框架或专门封装的第三方库，而是用简单、可组合的基础模式（composable patterns）直接搭出来的。

在这篇文章中，我们将分享与客户并肩实战以及 Anthropic 团队内部构建 Agent 积攒下来的第一手经验，为开发者提供一套务实、可直接上手的构建指南（注：自 2024 年 12 月本文首次发布以来，周边工具生态已不断演进；如果你想了解我们最新的托管式实践，可延伸阅读《我们如何构建 Claude 托管式 Agent》与《Managed Agents 官方文档》）。

导读：如何用好这篇 Anthropic Agent 架构开山之作？ 这篇文章是整个行业讨论 AI Agent 架构时引用率最高的基石文献，也是我们在精选中收录的《AI Agent 的高效上下文工程》《为长时间运行的 Agent 构建高效 Harness》与《面向长周期应用开发的 Harness 设计》的共同起点。读完本文，建议你在心里立住一把「从简到繁的三级选型标尺」：

  1. 能单次调用搞定，就别上多步系统：绝大多数日常需求，靠「单次模型调用 + 检索背景资料 + 几个好例子（Few-shot）」就完全够用了，既省钱又快。
  2. 步骤固定或分类明确，优先用「工作流（Workflows）」：用确定的代码逻辑把多次模型调用串起来（提示链、路由分流、并行化、协调者-执行者、评估者-优化者），兼顾高准确率与可预测性。
  3. 只有在步骤无法预判、必须边试边看环境反馈时，才上「自主 Agent」：而且一旦上 Agent，你最该花时间打磨的往往不是主提示词，而是像做防呆设计（Poka-yoke）一样打磨工具接口（ACI）——比如把容易出错的「相对路径」强制改成「绝对路径」。

什么是 Agent？（What are agents?）

每个人对「Agent（智能体）」这个词的定义都不太一样。有些团队把 Agent 定义为完全自主的系统——能够独立运转很长时间，自己调用各种工具去完成复杂任务；另一些团队则把按既定流程一步步往下走的系统也统称为 Agent。在 Anthropic，我们把这些形态统称为「Agent 系统（Agentic Systems）」，但在架构设计上，我们会严格区分「工作流（Workflows）」与「自主 Agent（Agents）」这两类截然不同的模式：

  • 工作流（Workflows）：通过预先写死的代码路径（predefined code paths），去编排和调度大语言模型与工具的系统。
  • 自主 Agent（Agents）：由大语言模型自己动态决定执行流程和工具调用方式，始终由模型自己掌控「下一步怎么完成任务」的系统。

下文我们将深入拆解这两类系统的具体设计模式。在文末的「附录 1：实战中的两类典型 Agent」中，我们还会专门探讨客户在真实业务中最常落地并拿到显著回报的两个核心场景。

什么时候该用（以及不该用）Agent？（When (and when not) to use agents）

在使用大语言模型开发应用时，我们的首要建议始终是：先寻找最简单的可行方案，只有当简单方案确实不够用时，才逐步增加系统的复杂度。 这很多时候意味着你压根不需要搭建什么 Agent 系统。因为多步运转的 Agent 系统往往是在用更高的延迟（Latency）和更高的调用成本（Cost）去换取更好的任务表现，你在动手前必须先算清楚这笔账到底划不划算。

当任务的复杂度确实超出了单次调用的能力上限时：

  • 如果任务流程明确、步骤固定，工作流（Workflows）能为你提供极高的可预测性与稳定性；
  • 如果任务需要大规模的灵活应变、必须由模型根据现场情况自己拿主意，那么自主 Agent（Agents）才是更好的选择。

不过对于绝大多数日常应用来说，只需要把单次大语言模型调用打磨好——配上海量资料的精准检索（Retrieval）和几组恰当的上下文示例（In-context examples）——通常就已经完全够用了。

什么时候、怎么用 Agent 框架？（When and how to use frameworks）

市面上有许多现成的开发框架，可以帮助你更省事地搭建 Agent 系统，例如：

这些框架把调用模型、定义与解析工具、串联多步调用等底层脏活累活都封装好了，能帮你在起步阶段快速跑通原型。但硬币的另一面是，它们往往会引入好几层额外的抽象，把真正发送给模型的底层提示词（Prompts）和原始返回结果（Responses）遮蔽在黑盒里，导致出问题时非常难排查调试；同时，现成的框架也很容易诱使开发者在简单方案就能搞定的地方，不自觉地把系统越搭越重。

因此，我们建议开发者在起步时直接调用大语言模型原生 API：你会发现，后文提到的绝大多数核心模式，用几十行简单的原生代码就能写得清清楚楚。如果你确实决定使用某个框架，请务必摸透它底层到底是怎么拼装提示词和调度代码的——在我们的客户支持经验中，对框架底层机制的想当然误判，是最常见的翻车根源之一。

你可以直接参考我们的官方实战代码示例库（Cookbook），查看这些模式用原生代码写出来的极简实现。

基础组件、工作流与自主 Agent（Building blocks, workflows, and agents）

在这一节中，我们将逐一拆解我们在生产环境中最常看到的几类 Agent 系统设计模式。我们会从最底层的核心基石——增强型大语言模型（Augmented LLM）讲起，再沿着复杂度的阶梯一步步往上走：先看五种可组合的固定工作流，最后再进入完全自主的 Agent。

基础构建块：增强型大语言模型（Building block: The augmented LLM）

所有 Agent 系统最基础的构建模块，都是一个配备了检索（Retrieval）、工具（Tools）和记忆（Memory）等扩展能力的大语言模型。如今的 Claude 模型已经能够非常主动地使用这些扩展能力——它会自己生成搜索关键词去查资料、挑选合适的工具去执行动作，并自己判断哪些关键信息值得记下来留给后续使用。

增强型大语言模型（The augmented LLM）

在实现这一基础模块时，我们建议把精力集中花在两件事上：一是根据你的具体业务场景量身定制这些扩展能力；二是确保它们为大语言模型提供了一套极易理解、文档说明清晰明了的调用接口。实现这些扩展能力的方法有很多，其中一条非常省心的路径是使用我们开源发布的模型上下文协议（Model Context Protocol，简称 MCP）——开发者只需要编写一个极简的 MCP 客户端实现，就能直接接入生态系统中不断丰富的各类第三方工具。

在接下来的所有章节中，我们都默认每一次大语言模型调用都已经具备了这些扩展能力。

工作流一：提示链（Workflow: Prompt chaining）

提示链（Prompt chaining）会将一个复杂任务拆解成一条按先后顺序执行的步骤链，后面的每一次大语言模型调用，都会拿前一次调用的输出结果作为输入继续处理。你还可以在任意两个中间步骤之间加上代码级检查（即下图中的「检查关卡 Gate」），用确定性的程序逻辑核验中间产物是否达标，确保整个流程没有跑偏。

提示链工作流（The prompt chaining workflow）

什么时候用这个模式： 当你的任务能够干净利落地拆解成几个固定不变的子步骤时，提示链是最理想的选择。它的核心思路是用多花一点时间（延迟）去换取更高的准确率——因为拆开之后，每一次模型调用面对的都是一个更简单、更纯粹的小任务。

典型应用场景：

  • 先让模型生成一份营销文案，再在下一步把它翻译并润色成另一种语言。
  • 先让模型写出整篇文档的结构大纲，通过代码或规则检查大纲是否符合指定要求（比如章节数、字数或必含要点），检查通过后再把大纲交给下一步去扩写成完整正文。

工作流二：路由分流（Workflow: Routing）

路由（Routing）会先对用户的输入进行分类识别，再根据分类结果把它分流到专门针对该类问题定制的后续流程中。这种模式实现了清晰的职责分离（Separation of Concerns），让你可以针对每一类细分问题单独编写最贴合的专用提示词。如果不做路由分流、非要用同一套提示词通吃所有类型的请求，你往往会陷入「顾此失彼」的泥潭：为了修好 A 类问题的表现去调提示词，结果反而把 B 类问题给改坏了。

路由工作流（The routing workflow）

什么时候用这个模式： 当面对的复杂任务天然包含几个界限分明的问题类别、分开处理效果更好，而且前期的分类动作（无论是交给大语言模型，还是用传统的机器学习分类算法）能够做到足够准确时，路由模式就能发挥奇效。

典型应用场景：

  • 将不同类型的客服咨询（如日常通用问答、退款申请、技术故障排查）分流到完全不同的下游处理流程、专用提示词与工具集中。
  • 将简单、高频的常规问题路由给速度更快、价格更便宜的轻量模型（如 Claude Haiku 4.5），同时把困难、罕见的复杂问题路由给能力更强的主力模型（如 Claude Sonnet 4.5），在整体回答质量与调用成本之间取得最佳平衡。

工作流三：并行化（Workflow: Parallelization）

有些时候，我们可以让多个大语言模型调用同时开工，等它们各自跑完后，再由程序代码把多路输出结果汇总（Aggregate）到一起。这种并行化（Parallelization）工作流在实际工程中主要有两种变体：

  • 任务切分（Sectioning）：将一个大任务拆成几个互不依赖的子任务，同时派发出去并行执行。
  • 多重投票（Voting）：把同一个任务同时跑好几次（或用多套不同视角的提示词同时跑），通过对比多份输出并投票汇总，拿到把握更大的结果。
并行化工作流（The parallelization workflow）

什么时候用这个模式： 当拆分出来的子任务可以同时跑以缩短总耗时，或者当你需要汇聚多个视角、多次尝试来提高结果的可靠度时，并行化非常有效。对于需要同时兼顾多项要求的复杂任务，如果把每一项考量拆给独立的模型调用去专心盯住，往往比让单次模型调用「一心多用」表现得好得多。

典型应用场景：

  • 任务切分（Sectioning）：
    • 实现安全护栏（Guardrails）：让一个模型实例专心处理用户的业务提问，同时让另一个模型实例并行审查输入内容是否包含违规或越界请求。这种「业务回答与安全审查分家」的做法，通常比让同一个模型调用既当客服又当安检员效果更好。
    • 自动化评测（Automated Evals）：在评估大语言模型表现时，同时发起多个模型调用，让每个调用只负责给同一个回答的某一个单一维度（如事实准确性、语气礼貌度、格式合规性）打分。
  • 多重投票（Voting）：
    • 代码安全漏洞审查：用好几套侧重点不同的提示词同时审查同一段代码，只要发现可疑漏洞就举牌报警（延伸阅读：可对照我们在精选中收录的《Claude Code 团队是如何做代码审查的》）。
    • 内容合规审核：用多个提示词从不同角度评估一段内容是否违规，并根据业务风险灵活设定不同的投票通过门槛，从而在「误杀正常内容（False Positives）」与「漏放违规内容（False Negatives）」之间找到最佳平衡点。

工作流四：协调者-执行者（Workflow: Orchestrator-workers）

在协调者-执行者（Orchestrator-workers）工作流中，会由一个居中的主模型充当「协调者（Orchestrator）」，负责根据当前接到的具体任务动态拆解子任务、把活派发给底下的多个「执行者（Worker）」模型，最后再把所有执行者交回来的结果综合汇总（Synthesize）成最终答案。

协调者-执行者工作流（The orchestrator-workers workflow）

什么时候用这个模式： 这种模式非常适合那些在开工前根本无法预先规定死要拆成哪几个子任务的复杂场景。比如在写代码时，一个需求到底需要修改几个文件、每个文件里具体要改什么内容，完全取决于当次需求本身以及代码库的现状。虽然从架构图上看，它和前面的「并行化」长得很像，但两者最核心的区别在于灵活性：它的子任务不是工程师提前在代码里写死的，而是由协调者模型根据每次输入的具体情况当场决定的（这也是本课程在《怎样用好子 Agent》中重点拆解的主从调度模式）。

典型应用场景：

  • 每次都需要跨多个文件做复杂代码修改的智能编程产品。
  • 需要从多个不同信息源分头收集线索、再交叉比对分析以寻找相关答案的深度搜索与调研任务。

工作流五：评估者-优化者（Workflow: Evaluator-optimizer）

在评估者-优化者（Evaluator-optimizer）工作流中，一个模型调用充当「生成器（Generator）」负责产出初步方案，另一个模型调用则充当「评估器（Evaluator）」，在循环中对方案进行挑刺评审并给出具体的修改反馈，直到方案达标为止。

评估者-优化者工作流（The evaluator-optimizer workflow）

什么时候用这个模式： 当你有明确的评估验收标准，而且多轮迭代打磨确实能带来肉眼可见的质量提升时，这个工作流尤为有效。判断你的场景适不适合用它，可以看两个明显的信号：第一，当人类看着模型的初稿指出具体修改意见时，模型改出来的第二版确实有明显进步；第二，大语言模型自己也具备写出这种高质量评审意见的能力。这其实就跟人类作家写出一篇精品文章时，经历的「写初稿 → 审阅修改 → 再打磨」的迭代过程一模一样（延伸阅读：Anthropic 在《面向长周期应用开发的 Harness 设计》中进一步展示了如何用「生成者 + 独立评估者」解决前端设计与全栈开发中的自我表扬问题）。

典型应用场景：

  • 文学与高质量翻译：翻译模型在第一遍直译时很容易漏掉微妙的语境和言外之意，但独立的评估器模型却能敏锐地指出哪里读起来生硬、哪里没翻出原味，从而指导生成器反复润色。
  • 复杂的深度搜索任务：需要经过多轮检索与综合分析才能收集全信息，由评估器模型来审查当前查到的资料够不够完整、决定需不需要补充下一轮搜索。

自主 Agent（Agents）

随着大语言模型在几项核心能力上日趋成熟——包括理解复杂输入、进行多步推理与规划、可靠地调用工具，以及从报错中自我恢复——真正的自主 Agent（Autonomous Agents）正在越来越多地走向生产环境。

一个自主 Agent 的工作，通常始于人类用户下达的一条指令，或者与用户进行的一轮互动讨论。一旦把任务目标对齐清楚，Agent 就会自己制定计划并独立运转起来，中间如果发现缺少关键信息或需要拍板决策，还可以随时回头向人类用户请示。在执行过程中，最关键的一环是Agent 必须在每走一步时，都从外部环境中获取真实的客观反馈（Ground Truth）——比如工具调用的返回结果，或是代码实际跑出来的终端输出与测试结果——以此来客观评估自己当前的推进进度。Agent 可以在预设的检查点暂停等待人工反馈，或者在遇到卡壳障碍时主动停下来求助。任务通常会在达成目标后自然结束，但在工程实现中，我们一般也会加上明确的停止条件（Stopping Conditions，例如最大循环步数上限），以确保系统始终处于可控范围内。

自主 Agent 虽然能搞定非常复杂的任务，但它的底层代码实现往往出人意料地简单：本质上就是一个大语言模型，根据外部环境的真实反馈，在循环（Loop）中持续调用工具。 正因如此，把工具集及其文档说明设计得清晰、易用、无歧义，就成了决定 Agent 成败的重中之重。我们会在文末的「附录 2：像打磨提示词一样打磨你的工具」中专门展开讲透工具开发的最佳实践。

自主 Agent 循环（Autonomous agent）

什么时候用自主 Agent： 自主 Agent 最适合用来解决那些开放式的问题（Open-ended problems）——在这类问题里，你很难甚至根本不可能在事前预测完成任务一共需要走多少步，也没法在代码里把执行路径硬编码写死。模型往往需要自己连续跑上很多轮，因此你必须对模型自身的决策能力有一定程度的信任。这种高度自主的特性，让 Agent 非常适合在受控、可信的环境中规模化地处理复杂任务。

当然，高度自主也意味着更高的调用成本，以及一步走错后引发错误滚雪球（Compounding Errors）的风险。因此，我们强烈建议在沙盒隔离环境（Sandboxed environments）中进行充分的测试，并配齐必要的安全护栏。

典型应用场景：

以下两个例子均来自 Anthropic 团队自己的工程实现：

编程 Agent 的高层运行流程（High-level flow of a coding agent）

组合与定制这些基础模式（Combining and customizing these patterns）

上文介绍的这些基础构建块和工作流并不是死板的教条，而是我们在生产实践中总结出来的常见积木模式。开发者完全可以根据自己的业务特点，把它们灵活变形、自由组合到一起。

和开发任何大语言模型功能一样，真正决定成败的关键，始终是建立客观的评测指标（Measuring performance）并在此基础上持续迭代实现方案。这里值得再三强调一句：只有当增加系统复杂度能够带来实打实、可验证的效果提升时，才值得把系统改得更复杂。

总结（Summary）

在大语言模型应用领域，真正的成功从来不在于搭出了多么炫酷、多么繁复的系统，而在于针对你的真实需求，搭出了复杂程度刚刚好的系统。请始终从最简单的单次提示词开始，配合全面的评测体系把简单方案压榨到极致；只有当简单方案确实力不从心时，再考虑引入多步运转的 Agent 系统。

当我们真正动手实现 Agent 时，始终遵循以下三条核心工程原则：

  1. 保持 Agent 架构极简（Simplicity）：能用简单代码写清楚的流程，绝不套多层黑盒抽象。
  2. 优先保证过程透明（Transparency）：把 Agent 的规划步骤与工具调用过程显式地展示出来，方便人类随时观察、理解与排查。
  3. 精心打磨「Agent-计算机接口（ACI）」：通过详尽清晰的工具文档说明与反复实测，像设计人类交互界面一样认真设计模型的工具接口。

现成的开发框架确实能帮你快速迈出第一步，但在系统走向生产环境的过程中，请毫不犹豫地剥离掉多余的抽象层，回归最扎实的基础组件。遵循这三条原则，你就能构建出不仅能力强大，而且稳定可靠、易于维护、真正赢得用户信任的 AI Agent。

附录 1：实战中的两类典型 Agent（Appendix 1: Agents in practice）

在与大量客户合作落地的过程中，有两个业务领域反复验证了前文所述设计模式的实战价值。这两个领域有一个共同特征：任务既需要自然对话沟通、又需要实际执行外部动作，拥有清晰明确的成功验收标准，能够形成有效的反馈闭环，并且可以在关键节点无缝接入人类监督。

A. 客户支持（Customer support）

客户支持场景将大家熟悉的聊天机器人界面，与调用外部工具的实际业务办理能力结合在了一起。它天生就非常适合引入更具自主性的 Agent，原因在于：

  • 客服沟通天然顺着多轮对话的脉络推进，但同时又必须随时调取外部业务数据并执行实际操作；
  • 我们可以非常方便地接入各类工具，让 Agent 按需拉取客户资料、历史订单记录以及内部知识库文档；
  • 诸如发起退款、修改收货信息或更新工单状态等动作，都可以通过工具接口由程序安全、自动地完成；
  • 任务有没有办成（即用户的问题是否真正得到解决），有着非常明确、可量化的衡量标准。

目前已经有多家企业跑通了这一模式，甚至推出了「按成功解决问题的单数收费（Usage-based pricing for successful resolutions）」的商业模式，足见他们对自家客服 Agent 实际解决率的高度自信。

B. 编程 Agent（Coding agents）

软件开发领域已经展现出了大语言模型最令人惊叹的落地潜力——AI 的角色正在从早期的「代码自动补全」，一步步演进为能够独立排查并解决复杂问题的自主编程 Agent。Agent 之所以在写代码这件事上格外有效，是因为：

  • 代码方案行不行得通，可以直接通过运行自动化测试（Automated tests）来客观检验；
  • Agent 可以直接拿测试报错和运行结果作为环境反馈，在循环中自己反复修改和迭代代码方案；
  • 编程问题本身所处的空间结构清晰、定义明确；
  • 最终产出的代码质量，可以用客观的工程指标来衡量。

在我们自己的实现中，编程 Agent 现在只看一段 GitHub Pull Request 的问题描述，就能在 SWE-bench Verified 权威基准测试中独立修好大量真实的开源项目 Issue。不过，尽管自动化测试能帮我们验证代码的功能逻辑是否跑通，但人类工程师的最终代码审查（Code Review）依然不可或缺——只有结合人工把关，才能确保 Agent 写出的改动真正契合整个系统的全局架构与长远规范。

附录 2：像打磨提示词一样打磨你的工具（Appendix 2: Prompt engineering your tools）

无论你打算搭建前文提到的哪一种 Agent 系统，工具（Tools）几乎都会是你系统中最关键的组成部分。Claude 的工具调用能力（Tool use）允许你在 API 请求中明确声明外部服务或函数的结构与定义；当 Claude 判断需要调用某个工具时，就会在 API 响应中返回一个结构化的工具调用块（Tool use block）。

在工程实践中，工具的定义与参数规范，完全应该获得与你的主提示词同等分量的提示词工程投入。 在这篇简短的附录里，我们就来聊聊到底该怎样为你的工具做「提示词工程」。

想要让模型完成同一个动作，往往有好几种不同的工具格式设计。举个最常见的例子：让模型修改一个代码文件，你既可以让它输出一段 diff 补丁，也可以让它直接重写整个文件；要让模型返回一段代码，你既可以让它把代码包在 Markdown 代码块里返回，也可以让它塞进 JSON 字符串字段里返回。在传统软件工程看来，这两种格式没有任何本质区别，写几行代码就能实现无损互转。但对大语言模型来说，有些格式写起来的难度，比另一些格式要高出好几个数量级！

比如让模型手写标准的 diff 补丁，它还没开始写下面那段新代码呢，就必须先在开头的块头信息（Chunk header）里准确算出「接下来一共会改动多少行、原文件从第几行到第几行」——这对从左往右逐词生成的模型来说极其容易算错；再比如让模型把大段代码塞进 JSON 字符串里（相比于直接写在 Markdown 代码块中），模型必须小心翼翼地对代码里的每一个换行符 \n 和双引号 \" 做转义处理，稍微漏掉一个斜杠就会导致整个 JSON 解析崩溃。

因此，在决定工具的输入输出格式时，我们有三条核心建议：

  • 给模型留出足够的思考空间，别逼它「先下结论再凑过程」：不要设计那种还没生成具体内容、就要求模型在第一个字段里先把统计行数或最终结果填出来的格式，避免它写到一半把自己逼进死胡同。
  • 尽量贴近模型在互联网自然文本里最常看到的原生格式：比如写代码就用标准的 Markdown 代码块，而不是强行塞进层层转义的 JSON 字符串。
  • 彻底砍掉不必要的「格式税（Formatting overhead）」：绝不要让模型去人工数几千行代码的行号，也不要让它去手动转义大段代码字符串。

一个非常管用的经验法则是：想想我们平时在人机交互界面（HCI，Human-Computer Interface）上花了多少心思，就应该计划在打造优秀的「Agent-计算机接口（ACI，Agent-Computer Interface）」上投入同样多的精力。具体可以从以下四点入手：

  • 站在模型的视角换位思考：光看这个工具的文字说明和参数列表，换作是你，能一眼看明白怎么调它吗？还是得皱着眉头反复琢磨半天？如果你自己看着都犯迷糊，那模型大概率也会用错。一份优秀的工具定义，通常都会包含清晰的调用示例、边界情况说明（Edge cases）、输入格式要求，以及它与其他相似工具之间的职责分界线。
  • 像给团队里的初级开发者写文档注释（Docstring）一样打磨参数名：仔细检查每一个参数名和描述文案，看看怎么改才能让它的用途更一目了然。当你手头有好几个功能相近的工具时，这一点尤为关键。
  • 在真实运行记录里观察模型是怎么用错工具的：在我们的开发者工作台（Workbench）里多跑几组真实的测试输入，仔细看模型在调用工具时到底会犯哪些错，然后针对性地迭代工具定义。
  • 为工具做好「防呆设计（Poka-yoke）」：直接修改工具的参数设计，从源头上把容易犯错的口子堵死，让模型想犯错都难。

在为 SWE-bench 构建编程 Agent 的过程中，我们花在打磨和优化工具上的时间，实际上比花在写主提示词上的时间还要多。 举个真实的例子：我们最初发现，一旦 Agent 在终端里切换了当前工作目录（跳出了项目根目录），它在调用文件编辑工具时就经常把「相对文件路径（Relative filepaths）」搞错。为了彻底根治这个问题，我们直接给工具做了防呆改造——强制要求所有文件工具的参数一律传入以 / 开头的绝对路径（Absolute filepaths）。改完这一条之后，模型在文件路径上就再也没有犯过错。

作者与致谢（Authors & acknowledgements）

本文由 Anthropic 团队的 Erik Schluntz 与 Barry Zhang 撰写。文中的方法与洞察源自我们在 Anthropic 内部构建各类 Agent 的一线实践，以及众多客户在合作过程中无私分享的宝贵实战经验，在此致以诚挚感谢。