智能体流水线中的“传声筒”游戏

你可能目睹过这样一种失败，只是没有给它命名。你的编排者（orchestrator）读取用户请求并向工作代理（worker agent）下达简报。工作代理运行了十几次工具调用，消化输出，然后汇报一份简洁的摘要。编排者将该摘要并入下一名工作代理的任务简报中，后者如法炮制。五跳（hop）之后，系统给出了一个自信的最终答案——却违反了用户在请求的第二句话中明确提出的约束。没有人故意丢掉这个约束。每一跳只是稍微压缩了一下上下文，方向无人选择，而这些压缩不断叠加。

这就是“传声筒游戏”（the telephone game），而多智能体系统（multi-agent systems）本质上就在玩这个游戏。流水线中的每一次交接都是一个有损压缩步骤：编排者的简报是对用户的转述，工作代理的报告是对其工具输出的转述，而最终答案则是转述之上的转述。问题不在于信息是否丢失——它确实丢失了，而且是可衡量的——而在于你是否决定了哪些信息允许被丢失，还是将这个决定留给了采样温度（sampling temperature）。

失败数据证实了这一点。MAST 分类法——基于对七个流行多智能体框架的 1,600 多个带注释的执行轨迹的分析——发现代理间的失调（inter-agent misalignment）约占所有多智能体失败案例的 37%：通信崩溃、交接过程中的上下文丢失、输出冲突、代理间的格式不匹配。这并非尾部风险。它是该分类法中的第二大失败类别，而且与模型能力不同，它完全是你将系统连接在一起的方式所产生的副产物。

每一跳都是一个无人调优的压缩器

当代理在交接前总结上下文时，它正在运行一种你从未指定损失函数（loss function）的压缩算法。代理通过逐个 token 隐式地决定哪些内容足够显著以备保留。而它对“显著性”的理解是通用的：基于文本中通常重要的内容进行训练，而不是基于对你的流水线重要的内容。

关于迭代 LLM 生成的研究使这种叠加效应变得显而易见。“断掉的传声筒”研究像人类曾经链接耳语那样将模型链接在传输循环中，发现扭曲在迭代中稳步累积，并向“吸引子”（attractors）漂移——文本变得更短、更通用、更积极，并收敛到模型认为最自然的措辞上。在单次生成中不可见的偏见，在五次之后就变成了结构性的。你的流水线就是一个带有额外步骤的传输链。

这种损失不是随机噪声（如果是噪声反而更容易处理），它具有特征性的形状：

• 限定词（Qualifiers）首当其冲。 一项关于 LLM 压缩财务分析的研究将“去上下文（decontextualization）”识别为一种主要的失败模式：显著的事实能在摘要中存活，但其附加条件却不能。“收入增长了 40%（受一次性合同驱动）”变成了“收入增长了 40%”。随后的代理便基于一个现在已经错误的前提进行正确的推理。
• Groundedness（忠实度）在压缩下崩塌。 关于提示词压缩的研究发现，激进的压缩会使 Groundedness 分数下降 30 到 50 点——压缩后的上下文读起来依然顺畅，但后续生成的文本对原始来源的忠实度显著降低。
• 负面结果消失。 一个尝试了三种方法并发现两条死路的工作代理会报告成功的那条。那些本可以避免下一个代理重复犯错的死路，很少能在摘要中存活，因为摘要偏向于结论而非过程。
• 隐性决策完全消失。 正如 Cognition 工程团队所说：行动带有隐性决策，而冲突的决策会带来糟糕的结果。当一个工作代理选择库 A 而不是库 B 时，这个选择约束了下游的一切。但由于它从未被表述为一个决策，因此没有摘要会保留它。

注意这四点的共同点：摘要本身并无错误。在它选择的分辨率下，它是准确的。伤害源于分辨率。

为什么直到第五跳你才会注意到

单跳的损失很小，这正是它能通过代码评审（code review）的原因。你检查一次交接，摘要看起来很忠实，于是你发布了。但每跳的损失是乘法关系，而非加法。如果每跳保留 90% 与决策相关的信息——考虑到 Groundedness 的数据，这已经是一个慷慨的估计了——一个五跳的链条只能交付 59% 的信息。如果每跳保留 80%，你就只剩下 33% 了。

这里的置信度信号比没用更糟糕，因为它与保真度呈负相关。链条中的每个代理都针对它收到的上下文写出流畅且笃定的散文。最终答案无论基于用户的实际约束，还是基于第五代转述，都带有同样的文采。流畅性是传声筒游戏中伟大的掩盖剂：在人类链条中，乱码听起来就像乱码；但在 LLM 链条中，每一次复述都辞藻华丽。

这也解释了许多团队遇到的一种模式：在适合单个上下文窗口的任务上，系统的多智能体版本表现不如单智能体版本。MAST 的作者指出，在流行基准测试中，多智能体相对于单智能体基准的性能提升通常微乎其微。原因之一是你在每一次交接中都要支付“传声筒税”，而如果任务不需要分解，这笔税就白交了。

Anthropic 团队在描述他们的研究系统时明确表示，该架构在“广度优先（breadth-first）”的问题上表现更优，因为这些问题的总信息量确实超过了一个上下文窗口——这时具有独立上下文的并行子代理才会胜过单个代理，而他们的评估显示，token 预算解释了大部分的性能差异。当交接能为你换取否则无法获得的 token 时，它是值得付出的代价。如果不能，它就是纯粹的损失。

在修复之前先衡量损失

如果没有损失函数，你无法调优压缩器，因此第一步是测量，而非重新设计。这里有三个实用的探测方法：

约束追踪（Constraint tracing）。 枚举原始请求中的显式约束——预算限制、格式要求、排除项、截止日期——并在每个下游智能体实际收到的上下文中搜索（grep）它们（或其语义等价物）。手动操作很乏味，但用 LLM 评判员（LLM judge）来实现自动化却是轻而易举的：“这是原始约束列表；这是智能体 N 收到的内容；哪些约束是可以恢复的？”绘制每一跳的约束存活率，你会得到一条衰减曲线。大多数第一次运行此测试的团队会发现，至少有一个约束在第二跳就消失了。

回程探测（Round-trip probing）。 借鉴自压缩文献：在交接之后，向接收方智能体询问那些答案存在于交接前上下文中的问题。如果编排器知道用户的 API 版本，而执行者无法回答“我们针对的是哪个 API 版本”，那么交接过程中就丢失了该信息。这能捕捉到约束列表漏掉的去语境化（decontextualization）问题，因为你可以探测限定修饰语，而不仅仅是事实。

失败后的决策考古（Decision archaeology on failures）。 当流水线产生错误输出时，向上追溯：在哪一跳，避免失败所需的信息最后一次出现？根据我的经验，这是多智能体系统中最具杠杆作用的调试问题，而大多数团队无法回答，因为他们只记录了智能体的输出，却没有记录每个智能体实际看到的组装后的上下文。记录输入。输出可以重新生成；上下文的构建过程才是证据。

这些测量通常会显示，损失是集中的而非均匀的——流水线中有一两个交接点造成了大部分破坏，通常是那些用通用的“总结你的发现”指令代替下游实际需要的规范的地方。

逐字通道与压缩通道

一旦你能看到损失，设计问题就变成了：哪些内容必须原样传递（verbatim），哪些可以压缩？将其视为针对每个字段（而非每条消息）的决策，是核心举措。

有些内容永远不应该经过转述：

• 用户提出的约束和验收标准。 这些是整个流水线服务的“地面真理”（ground truth）。复制它们，不要总结它们。它们通常很短；相对于失败的代价，Token 成本微不足道。
• 标识符和精确值。 文件路径、API 版本、错误消息、数字、ID。LLM 在复述时以“规范化”这些内容而臭名昭著——这种向“合理性”偏移的“传声筒”效应，对于那些“合理”与“正确”分道扬镳的字符串来说是致命的。
• 带有原由的决策。 不是“我设置了数据库”，而是“选择了 Postgres 而非 SQLite，因为我们需要并发写入者”。原由是防止下游智能体在无意中撤销决策的关键。
• 负向知识。 尝试过但失败的方法、被排除的选项及其原因。这是最容易被总结破坏、且重新发现成本最高的信息。

其他所有内容——探索过程的叙述、已提取为决策的原始工具输出、执行者的推理记录——都可以压缩，前提是原始记录保持可检索性。这就是为什么“传递产物”（artifact-passing）作为默认方案优于“传递摘要”（summary-passing）的原因：执行者将完整输出写入共享存储（文件、blob 或数据库行），并传递一个引用和一份摘要。摘要现在是通往真相的索引，而不是真相的替代品。接收方智能体阅读摘要，当某些内容看起来至关重要时，它会拉取原始产物。压缩变成了一种性能优化，而不是信息天花板——这与我们在数据库之上构建缓存而不是用缓存替代数据库的原因相同。

Anthropic 的研究系统采用了这种方式的一个变体：子智能体将发现写入持久存储并传递轻量级引用，正是为了让编排器的综合分析不受交接消息容量的限制。Cognition 则更进一步，主张共享完整的智能体轨迹（traces），根本不使用摘要——这是将同一原则推向极致，在跳数较少且上下文预算充裕时是可行的。

解决方案是 Schema，而非更好的提示词

本能的修复方法是提示词工程：“确保在摘要中包含所有重要的约束”。这会因为结构性原因而失败——它将压缩决策重新交还给模型的通用显著性判断，只是措辞更加强调。你是在要求压缩器减少损失，却没有告诉它损失对你意味着什么。

持久的修复方案看起来更像 Schema 设计。将交接定义为一个类型化契约（typed contract）：一个带有显式字段的结构化对象——constraints（从源头原样复制）、decisions（每个都带有原由）、artifacts（对完整输出的引用）、open_questions、ruled_out，以及一个用于处理真正可压缩内容的纯文本 summary。关于智能体间通信的研究支持这一直觉：比较交接策略的研究发现，你传递的内容——产物、结论、结构化状态——对下游任务性能的影响远大于传递消息的措辞有多么优雅。

Schema 能做到提示词做不到的三件事：

1. 它让遗漏变得可见。 一个空的 ruled_out 字段是一个可审计的事件；而一个恰好没提到死胡同的摘要是不可见的。必填字段将无声的损失转化为验证错误。
2. 它在机械上分离了通道。 逐字字段通过复制而非生成来填充——到达第五跳的约束文本与第一跳在字节级别上是完全一致的，因为没有模型重写过它。你无法转述你被禁止触碰的内容。
3. 它像 API 一样进行版本管理。 当下游智能体需要新信息时，你会扩展契约并更新生产者——这与任何接口变更的纪律相同，且可以独立测试。提示词没有“破坏性变更”的概念；Schema 有。

这也是为什么任何构建过分布式系统的人都会觉得这个问题似曾相识。服务之间不会交换关于其状态的随笔散文；它们交换 Schema，因为我们几十年前就认识到，组件之间的隐式契约会不断偏移直到崩溃。多智能体流水线是分布式系统，只不过其消息恰好是由随机过程编写的。这使得显式契约变得更加必要，而不是可有可无。

更少的跳转，更粗的管道

从宏观上看，传声筒游戏揭示了一个架构启发式原则：每一次交接都必须证明其自身的价值。只有当一个环节能够换取真正独立的子任务之间的并行性、任务实际需要的上下文容量，或者你能够辩护的隔离性时，这个跳转才是合理的。如果一个环节的存在仅仅是因为你的智能体组织架构镜像了你的团队组织架构——例如一个“规划者”为“研究者”转述用户意图，而“研究者”又为“作者”转述来源——那么这就是一个没有任何补偿性收益的压缩阶段。

因此，在增加一个智能体之前，先问问这次交接会损失什么，又会换来什么。倾向于选择更少、更粗的跳转：两个交换丰富结构化状态的智能体，胜过五个交换“优雅摘要”的智能体。为每一个环节提供一个 Schema，并为约束、标识符、决策和死胡同设置专门的原始信息通道。将完整输出存储为产物（Artifacts）并传递引用。此外，像测量服务延迟一样，去测量流水线中约束的存续情况——因为在目前的情况下，你的第五个智能体正在处理的消息已经不是用户最初发送的消息了，而且链路中没有人能告诉你到底发生了什么变化。