<!-- title: 入场费税：多智能体各重烧前缀 -->

# 入场费税：多智能体各重烧前缀

> 把一个任务扇出给 N 个专家智能体，看似并行、看似廉价。实测却给出另一组数字：180 套多智能体配置中，协调开销最高可达基线 token 的 150%；多智能体在复杂任务上常产生比单智能体高出一个数量级（研究给出 15× 量级）的 token。但其中最隐蔽、也最被低估的一笔账，既不是"协调对话"，也不是"输出归并"，而是**每个 Agent 各自重新编码同一份共享前缀**的"入场费"。本期以这一隐藏税种为主线，拆解其缓存机制、给出可落地的省税账本。

## 一、概述：被忽视的那笔 N 倍账

多智能体协作系统（LangGraph、CrewAI、AutoGen、OpenAI Agents SDK、Claude Agent SDK 等）的默认心智模型是：**N 个 Agent 并行 = 1 份工作 ÷ N，成本近似线性**。这个直觉在一个地方系统性破产——**上下文编码**。每条 Agent 调用都要把"任务规格 + 工具定义 + 检索到的文档 + 系统规则"这份**共享前缀**整段重新喂入。提示缓存（prompt caching）本可救场，但缓存是按**精确前缀逐 token 匹配**来命中的；而绝大多数框架把"角色 persona"放在最前面（`You are a Python expert…`），从第 1 个 token 起各 Agent 就分道扬镳，导致**跨 Agent 缓存命中率为零**。

结果是一份 40K token 的共享前缀，扇出到 8 个 Agent，被完整重烧 8 遍 = 320K token 的纯重编码，且大多发生在任何一个 Agent "开始思考"之前。AgentTaxo（ICML 2025）首次把多智能体 token 拆成分项基准，证实这类"结构性冗余"远超表面看到的对话开销。本文给出诊断、数学模型、代码改法与三档缓解方案。

## 二、多维度对比表：拓扑与入场费账本

| 拓扑 / 模式 | 入场费来源 | 跨 Agent 缓存命中 | 重烧倍数（N 体） | 典型框架 | 适配缓解 |
|---|---|---|---|---|---|
| 扇出-归并（fan-out/merge） | 任务规格 + 工具定义 + 检索文档 | 接近 0%（persona 在前） | ≈ N× 全量前缀 | LangGraph map-reduce、CrewAI crew | 前缀重排 + 共享 fork |
| 监督者-工人（supervisor-worker） | 逐轮把工人结果回灌监督者 | 部分命中（监督者侧稳定） | 监督者侧累积膨胀 | LangGraph supervisor、AutoGen GroupChat | 状态外移、摘要交接 |
| 对等网状（peer mesh） | 每对通话各自携带完整上下文 | 几乎 0% | 随边数二次膨胀 | AutoGen、CAMEL | 收敛为星型、限制对话跳数 |
| 黑板 / 共享内存 | 读取共享状态需整段重编码 | 依赖读取窗口 | 每次读取复付 | Letta/MemGPT、shared memory MCP | KV 复用、增量 diff |
| 冗余投票（N 副本取多数） | 同一 prompt 跑 N 次 | 高（同前缀） | N× 但可缓存共享 | 自研 quorum | 固定种子前缀、共享缓存 |
| 单上下文编排（orchestrator-in-one） | 只有一份大上下文 | 内部线性命中 | 1×（无跨体重烧） | Claude/OpenAI 单 Agent 多工具 | 优先选型 |

> 一句话判读：**冗余投票与单上下文编排是入场费的赢家，扇出-归并与网状是输家**。多数"看上去更聪明"的物理多智能体拓扑，恰恰是入场费最重的拓扑。

## 三、深度分析

### 1. 入场费的本质：什么是"共享前缀"

多智能体的每一次 LLM 调用，输入都可拆为两段：**S（Shared prefix）= 任务规格 + 工具定义 + 检索文档 + 全局规则**；**P（Persona suffix）= 角色定位 + 本次具体指令**。S 通常稳定且巨大（实测常 20K–60K token，工具定义与检索语料是大头），P 通常细小且因 Agent 而异（几百到两三千 token）。

入场费 = 编码 S 的成本。单 Agent 自循环里，S 只在首请求写入缓存、后续命中读出，边际成本接近只读折扣价（Anthropic 约 10% 读价、OpenAI 约 50% 折扣）。但在**物理多智能体**里，每个 Agent 是独立会话，S 要被重写 N 遍。AgentTaxo 把多智能体 token 划分为"系统/工具/历史/检索/对话"五类，发现真正干活的"对话+推理"占比常被"系统+工具+检索"三类的结构性重编码挤到次要位置。

### 2. 缓存键的拓扑陷阱：persona 在前，命中清零

提示缓存的核心规则——arXiv《Don't Break the Cache》表述得很干脆："**只有整个前缀逐 token 完全一致时，才发生缓存命中**。"缓存键由"前缀内容 + 模型 + 组织"内容寻址。这意味着：只要两个请求的**开头 token 完全相同**，就能共享同一份 KV 缓存。

问题出在**前缀顺序**。框架默认把 persona 放在最前：

```
[You are a senior Python reviewer …]   <- 第1 token 起，各 Agent 不同
[工具定义 18K] [检索文档 22K] [任务规格]  <- 巨大的共享段，却排在 persona 之后
```

从第 1 个 token 起各 Agent 就分叉，缓存命中区被压缩到 0。一份本可全局共享的 40K 段，退化成 N 份独立缓存写。这是"**写入即 N 倍税**"，且是纯结构问题，与模型能力无关。更隐蔽的是：缓存写入有最小阈值（Anthropic/OpenAI 均 1024 token 起）与 TTL（默认 5 分钟），扇出若是冷启动并发，几乎全是 miss + write，最贵的一档。

### 3. 实测账本：从 150% 到 15×

把分散的研究数据收拢成一张入场费账本：

- **协调税上限 150%**：一份覆盖 180 套多智能体配置的 2025 年 12 月研究发现，协调开销最高可达基线 token 的 150%——Agent"互相说话"的开销超过干活的 token。其中相当比例正是共享上下文的反复搬运与重编码。
- **整体膨胀 15× 量级**：多智能体在复杂任务上被报告产生高达单智能体 15 倍量级的 token，远超"线性并行"的预期，入场费是主因之一。
- **缓存可省 38%–80%**：cache-aware 编排（如开源 agentcache）通过共享缓存前缀与检测缓存断裂，实测**降本 38%+**；生产级提示缓存工程报告可省 **45%–80%** 成本。这条省税上限，恰好量化了入场费的体量。

三个数字叠加的结论：**入场费不是边际项，它是多智能体账单里最该被优化的单项**。

### 4. 扇出账本：N×S 与边际工作的此消彼长

把入场费写成公式，账本立刻清晰。设共享前缀 S、人格后缀 P、单 Agent 实际工作产出 W、扇出数 N、跨体命中 h∈[0,1]：

```
总输入 token ≈ N × [ (1−h)·S + h·(读折扣S) + P ] + 协调 C + 归并 M
入场费占比   ≈ N·S / 总token
```

代入典型值：S=40K、P=1.5K、W≈3K、N=8、h=0（persona 在前）。入场费 = 8×40K = **320K**，而全部 Agent 的"真实工作产出"仅 8×3K = 24K。**入场费是真实工作的 13 倍**。把 h 从 0 抬到 0.9（前缀重排后），入场费塌缩到约 8×(0.1×40K + 0.9×4K) ≈ 60.8K，省去约 260K。这就是"把 persona 挪到后面"这一个动作的杠杆——零代码逻辑改动，纯顺序调整，省下八成入场费。

### 5. 代码示例：从"persona 在前"到"共享前缀在前"

**❌ 朴素写法（缓存断裂，入场费全付）：**

```python
# 每个专家各自拼 prompt，persona 在最前 -> 跨 Agent 缓存命中 0%
def build_prompt(persona, tools, docs, task):
    return [
        {"role": "system", "content": persona},          # 第1token即分叉
        {"role": "system", "content": tools},            # 18K，本可共享却无法命中
        {"role": "system", "content": docs},             # 22K，本可共享却无法命中
        {"role": "user",   "content": task},
    ]

for p in PERSONAS:                 # 扇出 N 个专家
    call_llm(build_prompt(p, TOOLS, DOCS, TASK))   # 各自重烧 40K
```

**✅ cache-aware 写法（共享前缀前置 + fork）：**

```python
# 共享段全部前置，persona 作为最小后缀 -> 跨 Agent 命中共享同一份缓存
SHARED = [
    {"role": "system", "content": GLOBAL_RULES},     # 稳定，缓存锚点
    {"role": "system", "content": TOOLS},            # 18K，首个 Agent 写入后 N-1 个命中
    {"role": "system", "content": DOCS},             # 22K，同上
]

def fork(shared, persona, task):
    # persona 放最后：仅这一小段因 Agent 而异，缓存命中区 = 全部 SHARED
    return shared + [
        {"role": "system", "content": persona},       # 1.5K，唯一分叉点
        {"role": "user",   "content": task},
    ]

results = [call_llm(fork(SHARED, p, TASK)) for p in PERSONAS]
# 第1个请求承担 cache write；后 N-1 个对 SHARED 段全部 cache read（~10% 读价）
```

这段正是 agentcache"fork helpers that share cached prefixes"思路的最小可复现形态。要点有三：**共享段在前、persona 在后、扇出在共享段稳定之后**。实践中再把 SHARED 用 `cache_control`（Anthropic）或自动前缀缓存（OpenAI）标记为可缓存段，并把扇出请求**短时间内并发发出**（落在 5 分钟 TTL 内），命中即可最大化。

### 6. 解法一：精确前缀对齐与共享 fork（KVFlow / agentcache 路线）

学术界已为这条路背书。NeurIPS 2025 的 **KVFlow** 专门研究"LLM 多智能体工作流的高效前缀缓存"，指出多智能体工作流天然带有大量可共享前缀，关键在于**前缀复用调度**：让共享前缀尽可能长、分叉点尽可能靠后、并发请求落在同一缓存窗口。工程侧的 agentcache 则提供可复用原语：缓存断裂检测、共享前缀 fork、命中埋点。

落地清单：①审计所有 Agent 调用，统计"前 N 个 token 是否逐字相同"；②把 GLOBAL_RULES / TOOLS / DOCS 提到最前并固定顺序；③persona 与单次指令压到末尾；④扇出并发控制在 TTL 窗口内；⑤对长 SHARED 段显式标记可缓存。这一档零模型成本、零准确率损失，是性价比最高的"省税"动作。

### 7. 解法二：状态外移与精简交接包

入场费的另一面是**状态在带内（in-band）反复重传**。监督者-工人拓扑里，工人每轮的产出被原文回灌监督者，监督者上下文线性膨胀，相当于每轮重付一份不断变长的入场费。两条解法：

**状态外移（out-of-band）**：把共享状态放进独立存储（MCP 状态服务、KV 内存、向量库），Agent 只携带"指针 + 增量 diff"，读取走 KV 复用而非整段重编码。这对应"黑板/共享内存"拓扑的正确用法——读差异、而非读全量。

**精简交接包（distilled handoff）**：Agent 间传递的不是原始长上下文，而是结构化摘要（决策、状态机、待办）+ 指针。交接包控制在 1–2K token，把"重付入场费"换成"付一小份摘要费"。代价是摘要可能丢信息——需配合校验（呼应"工具结果回流税：截断即丢证"），但总体仍是净赢。

### 8. 解法三：能用单上下文编排，就别上物理多智能体

最彻底的省税是**消除跨体重烧**。单上下文编排器（一个 Agent + 多工具 + 子任务调度）天然只有一份大上下文，内部自循环缓存命中近似线性，**入场费付一次**。Claude Agent SDK、OpenAI Agents SDK 的单 Agent 多工具模式即此路线。

判据很直接：如果子任务**共享同一份世界状态、串行依赖、无需独立 persona**，单上下文几乎总是更省。只有当子任务**真正需要不同模型/不同 persona、可大规模并行、或需要故障隔离**时，物理多智能体才物有所值——且即便如此，也要先做解法一的前缀重排。把"多智能体"当默认架构，本身就是一笔没必要的入场费。

### 9. 变现与训练营评估

入场费税是极佳的训练营选题，因为它**可量化、可复现、可当场省下成本**——这三点正是一线工程师最买账的内容。建议打包成"多智能体成本审计 30 分钟实战"：用 AgentTaxo 思路做 token 分项审计 → 定位入场费占比 → 现场改前缀顺序 → 跑前后账单对比。差异化卖点在于"别人教你怎么搭多智能体，我教你为什么别搭、以及搭了怎么省八成"，避开红海。

产品化方向：一个**多智能体 token 审计与缓存对齐 linter**——静态扫描各 Agent 的 prompt 拼装顺序，标注"前 N token 不一致=缓存断裂"，给出重排建议与预期省税。这在 FinOps / 平台工程赛道有明确付费意愿，且能复用 agentcache 的命中埋点能力，工程量可控。

## 四、多智能体入场费架构图

```mermaid
flowchart TD
    subgraph SHARED["共享前缀 S（稳定·巨大 20K–60K）"]
        R[全局规则 GLOBAL_RULES]
        T[工具定义 TOOLS]
        D[检索文档 DOCS]
    end
    TASK[任务规格]

    subgraph NAIVE["❌ 朴素扇出：persona 在前 → 跨体命中 0%"]
        A1["Agent1: persona+40K 重烧"]
        A2["Agent2: persona+40K 重烧"]
        A3["Agent N: persona+40K 重烧"]
        A1 -.->|"cache miss/write"| KV1[(KV缓存 独立)]
        A2 -.->|"cache miss/write"| KV2[(KV缓存 独立)]
        A3 -.->|"cache miss/write"| KVN[(KV缓存 独立)]
    end

    subgraph FIX["✅ 缓存对齐：共享段在前 + fork"]
        F1["Agent1: 写入共享前缀"]
        F2["Agent2: 命中读 SHARED"]
        F3["Agent N: 命中读 SHARED"]
        F1 -->|"cache write 1次"| KVC[(共享 KV 缓存)]
        F2 -->|"cache read ~10%"| KVC
        F3 -->|"cache read ~10%"| KVC
    end

    SHARED --> NAIVE
    TASK --> NAIVE
    SHARED --> FIX
    TASK --> FIX

    NAIVE -->|"入场费 ≈ N×S 全价"| COST1["账单：320K 重编码"]
    FIX -->|"入场费 ≈ S + N×读折扣"| COST2["账单：约 60K"]

    classDef bad fill:#2b1414,stroke:#ff6b6b,color:#ffd5d5;
    classDef good fill:#142b14,stroke:#51cf66,color:#d5ffe0;
    class A1,A2,A3,KV1,KV2,KVN,COST1 bad;
    class F1,F2,F3,KVC,COST2 good;
```

## 五、推荐方案

- **已有物理多智能体、想立刻降本**：先做"解法一"前缀重排（共享段前置 + persona 后置 + 短窗口并发），零模型成本，预期省 38%–60%。这是任何团队都该先做的 30 分钟动作。
- **监督者-工人 / 网状拓扑、上下文膨胀严重**：叠加"解法二"状态外移 + 精简交接包，把带内重传换成增量 diff，配合摘要校验防丢证。
- **新项目选型**：默认走"解法三"单上下文编排器；只有当子任务需异构模型/真并行/故障隔离时才上物理多智能体，且上线前必做前缀审计。
- **平台/FinOps 团队**：把入场费审计做成 linter 指标，纳入多智能体 CI——跨体缓存命中率、前 N token 一致率、入场费占比三项纳入发布卡。

## 参考来源

1. [AgentTaxo: Dissecting and Benchmarking Token Distribution of LLM Multi-Agent Systems (ICML 2025)](https://icml.cc/virtual/2025/49320) — 首个多智能体 token 分项基准，把系统/工具/检索/历史/对话五类 token 拆解量化。
2. [The Multi-Agent Coordination Tax (AgentMarketCap, 2026)](https://agentmarketcap.ai/blog/2026/04/05/multi-agent-coordination-tax-context-propagation-token-burn) — 180 套配置研究，协调开销最高达基线 150%、Agent 间通信多烧 40%–60% token。
3. [KVFlow: Efficient Prefix Caching for Accelerating LLM-Based Multi-Agent Workflows (NeurIPS 2025)](https://neurips.cc/virtual/2025/poster/119883) — 学术侧论证多智能体工作流前缀复用调度，是共享 fork 方法的理论支撑。
4. [masteragentcoder/agentcache (GitHub)](https://github.com/masteragentcoder/agentcache) — cache-aware 编排工具，共享缓存前缀 fork、检测缓存断裂，实测降本 38%+。
5. [Don't Break the Cache: An Evaluation of Prompt Caching (arXiv)](https://arxiv.org/html/2601.06007v2) — 确立"整段前缀逐 token 完全一致才命中"的缓存键规则，本文前缀重排解法的判据来源。

---

*本文为 AI 智能体实战分析系列内容，聚焦多智能体协作系统的隐藏成本结构。关注「51学通信」，获取更多智能体工程实战拆解。*

> [!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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
