# 复述即税：中间人转手三栈实测 ## 概述 多智能体系统最大的成本漏洞，往往不在模型，而在"中间人"。当系统采用 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 抖动、审计难 | 周期窗口漏数据 | ## 深度分析 ### 一、复述税从哪来：supervisor 的"翻译开销" LangChain 在 LangGraph 基准里把 supervisor 的额外成本定位得很清楚——叫**translation overhead（翻译/转述开销）**。supervisor 模式的铁律是：worker 永远不直接面对用户，所有输出必须经过主管。这意味着主管 agent 每收到一个 worker 的返回，都要做三件事：读懂它、把它翻译成对用户友好的口径、再决定下一步。这三步对每个 worker 重复一次，N 个 worker 就是 N 轮"读—改—转"。本质上是让一个 LLM 充当"二道贩子"，把别人说过的话再说一遍。这段复述既不产生新信息，也无法跳过——它是 supervisor 拿到强审计性的对价。token 因此线性膨胀，延迟随 worker 数堆积。 ### 二、swarm 为何能砍掉 40%：handoff 是交权不是转发 swarm 的杀手锏是把"转发"换成"交权"。当 researcher 觉得该 writer 接手，它不是把内容发给一个中央节点再分发，而是把**对话控制权连同上下文整体移交给 writer**，writer 直接成为当前活跃 agent，直接回答用户。没有中间人复述，没有二次格式化，所以 LangChain 测出端到端时间约降 **40%**，且单查询 LLM 调用数更少。关键洞察是：复述税不是 handoff 次数带来的（swarm 也有 handoff），而是**"必经一个不复述就回不了话"的中央节点**带来的。只要存在一个强制二传手，税就在；只要活跃 agent 能直答，税就消。这正是 swarm 的成本结构优势。 ### 三、复述即失真：再加工一定伴随信息变形 复述不只是费 token，更危险的是它引入变形。主管在"翻译"worker 输出时，本质是在做一次有损重写：压缩、改写、补充、有时候甚至补出 worker 没说的内容。MAFBench 测到架构选择让**规划准确率掉 30%、协调成功率从 90% 跌到 30% 以下**，很大一部分来自这种链路重写。每一跳复述都是一次信息蒸馏，蒸掉的可能是关键细节，蒸出来的可能是幻觉。这与"工具返回二次幻觉"是同一类病——只要是 agent 重新叙述上游结果，就有再创作的风险。在强合规场景，主管复述提供了统一的对外口径，这是它的价值；但在信息保真优先的场景，复述链越长，可信度越低。 ### 四、100 倍延迟：架构问题伪装成模型问题 MAFBench 最反直觉的结论是：**同样的模型、同样的任务，仅仅因为套了不同的多智能体框架，延迟就能拉开 100 倍**。这等于宣告"慢"通常不是模型笨，而是框架强加的协调结构在拖。supervisor 的串行复述、不必要的全量上下文广播、强制等待所有 worker 的 barrier，都是框架替你"免费"加上的开销。团队的本能反应往往是换更大的模型或改 prompt，但根因在拓扑。识别方法很直接：把同一任务用单 agent + 好工具跑一遍做基线，如果多智能体版本慢出一个数量级且没换来准确率，那基本可以断定是中间人层在吃延迟。 ### 五、八式只用三：别为模式付溢价 Google ADK 给出八种多智能体设计模式，但实战中能覆盖 80% 场景的只有三种——**顺序流水线、协调/路由器、并行扇出**。剩下五种（层级委派、共识投票、对抗评测、人在回路、动态生成 agent）都是"优化而非起点"。共识投票要 N 个 agent 解同一题再判官选优，准确率有收益但成本翻几倍；层级委派要 10+ agent 才值得上 supervisor-of-supervisor。过早套用这些高级模式，等于为用不到的能力预先支付协调税。判据很简单：子任务独立吗？类别能预先枚举吗？需要审计吗？真需要 10 个 agent 吗？答完这四问，模式自己就跳出来了。 ### 六、提示词谬误：prompt 救不了系统失灵 O'Reilly 把这个坑命名为 **prompting fallacy（提示词谬误）**：当多智能体输出矛盾、丢上下文、反复返工，团队第一反应是改 system prompt、加 few-shot、调温度。但指南的判断很硬——**系统级失败无法靠提示词救场**。如果三个 agent 在打架，解药通常是协调层动作：加一道校验、改信息流向、塞一个调和 agent，而不是改任何一条 prompt。这与 Google 的规模化原则吻合：绝大多数"agent 失败"发生在 handoff 点，是协调与上下文传递问题，不是模型能力问题。把这个谬误记住，能省下大量在错误层 Debug 的时间。 ### 七、代码对照：复述在哪里发生 supervisor 版，每跳都经主管复述： ```python # 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 版，交权即直答，无复述： ```python # 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。**税就藏在这一行里。** ## 三栈架构对照 ```mermaid 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 倍延迟量级，远超换模型。 ## 参考来源 1. [Understanding Multi-Agent LLM Frameworks: A Unified Benchmark and Experimental Analysis (arXiv:2602.03128)](https://arxiv.org/abs/2602.03128) — MAFBench 基准，证明框架级设计可致延迟 100x、规划准确率 -30%、协调成功率 90%→30% 2. [Multi-Agent Architecture Patterns Guide 2026 — Supervisor vs Swarm vs Pipeline (paperclipped)](https://www.paperclipped.de/en/blog/multi-agent-architecture-patterns-design/) — LangGraph supervisor vs swarm 基准：swarm 约 -40% 响应时间、更少 LLM 调用；Google 八模式 80/20；提示词谬误；A2A vs MCP 分层 3. [Multi-Agent Orchestration Frameworks 2026 — LangGraph/CrewAI/AutoGen/Swarm/ADK (Presenc AI)](https://presenc.ai/research/multi-agent-orchestration-frameworks-2026) — 2026 多智能体编排框架横评，生产就绪度与生态对比 4. [Handoff vs. Supervisor: Why Your Multi-Agent Architecture Choice Matters (Medium)](https://medium.com/@attia.atef92/handoff-vs-supervisor-why-your-multi-agent-architecture-choice-matters-%EF%B8%8F-40cadb0e0dc2) — handoff 与 supervisor 选择决策与失败模式拆解 > [!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 等场景全覆盖。