一文解析多 Agent 编排架构模式全景

MULTI-AGENT DNA · 多 Agent 编排基因解码

LangGraph 、CrewAI 、Swarm ...10 种多 Agent 编排 DNA 的基因级拆解

从 Token 膨胀 15× 的物理约束到 N² 冲突的数学诅咒，从 64% 基准上单 Agent 持平多 Agent 的反直觉真相到一张选型决策公式

Orchestrator-Worker / Graph State Machine / Blackboard / Swarm / Hierarchical / Pipeline / Fan-out-Fan-in / Group Chat / Handoff / Magentic

KEY TAKEAWAY

1. 多 Agent 编排不是"越多越好"。Google Research 在 180 种 Agent 配置的横评中发现：单 Agent 在 64% 的 benchmark 上与多 Agent 系统持平。多 Agent 平均只增加 2.1 个百分点的准确率，但成本翻倍。Token 膨胀从单 Agent 的 4× 到多 Agent 的 15×（Anthropic 数据）。

2. 10 种编排模式的 DNA 可以拆解为三个基因轴：控制拓扑（集中 vs 分布）、通信模式（直接 vs 共享 vs 委托）、状态管理（无状态 vs 有状态 vs Checkpoint）。每个模式在这三个轴上的坐标决定了它的延迟、成本和适用场景。

3. 选型不是"哪个模式最好"，而是用一道公式算出你的场景应该落在哪个区间：编排价值 = 领域隔离收益 − (Token 膨胀 + 延迟累积 + N² 冲突成本)。当编排价值为负时，单 Agent + 更多工具就是最优解。

阅读提示：本文面向 AI 应用架构师 / 后端工程师 / 技术决策人。不做基础科普，假设你已了解 ReAct、Function Calling、StateGraph 等基础概念。预计阅读 20 分钟。

TABLE OF CONTENTS

01 · 为什么多 Agent 编排突然成了 2026 年 AI 工程的核心战场

02 · 物理约束钉在墙上：Token 膨胀 15×、延迟累积公式、N² 冲突诅咒

03 · 10 种编排模式的 DNA 拆解：三个基因轴定义全部拓扑

04 · 甜点区划分：按 Agent 数量 × 任务结构的四层 Bracket

05 · 没人谈的工程陷阱：64% 的 Benchmark 上多 Agent 打不过单 Agent

06 · 五种核心架构模式深度拆解：从代码原语到生产部署

07 · 五种补充模式与组合策略：Pipeline 到 Magentic 的完整光谱

08 · 选型公式与单位经济学：三个场景的成本对账

09 · Checklist：12 项编排架构决策清单

01 · 为什么多 Agent 编排突然成了 2026 年 AI 工程的核心战场

2025 年到 2026 年中，三股力量把多 Agent 编排推到了 AI 工程的舞台中央。第一，OpenAI Swarm（2024.10）和 LangGraph（2024 持续迭代）相继发布，把"多 Agent"从论文概念变成了可落地的代码原语。第二，企业级 AI 应用的复杂度爆炸——合规审查需要跨 5 个文档库推理、客户支持需要跨 3 个系统查询，单个 Agent 的上下文窗口和工具数量已经到了极限。第三，Microsoft 在 2026 年 2 月发布的 Azure Architecture Center 指南正式把 Agent 编排归纳为 6 种设计模式（Sequential、Concurrent、Group Chat、Handoff、Magentic），给了工程团队一个标准化的分类语言。

但"多 Agent"的热度掩盖了一个关键问题：什么时候该用多 Agent，什么时候不该用？Google Research 在 180 种 Agent 配置的横评中给出了一个让社区相当热闹的答案：在 64% 的 benchmark 上，单 Agent（配更多工具）与多 Agent 系统表现持平。多 Agent 平均只增加 2.1 个百分点的准确率，但成本翻倍。Princeton NLP 的独立研究得出了几乎相同的结论。

这篇文章要做的事情是：把 10 种编排模式的物理约束（Token、延迟、冲突）全部量化，把每种模式的三个 DNA 基因轴拆解清楚，然后给出一道选型公式——让架构师能算出自己的场景该落在哪个区间。

02 · 物理约束钉在墙上：Token 膨胀 15×、延迟累积公式、N² 冲突诅咒

在讨论"哪种编排模式更好"之前，先把多 Agent 系统的三道物理约束钉在墙上。后续的每一个选型结论都必须追溯到这张表里的数字。

图 1 · Token 膨胀与 N² 冲突——从单 Agent 的 4× 到多 Agent 的 15×，5 Agent 即产生 10 个冲突对

三道约束的推导公式：

# ① Token 膨胀模型

Token_total = Token_base × M_agent × M_coordination × M_tools

# Token_base = 单次 LLM 调用的基础 tokens（prompt + response）

# M_agent = Agent 数量

# M_coordination = 编排开销系数（Pipeline=1.2, Orchestrator=1.5, GroupChat=3.0）

# M_tools = 工具描述膨胀系数（每 Agent 10K-60K tokens, 60-80% 静态）

# 典型值：3 Agent Orchestrator, M_coord=1.5, M_tools=2.0

Token_total = 10K × 3 × 1.5 × 2.0 = 90K tokens（vs 单 Agent 10K = 9× 膨胀）

# ② 延迟累积模型

Latency_total = Σ(L_i) + H × L_hop

# L_i = 第 i 个 Agent 的处理延迟（典型 500ms–2s）

# H = 跳数（Agent 间通信次数）

# L_hop = 每跳延迟（序列化 + 网络 ~200–500ms）

# Pipeline 4 Agent：4 × 500ms + 3 × 300ms = 2.9s

# Hierarchical 3 层：3 × 1s + 4 × 500ms = 5.0s

# GroupChat 5 轮 × 3 Agent：15 × 500ms = 7.5s

# ③ N² 冲突诅咒

Conflicts = N(N − 1) / 2

# N=3 → 3 conflicts（可管理）

# N=5 → 10 conflicts（需冲突解决策略）

# N=10 → 45 conflicts（几乎不可行，除非严格隔离）

# 这就是为什么 Microsoft 建议 GroupChat ≤3 Agent

图 2 · 延迟模型——Pipeline/Orchestrator 2–5s 最快，Magentic/Swarm 10–60s+ 不可预测

结论：多 Agent 编排的三道物理约束——Token 膨胀 15×（Anthropic）、延迟逐跳累积（每跳 200–500ms）、N² 冲突诅咒（10 Agent = 45 冲突）——决定了"Agent 数量"不是线性扩展，而是在某个阈值后边际收益为负。Augmentcode 的研究指出，第 6/7 个 Agent 引入的开销通常超过其带来的价值。

数据来源：Anthropic Token 膨胀数据（via Augmentcode）、Beam AI Pipeline 延迟基准、Microsoft Azure Architecture Center 2026.02。

03 · 10 种编排模式的 DNA 拆解：三个基因轴定义全部拓扑

表面上看，10 种编排模式各不相同。但如果把每种模式拆解到三个基因轴上，它们的 DNA 差异就变得极其清晰：

图 3 · 三个基因轴——控制拓扑 × 通信模式 × 状态管理，10 种模式的 DNA 坐标一目了然

基因轴 1 · 控制拓扑（集中 vs 分布）：谁做决策？是单一编排者统一调度，还是每个 Agent 自主决策？集中式（Orchestrator-Worker、Pipeline、Graph State Machine）可调试性高但有单点故障；分布式（Swarm、Mesh、Blackboard）容错性高但难以调试；混合式（Hierarchical、Group Chat、Magentic）在两者之间取平衡。

基因轴 2 · 通信模式（直接 vs 共享 vs 委托）：Agent 之间怎么交换信息？直接通信（Mesh：点对点连接）延迟最低但连接数爆炸；共享介质（Blackboard：黑板读写、Group Chat：共享对话线程）解耦但带宽受限；委托传递（Handoff：控制权转移、Pipeline：输出传递）最简洁但信息可能丢失。

基因轴 3 · 状态管理（无状态 vs 有状态 vs Checkpoint）：中间结果存在哪里？无状态（Swarm、Handoff）每次交互从零开始，简单但无法恢复；有状态（Graph State Machine、Hierarchical）维护全局状态，可回溯但状态同步成本高；Checkpoint（LangGraph 的 Checkpointing、Magentic 的 Task Ledger）在关键节点持久化，支持断点续跑但写入有放大效应。

三个基因轴的交叉组合理论上可以产生 3 × 3 × 3 = 27 种模式，但实际工程中只有 10 种是稳定的——其余组合要么因为状态同步成本过高而不可行，要么因为控制拓扑和通信模式不兼容（比如"分布式控制 + 委托通信"在没有黑板的情况下无法实现）。这 10 种稳定组合就是多 Agent 编排的完整基因图谱。

结论：10 种编排模式的 DNA 可以用三个基因轴完全描述——控制拓扑（集中/分布/混合）、通信模式（直接/共享/委托）、状态管理（无状态/有状态/Checkpoint）。LangGraph 的基因是"集中 + 委托 + Checkpoint"，CrewAI 是"混合 + 委托 + 有状态"，Swarm 是"分布 + 共享 + 无状态"。选型不是选框架，是选基因组合。

04 · 甜点区划分：按 Agent 数量 × 任务结构的四层 Bracket

用 Agent 数量（横轴）和任务结构（纵轴：确定性 vs 探索性）做四层 Bracket，每层有明确的最优编排模式：

图 4 · 选型决策树——从"单 Agent 是否够用"出发，按 Agent 数量和任务结构推导最优模式

BRACKET 1 · 1–3 AGENTS · 确定性任务

"单 Agent + 更多工具可能就够了"

Agent 数量：1–3 个。 Token 膨胀：4×–8×（可控）。 N² 冲突：0–3 个（可忽略）。 最优模式：单 Agent + 工具（如果可行）→ Pipeline（如果步骤确定）→ Orchestrator-Worker（如果需要并行专业分工）。 框架映射：LangGraph 简单图、CrewAI Sequential。 判定：Google Research 的 64% 基准——在大多数简单任务上，单 Agent 配更多工具与 2–3 Agent 系统持平。先试单 Agent。

BRACKET 2 · 3–5 AGENTS · 半结构化任务

"编排的黄金区间"

Agent 数量：3–5 个。 Token 膨胀：8×–15×（需要控制策略）。 N² 冲突：3–10 个（需要冲突解决机制）。 最优模式：Graph State Machine（复杂工作流）→ Fan-out/Fan-in（并行分析）→ Group Chat（≤3 Agent 的辩论/审查）。 框架映射：LangGraph 复杂图、AutoGen GroupChat、CrewAI Hierarchical。 判定：这是多 Agent 编排 ROI 最高的区间——领域隔离的收益明确超过 Token 膨胀和延迟成本。但需要严格控制 Agent 数量在 5 以内。

BRACKET 3 · 5–20 AGENTS · 跨域复杂任务

"需要层级隔离或黑板架构"

Agent 数量：5–20 个。 Token 膨胀：15×+（必须用层级摘要压缩）。 N² 冲突：10–190 个（必须用隔离拓扑消除）。 最优模式：Hierarchical（组织式分工）→ Blackboard（知识发现）→ Magentic（开放式问题）。 框架映射：CrewAI Hierarchical Process、自定义 Blackboard、Microsoft Agent Framework Magentic。 判定：这个区间必须用层级或黑板来避免 N² 冲突。扁平的 Orchestrator-Worker 在 5+ Agent 时编排者上下文窗口溢出。Hierarchical 通过树形委托把全局 N² 冲突拆解为多个局部 N'² 冲突。

BRACKET 4 · 20+ AGENTS · 大规模探索

"只有 Swarm 和 Hierarchical 能活"

Agent 数量：20+ 个。 Token 膨胀：无法全局管理（必须完全分布式或严格层级隔离）。 N² 冲突：190+ 个（扁平拓扑完全不可行）。 最优模式：Swarm（大规模探索/爬取）→ Hierarchical（大规模组织模拟）。 框架映射：OpenAI Swarm 模式、自定义 Hierarchical 集群。 判定：20+ Agent 的场景极其罕见。如果你的设计需要 20+ Agent，先问自己：是不是应该拆成多个独立的 3–5 Agent 子系统？

05 · 没人谈的工程陷阱：64% 的 Benchmark 上多 Agent 打不过单 Agent

Google Research 和 Princeton NLP 的两项独立研究得出了一个让多 Agent 社区不安的结论：在大多数基准测试上，单 Agent（配足够的工具）的表现与多 Agent 系统持平甚至更好。

Google Research 测试了 180 种 Agent 配置（不同的编排模式、不同的 Agent 数量、不同的模型组合），发现单 Agent 在 64% 的 benchmark 上与最优多 Agent 配置的表现差距在统计误差范围内。多 Agent 系统平均只增加 2.1 个百分点的准确率，但成本（Token 消耗 + LLM 调用次数）翻倍。arXiv 2604.02460 的研究更直接——在多跳推理任务上，单 Agent 的表现优于多 Agent 系统。

这些发现不是否定多 Agent，而是揭示了一个被严重低估的工程陷阱：多 Agent 的编排开销（Token 膨胀、延迟累积、冲突解决）在很多场景下超过了领域隔离带来的收益。具体来说：

陷阱 1 · Token 膨胀吃掉精度增益：多 Agent 增加的 2.1pp 准确率，被 15× 的 Token 膨胀抵消。假设 GPT-4o 定价 2.5/M input tokens，单 Agent 每次查询消耗 10K tokens（0.025），多 Agent 消耗 150K tokens（

陷阱 2 · 编排者错误级联：Orchestrator-Worker 模式中，编排者的一个错误判断会触发所有 Worker 的并行重试，成本放大 2–3×。而单 Agent 没有这个级联风险。

陷阱 3 · 第 6/7 个 Agent 的边际价值为负：Augmentcode 的分析指出，每增加一个 Agent，编排开销（上下文传递、冲突解决、状态同步）的增长速度超过其专业分工带来的价值。拐点通常在第 5–6 个 Agent。

那么什么时候多 Agent 确实优于单 Agent？研究表明有三个条件（满足任一即可）：

条件 A · 安全边界需求：不同 Agent 操作不同的系统（数据库、支付、用户数据），需要权限隔离。单 Agent 持有所有权限是安全风险。

条件 B · 并行专业化：任务需要同时从多个独立视角分析（如金融分析：基本面 + 技术面 + 情绪面 + ESG），并行比串行快 75%。

条件 C · 上下文窗口溢出：任务的总上下文超过单个 Agent 的窗口容量（128K–1M tokens），必须拆分为多个 Agent 各自处理子上下文。

结论：多 Agent 编排的默认假设应该是"不需要"——除非你的场景满足安全边界、并行专业化、或上下文溢出三个条件中的至少一个。2.1pp 的准确率增益不值 2× 的成本。正确的决策流程是：先用单 Agent + 更多工具试，不够再加第二个 Agent，再加第三个——每次加 Agent 都要验证边际收益是否为正。

06 · 五种核心架构模式深度拆解：从代码原语到生产部署

10 种模式中有 5 种是生产环境中最常见的核心模式。逐一拆解每种模式的代码原语、生产特性和典型陷阱。

图 5· 五种核心模式架构拓扑——Hub-and-Spoke / DAG / 黑板 / 蜂群 / 树形

模式 1 · Orchestrator-Worker · "一个老板，多个打工仔"

DNA：集中控制 + 委托通信 + 无状态 Worker 代码原语：一个 Supervisor Agent 持有任务分解 prompt + Worker 列表。收到任务 → LLM 决定调用哪个 Worker → Worker 返回结果 → Supervisor 聚合。LangGraph 的 Supervisor 模式和 AutoGen 的 SelectorGroupChat 都是这种模式。 生产特性：延迟 2–5s（单次编排 + Worker 执行）。Worker 可水平扩展。成本比单 Agent 低 40–60%（Worker 用小模型，编排者用强模型）。 致命限制：编排者是单点故障和上下文瓶颈。4+ Worker 的结果聚合可能超出编排者的上下文窗口。编排者的一次错误判断触发 2–3× 成本级联。 选型信号：子任务独立、可并行、需要不同专业知识。典型场景：客服分流、多源数据聚合、代码生成 + 测试 + 审查。

模式 2 · Graph State Machine · "一张图定义所有可能的路径"

DNA：集中控制 + 委托/直接通信 + Checkpoint 状态 代码原语：StateGraph 定义节点（Agent 或函数）和边（条件路由）。TypedDict 存储全局状态，Reducer 函数决定状态如何合并。支持有环图（Agent 可以回到之前的节点）。LangGraph 是这种模式的标杆实现——用 Pregel 超步模型执行，支持 interrupt_before/interrupt_after 做 Human-in-the-loop。 生产特性：延迟 3–10s（取决于图深度）。Checkpoint 支持断点续跑和状态回溯。状态可持久化到 PostgreSQL/SQLite。可观测性最好——图的执行路径可以完全可视化。 致命限制：图必须在部署时预定义，无法运行时动态发现新路径。状态同步有 Checkpoint 写入放大（参考之前 LangChain vs LangGraph 文章中的 15× 放大系数）。复杂图的调试需要理解图拓扑。 选型信号：工作流有明确的分支和循环、需要断点续跑、需要 Human-in-the-loop 审批。典型场景：审批流程、数据管道、复杂客服路由。

模式 3 · Blackboard · "一块共享黑板，Agent 自愿贡献"

DNA：混合控制 + 共享通信 + 有状态 代码原语：三个组件——黑板（共享内存/数据库）、控制器 Agent（决定哪个知识源 Agent 下一个行动）、知识源 Agent（各自持有专业能力，读写黑板）。Agent 之间不直接通信，所有信息交换通过黑板。源自 1970s 的 Hearsay-II 语音识别系统，2025 年被 arXiv 2510.01285 引入 LLM 多 Agent 系统。 生产特性：延迟 5–15s（黑板读写开销）。Agent 可热插拔（新增/移除知识源不影响其他 Agent）。arXiv 论文报告 13%–57% 的端到端成功率提升。Google Research 在数据科学信息发现任务中使用此模式。 致命限制：黑板是单点瓶颈和一致性风险（并发写入冲突）。控制器的决策质量直接决定系统表现。调试需要回放黑板的完整写入历史。 选型信号：多种异构知识源需要协作、Agent 数量较多（10–20）、问题没有预定义的解决路径。典型场景：数据科学探索、复杂信息抽取、多源情报融合。

模式 4 · Swarm · "蜂群：没有老板，只有局部规则"

DNA：分布控制 + 共享通信（黑板）+ 无状态 代码原语：两个核心概念——Handoff（Agent 间交接控制权）和 Routine（每个 Agent 的局部行为规则）。没有全局编排者，每个 Agent 只看到自己的输入和黑板状态，基于局部规则决定是自己处理还是交接给谁。OpenAI Swarm 是教育性实现。 生产特性：延迟可变（取决于收敛条件）。容错性最高（任何 Agent 崩溃不影响其他）。可水平扩展到理论无限的 Agent 数量。HCLTech 报告案件解决速度提升 40%。 致命限制：几乎不可调试（需要分布式追踪 + 黑板回放）。收敛条件必须精心设计，否则无限循环。无法保证事务一致性或严格顺序。上下文在交接中逐次丢失。 选型信号：最优路径未知、需要大规模探索、容错比确定性更重要。典型场景：竞品情报收集、大规模网页爬取、开放式客户支持路由。

模式 5 · Hierarchical · "组织架构的数字孪生"

DNA：混合控制 + 委托通信（垂直）+ 有状态 代码原语：树形结构。顶层 Manager 持有全局目标，将任务分解为子目标委托给中层 Supervisor。每个 Supervisor 管理一组底层 Worker。每层增加一个抽象层——Manager 思考战略，Supervisor 思考战术，Worker 执行具体操作。CrewAI 的 Hierarchical Process 和 IBM 的大规模企业 Agent 系统都是这种模式。 生产特性：延迟 6–12s（3 层累积，每层 +2–4s）。上下文管理最好——没有单个 Agent 持有全部上下文，每层只看到自己需要的信息。分支故障隔离（一个 Supervisor 失败不影响其他分支）。支持 20+ Agent。 致命限制：信息在层间摘要时丢失（"Manager 让 Supervisor 做 X，Supervisor 让 Worker 做 Y，但 Worker 不知道 X 的全局目标"）。延迟逐层累积，3 层最少 6 秒。管理成本随层级增长。 选型信号：Agent 数量 20+、需要组织式分工、需要上下文隔离。典型场景：大型企业流程自动化、跨部门合规审查、模拟组织架构的 AI 团队。

07 · 五种补充模式与组合策略：Pipeline 到 Magentic 的完整光谱

除了上面 5 种核心模式，还有 5 种在特定场景中不可或缺的补充模式：

组合策略是生产环境中最常见的实践。Microsoft Azure Architecture Center 明确指出："不要试图让一个工作流适配单一模式——不同阶段可以用不同模式。"最常见的组合是：Pipeline（数据预处理）→ Fan-out/Fan-in（并行分析）→ Orchestrator-Worker（结果聚合）→ Group Chat（质量审查）。另一种高频组合是 Graph State Machine 作为骨架 + Handoff 做动态路由 + Checkpoint 做断点续跑。

结论：10 种编排模式不是互斥的选项，而是一个光谱。从最简单的 Pipeline（固定线性）到最复杂的 Magentic（自适应规划），复杂度和成本逐层递增。生产环境的最佳实践是"组合模式"——用 Graph State Machine 做骨架，在特定节点嵌入 Fan-out/Fan-in、Handoff 或 Group Chat。但每次组合都要验证：增加的模式带来的精度增益是否超过其编排开销。

08 · 选型公式与单位经济学：三个场景的成本对账

把选型逻辑浓缩为一道公式：

图 6 · 三个场景 ROI——客服 +2.77/query（多 Agent）、知识库 −0.13（单 Agent）、合规 +

# 编排价值公式

V_orchestration = G_isolation − (C_token + C_latency + C_conflict)

# G_isolation = 领域隔离收益（安全边界、专业化精度、上下文管理）

#   量化方式：多 Agent vs 单 Agent 的准确率差 × 每次错误的业务成本

#   典型值：2.1pp × $50/错误 = $1.05/query（Google Research）

# C_token = Token 膨胀成本

#   = (M_multi - M_single) × tokens_base × $/M_tokens

#   典型值：(15× - 4×) × 10K × $2.5/M = $0.275/query

# C_latency = 延迟业务成本

#   = (latency_multi - latency_single) × $/秒（用户流失、SLA 罚金）

# C_conflict = N² 冲突解决成本

#   = N(N-1)/2 × P_conflict × $/resolution

#   P_conflict = 每对冲突实际发生的概率（典型 5-20%）

# 决策规则：

# V > 0 → 多 Agent 有正 ROI → 选对应 Bracket 的模式

# V < 0 → 单 Agent + 更多工具更优

# V ≈ 0 → 用安全边界和可维护性做 tie-breaker

用三个场景代入公式：

场景 A · 客户支持路由（3 Agent Orchestrator-Worker，5K 查询/天）

G_isolation：领域隔离（账单/技术/账户三个专业 Worker）使首次解决率提升 15pp × 20/重复来电 = 3.00/queryC_token：3 Agent × M_coord=1.5 × 10K × 2.5/M = 0.11/query（vs 单 Agent 0.025）→ 膨胀 0.085C_conflict：3 Agent = 3 对 × 10% 冲突率 × 0.50/解决 = 0.15/queryV = 3.00 − (0.085 + 0.15) = 2.77/query → 正 ROI判定：Orchestrator-Worker 明确有正 ROI。年化收益 2.77 × 5,000 × 365 ≈ 5.05M/年。

场景 B · 内部知识库问答（单 Agent + RAG，1K 查询/天）

G_isolation：简单问答任务，多 Agent 准确率提升仅 2.1pp × 5/错误 = 0.105/queryC_token：3 Agent 编排膨胀 = 0.085/queryC_conflict：3 Agent = 0.15/queryV = 0.105 − (0.085 + 0.15) = −0.13/query → 负 ROI判定：单 Agent + RAG 更优。多 Agent 的编排成本超过精度收益。年化节省 0.13 × 1,000 × 365 ≈ 47.5K/年。

场景 C · 金融合规审查（5 Agent Hierarchical，50 查询/天）

G_isolation：合规审查需要 5 个专业领域（反洗钱/KYC/市场风险/操作风险/报告），多 Agent 准确率提升 8pp × 500/合规遗漏 = 40/queryC_token：5 Agent Hierarchical = 0.15/queryC_conflict：层级隔离后实际冲突对 = 5 × 2 对/层 × 10% × 2/解决 = 2.0/queryV = 40 − (0.15 + 2.0) = 37.85/query → 强正 ROI判定：Hierarchical 是明确最优解。高业务风险（500/遗漏）使精度增益远超编排成本。年化收益 37.85 × 50 × 365 ≈ 691K/年。

结论：选型公式的核心不是"哪种模式最好"，而是"在你的场景下，领域隔离收益是否超过编排成本"。场景 A（客服）V = +$2.77 → 多 Agent。场景 B（知识库）V = −$0.13 → 单 Agent。场景 C（合规）V = +$37.85 → 多 Agent。关键输入变量是"每次错误的业务成本"——这个值越高，多 Agent 的 ROI 越强。

09 · Checklist：12 项编排架构决策清单

如果你正在为一个新项目选择多 Agent 编排架构，以下 12 项可以逐步推导出最优方案：

1 先试单 Agent：64% 的 benchmark 上单 Agent 够用。给单 Agent 加更多工具、更好的 prompt、RAG——只有这些都不够时才考虑多 Agent

2 验证三个准入条件：安全边界需求？并行专业化需求？上下文窗口溢出？至少满足一个才进入多 Agent 设计

3 算编排价值公式：V = G_isolation − (C_token + C_latency + C_conflict)。V < 0 → 停止，回到单 Agent

4 确定 Agent 数量 Bracket：1–3 → Bracket 1，3–5 → Bracket 2，5–20 → Bracket 3，20+ → Bracket 4。数量决定了可选模式范围

5 选择控制拓扑：确定性任务 → 集中式（Pipeline/Graph）。探索性任务 → 分布式（Swarm）。混合 → 层级/黑板

6 选择通信模式：Agent 间需要紧耦合反馈 → 直接通信（Mesh）。松耦合知识共享 → 黑板。简单委托 → 输出传递

7 选择状态管理：需要断点续跑 → Checkpoint（LangGraph）。需要全局一致性 → 有状态（Blackboard）。简单无副作用任务 → 无状态

8 检查 N² 冲突：计算 N(N−1)/2，超过 10 对就必须引入层级隔离或黑板解耦。5 Agent 是扁平拓扑的实际上限

9 控制 Token 膨胀：为每个 Agent 选择匹配任务复杂度的模型（不是所有 Agent 都需要 GPT-4o）。工具描述缓存复用，减少 60–80% 的静态 Token

10 设计终止条件：每个编排模式都需要明确的终止条件——最大轮数、质量阈值、预算上限。Group Chat 尤其需要防止无限辩论循环

11 建立可观测性：每个 Agent 调用记录 trace（输入/输出/Token/延迟/决策理由）。分布式编排没有 trace = 无法调试

12 渐进式增加复杂度：从单 Agent → 加第二个 Agent → 加第三个。每次加 Agent 都验证边际精度增益是否为正。不要在第一天就设计 10 Agent 系统

结语

多 Agent 编排不是"更高级的 AI 工程"——它是"更贵的 AI 工程"。15× 的 Token 膨胀、逐跳累积的延迟、N² 的冲突诅咒，这些物理约束决定了多 Agent 编排只在特定条件下有正 ROI。Google Research 的 64% 基准和 2.1pp 精度增益是一盆冷水：在大多数场景下，把投入多 Agent 编排的精力用来优化单 Agent 的工具集和 prompt，回报率更高。

但当你的场景确实满足准入条件——安全边界、并行专业化、或上下文溢出——10 种编排模式提供了完整的基因库。选型不是"LangGraph vs CrewAI vs Swarm"的框架之争，而是"集中 vs 分布、直接 vs 共享 vs 委托、无状态 vs 有状态 vs Checkpoint"的基因组合选择。框架只是基因的载体。

对于 AI 应用架构师来说，核心行动项不是"学会所有 10 种模式"，而是掌握那道选型公式：V = G_isolation − (C_token + C_latency + C_conflict)。算出 V 的值，Bracket 和模式自然浮现。然后从单 Agent 起步，逐步增加复杂度——每次加一个 Agent，验证边际收益是否为正。

FINAL TAKEAWAY

默认答案 = 单 Agent + 更多工具 → 64% 的 benchmark 上与多 Agent 持平（Google Research）

准入条件 = 安全边界 ∨ 并行专业化 ∨ 上下文溢出 → 至少满足一个才进入多 Agent 设计

选型公式 = V = G_isolation − (C_token + C_latency + C_conflict) → V > 0 才值得编排

10 种模式 = 三个基因轴（控制拓扑 × 通信模式 × 状态管理）的全部稳定组合 → 选基因不选框架

REFERENCES

[1] Google Research, "Towards a Science of Scaling Agent Systems"（2025）— 180 种 Agent 配置横评，单 Agent 在 64% 基准上持平多 Agent，+2.1pp 精度

[2] Microsoft Azure Architecture Center, "AI Agent Orchestration Patterns"（2026.02）— 6 种编排模式分类、Group Chat ≤3 Agent 建议、Magentic 模式定义

[3] arXiv 2510.01285, "LLM-Based Multi-Agent Blackboard System"（2025）— Blackboard 模式 LLM 化，13%–57% 端到端成功率提升

[4] Beam AI, "6 Multi-Agent Orchestration Patterns for Production"（2026）— Pipeline 延迟基准（950ms 开销）、N² 冲突公式、Princeton NLP 64% 数据

[5] Augmentcode, "Multi-Agent Cost Compounding: Why 3 Agents Cost 10×"（2026）— Token 膨胀 15×、工具描述 60–80% 静态、自验证 2.3× 开销

[6] LangChain, "Choosing the Right Multi-Agent Architecture"（2025）— 四种架构模式（Subagents/Skills/Handoffs/Router）、40–50% Token 节省数据

#MultiAgent #LangGraph #CrewAI #Swarm #AgentOrchestration #编排DNA

本文数据截至 2026 年 6 月，所有数值来自公开论文、官方架构指南与行业基准测试。欢迎指正。