别急着上多 Agent：三家官方架构指南的共识与分歧

别急着上多 Agent：三家官方架构指南的共识与分歧

先说结论，可能会得罪一些做多 Agent 框架的人。

过去一年，Google、Anthropic、Microsoft 各自发布了一套 Agent 架构指南：Google 有 ADK 加 Cloud Architecture Center 的设计模式，Anthropic 有《Building Effective Agents》和 2026 年的 Managed Agents，Microsoft 有 Azure Architecture Center 加 Agent Framework。三家的用词、API、生态各不相同，但把三份文档并排读下来，会发现它们收敛到了同一句话：

能用单 Agent 就不要上多 Agent；能用确定性流水线就不要让模型编排流程。

这不是巧合。三家的商业模式不同（卖云的、卖 API 的、卖企业软件的），他们在这件事上的口径一致，说明这条原则是从工程实践的坑里挖出来的，不是营销话术。本文把三套体系摆在一起对照，看它们在哪里重合、在哪里分歧，再算一笔 token 账解释为什么这条原则成立。

本文提纲

  1. 三家是怎么切概念的
  2. 拓扑对照表：名字不同，骨架相通
  3. 表面共识下的三个真分歧
  4. 为什么默认单 Agent：算一笔 token 账
  5. 反方证据：Cognition 说连多 Agent 都别用
  6. 多 Agent 的甜点区和失效边界
  7. 一棵决策树
  8. 协议层：MCP 连工具，A2A 连 Agent

三家是怎么切概念的

Google ADK：原语三类，模式十二种

Google 的 ADK 先把实现原语分成三类：LLM Agent（模型自主决策）、Workflow Agent（SequentialAgent / ParallelAgent / LoopAgent，流程由代码写死）、Custom Agent（自定义逻辑）。在这个基础上，Cloud Architecture Center 列出 12 种设计模式：

  • 单 Agent：Single-agent（一个模型 + 工具 + 系统提示，官方建议作为起步默认）和 ReAct（Thought → Action → Observation 循环，直到完成或达到迭代上限）
  • 确定性多 Agent：Sequential（固定顺序流水线，经 session.state 传数据）、Parallel（并发扇出再 gather）、Loop（重复子序列直到退出条件）、Review and critique（Generator + Critic 对错门）、Iterative refinement（循环打磨同一份草稿，追求质量而非 Pass/Fail）
  • 动态多 Agent：Coordinator / Dispatcher（中心 LLM 按意图路由到专家）、Hierarchical task decomposition（多层父子拆解，Coordinator 的递归形态）、Swarm（Dispatcher 只引入场，Agent 彼此移交，没有持续监督者）
  • 特殊：Human-in-the-loop（高风险动作在检查点等人审批）、Custom logic（代码条件分支，混用上述模式）

注意这里的分界线：确定性多 Agent 里，“下一步做什么”是代码决定的；动态多 Agent 里，这个决定权交给了模型。这条线是整套体系里最重要的一条。

Anthropic：workflow 与 agent 分家，再加脑手分离

Anthropic 的《Building Effective Agents》做了更彻底的概念切分：Workflows 是 LLM 和工具走代码写死的路径，Agents 是 LLM 自己决定下一步和工具用法。名字上有本质区别，不是规模区别。

然后给出 7 个可组合积木，由简到繁：

  1. Augmented LLM — 检索 + 工具 + 记忆（可用 MCP）
  2. Prompt chaining — 固定子任务串联，中间可加程序化 gate
  3. Routing — 先分类再交给专用提示 / 模型 / 流程
  4. Parallelization — Sectioning（独立子任务并行）和 Voting（同一任务跑多次再聚合）
  5. Orchestrator-workers — 中心模型动态拆任务、委派 worker、汇总，前提是子任务事先未知
  6. Evaluator-optimizer — 生成器与评估器循环，直到达标
  7. Autonomous Agent — 工具循环 + 环境反馈，可在检查点问人，必须设停止条件

2026 年的 Managed Agents 又给出运行时三分法，强调接口稳定、实现可换：Brain = Claude + harness（无状态循环）、Hands = sandbox / 工具（execute(name, input) → string）、Session = 追加式事件日志（独立于上下文窗口）。落地方式四选一：手写 Messages 循环、Tool Runner、Claude Agent SDK、Claude Managed Agents。

核心建议只有一句：尽量简单，先直连 API，框架能不用就不用。

Microsoft：先选复杂度层级，再谈编排

Microsoft 的 Azure Architecture Center 先让你选复杂度层级：

  1. Direct model call — 一次提示，无 Agent
  2. Single agent with tools — 企业默认
  3. Multiagent orchestration — 只有单 Agent 扛不住时才上

多 Agent 层级内置五种编排：Sequential（线性管道，顺序写死）、Concurrent（扇出/扇入，独立多视角或投票）、Group chat（星形，manager 选发言者，含 maker-checker）、Handoff（网状，当前 Agent 决定移交给谁，典型场景是分诊）、Magentic（规划经理维护 task ledger，动态增删重排任务，面向无预定路径的开放问题）。

HITL 在 Microsoft 体系里是叠加能力（工具审批、RequestInfo），不是单独一种拓扑。实现上，Workflow 是 executor + edge 的有向图，按 Pregel superstep 批量同步执行——这是从图计算领域借来的执行模型，和 LangGraph 的思路同源。

拓扑对照表：名字不同，骨架相通

把三家的模式按拓扑结构对齐，重合度一目了然。空单元格表示该厂商没有把它作为一等公民单独命名。

通用类型 Google Anthropic Microsoft
增强型单模型 Single-agent / ReAct Augmented LLM → Autonomous Agent Single agent with tools
顺序流水线 Sequential / SequentialAgent Prompt chaining Sequential
并行扇出 Parallel / ParallelAgent Parallelization（sectioning / voting） Concurrent
路由分发 Coordinator / Dispatcher Routing Handoff（含 triage）
动态拆解委派 Hierarchical task decomposition Orchestrator-workers Magentic（task ledger）
生成-评审循环 Review and critique / Loop / Iterative refinement Evaluator-optimizer Group chat maker-checker
群体辩论 Swarm（全互连移交） — Group chat / roundtable
人在环中 Human-in-the-loop 检查点 / 权限门 HITL overlay（审批、RequestInfo）
自定义图 Custom logic / CustomAgent 组合上述模式，少用框架 WorkflowBuilder 图 + Pregel superstep

顺序、并行、路由、编排器-工人、生成-评审这五类，三家全部覆盖。差异主要在命名，以及三家各自的“特产”：Microsoft 把 Magentic 和 Group Chat 做成一等公民，Google 单独列出 Swarm 与 ReAct，Anthropic 更强调 workflow 与 agent 的概念分界以及后来的 brain / hands / session 解耦。

表面共识下的三个真分歧

分歧一：编排决策放在哪一层。 Google 的 Workflow Agent 和 Microsoft 的 Sequential/Concurrent 都把流程控制留在代码层，但 Magentic 把规划权整个交给一个 manager 模型；Anthropic 则干脆说框架本身都是负担，直连 API 手写循环就够。三家对“代码编排 vs 模型编排”的分界线画的位置不一样。

分歧二：群体拓扑是否值得做成一等公民。 Google 的 Swarm 和 Microsoft 的 Group chat 都为多 Agent 平等协作提供了正式抽象，Anthropic 的积木清单里没有对应物。这不是遗漏——Anthropic 的工程团队公开说过，他们观测到的大多数多 Agent 失败案例恰恰发生在 Agent 互相干扰的场景。

分歧三：运行时是否值得重新设计。 Anthropic 的 brain / hands / session 三分法把 Session 独立成追加式事件日志，明确脱离上下文窗口而存在，这是在为“长任务 + 可恢复执行”铺路。Google 和 Microsoft 还停留在“编排器 + 状态传递”的框架视角。谁对要看未来两年的实践，但方向上 Anthropic 押的是 Agent 会变成一种长期运行的基础设施，而不是一次性的请求-响应。

为什么默认单 Agent：算一笔 token 账

原则要有数据支撑才不是教条。Anthropic 在《How we built our multi-agent research system》里给过一组硬数字：

  • Agent（单 Agent）比普通对话多消耗约 4 倍 token；多 Agent 系统比普通对话多消耗约 15 倍 token
  • 在 BrowseComp 基准上，token 消耗量单项就能解释 80% 的性能方差；加上工具调用次数和模型选择，三个因素合计解释 95%
  • 多 Agent 研究系统（Opus lead + Sonnet subagents）在内部研究评估上比单 Agent Opus 高出 90.2%

前两个数字是警告，第三个数字是诱惑。合起来的结论是：多 Agent 的性能提升很大程度上是拿 token 堆出来的，而且堆得极不稳定——token 用得多不一定好，但想好通常得多花 token。你在为“探索的宽度”付费，不是为“智能”付费。

失败模式同样值得看。Anthropic 自己列出的多 Agent 事故清单包括：简单查询触发 50 个 subagent、为不存在的信源无限搜索、Agent 之间互相刷更新把上下文污染、任务描述太模糊导致多个 subagent 重复干同一件事、模型选了 SEO 内容农场而不是权威信源。每一个都是编排复杂度带来的税。

还有一个容易被忽略的调试成本。确定性流水线出错了，你能定位到是哪一步、哪个输入；模型编排出错了，你要面对的是一次性的、不可复现的决策链。工程团队对前者的处理是日常，对后者的处理是玄学。这解释了为什么三家的指南都把“动态编排”放在阶梯最顶端而不是最常用的位置。

反方证据：Cognition 说连多 Agent 都别用

如果觉得三家厂商（都卖多 Agent 能力）的警告还不够狠，Cognition（Devin 背后的公司）2025 年那篇《Don't Build Multi-Agents》是更极端的反方。作者 Walden Yan 给出两条原则，建议直接排除任何违反它们的架构：

  1. 共享完整上下文——要共享就共享完整的 Agent trace，不是单条消息摘要
  2. 行动携带隐式决策——互相冲突的决策会产生坏结果

他的论据是上下文碎片化：父 Agent 拆任务时，子 Agent 拿到的只是任务描述，丢掉了原对话的细节。他举的例子是让 subagent 各自做 Flappy Bird 的部件，结果一个做了超级马里奥风格的背景，另一个做了和背景完全不搭的鸟。即使共享了上下文，并行的子 Agent 也看不到彼此当前的工作，各自基于没对齐的假设行动。

Cognition 的替代方案是单线程线性 Agent：所有动作共享同一条上下文，每个决策都被之前的全部决策约束。长任务的解法不是拆 Agent，而是加一个专门做上下文压缩的模型（他们为此微调过小模型）。如果要用 subagent，参考 Claude Code 的用法——串行调用、只回答边界清晰的问题，目的是把调研过程隔离在主 Agent 的历史之外，延长可用 trace 长度。

Cognition 的立场比三家厂商激进得多，但它和厂商指南在方向上一致：多 Agent 不是默认架构，是需要用充分理由换取的例外。

多 Agent 的甜点区和失效边界

批评归批评，Anthropic 的多 Agent 研究系统毕竟跑赢了单 Agent 90.2%。关键是搞清楚它赢在哪里。

甜点区：广度优先、可并行的信息搜集类任务。 典型例子是“列出标普 500 所有 IT 公司的董事会成员”——几十个独立方向，互不依赖，天然适合扇出。信息量超过单个上下文窗口、需要大量异构工具的场景也在此列。Anthropic 的实测里，一次并发 3-5 个 subagent、每个 subagent 并发 3 个以上工具调用，把研究时间缩短了最多 90%。

失效区：需要共享上下文的任务。 Anthropic 点名了编码——多个 Agent 改同一份代码库，决策互相冲突的风险远大于并行的收益。Cognition 的 Flappy Bird 例子是同一类问题。Heavy inter-agent 依赖的任务也不行，Agent 之间的通信带宽撑不起实时的假设对齐。

一个实用的判断方法：问自己“这个任务的子任务之间，需要看到彼此的中间结果吗”。答案是“不需要”，多 Agent 是杠杆；答案是“需要”，多 Agent 是负债。

另外有一个反直觉细节值得单独说：Microsoft Learn 的 Magentic 官方文档里明说，这个编排基于 Magentic-One 论文的固定提示词设计，在原始设计之外的场景“未经验证”（原文：it is untested how well the Magentic orchestration will perform outside of the original Magentic-One design）。官方文档自己给自家旗舰模式打折扣，这在厂商文档里相当罕见。选型时把这句话读进去。

一棵决策树

把三家的建议压缩成一棵可执行的决策树：

MERMAID_BLOCK_0

自底向上读这棵树，就是三家的共同建议：永远从最简单的形态起步，只有在下一层被证明扛不住时才上移一层。每一层上移都带来确定性的丢失和成本的倍增，要用具体的失败证据（单 Agent 上下文爆了、延迟不可接受、工具列表撑爆系统提示）来换，不要用架构上的审美偏好来换。

Anthropic 还给了一条实现层面的忠告，值得抄进工程手册：给 subagent 的任务描述必须包含四要素——明确的目标、输出格式、工具指引、任务边界。他们观测到的大部分重复劳动和搜索浪费，源头都是任务描述的模糊。

协议层：MCP 连工具，A2A 连 Agent

模式之外还有一层，三家现在也基本对齐了：协议。

MCP（Model Context Protocol）解决工具连接——Agent 怎么发现和调用外部能力，中间的 schema 发现和状态管理是真正的瓶颈，传输层反而不是。A2A（Agent-to-Agent Protocol）解决 Agent 连接——不同实现、不同厂商的 Agent 之间怎么互相发现和委派。Google ADK 的 RemoteA2aAgent 把远程 A2A 服务当成本地 sub-agent 使用，是这两个协议咬合的例子。

协议层的存在意义和架构层的保守主义是配套的：模式层面能简则简，是因为复杂性被下沉到了协议层标准化。工具接入不需要每个框架自己发明一遍，Agent 互操作也不需要。当你发现自己在给“两个 Agent 怎么说话”写胶水代码时，先查协议有没有已经解决。

参考文档与链接

你的项目上过多 Agent 吗？是真实需要还是架构冲动？评论区聊聊你的选择和代价。觉得有用点个在看，让更多人少踩坑。

作者: itech001
来源: 公众号：AI人工智能时代(the-ai-era)
网站: https://www.theaiera.top/
关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top

本文首发于 AI人工智能时代，转载请注明出处。

posted @ 2026-09-07 08:50  iTech  阅读(11)  评论(0)    收藏  举报