代理系统的非确定性 CI：为什么二进制的通过/失败模式会失效，以及取而代之的是什么

你的 CI 流水线假设了一件自你加入 LLM 调用以来就不再成立的事情：运行相同的代码两次会产生相同的结果。传统的 CI 是为确定性软件构建的 —— 编译、运行测试、获得绿灯或红灯。传统的 ML 评估是为固定的输入输出映射构建的 —— 对测试集进行推理、计算准确率。Agent AI 同时打破了这两个假设，其结果是一个要么对你撒谎，要么因误报而阻塞每次合并的 CI 系统。

核心问题不在于 Agent 难以测试，而在于你现有的测试基础设施是为一个“非确定性是 Bug 而非特性”的世界设计的。当你的 Agent 在连续运行中通过不同的工具调用路径得到相同的正确答案时，确定性断言就会失败。当它产生语义等效但词汇不同的响应时，字符串比较会将其标记为回归。测试框架本身变成了噪音的来源。

CI 的三个假设及其在 Agent 中被打破的情况

传统的 CI 流水线基于三个隐含假设，而 Agent 系统在每次运行时都会违反这些假设。

假设 1：相同的输入，相同的输出。 即使在 temperature 为 0 时，LLM 的输出也会有所不同。2025 年的研究表明，即使在强制执行确定性配置的情况下，重复的相同推理运行中准确率波动也高达 10%。GPU 操作中的浮点非确定性、批处理效应以及提供商侧的基础设施差异都是原因。你的 Agent 不仅仅会产生不同的文本 —— 它可能会选择不同的工具，采取不同的推理路径，并达到不同的中间状态。

假设 2：测试是二进制的。 传统的单元测试要么通过，要么失败。但是当一个 Agent 产生一个 85% 正确的响应时 —— 结论正确，中间推理错误 —— 结论是什么？当它以不同的顺序调用正确的工具并仍然得到正确答案时，这是通过还是回归？二进制断言迫使你将质量光谱坍缩为两个桶，而这两个选择都是错误的。太严格，你会淹没在错误的失败中；太宽松，真正的回归就会溜走。

假设 3：单个测试结果是独立的。 在确定性代码中，如果测试 A 通过且测试 B 通过，则系统正常工作。但 Agent 系统具有涌现行为。单个 Agent 可以通过每一项能力测试，而组合系统却会以单 Agent 分析无法预测的方式失败。当 Agent 相互作用时，状态空间呈指数级增长，CI 关于可以孤立测试组件的假设就失效了。

统计判定取代二进制断言

替代二进制通过/失败的是三值概率判定系统：通过 (Pass)、失败 (Fail) 和不确定 (Inconclusive)。这不是一种妥协 —— 而是承认某些测试运行确实没有包含足够的信息来做出决定。

该框架借鉴了临床试验方法论。你预先定义两个错误率：alpha（在不存在回归时宣布回归的概率）和 beta（错过真实回归的概率）。然后，你不再运行一次测试，而是运行多次并积累证据。

实际问题是：运行多少次？在固定所有随机性的情况下，对相同数据运行 10 次评估流水线是一个合理的基准。计算变异系数 (CV) —— 标准差除以平均值 —— 并将目标 CV 设定在 0.05 以下。如果你的平均分数是 80%，那么运行之间的变化应保持在 4 个百分点以内。

对于生产级的信心，数学要求更高。在 95% 的置信度、5% 的误差幅度且预期指标约为 80% 的情况下，你大约需要 246 个样本。将误差幅度降低到 2.5%，则需要 984 个。大多数团队无法在每次 PR 中负担得起。

实际的解决方案是 Wald 序贯概率比检验 (SPRT)，它改编自制造业的质量控制。SPRT 不再预先承诺固定的试验次数，而是在积累了足够的证据（支持或反对回归）后立即终止测试。针对这种方法的研究显示，在 Agent 测试场景中，SPRT 始终能减少 78% 的所需试验次数。对于在标准错误率下检测 10% 的回归，SPRT 将预期试验次数从大约 109 次减少到 34–52 次，具体取决于 Agent 是否真的发生了回归。

这意味着当答案明确时（Agent 显然正常或显然损坏），你的 CI 流水线运行的试验次数较少；只有当行为真正处于边界时，才会运行更多试验。干净的更改快速合并，模糊的更改则进行刻意调查。

分级阈值：软失败区

即使有了统计判定，你仍然需要决定什么构成了“通过”。最有效的模式是用分级阈值取代二进制门控。

LLM-as-judge 的评估返回 0 到 1 之间的分数。定义三个区域：

• 硬失败 (Hard failure)（低于 0.5）：阻止合并。显然出了问题。
• 软失败 (Soft failure)（0.5 到 0.8）：允许合并，但标记为待评审。该更改是模棱两可的 —— 它可能是一个真实的回归，也可能是一个可接受的行为变化。
• 通过 (Pass)（高于 0.8）：自动合并。

具体阈值取决于你的风险承受能力和领域。医疗 Agent 需要比内容摘要器更高的硬失败阈值。关键的见解是，软失败区是存在的 —— 它是对某些更改需要人类判断而自动化系统无法替代的明确承认。

将这些阈值连接到你的 CI 中，使硬失败阻止 PR，软失败添加警告标签并需要额外的评审人员，而通过则正常进行。这既保持了开发者在干净更改时的速度，又能捕捉到真实的回归。

智能体轨迹快照测试

输出的正确性是必要条件，但并非充分条件。一个通过完全不同的执行路径返回正确答案的智能体可能没问题 —— 或者它可能距离灾难性的失败仅有一个提示词（prompt）改动的距离。你需要测试的是过程，而不仅仅是终点。

加载中…