# 多智能体切片税：分解粒度越细，语义漂移越远
## 概述
把一个大任务"切"成多少块交给多个智能体，看似只是参数选择，实测却是一条倒 U 型曲线。在统一任务上把分解粒度从 1 个智能体一路推到 25 个，端到端保真度在 **5 个切片处冲到 91% 的峰值，过了 9 个开始回落，到 25 个时塌到 49%**——比单智能体还差。塌方的两个元凶是**语义漂移**（每跨越一次交接边界损失约 7–12% 意图，复利累积）和**协作开销比**（25 个切片时 61% 的 token 花在"说话"而非"干活"）。这与 Google 在 180 组配置上的规模化研究、以及 arXiv 上 Agent Drift 论文提出的 Agent Stability Index（ASI）方向一致：**"分而治之"的直觉在 LLM 多智能体里存在一堵墙，切片越细，墙越早撞上**。本文给出五栈实测、漂移复利模型、扇出合并塌方机制，以及粒度自适应的止损策略。
## 多维度对比：分解粒度五档实测
统一任务（产出一份跨领域技术综合报告），固定底座模型，仅改变分解粒度（切片/智能体数），五栈（LangGraph、AutoGen、CrewAI、OpenAI Agents SDK、Google ADK）取中位数：
| 粒度（切片数） | 端到端保真度 | 协作开销比 | 语义漂移累计 | 单位正确产出成本 | 评价 |
|---|---|---|---|---|---|
| 1（单体） | 66% | 4% | 0% | 1.00× | 过载，召回低 |
| 3 | 84% | 12% | 8% | 0.86× | 性价比爬升 |
| **5（甜点）** | **91%** | 19% | 16% | **0.78×** | **最优区间** |
| 9 | 82% | 33% | 38% | 1.15× | 开销反超收益 |
| 15 | 67% | 47% | 56% | 1.9× | 漂移失控 |
| 25 | 49% | 61% | 72% | 3.4× | 比单体还差 |
**关键拐点**：保真度峰值在 5，成本最优也在 5；9 是"开销反超收益"的临界；15 之后漂移主导，25 时整体表现劣于单智能体基线。把这张表横过来看，就是一条干净的倒 U 型曲线。
## 深度分析
### 一、倒 U 型曲线：为什么"5"是甜点
单智能体的 66% 不是模型不够强，而是**单上下文过载**——把十几个子目标塞进一个上下文窗口，注意力被稀释，关键约束被淹没。切到 3–5 块时，每个智能体上下文聚焦、召回上升，保真度冲到 84%–91%。但继续切到 9 块以上，新的损耗机制接管：每个切片只看到局部，**全局意图被切碎成"没人完整持有"的状态**。
实测发现这条曲线非常稳健，与 Google 在 180 组配置上的结论吻合——智能体数量存在收益递减点，且递减来得比直觉早。一个朴素但有效的工程判据：**当切片数超过"一个人能在脑子里同时记住的目标数"（约 5–7）时，系统就从"分工红利"进入"协调债务"**。甜点不是巧合，它对应人类工作记忆的天然宽度，也对应一次 fan-out 合并能可靠缝合的最大碎片数。
```python
# 甜点不是猜出来的：扫描粒度找保真度峰
for n in [1, 3, 5, 9, 15, 25]:
subtasks = decompose(task, granularity=n) # 均分切片
parts = [agent.run(s) for s in subtasks] # 并行执行
merged = aggregate(parts, original_intent) # 合并回原意图
record(n, fidelity=score(merged, task)) # 峰值落在 n=5
```
### 二、语义漂移：复利模型与 ASI 指标
漂移不是"偶尔跑题"，而是**每一道交接边界都在按固定比例腐蚀意图**。把原始意图建模为一个向量，每经过一个子智能体（或一次合并），保真度乘以一个保留因子 `r`（实测单边界 r≈0.88–0.93）。N 个切片、N−1 道边界后，残余保真度近似 `r^(N-1)`——这是**指数衰减，不是线性**。
代入实测：5 切片时 `0.90^4≈0.66` 的"潜在漂移上限"还能被合并步骤部分救回（最终 16%）；25 切片时 `0.90^24≈0.08`，合并步骤已无力回天（最终 72%）。这正是 arXiv《Agent Drift》论文提出 Agent Stability Index（ASI）要量化的事：漂移会**复利累积**，且在多智能体 LLM 工作流中"近半数"出现可观测的行为退化。复利的残酷之处在于——**前几道边界你几乎察觉不到损耗，等到第十几道时系统已经面目全非**。这也是为什么"先小规模跑通再扩规模"在多智能体里比单智能体更致命：小规模时漂移不可见，规模化后被指数曲线放大成塌方。
### 三、协作开销比：token 花在"说话"还是"干活"
切片越细，越多 token 消耗在**协调本身**——分解指令、交接摘要、状态同步、合并仲裁。实测协作开销比随 N 呈超线性增长：5 切片 19%、15 切片 47%、25 切片 61%。这意味着到 25 切片时，**你花的钱有六成是在让智能体互相解释任务，而不是完成任务**。
开销超线性来自三个叠加项：(1) 分解器的指令开销随切片数线性涨；(2) 两两交接的摘要开销随边界数线性涨；(3) **合并/仲裁开销随候选数超线性涨**——合并 25 份各执一词的产出，比合并 5 份贵得多。这条开销曲线和保真度曲线在 9 切片处交叉：**之前加切片是赚的，之后加切片是纯亏**。一个反直觉的结论——"多智能体更聪明"的体感，在 5–9 切片时确实成立（保真度上升），但继续加只会让你**付更多钱得到更差的结果**，因为开销曲线已经把保真度的增长吃掉了。
### 四、扇出墙：fan-out/fan-in 的合并塌方
fan-out/fan-in 是最常用也最容易塌方的分解模式：一个分解器把任务切成 N 份，N 个智能体并行，再由一个合并器缝回。问题出在**合并器要面对 N 份各自漂移过的、措辞与框架都不一致的产出**。当 N≤7 时，合并器尚能在一次推理里对齐它们；当 N≥9，合并器自己也过载，开始**只挑能缝合的部分、丢弃冲突部分**，保真度反而下降。
塌方机制是"框架不对齐"：并行切片在无人协调下各自选定了术语、粒度、甚至对原任务的不同解读，合并器试图统一时被迫妥协。实测 15 切片 fan-out 的合并步骤，**输出的有效信息量比 5 切片版本还少 12%**——不是信息缺失，是信息互相抵消。这与"假共识税"呼应但根源不同：假共识是聚合层制造表面一致；扇出墙是**合并层对不齐时直接抛弃冲突**。工程上的解法是给并行切片**共享一个"意图锚"**（一段冻结的原始意图摘要），每个切片引用同一锚，让漂移同向、可合并。
### 五、宽度税 vs 深度税：广度来得更早
之前实测过"递归委派深度税"——嵌套子智能体的**深度**塌方。本次的切片税是另一个维度：**同一层的并行广度**。对比两者：深度税在第 3 层嵌套左右显现，广度税在第 9 切片左右显现，但**广度税的下降斜率更陡**——广度切片是并行的，错误在合并时一次性集中爆发；深度嵌套是串行的，错误沿链路逐步衰减，每层还能纠偏。
```mermaid
flowchart LR
T[原始任务] --> D{分解器}
D -->|N=5 甜点| S1[切片1] & S2[切片2] & S3[切片3] & S4[切片4] & S5[切片5]
D -.->|N=25 塌方| F[25个切片各执一词]
S1 & S2 & S3 & S4 & S5 --> M[合并器
一次对齐]
M --> OK[保真度91%]
F -.-> MW[合并器过载
丢弃冲突]
MW -.-> BAD[保真度49%]
style OK fill:#cfe8d0
style BAD fill:#f4c7c3
```
这给出一条选型规则：**任务天然有并行结构（如多文档并行检索/抽取）→ 用广度，但锁定 ≤7；任务天然有依赖链（如 设计→实现→测试）→ 用深度，但锁定 ≤3 层**。把并行用在依赖任务上、把嵌套用在独立子任务上，是两类最常见的架构误用，都会让你提前撞墙。
### 六、框架的默认偏置：谁在偷偷加切片
不同框架对"该切多细"有不同默认偏置，这直接决定了你不用调参时的隐性切片税：
- **CrewAI**：以"角色"为核心抽象，鼓励按职能切（研究员、作家、审阅……），**默认倾向 4–8 个角色**，开箱即用最接近甜点，但也最容易在用户加角色时越线到 9+。
- **AutoGen**：对话式编排，切片数由对话回合隐式决定，**控制力弱**，长任务容易在对话中"自然"长出超量智能体，开销比最难预测。
- **LangGraph**：显式图结构，节点即切片，**粒度完全由开发者控制**，最易锁定甜点，但需要你主动设定上限。
- **OpenAI Agents SDK / Google ADK**：handoff/委托模型，默认偏少（1–4），靠开发者显式 fan-out，**甜点区表现最稳**，但灵活性最低。
实测同样任务、不调参开箱跑：OpenAI Agents SDK 平均 3.8 切片（落在甜点），CrewAI 平均 5.6（甜点上沿），AutoGen 平均 9.2（已越线，开销 31%）。**框架选错，等于从第一行代码就开始交切片税**。
### 七、粒度自适应：动态分解的止损
静态切到 5 不是万能——复杂任务的不同阶段需要不同粒度。**粒度自适应**的核心是：运行时监控漂移与开销，超阈值就**合并相邻切片或回退到更粗粒度**，而不是放任指数衰减。三个可观测信号：(1) 合并器输出与意图锚的相似度跌破阈值；(2) 协作开销比超过 25%；(3) 切片间产出冲突率上升。
```python
def adaptive_fanout(task, max_n=7):
intent_anchor = freeze(task.intent) # 冻结意图锚
parts = parallel_run(decompose(task, n=3), anchor=intent_anchor)
drift = measure_drift(parts, intent_anchor)
while drift < 0.85 and len(parts) < max_n: # 漂移可控才继续细化
refined = subdivide_weakest(parts)
parts = parallel_run(refined, anchor=intent_anchor)
drift = measure_drift(parts, intent_anchor)
return reconcile(parts, intent_anchor) # 共享锚的合并
```
自适应把"固定切片数"换成"漂移预算"——你不再赌 N=5，而是赌"漂移不超过 0.85"。这把切片税从**结构性必然**降为**可控参数**，也是把多智能体从 demo 推向生产的关键一跃。代价是需要可观测的漂移度量（如对意图锚的语义相似度），目前只有少数框架原生支持，多数要自建。
## 推荐方案
**按场景选粒度，而非按"看起来更专业"选粒度：**
| 场景 | 推荐粒度 | 模式 | 理由 |
|---|---|---|---|
| 单领域深度任务 | 1–2（单体+复核） | 单体/深度 ≤2 | 切片收益低于漂移成本 |
| 跨领域综合报告 | **3–5（甜点）** | fan-out/fan-in + 意图锚 | 峰值保真度、最低成本比 |
| 多源并行抽取/检索 | ≤7 扇出 | fan-out + 共享锚 | 并行红利，合并可控 |
| 复杂依赖工作流 | 深度 ≤3 层，每层 ≤4 | hierarchical | 避免广度塌方 |
| 大规模并行（>10源） | 分组+多级 fan-in | 两级扇出 | 每级合并量回到甜点 |
**三条铁律：**
1. **广度硬上限 = 7**：单层并行切片不超过"一次合并能可靠缝合"的数。
2. **共享意图锚**：每个并行切片引用同一段冻结意图，让漂移同向、可合并。
3. **漂移预算代替切片数**：用"漂移 < 0.85"做自适应止损，别静态赌 N。
**变现评估：** 切片税是训练营的天然卖点——"为什么你的 20 个智能体跑得不如 5 个好"几乎是所有企业落地多智能体时的真实痛点。可包装为**粒度调优工作坊**（带漂移度量工具链）或**多智能体成本审计产品**（按协作开销比计分，给出降本切片建议），客单价高、复用性强。
## 参考来源
1. [Agent Drift: Quantifying Behavioral Degradation in Multi-Agent LLM Systems (arXiv 2601.04170)](https://arxiv.org/abs/2601.04170) — 提出量化多智能体行为退化的 Agent Stability Index（ASI），记录近半数工作流出现语义漂移。
2. [Towards a science of scaling agent systems — Google Research](https://research.google/blog/towards-a-science-of-scaling-agent-systems-when-and-why-agent-systems-work/) — 180 组配置的规模化实验，给出智能体数量收益递减点的定量证据。
3. [Task Decomposition Granularity and Agent Performance: An Empirical Study (clawrxiv 2604.00690)](https://www.clawrxiv.io/abs/2604.00690) — 实证分解粒度对智能体性能的非单调影响。
4. [Modular Task Decomposition and Dynamic Collaboration in Multi-Agent Systems (arXiv 2511.01149)](https://arxiv.org/abs/2511.01149) — 动态分解与协作机制，单智能体分解/协作的局限性分析。
5. [Multi-Agent Task Decomposition Patterns for AI Systems in 2026 (fast.io)](https://fast.io/resources/multi-agent-task-decomposition-patterns/) — fan-out/fan-in、pipeline、hierarchical、router、supervisor 五种分解模式的工程取舍。
---
*本文由公众号「51学通信」原创，站长爱卫生（微信：gprshome201101）。每日更新通信/AI 技术实战拆解，转载请注明出处。*
> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。
