多智能体交接丢失：规划从未到达执行者

一个本地 8B 模型的三步流水线，跑出了比单次调用更高的准确率。但拆开日志后发现，这份增益并不来自被寄予厚望的规划步骤——规划器的完整笔记在跨过 LangGraph 子图边界时就被截断了,真正干活的是执行器和审阅器对原始报告的二次阅读。

实验设定：一个被刻意收窄的交接

这项实验想复现的是多智能体系统里一个具体却常被忽略的失效模式。作者用 Ollama 本地运行 llama3.1:8b，temperature 0、固定种子、零 API 成本，在 12 个合成的事件报告抽取任务上对比两种条件：条件 A 是每个任务一次调用，条件 B 是规划器、执行器、审阅器三步流水线，共 36 次调用。

每个任务要求抽取三个字段：root_cause、affected_component、fix_action。只要答案包含任一必需关键词即算正确，这种机械评分方式是为了让结果可复现，而非依赖人工判断。

交接的载荷细节只有一行 Python：

focus_hint = plan_notes.split(".")[0][:60] if plan_notes else ""

作者故意用纯 Python 而不是 LangGraph 的 StateGraph 来建模子图边界：子图的状态 schema 才是真正跨越父子边界的东西，父步骤产生但子 schema 从未声明的键，在另一侧就是不存在——没有异常，没有警告。这条边界设计得很窄，正如团队在交付压力下真实的做法。

数据处理不等式（Data Processing Inequality） 是信息论中的经典定理：若随机变量 X → Y → Z 构成马尔可夫链，则互信息满足 I(X;Z) ≤ I(Y;Z) ≤ I(X;Y)。通俗地说，对数据做的任何加工（摘要、压缩、改写）都不可能凭空增加关于原始信源的信息量，只会丢失或保持不变。在多智能体流水线中，前一步智能体输出的“摘要”就是中间变量 Y，它相较原始输入 X 已经损失了信息；下游无论多聪明，都无法从 Y 中恢复 X 里被丢掉的细节。这正是“传话游戏”必然越传越模糊的数学根基，也解释了为何让后续步骤直接重读原始素材，往往比信任上游摘要更可靠。

LangGraph 的 StateGraph 与子图状态 schema 是理解本文“交接丢失”的关键。LangGraph 用 StateGraph 显式声明一个图的状态结构（schema），节点之间通过这个共享状态字典交换数据。当父图中嵌入一个子图时，父图与子图各自维护自己的 schema，跨越边界时只传递两边都声明过的键。父步骤若产生了一个子 schema 从未声明的键，这个键在子图一侧就等于不存在——不会有异常抛出，也不会有警告日志，数据静默消失。作者刻意用一行纯 Python 的字符串切片来模拟这一行为，正是为了凸显这类边界失败在真实工程中多么隐蔽。

结果：准确率赢了，交接输了

数据摆在一起看：

• 字段准确率：单次调用 30/36（83.3%），三步流水线 33/36（91.7%）
• 三个字段全对的任务：7/12 对比 9/12
• LLM 调用次数：12 对比 36
• 总 token：1,659 对比 7,323（4.4 倍）
• 墙钟时间：72.7 秒对比 411.1 秒（5.7 倍）

但那张对比表没有展示的是交接本身：12 个任务全部出现截断，规划器输出在 368 到 584 字符之间，而真正到达执行器的 focus_hint 被卡在 60 字符。在 retry-storm 这个任务上，规划器完整写道要「检查重试逻辑，弄清系统为何最初没有实现指数退避」,执行器收到的却是「Here's a short investigation note: 'Review the system logs」——在 "retry storm" 或 "backoff" 出现之前就被切断了。

固定种子与 temperature=0 的确定性运行 是本文可复现性的基础，也界定了结论的边界。将采样温度设为 0 并固定随机种子后，同一模型对同一输入会给出几乎确定一致的输出，因此每个条件只需运行一次即可得到稳定结果，无需多次采样取平均。代价是这种单次确定性运行无法反映真实推理的方差，任何一个字段的翻转都会在 12 任务 × 3 字段 = 36 单位的评分中移动约 2.8 个百分点。因此文中 91.7% 与 83.3% 的差距虽然真实存在，却建立在单条样本轨迹上，不能直接推广为统计意义上的普遍优势。

三个翻转案例：增益到底从哪来

有三个字段在两种条件间从错变对。作者特意把执行器的中间答案和审阅器的最终答案分开记录，就是为了查清是哪一步真正起了作用，而这三个案例的解决路径各不相同。

在 feature-flag-leak 任务上，规划器的提示是纯样板：「Here's a short investigation note: Investigation Note」，60 个字符全是开场白，零任务信息。但执行器在审阅器介入之前，读着完整原始报告就给出了正确答案「feature-flag targeting rule leak due to shared cache entry reuse」。

在 retry-storm 任务上，提示半通用（「Review the system logs」），执行器答案仍错，与单次调用相同的缺口。是审阅器拿到完整报告第二次阅读后，才修正为「downstream outage caused a retry storm」。这是全程唯一一个明确需要审阅器的修复。

第三个案例是诚实的复杂情况。在 redis-pool 上，单次调用漏掉了 "redis" 和 "connection pool"，执行器修好了它，而这次 60 字符提示里恰好包含了「Review the Redis connection pool confi」——规划器碰巧在截断点之前就写对了关键词。作者承认无法排除提示在这里起了作用，但强调这只是句子断点侥幸，不是架构设计保证的能力。

综合来看，规划步骤这次没有挣到任何可靠的贡献。它的唯一可能贡献依赖偶然措辞，而非架构本身。执行器独立于提示、只靠完整报告阅读就已经达到 88.9%（32/36），这是从保存的中间答案直接测得的；审阅器在此基础上只多加了一个字段，33/36。

为什么「重读原文」比「传递摘要」更值钱

这里有一个理论依据支撑作者的观察。斯坦福的一篇预印本论文《Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets》，在三个模型家族上保持推理 token 预算恒定，发现单智能体始终持平或优于多智能体。论文的解释依赖数据处理不等式：一旦一个智能体把处理过的上下文版本传给下一个，信息在该步骤上只能丢失或保持不变，永远无法增加。

那次 focus_hint 截断正是这个不等式具体化、可测量的实例，而非边缘情况。Anthropic 在其多智能体系统工程文章中同样指出了这种「传话游戏」的成本——智能体通常比单次对话多用约 4 倍 token，完整多智能体系统约 15 倍，部分开销正流向输出被反复摘要重写的过程。Anthropic 自己的修复方案是让子智能体把完整输出写入共享存储，而不是通过对话传递压缩摘要。

本次实验用日志可见的机制补充了一个同向的数据点：91.7% 确实赢了 83.3%，但这份收益主要由各步骤重新阅读原始报告买来，而非架构中的规划步骤——而规划恰恰是多智能体文章花最多笔墨论证的部分。

Anthropic 的多智能体工程实践 指出了一个与本文同向的成本结构：多智能体系统通常比单次对话消耗约 4 倍 token，完整的多智能体架构甚至可达 15 倍。其中一个显著开销来源，就是智能体之间反复对输出进行摘要与重写——每次压缩都伴随信息损失，还额外烧掉算力。Anthropic 给出的修复思路是让子智能体把完整输出写入共享存储（如文件或数据库），下游按需读取原始内容，而不是通过对话上下文传递压缩后的摘要。这与本文观察一致：把“重读原始报告”作为流水线的常规动作，比依赖一个经过多次转述的规划摘要更能保住关键信息。

规划步骤值不值，先问 schema 承载了什么

这轮实验支撑的结论比「多智能体赢」或「多智能体是坑」都更窄。两者都会过度解读一次 12 任务的本地运行。它真正支持的只有两点：一个重新查看原始素材、而不是信任前一步摘要的步骤，能捉住真实错误，这里体现在三个字段上；而一个通过过窄 schema 交接产出的规划步骤，买不到任何可靠的东西——如果砍掉它、直接从报告流向执行器再到审阅器，汇总表里几乎看不出区别。

给流水线加规划步骤之前，值得问的不是「更多结构会否有帮助」，而是「这一步到下一步，具体有什么必须存活下来，我的状态 schema 是否真的承载了它」。这是一个可检查的具体问题，不是感觉。加审阅步骤之前，更该问的是审阅器拿到的是原始素材还是上一步的输出——本次审阅器的优势恰恰来自重读报告，而不是孤立地批判执行器的 JSON。

可复现性与诚实的缺口

完整脚本、任务集、逐任务原始输出都在公开仓库 github.com/priyansh18/agent-handoff-loss-benchmark，全部本地运行于 Ollama，零 API 密钥。两个限制被明确标注：一是每个条件只跑一次确定性运行，不是重复试验分布，单个字段翻转就会在 36 单位里移动 2.8 个百分点；二是基于关键词的评分器奖励完整性而非精确性，这在一定程度上解释了为何另外三个任务在两种条件下都保持错误。

作者在文末抛出的问题值得每个搭过 planner-executor-reviewer 流水线的人自问：你的规划步骤，有没有被真正检查过交接之后到底还剩什么，还是你像作者差点做的那样，直接信任了它？