多 Agent 传话实验：需求能传到，但「为什么」会在最后一跳被砍掉

作者用 853 次 Claude 运行和 432 次 GPT-6 Luna 运行，模拟客户需求经过 lead、PM、architect 到 implementer 的多级传递，逐条追踪事实的保留情况。结果发现禁令、数字、细节大多能完整到达，但决策背后的「原因」在写给执行者的那一跳骤降到 8–31%——即使写的人手里就有原始需求。文章还测了三种消息格式和四类转写错误的影响，结论对设计多 Agent 工作流很有实操价值。

实验设计：真实的层级，不是传话游戏

• 6 条客户请求（3 个软件任务 + 3 个活动策划），每条预先标注了名字、数字、禁令、条件、优先级、易漏细节和原因等事实类型
• 两种团队结构：链式（lead→PM→architect→implementer）和接力式（lead 直接写第 4 跳），用来区分「距离损耗」和「受众选择」
• 消息用三种格式传递：自由散文、编号需求清单、附上客户原始请求的短笺
• 模型为 Claude Haiku 5.5 和 Sonnet 5.5（Claude Code 真实嵌套 subagent）以及 GPT-6 Luna，每格跑 3 次，共 853 次 Claude 运行 + 432 次 Luna 运行

大部分信息能到达，唯独「原因」被砍

• 第 4 跳时，禁令到达率 98%、易漏细节 96%、数字 92%、名字和条件 90%、优先级 85%
• 但「原因」在链式结构中前两跳还有 88–99%，到 architect 写给 implementer 时跌到 8–31%
• 接力式排除了距离因素：lead 手里拿着原始需求，写给 implementer 时也只有 24% 保留原因——这是对受众的选择，不是磨损
• Luna 更早丢原因：第一跳就只剩 30%，之后一直很低

丢原因反而可能有害？一个意外发现

• 对比保留与丢失原因的运行：Claude 下保留原因的规则遵守率反而低 10 个百分点
• 最极端的例子：Haiku 在消息里带上「用 last_seen_at 而不是 last_login，因为移动端停更了 last_login」这条原因时，用对字段的比例只有 59%；不带时是 97%
• 作者假设原因里的旧字段名成了干扰项，但这是事后分析，只当假设看待
• 真正致命的是需求本身丢失：完整到达的事实 95% 在最终产物中被满足，丢失的只有 40%

名字会冻结，标点能自愈

• 被转写错的名字（如 Siobhán）几乎无法从文本修复，但可以质疑——Claude 的传递消息中不到 2% 标记了存疑，Luna 从不质疑，错误名字 100% 进入最终产物
• 改变语义的标点错误（如 "No, do it" vs "No do it"）约三分之二在传递中被修复，因为上下文能推断本意

格式的影响因模型而异

• 对 Claude，三种格式差别不大：编号清单在第 4 跳保留 88% vs 散文 85%，最终代码得分接近
• 对 Luna 影响巨大：散文格式下 72 次运行中有 54 次丢掉了输入字段清单，implementer 只好自己编字段名，模块第一次测试就崩
• 附上原始请求是唯一让 Luna 不丢数据契约的格式，之后其代码得分 0.76–0.86，与 Sonnet 相当
• Claude 的另一类失败：216 次软件运行中有 29 次，Haiku 的 implementer 交付的是规格文档而非代码——交付物类型也会沿链条漂移