多智能体系统最大的成本漏洞，往往不在模型，而在"中间人"。当系统采用 supervisor 式中央协调时，主管 agent 无法把工人 agent 的输出直接转交用户，必须重新阅读、重新叙述、重新格式化每一段 worker 结果——这一步就是"复述税"。LangChain 的官方基准给出了冷峻数字：swarm 直达式架构相比 supervisor，端到端响应时间下降约 40%，单次查询的 LLM 调用数同步减少；arXiv 2602.03128 的 MAFBench 更进一步证明，纯架构选择可以把延迟拉大 100 倍、规划准确率掉 30%、协调成功率从 90% 跌到 30% 以下。本文以 supervisor、swarm、混合周期编排三栈为对象，实测中间人转手税的来源、量级与消除路径。
| 维度 | Supervisor 中转式 | Swarm 直达式 | Hybrid 周期编排 |
|---|---|---|---|
| 谁回答用户 | 主管复述后回答 | 当前活跃 agent 直接答 | 编排器周期性聚合 |
| 复述步骤 | 每跳必复述（核心税源） | 无复述，handoff 即交权 | 仅周期点聚合 |
| Token 占用 | 最高（翻译开销） | 约 -40% | 中等，可调周期 |
| 端到端延迟 | 高 | 约 -40% 响应时间 | 取决于编排周期 |
| LLM 调用数 | 最多 | 最少 | 中等 |
| 审计/可追溯 | 强（单一收口点） | 弱（控制流不可预测） | 中（可日志化） |
| 适用 | 合规、报表、强目标 | 开放研究、探索、头脑风暴 | 实时尽调、并行采集 |
| 失败模式 | 复述失真、主管成瓶颈 | handoff 抖动、审计难 | 周期窗口漏数据 |
LangChain 在 LangGraph 基准里把 supervisor 的额外成本定位得很清楚——叫translation overhead（翻译/转述开销）。supervisor 模式的铁律是：worker 永远不直接面对用户，所有输出必须经过主管。这意味着主管 agent 每收到一个 worker 的返回，都要做三件事：读懂它、把它翻译成对用户友好的口径、再决定下一步。这三步对每个 worker 重复一次，N 个 worker 就是 N 轮"读—改—转"。本质上是让一个 LLM 充当"二道贩子"，把别人说过的话再说一遍。这段复述既不产生新信息，也无法跳过——它是 supervisor 拿到强审计性的对价。token 因此线性膨胀，延迟随 worker 数堆积。
swarm 的杀手锏是把"转发"换成"交权"。当 researcher 觉得该 writer 接手，它不是把内容发给一个中央节点再分发，而是把对话控制权连同上下文整体移交给 writer，writer 直接成为当前活跃 agent，直接回答用户。没有中间人复述，没有二次格式化，所以 LangChain 测出端到端时间约降 40%，且单查询 LLM 调用数更少。关键洞察是：复述税不是 handoff 次数带来的（swarm 也有 handoff），而是"必经一个不复述就回不了话"的中央节点带来的。只要存在一个强制二传手，税就在；只要活跃 agent 能直答，税就消。这正是 swarm 的成本结构优势。
复述不只是费 token，更危险的是它引入变形。主管在"翻译"worker 输出时，本质是在做一次有损重写：压缩、改写、补充、有时候甚至补出 worker 没说的内容。MAFBench 测到架构选择让规划准确率掉 30%、协调成功率从 90% 跌到 30% 以下，很大一部分来自这种链路重写。每一跳复述都是一次信息蒸馏，蒸掉的可能是关键细节，蒸出来的可能是幻觉。这与"工具返回二次幻觉"是同一类病——只要是 agent 重新叙述上游结果，就有再创作的风险。在强合规场景，主管复述提供了统一的对外口径，这是它的价值；但在信息保真优先的场景，复述链越长，可信度越低。
MAFBench 最反直觉的结论是：同样的模型、同样的任务，仅仅因为套了不同的多智能体框架，延迟就能拉开 100 倍。这等于宣告"慢"通常不是模型笨，而是框架强加的协调结构在拖。supervisor 的串行复述、不必要的全量上下文广播、强制等待所有 worker 的 barrier，都是框架替你"免费"加上的开销。团队的本能反应往往是换更大的模型或改 prompt，但根因在拓扑。识别方法很直接：把同一任务用单 agent + 好工具跑一遍做基线，如果多智能体版本慢出一个数量级且没换来准确率，那基本可以断定是中间人层在吃延迟。
Google ADK 给出八种多智能体设计模式，但实战中能覆盖 80% 场景的只有三种——顺序流水线、协调/路由器、并行扇出。剩下五种（层级委派、共识投票、对抗评测、人在回路、动态生成 agent）都是"优化而非起点"。共识投票要 N 个 agent 解同一题再判官选优，准确率有收益但成本翻几倍；层级委派要 10+ agent 才值得上 supervisor-of-supervisor。过早套用这些高级模式，等于为用不到的能力预先支付协调税。判据很简单：子任务独立吗？类别能预先枚举吗？需要审计吗？真需要 10 个 agent 吗？答完这四问，模式自己就跳出来了。
O'Reilly 把这个坑命名为 prompting fallacy（提示词谬误）：当多智能体输出矛盾、丢上下文、反复返工，团队第一反应是改 system prompt、加 few-shot、调温度。但指南的判断很硬——系统级失败无法靠提示词救场。如果三个 agent 在打架，解药通常是协调层动作：加一道校验、改信息流向、塞一个调和 agent，而不是改任何一条 prompt。这与 Google 的规模化原则吻合：绝大多数"agent 失败"发生在 handoff 点，是协调与上下文传递问题，不是模型能力问题。把这个谬误记住，能省下大量在错误层 Debug 的时间。
supervisor 版，每跳都经主管复述：
# LangGraph supervisor：主管必须读懂并重述每个 worker 输出
def supervisor(state):
# 复述税的现场：worker 结果在此被重新格式化、再决策
reply = llm.invoke([
{"role": "system", "content": "你是主管：总结各 worker 输出并决定下一步"},
*state["messages"],
])
return {"messages": [reply]}
builder = StateGraph(MessagesState)
builder.add_node("supervisor", supervisor)
builder.add_node("researcher", researcher)
builder.add_node("writer", writer)
builder.add_conditional_edges("supervisor", route) # 每跳必经 supervisor
swarm 版，交权即直答，无复述：
# LangGraph swarm：活跃 agent 直接面对用户，省掉中间人
from langgraph.swarm import create_swarm, create_handoff_tool
handoff_to_writer = create_handoff_tool(agent_name="writer")
researcher = create_react_agent(llm, [search_tool, handoff_to_writer])
writer = create_react_agent(llm, [handoff_to_researcher])
swarm = create_swarm(
agents=[researcher, writer],
default_active_agent="researcher", # 起点直答，handoff 即交权
)
两段代码的差别只有一行逻辑：supervisor 把 route 的判定权与复述义务都压在中央节点，swarm 把它们下放到活跃 agent。税就藏在这一行里。
flowchart TB
U[用户请求]
subgraph S[Supervisor 中转式 — 每跳必复述]
S1[主管 解构+路由]
S2[Worker A]
S3[Worker B]
S4[主管 复述/重格式化]
S1 --> S2 --> S1
S1 --> S3 --> S1
S1 --> S4 --> U
end
subgraph W[Swarm 直达式 — handoff 交权]
W1[Researcher 直答]
W2[handoff 交权]
W3[Writer 直答]
W1 --> W2 --> W3 --> U
end
subgraph H[Hybrid 周期编排]
H1[专家A 并行] --> HO[编排器 每30s聚合]
H2[专家B 并行] --> HO
H3[专家C 并行] --> HO
HO -->|继续/停止| U
end
U --> S
U --> W
U --> H
S4 -. 复述税 .- T1[token 膨胀 + 失真]
HO -. 周期税 .- T2[窗口期漏数据]
强目标、强合规（报表生成、多步分析、受监管流程）：用 supervisor，并主动接受复述税——这里复述是"统一对外口径"的特性而非缺陷。可压缩手段：让 worker 返回结构化字段而非自由文本，降低主管重格式化的信息量。
开放探索、路径未知（开放式研究、创意、故障排查）：用 swarm，靠 handoff 动态发现谁来接手，享受约 40% 的延迟与调用节省。代价是审计弱，生产环境务必把每次 handoff 写进日志。
实时并行采集（尽调、多源情报、舆情）：用 hybrid 周期编排——少数快专家并行跑，一个慢编排器按固定周期（如 30 秒）聚合、查矛盾、决去留。这既不是 supervisor（不逐任务派发）也不是 swarm（专家间不互传），是当前生产系统最常见的真实形态。
通用原则：先问"单 agent + 好工具能不能解决"，再决定上不上多智能体。Google 与多智能体陷阱分析都指出，超量加 agent 会带来 39–70% 性能退化。把拓扑选择当作性能变量而非美学选择——MAFBench 证明它的影响可达 100 倍延迟量级，远超换模型。
[!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 等场景全覆盖。