把一个任务扇出给 N 个专家智能体，看似并行、看似廉价。实测却给出另一组数字：180 套多智能体配置中，协调开销最高可达基线 token 的 150%；多智能体在复杂任务上常产生比单智能体高出一个数量级（研究给出 15× 量级）的 token。但其中最隐蔽、也最被低估的一笔账，既不是"协调对话"，也不是"输出归并"，而是每个 Agent 各自重新编码同一份共享前缀的"入场费"。本期以这一隐藏税种为主线，拆解其缓存机制、给出可落地的省税账本。
多智能体协作系统（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 多工具 | 优先选型 |
一句话判读：冗余投票与单上下文编排是入场费的赢家，扇出-归并与网状是输家。多数"看上去更聪明"的物理多智能体拓扑，恰恰是入场费最重的拓扑。
多智能体的每一次 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 划分为"系统/工具/历史/检索/对话"五类，发现真正干活的"对话+推理"占比常被"系统+工具+检索"三类的结构性重编码挤到次要位置。
提示缓存的核心规则——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，最贵的一档。
把分散的研究数据收拢成一张入场费账本：
三个数字叠加的结论：入场费不是边际项，它是多智能体账单里最该被优化的单项。
把入场费写成公式，账本立刻清晰。设共享前缀 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 挪到后面"这一个动作的杠杆——零代码逻辑改动，纯顺序调整，省下八成入场费。
❌ 朴素写法（缓存断裂，入场费全付）：
# 每个专家各自拼 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）：
# 共享段全部前置，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 内），命中即可最大化。
学术界已为这条路背书。NeurIPS 2025 的 KVFlow 专门研究"LLM 多智能体工作流的高效前缀缓存"，指出多智能体工作流天然带有大量可共享前缀，关键在于前缀复用调度：让共享前缀尽可能长、分叉点尽可能靠后、并发请求落在同一缓存窗口。工程侧的 agentcache 则提供可复用原语：缓存断裂检测、共享前缀 fork、命中埋点。
落地清单：①审计所有 Agent 调用，统计"前 N 个 token 是否逐字相同"；②把 GLOBAL_RULES / TOOLS / DOCS 提到最前并固定顺序；③persona 与单次指令压到末尾；④扇出并发控制在 TTL 窗口内；⑤对长 SHARED 段显式标记可缓存。这一档零模型成本、零准确率损失，是性价比最高的"省税"动作。
入场费的另一面是状态在带内（in-band）反复重传。监督者-工人拓扑里，工人每轮的产出被原文回灌监督者，监督者上下文线性膨胀，相当于每轮重付一份不断变长的入场费。两条解法：
状态外移（out-of-band）：把共享状态放进独立存储（MCP 状态服务、KV 内存、向量库），Agent 只携带"指针 + 增量 diff"，读取走 KV 复用而非整段重编码。这对应"黑板/共享内存"拓扑的正确用法——读差异、而非读全量。
精简交接包（distilled handoff）：Agent 间传递的不是原始长上下文，而是结构化摘要（决策、状态机、待办）+ 指针。交接包控制在 1–2K token，把"重付入场费"换成"付一小份摘要费"。代价是摘要可能丢信息——需配合校验（呼应"工具结果回流税：截断即丢证"），但总体仍是净赢。
最彻底的省税是消除跨体重烧。单上下文编排器（一个 Agent + 多工具 + 子任务调度）天然只有一份大上下文，内部自循环缓存命中近似线性，入场费付一次。Claude Agent SDK、OpenAI Agents SDK 的单 Agent 多工具模式即此路线。
判据很直接：如果子任务共享同一份世界状态、串行依赖、无需独立 persona，单上下文几乎总是更省。只有当子任务真正需要不同模型/不同 persona、可大规模并行、或需要故障隔离时，物理多智能体才物有所值——且即便如此，也要先做解法一的前缀重排。把"多智能体"当默认架构，本身就是一笔没必要的入场费。
入场费税是极佳的训练营选题，因为它可量化、可复现、可当场省下成本——这三点正是一线工程师最买账的内容。建议打包成"多智能体成本审计 30 分钟实战"：用 AgentTaxo 思路做 token 分项审计 → 定位入场费占比 → 现场改前缀顺序 → 跑前后账单对比。差异化卖点在于"别人教你怎么搭多智能体，我教你为什么别搭、以及搭了怎么省八成"，避开红海。
产品化方向：一个多智能体 token 审计与缓存对齐 linter——静态扫描各 Agent 的 prompt 拼装顺序，标注"前 N token 不一致=缓存断裂"，给出重排建议与预期省税。这在 FinOps / 平台工程赛道有明确付费意愿，且能复用 agentcache 的命中埋点能力，工程量可控。
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;
本文为 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 等场景全覆盖。