第 1 章 智能体架构

学习目标

• 说明工作流与智能体的区别，并找出同一系统中两种方式混合使用的位置。
• 区分提示词链、路由、并行化、编排者-执行者、评估者-优化者的适用条件与失败表现。
• 解释多智能体结构为什么会使成本增加，并以每个成功完成的任务所需的成本为依据，判断是否应当引入这种结构。
• 在 handoff 与 agent-as-tool、LLM 编排与代码编排之间选择合适的连接方式。
• 运用这样的决策流程：从最简单的结构开始，只有获得支持增加复杂度的依据时，才采用更复杂的结构。

引言

某个团队把客户咨询处理重新做成了“由智能体处理”的系统。在这种结构中，模型自行选择工具，必要时还会把工作转交给其他智能体。演示效果十分出色。然而，运营仅一个月，就有人提出了三项不满：即使面对同一个问题，每次的处理路径也不同，无法复现；响应速度变慢；账单金额达到了预期的三倍。团队打开日志后发现，大多数咨询其实都是处理顺序始终相同的结构化请求。这就好比本来只要沿着固定线路行驶就能办成的事，却每次都要叫一辆出租车，再向司机问路。

本章介绍如何避免这样的错误。我们先区分工作流与智能体，辨别哪些工作需要智能体，再剖析五种工作流模式，以及自主智能体和多智能体所带来的成本。接着，梳理连接智能体的方法，以及从最简单结构出发的决策流程；在“深入阅读”中，则进一步考察混合设计与相关性错误。

核心概念

工作流与智能体

Anthropic 的《Building effective agents》这样区分二者：工作流是 LLM 与工具按预先定义的代码路径协同运行的系统；智能体是由 LLM 动态决定自身执行过程和工具使用的系统。同一篇文章指出，工作流能为定义明确的任务提供可预测性与一致性，而当任务需要规模化的灵活性和模型主导的判断时，智能体更合适。

如果说工作流是按固定线路行驶的公交车，智能体就是只听目的地、自己选路的出租车。对于线路固定的任务却叫出租车，只会增加成本，路线也更难预测。反过来，如果每条小巷的路线都不同，却坚持坐公交车，乘客就到不了需要下车的地方。

这种区分并不是贴在整个系统上的标签。即使在同一系统内，不同步骤中决定下一步行动的主体也可能不同。例如，由代码决定咨询分类与权限检查，仅让模型自主调查其中某些类别的咨询。设计文档应写明“这一步由谁决定下一步行动”，而不只是“本系统是智能体”。

哪些任务需要智能体

智能体是以延迟和成本为代价换取更好任务表现的选择。Anthropic 建议先寻找最简单的方案，只在必要时才增加复杂度，并指出，对很多应用而言，优化带有检索与示例的单次 LLM 调用通常就足够。

OpenAI 的《A practical guide to building agents》提出了三项值得考虑使用智能体的任务标准。

指南补充说，应先确认任务是否明确满足这些标准；否则，确定性（deterministic）方案可能已经足够。确定性是指相同输入总会产生相同路径和结果。对于验证并上传固定格式文件这类规则简单且稳定的任务，普通代码比智能体更便宜、更准确。

增强型 LLM 与智能体循环

所有结构的基本部件都相同。Anthropic 将其称为增强型 LLM，即加入检索、工具、记忆等扩展的 LLM。OpenAI 指南也用模型、工具、指令三个要素来说明智能体。工具又分三类：获取上下文和信息的数据工具、作用于外部系统的行动工具，以及把其他智能体当作工具调用的编排工具。

智能体让这些部件循环运转：模型选择下一步行动，执行工具，再把结果输入模型。Anthropic 解释，智能体应在每一步从环境中取得真实结果（用 Anthropic 的话说是“ground truth”），例如工具结果或代码执行结果，据此判断进展，也可以在检查点或受阻之处停下来获取人工反馈。如果循环只依靠模型猜测，而不依靠这些真实结果，错误就会不断累积。

提示词链与关卡

提示词链把任务拆成固定的子步骤，将前一次调用的输出传给下一次调用。步骤之间可以设置代码检查，即关卡。Anthropic 的示例包括先写营销文案再翻译，以及先写提纲、检查是否符合标准，再写正文。任务能够清晰地拆成固定步骤时，适合采用这种模式。

设计提示词链时，先定义步骤之间的数据契约，也就是用 schema 固定前一步以什么格式传递什么内容，以及下一步依赖哪些前提。

1. 为每一步定义输出 schema（字段、单位、允许范围）。
2. 在关卡中用代码检查 schema 和业务规则。
3. 检查失败时，只重跑该步骤或转交人工。
4. 将各步骤延迟相加，确认是否落在总延迟预算之内。

提示词链的典型失败是错误传播。如果第一步读错单位，后续步骤仍会用这个数字写出看似合理的文字。关卡正是阻断这种传播的装置。此外，步骤越多，延迟越长，因此要权衡拆分步骤的收益（每次调用更专注）是否大于延迟成本。

路由

路由对输入进行分类，再交给专门的后续处理。存在适合分开处理的明确类别时，可以使用。Anthropic 的示例包括按类型划分客户咨询，以及把简单问题交给小而快的模型、复杂问题交给更强的模型。

设计路由器时，误分类成本与准确率同样重要。把退款咨询误送到一般说明流程，与把一般说明请求误送到退款流程，损害不同。因此，路由器还应同时设计以下内容。

分类本身可以使用规则、小模型，或输出结构化结果的 LLM 调用。类别稳定时，代码或小模型成本更低；类别边界依赖自然语言细微差别时，LLM 分类更合适。

并行化：分段与投票

并行化有两种变体。分段（sectioning）同时运行相互独立的子任务；投票（voting）多次运行同一任务，收集多个输出。Anthropic 用来说明分段的例子是：一个模型生成回答时，另一个模型检查请求是否不当，组成护栏。投票的例子则包括让多个提示词分别寻找代码漏洞，或用不同阈值判断内容是否合适。希望提高速度，或通过多种视角、多次尝试获得更可靠的结果时，可以采用这种模式。

计算并行化收益时，要看关键路径。总耗时取决于耗时最长的路径以及汇总结果的时间。即使同时启动十个执行者，总耗时也不会短于最慢执行者的耗时加上整理结果的时间。此外，并发数量可能受到外部 API 限制；某个执行者失败时是使用部分结果还是全部重跑，也应事先决定。

投票会按调用次数增加成本。请只在判断模糊且单次错误代价高的地方使用。

编排者-执行者

编排者-执行者由中央 LLM 动态拆分任务，交给执行者 LLM，再综合结果。外观与并行化相似，但有一个关键区别：并行化的子任务在设计时已经确定，而编排者-执行者在看到输入之前，无法预测需要哪些子任务。Anthropic 的示例包括需要修改多个文件的编码工具，以及搜索多个来源的检索任务。

这种模式的成败取决于委派契约。Anthropic 关于研究系统的文章指出，每个子智能体都需要目标、输出格式、工具与来源使用指引，以及明确的任务边界。文章还介绍了一个案例：因为指令模糊，三个子智能体中有两个重复调查了同一个供应链主题。委派指令必须包含以下四项。

目标：仅调查 2024～2026 年韩国电动汽车充电费政策的变化。
输出格式：包含年份、政策名称、变更内容、来源 URL 的表格，不超过 20 行。
工具与来源：优先使用政府和公共机构网站，不使用博客摘要。
边界：海外政策和充电桩普及统计由其他执行者负责。

还必须用代码限制再次委派的深度（执行者能否再创建执行者）以及执行者总数。

评估者-优化者

评估者-优化者是一种循环：由一次调用生成内容，再由另一次调用评估内容并提供反馈。Anthropic 建议，只有在评估标准明确、反复改进所带来的价值能够测量时，才使用这种模式。可以从两个方面确认是否满足条件：如果由人提供反馈，结果是否确实会改善；模型是否能够自行产生这样的反馈。例子包括文学翻译，即像译者的批评意见那样辨别细微差异的工作，以及多轮搜索，即由评估者判断是否需要继续查找的工作。

循环必须有结束的时候，因为评估者可能无休止地要求“再改进一点”。代码中应设置最大迭代次数、分数不再上升时停止的条件，以及相邻两次迭代之间改进幅度的下限。如果循环结束时仍未收敛，就应把最后的结果与评估记录一并保留下来，让人作出判断。

自主智能体与停止条件

对于难以预测需要多少个步骤、或无法事先用代码写定步骤的开放式问题，应使用自主智能体。Anthropic 说明，此时必须能够在一定程度上信任模型的判断；同时也建议，考虑到运行成本较高，而且错误可能不断累积，应在沙箱环境中进行充分测试，并设置适当的护栏。为了始终保持对运行过程的控制，需要加入最大迭代次数等停止条件。第 5 章将介绍停止条件的具体设计。

同一篇文章还列出了智能体设计的三项原则：保持设计简洁；明确呈现智能体制定计划的步骤；通过充分编写工具文档并进行彻底测试，改进智能体-计算机接口（ACI）。其中，第三项原则正是第 2 章所讨论的主题。

多智能体的成本

在 Anthropic 研究系统的案例中，智能体消耗的 token 约为聊天的 4 倍，多智能体系统约为 15 倍。在 BrowseComp 评估分析中，三个因素解释了性能方差（差异）的 95%，其中仅 token 用量就解释了约 80%；另两个因素是工具调用次数和模型选择。多智能体的收益很大程度上来自“能够在多个窗口中使用更多 token”。

因此，该文指出，多智能体适合并行空间大、信息无法装进单个窗口的高价值任务；不适合所有智能体都必须共享同一上下文、或智能体之间依赖关系强的任务。文章也指出，大多数编码任务真正可以并行的部分比研究任务少，因此不那么适合。

成本并不只有 token。

比较指标应是每个成功任务的成本，而不是总成本。即使总成本翻倍，只要成功率变为三倍，仍有收益；即使成本相同，若成功率也保持不变，仍会得不偿失。

编排：由 LLM 决定，还是由代码决定

OpenAI Agents SDK 文档区分了两种方式。LLM 编排让模型自行规划并选择下一步，适合开放式任务。代码编排用代码确定流程，在速度、成本和性能方面更具确定性、更可预测。文档列举的代码编排方法包括：用结构化输出分类任务并选择下一个智能体；把一个智能体的输出连接为下一个智能体的输入；运行 while 循环，直到评估智能体宣告通过；以及用 asyncio.gather 等基础工具并行运行相互独立的智能体。

连接智能体的方法也有两种。

handoff 发生在一次运行（一个轮次）之内；下一轮从哪个智能体开始，由应用在调用运行时决定。OpenAI 指南把同样的区分称为管理者模式（将智能体作为工具调用）和去中心化模式（同级智能体之间 handoff），并解释：若把多智能体看作图，管理者模式的边是工具调用，去中心化模式的边是转交执行的 handoff。指南的一般建议是，先尽可能发挥单个智能体的能力。值得拆分的信号有两个：提示词中的 if-then-else 分支过多，模板难以继续扩展；以及选错工具，原因往往是工具相似或重叠，而不只是数量多。指南指出，有的实现能够处理 15 个以上区分清楚的工具，也有实现在不到 10 个相互重叠的工具之间迷失。

Google ADK 的顺序、循环、并行工作流智能体也是代码编排的例子。它们按预定逻辑执行，编排时不使用模型，因此是确定性的。不过，从 Python 和 Go 版的 ADK 2.0 起，这类模板式工作流已被基于图的动态工作流取代，请查阅所用语言和版本的文档。

从最简单的结构开始选择

选择结构就像逐级爬梯子。只有实测表明较低一级的结构无法满足要求时，才向上一级移动。

应将决定记录为架构决策记录（ADR）。ADR 是说明选择了什么、为什么选择的简短文档，记录比较过的方案（至少包括低一级的结构）、用同一任务集测得的质量、延迟与成本、被否决的方案及原因，以及重新审视该决定的条件。半年后有人问“为什么这么复杂”时，它能给出答案；反过来，“现在可以改得更简单”的依据也来自这里。

深入阅读

代码搭骨架，模型做判断

实践中最常见也最稳健的是工作流与智能体混合的结构。状态转换、业务规则、权限和预算由代码掌握，只把解释、规划、文本生成等难以写成规则的判断交给模型。打个比方，代码铺设铁路，模型决定在各站向乘客提供什么指引。

这一结构的核心规则是分离建议与执行。模型建议“接下来用这些参数调用退款工具”，代码检查该建议在当前状态下是否允许、是否在预算内、是否需要审批，然后才执行。即使模型犯错或受骗，代码检查也能阻止损害。反过来，如果把所有分支都写死在代码中，每次业务规则变化都要改代码。因此，可以让判断区域保持较大自由度，只在出口设置检查站。

一致同意不等于验证

在多智能体或投票配置中，“三个智能体给出相同答案”的说服力比想象中弱。使用相同模型、同类提示词、相同检索结果的智能体，会以同样的方式出错。这称为相关性错误。三个读了同一条假新闻的人异口同声，也不能让假新闻变成事实。

验证的力量来自独立性。需要区分的是依据，而不只是角色。例如，让它们查看不同来源，以不同于生成的方式核实（代码检查、原文对照），或让某个智能体只寻找反面证据。在使用投票结果前，还应在评估集中测量“投票是否确实比单次调用减少了错误”。

使用框架时

智能体框架能够降低起步的难度。然而，Anthropic 指出，框架会引入抽象层，遮蔽其底层的提示词和响应，从而使调试变得困难；即使简单的配置已经足够，也会让人想进一步增加复杂度。为此，Anthropic 建议先从直接调用 LLM API 开始；如果要使用框架，则应理解框架底层的代码。

在实际工作中，判断标准只有一条：对于实际传递给模型的提示词、工具定义和工具结果，必须随时能够查看未经改动的原始内容。请先通过追踪（第 4 章）与请求日志，确保能够看清这些内容。

工作场景

暖途：结构化请求不必每次都叫出租车

旅行平台“暖途”用单个自主智能体实现行程推荐。该智能体在机票、住宿、景点等工具之间来回切换，平均调用工具 23 次，响应需要 40 秒，即使是同一请求，每次路径也不同。

团队对 2,000 条请求日志进行分类。87% 是给定了“城市、时段、预算”的结构化请求，处理步骤几乎都是机票与住宿查询 → 行程草案 → 预算检查；只有 13% 是“适合带父母去的安静地方”这类开放式请求。

有三个替代方案。第一，更换更强的模型；因路径不稳定和成本问题依然存在，被否决。第二，把所有请求改为固定提示词链；在 20 条试验中确认开放式请求的质量下降，被否决。第三，用一次分类调用设置路由，将两类请求分开：结构化请求交给并行查询机票与住宿的固定提示词链和代码预算关卡，只有开放式请求交给设置了最大轮数的智能体。团队选择了第三种方案，并把分类置信度低的请求送往智能体路径，以降低质量损失的风险。

结构化请求的响应时间缩短到 9 秒，每个请求的成本下降超过 60%；开放式请求在评估集上的质量保持不变。ADR 中留下了“开放式请求比例超过 30% 时重新审视结构”的条件。依据并不是“智能体不好”，而是团队一直在用为不可预测的少数请求设计的结构，去处理可预测的大多数请求。

松风能源：拆除接力式智能体结构

城市燃气公司“松风能源”的客户服务质量团队每周编写投诉原因报告。最初的结构由收集、分析、撰写、审核四个智能体接力式依次转交工作。四个智能体都会重新阅读同一批每周约 4,000 条投诉数据，每篇报告的 token 消耗量是单智能体原型的 7 倍。质量分数略高于原型，但对话记录显示，审核智能体几乎原样批准撰写智能体的结论。

团队使用相同的 30 周任务比较了三种结构：原有接力结构、单个智能体，以及混合结构。在混合结构中，收集与分类交给代码和小模型路由器；仅把原因分析按地区分配给执行者并行调查；撰写则采用评分标准明确的评估者-优化者循环，最多 3 次。

结果是，混合结构每份成功报告的成本仅为接力结构的三分之一，质量相同或更好。团队取消了审核智能体，因为查看同一数据的同一模型所给出的“同意”无法起到验证作用，改为用代码将报告数字与源数据对照。被否决的方案是“保持智能体数量，只换成更小的模型”。团队判断，这虽能降低成本，但重复阅读与协调成本这一结构性原因仍然存在。

易错点

1. “智能体总是比工作流更好。” 演示令人印象深刻时，这种结构看起来更聪明。但自主性伴随着成本、延迟与不可预测性。对于步骤固定的工作，工作流更快、更便宜，也更容易复现。
2. “专业智能体越多，质量越高。” 像人类组织一样分工似乎能产生专业能力，但性能提升很大程度上来自多用了 token。在需要大量共享上下文、依赖关系强的任务中，协调成本会超过收益。
3. “用 handoff 转交后，结果会回到原来的智能体。” 它看起来像函数调用，容易令人误解，但 handoff 转移的是控制权。如果需要接收结果并继续使用，应选择 agent-as-tool。
4. “并行运行后，总耗时会缩短到原来的执行者数量分之一。” 很容易用除法估计，但总耗时由关键路径与综合步骤决定。应先画出依赖关系和外部限制。
5. “多个智能体同意，就是正确答案。” 多数表决看起来可靠，但查看相同依据的同一模型会以同样方式出错。验证应使用独立依据或不同方式。
6. “评估者-优化者循环可以一直运行到质量提高。” 似乎反复迭代就能改善，但没有终止条件，成本可能无限增长。应在代码中设置最大迭代次数和改进幅度下限。
7. “工具太多容易混淆，所以应拆分智能体。” 数量显眼，容易被当作原因，但问题往往是工具相似。应先改名称、参数和说明，仍无效时再拆分。

要点速览

查阅官方文档

• Anthropic: Building effective agents — 工作流与智能体的定义、五种模式及适用条件、三项原则、关于框架的建议
• Anthropic: How we built our multi-agent research system — token 倍数与性能因素、委派指令要素、资源投入规模调整
• OpenAI: A practical guide to building agents — 值得考虑使用智能体的任务标准、单个智能体优先、管理者与去中心化模式
• OpenAI Agents SDK: Agent orchestration — LLM 与代码编排、handoff 与 agents as tools
• Google ADK: Workflow agents — 确定性工作流智能体与 ADK 2.0 变更说明

自测

1-1. 用一句话写出区分工作流与智能体的标准，并举出同一系统中同时使用两种方式的例子。

1-2. 并行化的两种变体各自想要获得什么？为什么不把投票作为所有步骤的默认方式？

1-3. 列出编排者把任务交给子智能体时，委派指令应包含的四项要素，并说明缺少其中一项可能产生的一种表现。

1-4. 为避免评估者-优化者循环无限消耗成本，循环外部的代码应具备哪两种机制？

1-5. handoff 与 agent-as-tool 在对话控制权和最终回答主体方面有何不同？

1-6. Anthropic 的 BrowseComp 分析发现，token 用量解释了大部分性能方差。这一观察意味着，在决定是否引入时，应比较什么，而不只是比较总成本？

1-7. 设计一个每周阅读 50 条内部公告、并按部门发送摘要的功能。依次写出最简单的结构、表明该结构已不足的测量信号，以及此时应升级到的下一种结构。

实操练习