代理系统的非确定性 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）改动的距离。你需要测试的是过程，而不仅仅是终点。

轨迹快照测试在行为已知良好时记录完整的执行追踪（trace）：调用了哪些工具、顺序如何、生成了什么样的推理、访问了哪些中间状态。这成为了你的基准（baseline）。在后续运行中，系统会将新的轨迹与快照进行对比（diff）。

这种对比不是字符串比较，而是一种结构化比较，它能区分：

• 等效排序：智能体先调用了工具 A 后调用工具 B，而不是先 B 后 A，但结果是相同的。这通常没问题。
• 替换：智能体使用了不同的工具来达到相同的子目标。这需要调查。
• 遗漏：智能体跳过了之前轨迹中包含的步骤。这通常是回归（regression）。
• 增加：智能体增加了一个新步骤。这可能预示着推理能力的提升，也可能预示着困惑。

行为指纹识别（Behavioral fingerprinting）通过提取执行追踪的紧凑向量表示，进一步捕捉工具使用模式、决策路径和推理深度。你不再比较单个追踪，而是比较多次运行中指纹的分布。这让你能够使用诸如 Hotelling's T² 之类的多元统计检验，来检测二进制测试（通过/失败）完全无法察觉的行为漂移 —— 研究表明，对于相同的回归问题，指纹识别的检测能力为 86%，而二进制测试则为 0%。

最小可行智能体 CI 流水线

以下是一个实用的非确定性 CI 流水线的样子，按实施优先级排序。

第一阶段：多轮运行语义断言。 将精确匹配断言替换为语义评估器（semantic evaluators），检查输出是否满足意图，而不是是否匹配特定字符串。每个测试用例运行 3–5 次，取中位分数。设定一个阈值。仅此一项就能消除大部分由于非确定性导致的虚假失败。

第二阶段：统计回归门控。 在推送到主分支或进行夜间测试时，运行具有足够试验次数的评估套件，以达到统计置信度。使用 SPRT 来最小化成本。使用双样本检验（two-sample test）将得分分布与上一个已知良好的基准进行比较。标记具有统计显著性的下降。

第三阶段：轨迹指纹识别。 记录关键用户流程的执行追踪。每次部署后，运行相同的流程并比较行为指纹。针对高严重性的结构变化发出警报 —— 工具遗漏、推理路径偏离、意外的错误模式。

第四阶段：持续生产监控。 对实时流量进行采样，并持续运行相同的评估。这可以捕捉到评估集与真实用户查询之间的分布偏移 —— 在这种失效模式下，你的 CI 显示 92% 的成功率，但用户的满意度却只有 40%。

大多数团队应该从第一阶段开始，这可以在一天内完成，并随着系统的成熟逐渐增加阶段。在交付任何产品之前，不要试图构建完整的流水线。

成本问题及其管理

在按 token 计费的系统上多次运行测试是非常昂贵的。一个天真的实现方式 —— 100 个测试用例，每个运行 10 次，由 LLM 裁判进行评估 —— 每次 PR 可能会花费数百美元。这是不可持续的。

三种技术可以使成本保持在可控范围内。

自适应预算优化。 根据实际行为方差而非最坏情况的假设来校准试验次数。稳定的智能体需要较少的试验。跟踪每个测试用例随时间变化的方差，并相应地分配运行次数。研究表明，对于行为一致的智能体，这可以实现 4–7 倍的成本降低。

追踪优先的离线分析。 许多评估 —— 覆盖率检查、契约验证、蜕变测试（metamorphic testing） —— 可以在预先记录的追踪上运行，无需额外的 LLM 调用。记录一次追踪，以多种方式进行评估。这将增加新评估维度的边际成本降低至零。

多保真度代理测试。 使用更便宜、更快速的模型进行初步筛选。一个小模型就能以极低的成本捕捉到明显的回归。只有当代理测试无法得出结论时，才升级到前沿模型（frontier-model）进行评估。这种分层方法意味着你只为真正模糊的情况支付高昂的价格。

结合这些技术，可以在保持相同统计保证的同时，实现 5–20 倍的成本降低。核心洞察在于，天真实现中的大部分成本来自于对答案已经显而易见的测试用例运行昂贵的评估。

这对你的团队意味着什么

非确定性 CI 不仅仅是技术上的改变 —— 它也是文化上的改变。你的团队需要接受以下观点：

• 某些测试运行将是无定论的，这是一种信息，而不是失败。
• 合并决策有时需要基于统计证据的人为判断，而不仅仅是一个绿色的对勾。
• CI 流水线本身也需要监控 —— 不稳定的评估器、漂移的阈值以及代理模型的偏差都是失效模式。
• 成本管理是首要考虑的问题，而不是事后才想到的。

在 2026 年交付可靠智能体系统的团队，不会是那些拥有最全面测试套件的团队。相反，他们将是那些 CI 流水线能够诚实地反映已知和未知信息的团队 —— 将不确定性视为需要管理的信号，而不是隐藏在二进制通过/失败徽章背后的问题。