Google 在 ADK（Agent Development Kit）文档里画过一张图——8 种多智能体设计模式，从 Sequential Pipeline 一直排到 Composite Pattern。这张图现在已经是 Agent 工程圈的事实标准，被反复引用、反复改写。
但它真正值得拿来写一篇长文，不是因为"新"——它已经发布半年了。而是因为国内大部分做 AI 应用的人，到现在还在用单体 Agent：一个 prompt 塞到底，一段上下文从头用到尾，模型一变笨整个系统就崩。Google 这张图提供的是一条逃出单体陷阱的路径，而绝大多数团队根本没用上。
这篇文章把这些模式拆开讲清楚——每一种到底适合什么场景，什么情况下千万别选。文章最后再把它放回 2026 年更大的版图——Anthropic 同期的 5 种 Workflow 模式、A2A/MCP 协议栈、以及"Agent 间通信"这条更前沿的赛道。
一、先看清楚地基：所有模式都建在三块原语上
很多文章把这 8 种模式当作平铺的清单来讲，那是看错了层次。Google 这套东西真正的高明之处，是先定义了三个编排原语，然后用这三个原语拼出 8 种模式：
| Sequential（顺序） | ||
| Parallel（并行） | ||
| Loop（循环） |
在这三块原语之上，再叠加 LlmAgent（大脑）和 AgentTool（把子 Agent 包成工具），就拼出了 8 种模式。这件事的工程意义是：你不需要记 8 个新概念，只需要理解 3 个。剩下的都是组合。
Google 还顺手立了一条贯穿全文的工程红线：session.state 是所有 Agent 共享的那块白板。跨 Agent 传数据，本质上就是往这块白板上写 key、读 key。这条红线会贯穿后面所有模式。
二、8 种模式逐个拆解
模式 1：Sequential Pipeline（顺序流水线，别名 the assembly line）
▲ 官方架构图 1/8
机制：用 SequentialAgent把多个 LlmAgent串成一条线。每个 Agent 把自己的输出通过 output_key写进 session.state，下一个 Agent 从这个 key 接力。
适合什么场景：最经典的是数据处理流水线——上游产物天然是下游的输入，步骤固定、可预测。比如：
-
文档处理链
：PDF 解析 → 结构化字段抽取 → 摘要生成 → 多语言翻译。每一步的输出格式都明确，下一步直接消费。 -
客服工单分级
：意图识别 → 情绪判断 → 业务分类 → 路由到对应处理流程。每一步只做一件事，失败时能精确定位是哪一环出错。 -
报表生成
：查数据库 → 数据清洗 → 异常值标注 → 生成文字解读 → 套模板输出。每一步都是确定性的变换。 -
代码任务流水
：需求拆解 → 生成实现方案 → 写代码 → 跑测试 → 生成 commit message。
判断标准（满足越多越适合）：
步骤之间的依赖关系是线性的——B 必须等 A 完成，C 必须等 B 完成。 每一步的输入输出格式能提前定义清楚，不会随运行时变化。 你需要精确的失败定位——第几步出错、为什么错。 步骤数不会动态变化（不是"有时候 3 步有时候 7 步"）。
什么时候别选 Sequential：只要这四条有一条不满足，就该考虑别的模式。最常见的反例：
如果"下一步去哪"取决于上一步的内容（不是单纯的执行完成），该用 Coordinator/Dispatcher。 如果多个步骤互相独立（不需要等彼此），硬串成 Sequential 会白白浪费时间，该用 Parallel。 如果某一步可能失败需要重试或回退，Sequential 不会帮你处理，得叠加 Loop。
我的观点是：Sequential 看起来朴素，但它是唯一一种你可以闭着眼睛调试的模式。任何复杂系统调试不动了，把它拆回 Sequential 都能跑通——这也是 Google 把它列为第一条的原因。如果你现在还在用单体 Agent，第一步永远是先把它拆成 Sequential，别一上来就追 Coordinator 那种花活。
模式 2：Coordinator/Dispatcher（协调者分发，别名 the concierge）
▲ 官方架构图 2/8
机制：一个父级 CoordinatorAgent（本质是个 LlmAgent）+ 一组 sub_agents。ADK 的 AutoFlow机制会根据子 Agent 的 description字段，让 LLM 自动决定路由到哪个子 Agent。
适合什么场景：核心特征是一个入口、多个出口，出口由内容决定。典型场景：
-
客服机器人分流
：用户问什么不知道，可能是账单、可能是技术问题、可能是投诉。Coordinator 看一眼意图，路由到对应专家。 -
企业知识库问答
：同一个问答入口，问题可能涉及 HR 政策、IT 操作、产品文档、法务条款——每个领域一个子 Agent，背后接不同的知识库。 -
多技能助手
：用户说"帮我订下周的机票顺便提醒我开会"，Coordinator 把订机票路由给 TravelAgent，把提醒路由给 CalendarAgent。 -
多租户 SaaS 的请求分发
：不同行业的客户问类似的问题，但答案需要按行业定制——Coordinator 按客户标签路由到对应行业 Agent。
判断标准（满足越多越适合）：
请求类型事先列不全，且会持续增加新类型。 不同类型的请求需要完全不同的处理逻辑（不同的 prompt、不同的工具、不同的知识库）。 路由决策依赖语义理解，不是简单的关键词匹配。 用户希望一个统一入口，不想自己选菜单。
关键 Pro-tip（这是这个模式最容易踩的坑）：description字段就是给 LLM 看的 API 文档。它写得模糊，路由就会错。Google 的原话是"description 即 API 文档"——这不是比喻，是字面意义上的。LLM 在路由时唯一能看到的就是这个字段，你写"处理账单问题"和"处理用户账单查询、退款申请、发票开具、扣费争议"，路由准确率能差一个数量级。
什么时候别选 Coordinator：
如果路由逻辑是确定性的（比如"金额 > 1 万走 A 流程，否则走 B"），直接用 if-else 比 LLM 路由快、准、便宜。Coordinator 的价值是处理"路由规则写不出来"的场景。 如果子任务之间有强依赖（B 要用 A 的结果），Coordinator 不是为了管这种事，应该用 Hierarchical。 如果路由错了代价很高（比如医疗、金融、法律），AutoFlow 的不可控是硬伤，要么叠加 Human-in-the-Loop，要么改回 Sequential。
值得强调的是，这是 8 种模式里唯一一种由 LLM 做运行时决策的模式。Sequential 是开发时写死的，Parallel 是开发时写死的，只有 Coordinator 把"下一步去哪"这个决定权交给了模型。这个差异决定了它的两面性——灵活，但难调试。生产环境里，"路由准确性"会成为最大的工程债——前期 demo 时 90% 准，上线后被真实长尾问题一冲击可能掉到 70%，而 70% 的客服机器人比没有还糟。
模式 3：Parallel Fan-Out/Gather（并行扇出汇总，别名 the octopus）
▲ 官方架构图 3/8
机制：ParallelAgent让多个子 Agent 并发执行，外面再套一个 SequentialAgent接 Synthesizer 做汇总。
适合什么场景：核心特征是同一个对象需要从多个独立维度同时处理。典型场景：
-
代码评审（PR Review）
：一个 PR 同时被 SecurityAuditor（查安全漏洞）、StyleEnforcer（查代码风格）、PerformanceAnalyst（查性能问题）三个 Agent 看，最后 PRSummarizer 合并成一条评审意见。 -
多维度内容审核
：一篇内容同时过政治敏感检查、广告法检查、品牌调性检查、事实核查——四个检查互不依赖，并行能比串行快 4 倍。 -
多源数据采集
：查 5 个新闻源、3 个社交媒体、2 个数据库，互不依赖，并行拉取后由 Synthesizer 去重合并。 -
多视角分析报告
：分析一家公司，同时让财务 Agent 看财报、市场 Agent 看竞品、技术 Agent 看产品、法务 Agent 看合规——最后合并成一份尽调报告。 -
批量任务处理
：100 封邮件要分类，并行跑比串行快几十倍。
判断标准（满足越多越适合）：
子任务之间逻辑上互相独立，不需要等彼此。 总延迟主要来自串行等待，而非单步执行时间。 输出需要合并/对比/去重，不是简单拼接。 你能接受为并行付出更高的资源峰值（同时跑 N 个 LLM 调用）。
关键 Pro-tip（这个坑 Google 单独拎出来讲了）：并行 Agent 共享同一个 session.state，但跑在独立线程里。如果不给每个 Agent 设唯一的 output_key，就会出现竞态条件（race condition）——三个 Agent 同时往 output这个 key 写，最后只剩最后一个的输出。正确做法是分别叫 security_report/ style_report/ performance_report，让 Synthesizer 通过三个独立 key 读三份报告。
什么时候别选 Parallel：
如果子任务之间有数据依赖（B 要读 A 的结果），强行并行会出错。这种场景要么改 Sequential，要么用 Hierarchical 让父 Agent 协调。 如果资源是硬约束（API rate limit、GPU 显存、成本预算），并行会让峰值爆掉。Sequential 慢但便宜，Parallel 快但贵——这是真实工程权衡。 如果 Synthesizer 合并 N 份输出比让一个 Agent 直接做更慢更差（N 很小、任务很简单时常见），并行没有意义。
这件事的工程含义是：并行 ≠ 简单地把 Agent 扔进一个数组。它要求你在设计阶段就把"谁写哪个 key"想清楚，否则跑出来的结果会让你怀疑是不是模型变笨了。很多团队第一次上 Parallel 都踩过 output_key 冲突的坑——症状是"明明跑了三个 Agent，最后只看到一个的输出"，根因就是 state 互相覆盖。
模式 4：Hierarchical Decomposition（层级分解，别名 the russian doll）
▲ 官方架构图 4/8
机制：和 Coordinator 的关键区别——父 Agent 不是把整个请求转交，而是委派任务的一部分，等结果回来继续推理。技术上用 AgentTool(sub_agent)把子 Agent 包装成一个可调用的工具，父 Agent 像调函数一样调它。
适合什么场景：核心特征是任务太大，单 Agent 上下文装不下，或者子流程需要被复用。典型场景：
-
深度研究报告
：ReportWriter 写一份行业报告，需要调研、分析、写作三步。它把"调研"委派给 ResearchAssistant（内部又管 WebSearchAgent 和 SummarizerAgent），拿到结果后自己继续推理和写作。父 Agent 只关心"调研结果是什么"，不关心子流程内部怎么搜、怎么总结。 -
复杂代码任务
：一个 coding agent 接到"给这个项目加单点登录"的需求，它自己拆解架构，把"调研现有 SSO 库"委派给一个 Researcher sub-agent，把"写迁移脚本"委派给 Coder sub-agent，自己负责整合。 -
多步骤业务流程
：贷款审批 Agent 把"查征信"委派给 CreditCheck 子 Agent、"核实收入"委派给 IncomeVerify 子 Agent、"评估抵押物"委派给 CollateralAppraisal 子 Agent，自己综合判断批不批。 -
可复用能力封装
：公司里"发票识别 + 字段抽取 + 校验"这套流程，被报销、付款、税务三个上层 Agent 共同调用——封装成 Hierarchical 子 Agent 后，三处都能复用同一套实现。
判断标准（满足越多越适合）：
父 Agent 的主任务逻辑复杂，但可以拆出几个相对独立的子任务。 子任务有独立价值，能被多个父 Agent 复用（一次性子任务用 Sequential 就行，不必封装成 Tool）。 父 Agent 的上下文窗口紧张，需要把子流程的中间产物隔离掉。 子流程内部有自己的复杂控制流（循环、并行、路由），父 Agent 不需要关心。
关键差异（和 Coordinator 比）：
Coordinator 是"用户问题 → 路由到某个专家 → 专家处理完结束"。 Hierarchical 是"父 Agent 推到一半 → 调用子 Agent 帮忙 → 拿到结果继续推理"。 一句话：Coordinator 是"转交"，Hierarchical 是"调用"。
什么时候别选 Hierarchical：
如果任务单 Agent 就能装下，硬拆成 Hierarchical 是过度设计，反而增加调试复杂度。 如果子任务只被一个父 Agent 用一次，封装成 Tool 的成本高于收益，直接 Sequential 写一起就行。 如果父 Agent 需要实时观察子流程的中间状态（比如流式输出给用户看），Hierarchical 的黑盒化反而是阻碍。
我的观点是：Hierarchical 是 8 种模式里被严重低估的一个。大家都在追 Coordinator 的灵活、Parallel 的快，但实际上 90% 真实业务里"任务太大一个 Agent 装不下"才是主矛盾，Hierarchical 才是正解。判断标准很简单：如果你的 prompt 经常逼近上下文窗口上限，就该考虑 Hierarchical 了。
模式 5：Generator + Critic（生成者+评审者，别名 the editor's desk）
▲ 官方架构图 5/8
机制：SequentialAgent内部管理"草稿-评审"交互，外层套 LoopAgent做质量门。退出条件靠 condition_key="feedback"+ exit_condition="PASS"控制。
适合什么场景：核心特征是输出有明确的对错标准，错了能改。典型场景：
-
SQL 生成
：Generator 出 SQL，Critic 检查语法（编译能不能过）、检查表名/字段是否存在、检查是否符合业务约束，FAIL 就把 feedback 回灌 Generator 重写。这类任务有"运行时报错"作为客观反馈，Critic 不用靠 LLM 主观判断。 -
代码生成 + 单元测试
：Generator 写代码，Critic 跑测试用例，失败就把错误信息回灌。这是最早被验证有效的 Generator+Critic 应用，Cursor、Claude Code 内部都在用。 -
结构化输出校验
：Generator 输出 JSON，Critic 用 schema validator 校验（字段齐全、类型正确、必填项不缺）。校验失败的具体原因回灌，Generator 下一轮就能修对。 -
合规审核
：内容生成后，Critic 检查是否触犯广告法、是否涉及敏感词、是否符合品牌调性，不符合就退回重写。
判断标准（满足越多越适合）：
输出有可机器判定的对错标准（语法、schema、规则、测试通过率）。 错了有具体的修复方向，不是"感觉不对"。 错误率不能容忍（生产环境 SQL 错一条可能毁数据）。 你接受多轮 LLM 调用带来的延迟和成本（典型 2-5 轮收敛）。
核心特征是"条件循环"——评审 PASS 就退出，FAIL 就带反馈重跑。和模式 6 的区别在于：它关注的是正确性（Pass/Fail），不是质量改进。SQL 要么语法对要么错，没有"更好一点"这个中间态。
什么时候别选 Generator+Critic：
如果输出没有客观对错标准（比如写诗、写广告文案、画图），用 Critic 做 Pass/Fail 判断本身就不靠谱——这种场景该用模式 6 的 Iterative Refinement。 如果错误代价可接受（比如推荐内容不准用户划走就是了），加 Critic 的成本超过收益。 如果单次生成已经够准（简单任务、强模型），加 Critic 是浪费 token。 如果 Critic 自己也是 LLM 且和 Generator 是同一个模型，会出现"自己审自己"的同源偏见——它倾向于认为自己的输出是对的。最好用不同模型、或者用规则引擎做 Critic。
这条模式的价值是它把"自我审查"这种本来要靠 prompt 工程硬塞进去的能力，变成了架构层面的一等公民。Generator 可以专心生成，Critic 可以专心挑刺，两个角色职责清晰。特别是涉及数据库写入、代码执行、API 调用这类"错了不可逆"的场景，Generator+Critic 几乎是必备——单次生成哪怕 95% 准确率，5% 的错误在生产环境也会很快累积成事故。
模式 6：Iterative Refinement（迭代精炼，别名 the sculptor）
▲ 官方架构图 6/8
机制：LoopAgent套 [Critic + Refiner] 两个 Agent，用 max_iterations设硬上限。ADK 还支持 Agent 通过 EventActions(escalate=True)主动提前退出。Refiner 用同一个 output_key="current_draft"覆盖式写回。
适合什么场景：核心特征是输出没有客观对错，但有质量高低，且每次都能改进一点。典型场景：
-
长文打磨
：写一篇 5000 字的深度文章，Critic 指出"第三节论证薄弱、第五节例子陈旧、开头不够吸引人"，Refiner 针对性修改。每轮都比上一轮好，但永远没有"PASS"的那一天——靠 max_iterations 强制停。 -
代码性能优化
：Critic 用 profiler 分析热点函数，指出"这段循环可以向量化和、那次内存分配可以省掉"，Refiner 改写。每轮都有提升，但提升幅度递减。 -
Prompt 自我优化
：让 Agent 反复打磨自己的 prompt——Critic 评估"这个 prompt 在测试集上的表现"，Refiner 微调措辞、增删示例。这是 prompt 工程自动化的典型用法。 -
UI/UX 设计稿迭代
：Critic 评估"这个布局的视觉重心、留白、对比度"，Refiner 调整。和 Generator+Critic 的区别是——这里没有"对错"，只有"更好"。 -
谈判/对话策略
：模拟对话场景，Critic 评估"这个回应是否礼貌、是否表达了诉求、是否给对方留台阶"，Refiner 重写。
判断标准（满足越多越适合）：
质量改进是连续光谱，不是二元对错。 每轮改进的边际收益递减（前几轮大、后面小），需要 max_iterations 兜底。 Critic 能给出具体的改进方向，而不是"再好一点"这种空话。 你接受不确定性——不知道第几轮会"够好"，靠预算而不是质量阈值停。
和 Generator+Critic 的本质差异：
Generator+Critic：关注正确性（Pass/Fail），Critic 输出二元判定 Iterative Refinement：关注质量改进（qualitative improvement），Critic 输出改进建议，Refiner 负责落地
什么时候别选 Iterative Refinement：
如果输出有明确对错标准，用 Generator+Critic 更高效——能 PASS 就立刻跳出，不用跑满 max_iterations。 如果单次生成已经够用，迭代是浪费。 如果 max_iterations 设得太高（比如 20 轮），Refiner 可能陷入"为了改而改"的过度优化——把本来不错的稿子改差了。通常 3-5 轮是甜点区。
这两条模式分开看像是孪生兄弟，合起来其实回答了两个不同的问题——"这个输出对吗"和"这个输出能更好吗"。我的观点是：大部分 Agent 系统该用模式 6 的时候都在用模式 5，结果陷入"评审永远过不去"的死循环——因为它们误把"质量不够好"当成了"输出不正确"，Critic 永远说 FAIL，循环永远停不下来。判断标准很简单：你的 Critic 能不能给出 PASS 判定？不能就用 Iterative Refinement，能就用 Generator+Critic。
模式 7：Human-in-the-Loop（人在回路，the human safety net）
▲ 官方架构图 7/8
机制：自定义一个 ApprovalTool，Agent 调用时暂停执行等待人类给 Yes/No。通常用 SequentialAgent(sub_agents=[transaction_agent, approval_agent])串联。
适合什么场景：核心特征是某些操作不可逆或后果重大，必须有人按一下确认。典型场景：
-
金融交易执行
：Agent 算出"该买入 100 万美元某资产"，但在下单前暂停，等交易员确认。Agent 负责准备所有上下文（行情、风险、历史仓位），人负责拍板。 -
生产环境代码部署
：Agent 自动准备好部署脚本、灰度计划、回滚预案，但在"按部署按钮"这步暂停，等 SRE 确认。Agent 干 90% 的活，人只做最后的安全审查。 -
大额支付/转账审批
：B 端财务系统里，Agent 自动准备付款单（金额、收款方、用途、附件齐全），但在提交银行前等财务总监签字。 -
医疗决策辅助
：Agent 给出诊断建议和用药方案，但开处方前必须由医生确认。这是医疗 AI 的合规硬要求。 -
敏感数据操作
：删除用户数据、导出客户名单、修改权限配置——这些操作影响面大，Agent 准备好"将要做的事"，人确认无误才执行。 -
对外发送内容
：Agent 起草了给客户的邮件、给媒体的声明、给监管的报告，发送前等 PR 或法务确认。
判断标准（满足越多越适合）：
操作不可逆（发出去就收不回、删掉就找不到、改了就难撤销）。 后果经济或合规代价大（错一笔交易几十万、错一份报告被罚款、错一次诊断出人命）。 法规或内控硬性要求人工审批（金融、医疗、政府、上市公司财报）。 Agent 准确率够不到"全自动"门槛，但能完成 90% 的准备工作。
关键 Pro-tip：Google 特别强调，这个模式不是让你对每个步骤都暂停。事无巨细都暂停等于退化成 RPA，Agent 的价值就没了。它的正确用法是——只在"不可逆或后果重大"的节点加人工门，让 95% 的低风险步骤自动跑过去，只在关键岔路口叫人。
什么时候别选 Human-in-the-Loop：
如果操作完全可逆且代价小（比如生成一段文案、查一个数据），加人工门是纯负担，反而拖慢整个流程。 如果任务量大到人工审批跟不上（比如每天几万笔小额订单），加人工门会变成瓶颈——这种场景要么用规则引擎做自动审批，要么提高模型准确率做到全自动。 如果审批标准本身模糊（人说不出"什么样的该批什么样的不批"），人工门会变成"全批"或"全拒"的形式主义。
审批节点设计是工程问题，不是哲学问题——好的设计是把人工审批放在"少数关键节点 + 影响面大的操作"上，而不是均匀撒在每个步骤。判断标准很简单：这一步如果错了，需要花多少时间/金钱/信誉才能挽回？挽回成本高于人工审批成本的，就该加门。这条模式在 2026 年有了新的现实意义——随着 Agent 能直接调支付、改生产配置、操作医疗系统，监管和企业内控对"人在回路"的硬性要求只会越来越严。
模式 8：Composite（组合模式，the mix-and-match）
▲ 官方架构图 8/8
机制：把前 7 种模式任意组合，没有新原语，靠 SequentialAgent/ ParallelAgent/ LoopAgent嵌套实现。
适合什么场景：核心特征是真实业务复杂到单一模式搞不定。典型场景：
-
企业级客服系统
：Coordinator 做意图路由 → 技术问题分支触发 Parallel（并行搜文档+查历史工单）→ 结果经 Generator+Critic 循环检查语气和事实一致性 → 涉及退款的分支走 Human-in-the-Loop → 输出。 -
自动化数据分析平台
：Coordinator 路由（描述性分析/诊断性分析/预测性分析）→ 每条分支内部 Sequential（取数 → 清洗 → 建模 → 出图）→ 关键结论走 Generator+Critic 验证 → 最终报告由 Hierarchical 的 ReportWriter 统稿。 -
智能投顾
：用户输入需求 → Coordinator 路由到风险评估/资产配置/择时策略 → 风险评估用 Sequential 跑问卷+建模 → 资产配置用 Parallel 同时评估多类资产 → 最终交易建议走 Human-in-the-Loop → 执行后 Iterative Refinement 持续优化持仓。 -
内容生产流水线
：选题 → Coordinator 路由到不同内容类型（教程/观点/案例分析）→ 每类内部 Sequential 起草 → Iterative Refinement 打磨 → 事实核查用 Generator+Critic → 涉及合规的过 Human-in-the-Loop → 发布。
判断标准（什么时候该上 Composite）：
Google 在这一节给了三条总结性的 Pro-tips：
-
State management is vital
： session.state就是白板，output_key必须用描述性命名。复合模式越复杂，状态管理越要严格——一个 key 写错，整套都会出错且很难调试。 -
Clear descriptions
：路由用的 sub-agent 的 description就是 LLM 的 API 文档。复合模式下，多层级路由的 description 任何一个写模糊，整套都会出错。 -
Start simple
：第一天别上来就搞嵌套循环。先从一条 Sequential 链开始，跑通、调好，再往上叠加复杂度。这是工程纪律，不是技术问题。
什么时候别上 Composite：
如果业务单种模式就能搞定，硬上 Composite 是过度工程。 如果团队没有完整的可观测性设施（trace、metrics、logs），复合模式的调试会变成噩梦——一个错误可能来自任何一层嵌套。 如果还在 demo 阶段，先用最简单的模式跑通核心价值，等真实用户验证后再上复合——别为想象中的复杂度提前付工程成本。
我的观点是：这 8 种模式看起来是清单，本质上是分层的。前 4 种是"拓扑结构"（怎么排），后 3 种是"质量保证机制"（怎么稳），最后 1 种是"组合工程"（怎么搭）。理解了这个分层，比记住 8 个名字重要得多。真实生产系统几乎一定是 Composite——没有谁的业务能被单一模式覆盖。但 Composite 不是起点，是终点：你得先把每个单一模式都跑通过，才知道什么时候该怎么组合。
三、把 Google 的 8 种模式放回更大的版图
只看 Google 这一份指南，会以为 Agent 设计模式是 ADK 独家。但实际上，2026 年这条赛道上至少还有两个重量级玩家在画自己的地图。把它们放一起看，才能看清 Google 这份指南的位置和局限。
Anthropic 的 5 种 Workflow 模式：另一种切法
Anthropic 在自家 Engineering 博客的《Building Effective AI Agents》里，提出了 5 种工作流模式——这比 Google 的 8 种要早，也是业界被引用最多的一份。
| Prompt Chaining | ||
| Routing | ||
| Parallelization | ||
| Orchestrator-Workers | ||
| Evaluator-Optimizer |
值得强调的是两家的切法不同：
-
Google 偏工程实现
——按 ADK 里用什么类、怎么传 state 来分类，所以会把 Generator+Critic 和 Iterative Refinement 拆成两个（因为 exit_condition的语义不同）。 -
Anthropic 偏概念抽象
——按"控制流形态"来分类，所以把两者合一（都是 evaluator-optimizer 的特例）。
我的观点是：Google 的 8 种更贴近"代码该怎么写"，Anthropic 的 5 种更贴近"系统该怎么想"。两者互补，不互斥。真要做架构选型，先用 Anthropic 的 5 种定方向，再用 Google 的 8 种落代码，是目前最顺的工程路径。
另外 Anthropic 还做了一个被低估的概念区分——Workflow vs Agent：
-
Workflow
：开发者预定义控制流，LLM 在固定路径里被调用（前面 5 种都是 Workflow） -
Agent
：LLM 自己决定下一步做什么，控制流是涌现的
这个区分之所以重要，是因为它划清了"可控"和"灵活"的边界。Google 的 8 种模式大部分属于 Workflow，只有 Coordinator/Dispatcher 的 AutoFlow 路由算是 Agent 性质的。生产环境优先选 Workflow，研究探索才用真 Agent——这是 2026 年业界逐渐达成的共识。
A2A vs MCP：Agent 间通信这条新赛道
如果说前面讲的都是"一个系统内部怎么编排多个 Agent"，那么 2026 年冒出来的 A2A 协议把问题推到了新的层面——多个独立部署的 Agent 之间怎么通信。
一句话区分：
-
MCP（Anthropic 主导）
：连接 Agent 和工具/数据。给 Agent 装上"手"。 -
A2A（Google 主导）
：连接 Agent 和 Agent。给 Agent 找到"同事"。
这两条不是竞争关系，是互补关系。一句话总结行业里流传最广的那个比喻——"MCP gives your agent hands; A2A gives your agents colleagues"（MCP 给你的 Agent 一双手，A2A 给你的 Agent 一群同事）。
| 连接什么 | ||
| 连接方向 | ||
| 传输 | ||
| 主导方 | ||
| 典型场景 |
这件事的深远含义是：Google 的 8 种模式解决的是"一个进程内"的协作，A2A 解决的是"跨进程、跨组织"的协作。两者是不同的层次。
值得关注的还有 2025-2026 涌现的其他几个协议——IBM 的 ACP（Agent Communication Protocol，偏边缘场景）、社区驱动的 ANP（Agent Network Protocol）、以及专门管 UI 层状态同步的 AG-UI。这条赛道目前还是战国时代，但方向已经很清楚——Agent 间标准化通信会成为下一代基础设施，重要性可能不亚于当年的 HTTP。
几个值得关注的新理论方向
除了上面两套主流框架，2026 年还有几条更前沿的理论线在发展：
1. Self-Reflection（自我反思）作为独立模式。Reflection 不再被当作 Generator+Critic 的子能力，而是被独立出来——Agent 在执行后主动回顾"我刚才做得怎么样、下次该怎么改"。这是从"被动接受评审"到"主动自我复盘"的升级。
2. Memory-Augmented Agent（记忆增强 Agent）。Anthropic 的 multi-agent research system、腾讯开源的分层记忆方案，都在把"长期记忆"从 prompt 工程问题变成架构问题。Memory 不再是 RAG 的附属，而是和 Sequential/Parallel/Loop 并列的第四类基础设施。
3. Agent-as-a-Tool 的反向应用。不只是 Hierarchical Decomposition 里父 Agent 调子 Agent，2026 年开始出现"把整个 Agent 系统作为另一个 Agent 的工具"——本质上是把 MAS 当成一个可调用的黑盒服务。这是云原生时代的"Agent 微服务化"。
4. Computer-Using Agents（CUA）与上述模式的融合。OpenAI 的 Operator、Anthropic 的 Computer Use，把"操作浏览器/桌面"也变成了一种 Agent 能力。它和 Coordinator 模式结合，催生了"Agent 自己决定什么时候用浏览器、什么时候调 API"的新形态。
我的判断是：未来 12 个月，多智能体架构的核心战场会从"模式设计"转移到"协议标准化"和"记忆架构"上。Google 这 8 种模式是骨架，但骨架之上的"血管"（协议）和"神经"（记忆）才是接下来要补齐的部分。
写在最后
Google 这 8 种模式的价值，不在于它提出了什么新东西——Sequential、Parallel、Loop 这些概念软件工程里用了几十年。它的真正价值是第一次把 AI Agent 的设计模式，从"实验室 demo"和"开源框架黑魔法"里抽出来，变成了一份可以照着搭的工程蓝图。
这件事的隐喻是——Agent 工程正在从"炼金术时代"进入"土木工程时代"。当大家开始统一术语、归并模式、画架构图的时候，这门手艺才算真正立住了。
但我也想泼一盆冷水。这 8 种模式解决的是"如何编排"，没有解决"如何评估"。多 Agent 系统的可靠性、可观测性、失败回放——这些才是 2026 年真正的硬骨头。模式是骨架，骨架之上的"血液系统"（评估与监控）才是接下来真正的难关。
如果只能记一句话，记住这一条——先想清楚状态怎么传（state），再想清楚 Agent 怎么排（pattern），最后才想清楚协议怎么连（protocol）。Google 的指南讲的是中间这一层，但它给的地基和天花板，都值得反复回看。
如果你在做 AI Agent 相关的产品，这 8 张架构图建议存下来当 cheat sheet。不是因为它权威，而是因为它第一次让"多智能体"这件事变得可讨论、可对照、可设计——这本身就是一种进步。
本文所有架构图版权归 Google 原作者所有，原图来自 Google Developers Blog 官方文章，仅作学习交流引用。
