你的规划智能体（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）：
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- 完整文章，包含未公开存档的部分
- 可落地的工作框架，附带权衡与决策依据
- 新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部