组合测试鸿沟：为什么你的智能体通过了每一项测试却在协作时失败

你的规划智能体（planner agent）在评估套件中的通过率为 94%。你的研究智能体（researcher agent）得分甚至更高。你的合成智能体（synthesizer agent）完美通过了你投喂的每一个基准测试。你将它们组合成一个流水线，部署到生产环境，然后眼睁睁地看着它产生自信的错误答案——而任何单个智能体都不可能独立生成这些错误。

这就是组合测试鸿沟（composition testing gap）——这是一个系统的盲点，即经过独立验证的智能体会以单智能体分析无法预测的方式失败。对多智能体 LLM 系统（multi-agent LLM systems）的研究表明，67% 的生产故障源于智能体之间的交互，而非单个智能体的缺陷。你测试的是原子，但交付的是分子，而分子的行为并非原子属性的简单叠加。

没人预算过的组合爆炸

数学规律很快就会让你陷入困境。两个智能体交互需要测试一条通信路径。五个智能体产生十条潜在交互路径。十个智能体产生四十五条。但这比简单的组合更糟糕，因为每条交互路径都带有非确定性行为——同样的输入可能会根据上下文、之前的对话状态以及上游智能体选择的特定措辞，触发不同的智能体编排（choreography）。

MAESTRO 评估框架的最新研究量化了这一点：多智能体系统在相同运行中的执行顺序显示出约 35% 的变异性，即使结构化交互模式（哪个智能体与哪个智能体通信）保持 86% 的稳定性。智能体以相同的模式相互调用，但序列的偏移足以产生显著不同的结果。

这意味着你在周二通过的集成测试可能会在周三因完全相同的输入而失败。不是因为任何东西改变了——而是因为系统在其自身的状态空间中探索了一条不同的路径。

单元测试无法捕获的三种组合失败

单个智能体的评估测试的是孤立的能力。组合失败产生于智能体之间的空间。它们分为三类，需要根本不同的测试方法。

交付边界的信息丢失

当智能体 A 将结果传递给智能体 B 时，总会有一些信息丢失。智能体 A 的内部推理——为什么它选择这个特定的框架，它考虑过哪些替代方案，它默默放弃了哪些注意事项——并不会被传递。智能体 B 接收到一个扁平化的文本产物，并从头开始构建自己的心理模型。

在多智能体代码生成系统中，研究人员发现，语义等效的输入会导致性能下降 7.9% 到 83.3%，具体取决于规划智能体选择如何表述其任务分解。代码生成智能体完全胜任。规划智能体也完全胜任。但它们之间的转换层引入了脆弱性，而任何一个智能体的单独评估都无法发现这一点。

冲突的隐性假设

每个智能体都会根据其系统提示、工具访问权限和训练，对世界形成隐性假设。当智能体进行组合时，这些假设会发生无声的碰撞。

一个研究智能体可能认为“最近”意味着“过去 30 天”，而合成智能体则将“最近”解释为“在提供的上下文中提到的内容”。孤立来看，这两个智能体都没有错。但当研究智能体检索信息并标记为“最近发现”时，合成智能体可能会仅仅因为它们出现在其输入窗口中，就将过时的缓存结果视为当前信息。

这些假设不匹配对于基于能力的评估来说是不可见的，因为每个智能体在其自身参考框架内都能正确处理该概念。失败仅在组合边界处显现。

突发的资源竞争

多智能体系统共享单智能体测试从未压测过的资源：API 速率限制、上下文窗口、token 预算和执行时间。在孤立状态下，每个智能体消耗的资源都是合理的。而在组合状态下，它们会相互竞争。

生产数据表明，单智能体系统的成功率为 99.5%，而等效的多智能体实现仅为 97%——这个差距听起来很小，直到你意识到它代表了故障率增加了 5 倍。这在很大程度上源于资源竞争：智能体耗尽了共享的速率限制，上下文窗口由于多个智能体将其输出塞入共享线程而溢出，或者当一个智能体的缓慢响应阻塞了整个流水线时发生连锁超时。

为什么分布式系统测试适用（以及它在何处失效）

组合测试问题并不新鲜。分布式系统工程师几十年来一直在开发测试组合服务中突发行为的技术。基于属性的测试、混沌工程、契约测试——所有这些在多智能体系统中都有类似的对应项。但这种类比在某些重要方面是失效的。

在微服务中，服务之间的契约是显式的：API 模式、消息格式、文档化的 SLA。在多智能体系统中，“契约”是自然语言——本质上是模糊的、依赖上下文的，并且无法通过模式检查进行验证。你可以验证智能体 A 生成了有效的 JSON，但你无法验证智能体 A 是否传达了正确的细微差别，以便智能体 B 做出正确的决策。

此外，微服务在一个请求内是确定性的。给定相同的输入和状态，服务会产生相同的输出。基于 LLM 的智能体是随机的。MAESTRO 的发现——结构稳定但时间多变的执行——在传统分布式系统中没有直接的类比。你的混沌工程手册假设注入相同的故障会产生相同的失败模式。而对于 LLM 智能体，它可能会产生完全不同的失败模式。

这意味着你需要借用这些框架，但必须重构其核心假设。

构建一个真正有效的组合测试套件

有效的组合测试（Composition testing）需要承认你无法枚举所有可能的交互状态。相反，你应该测试那些无论系统采取哪条路径都应该保持不变的属性。

基于属性的不变量优于点状断言

与其断言系统针对特定输入产生特定输出，不如定义必须在所有组合中保持的不变量（Invariants）：

• 信息单调性：如果研究员找到了三个相关来源，综合器应至少引用三个来源。信息不应在交付边界处消失。
• 一致性：如果 Agent A 报告了一个约束条件，下游 Agent 不应违反该约束。
• 有界资源消耗：单个请求中所有 Agent 的总 Token 使用量不应超过定义的预算。
• 幂等交付：重放相同的 Agent 间消息不应改变下游 Agent 的行为。

这些不变量检查会在相同输入的多次执行中运行。MAESTRO 建议至少进行 20 次重复运行，以刻画方差模式——这足以区分系统性失败与随机噪声。

记录轨迹回放

捕获多 Agent 运行的完整执行轨迹（Trace）：每一条 Agent 间消息、每一个工具调用、每一个中间结果。这个轨迹就变成了一个测试伪像（Artifact）。

当你更改流水线中的一个 Agent 时，在修改后的系统中重放记录的轨迹，并对比输出差异。你寻找的不是完全相同的运行结果，而是被破坏的不变量。新的规划者 Agent 是否产生了编码员 Agent 无法处理的任务分解？更新后的综合器是否丢失了研究员提供的引用？

基于轨迹的回归测试是多 Agent 领域的快照测试：它能捕获组合行为中意料之外的变化，而无需你枚举每一种可能的交互。

针对受控故障的接缝注入

在组合中识别出“接缝（Seams）”——即 Agent 相互交付的节点。在每个接缝处，注入受控的扰动：

• 截断式交付：在不同位置截断上游 Agent 的输出。下游 Agent 是优雅地失败，还是对缺失的上下文产生幻觉？
• 延迟响应：在 Agent 之间引入延迟。编排器是处理超时，还是无限期挂起？
• 矛盾输入：向下游 Agent 提供与上游 Agent 被要求执行的任务相冲突的结果。它是捕获到了不一致性，还是盲目地处理？
• 格式漂移：稍微改变 Agent 间消息的格式。鲁棒的 Agent 会处理微小的变化；脆弱的组合则会崩溃。

这是针对 Agent 组合的混沌工程（Chaos engineering）。其目的不是证明系统可以工作，而是在用户发现故障边界之前将其映射出来。

Agent 接口的契约测试

尽管 Agent 的“契约”是自然语言，你仍然可以将其部分形式化。对于每个 Agent 对 Agent 的接口，定义：

• 必填字段：上游 Agent 必须提供哪些信息？
• 禁止内容：上游 Agent 永远不应包含什么（例如，下游 Agent 不应看到的原始工具输出）？
• 语义约束：交付消息必须满足哪些属性（例如，“必须包含置信度分数”，“不得超过 2000 个 Token”）？

在每个交付边界验证这些契约。这不会捕获所有的组合失败，但它能捕获 Agent 偏离预期接口的那一类失败——这是多 Agent 版本的 API 版本冲突问题。

沉默的大多数：灰色故障

最隐蔽的组合失败不会抛出错误。关于多 Agent 评估的研究发现，75% 的失败表现为“沉默的灰色错误（Silent gray errors）”——系统在没有任何异常的情况下完成，返回一个看起来似是而非的结果，但结果是错误的。其中近一半（48%）是缺失或描述不足的输出，28% 是事实错误。

这些灰色故障是组合特有的。一个不知道答案的单个 Agent 通常会直说。但在组合流水线中，不确定性被“洗白”了：研究员返回了贫瘠的结果，规划者认为这些结果足够了，而综合器则根据不足的证据生成了自信的文字。每个 Agent 都完成了自己的工作，但系统失败了。

捕获灰色故障需要能够理解整个流水线意图的输出验证，而不仅仅是最终 Agent 的输出格式。这意味着要将最终输出的丰富程度与中间结果进行比较以检测信息丢失，检查最终输出中的陈述是否可以追溯到特定的中间 Agent 输出，并根据每个阶段可用的实际证据来衡量输出置信度。

从何处开始

如果你现在正在生产环境中运行多 Agent 系统，你可能根本没有任何组合测试。以下是优先级顺序。

第一步，为每个 Agent 间的交付设置结构化日志埋点。你无法测试你无法观察到的东西。为每条 Agent 间的消息发送一个追踪跨度（Trace span），包括发送者、接收者、消息内容和时间戳。

第二步，为你的流水线定义 3-5 个应该保持的不变量，并将现有的测试用例各运行 20 次。观察其方差。如果你的不变量在所有运行中都保持不变，那么你拥有一个稳定的组合。如果它们间歇性失败，你就找到了第一个组合 Bug。

第三步，为最关键的用户旅程构建轨迹回放。记录生产环境的轨迹（经过脱敏处理），并在每次更新 Agent 时进行重放。这是你的回归安全网。

第四步，针对在生产环境中失败最频繁的交付边界加入接缝注入。你可能已经知道是哪一个了——就是那个产生最令用户困惑的错误的边界。

你不需要一个完整的组合测试套件才能开始捕获组合失败。你需要足够的仪表化手段来观察它们，以及足够的不变量来识别它们。差距不在于工具问题，而在于可见性问题。让组合变得可观测，测试自然会随之而来。