AI Agent的CI难题：分数波动到底该不该阻断PR？

在传统软件测试中，一次通过就是通过，失败就是失败，判断标准非黑即白。但当被测对象换成AI Agent时，这套确定性逻辑彻底失灵了——同一个Agent、同一份代码，跑两次可能得出完全不同的结果。一位从事Agent持续集成（CI）工作的开发者在Reddit分享了他踩过的坑，并开源了应对方案AgentSeism。

问题的根源：Agent评估的非确定性

这位开发者最初低估了一个事实：同一个Agent在代码毫无变化的情况下，也能产生显著不同的评估结果。

他给出了一个真实案例：一个编码Agent在没有任何改动的情况下，成功率从92%掉到了88%。如果按照传统CI的思路，这4个百分点的下降就足以阻断（block）这次PR合并。但这其实是一次误报——分数波动只是Agent本身随机性的体现，而非真实的能力退化。

如果只是简单地设一个阈值，比如"成功率下降超过X%就拦截"，那么这类正常波动会不断触发假警报，让整个CI流程变得不可信。

反向的陷阱：真正的退化反而溜了过去

更棘手的是相反的情况。作者故意把Agent的能力"做坏"，成功率从92%暴跌到52%——这是一次实实在在的严重退化。然而他最初设计的统计规则却放行了这次PR。

原因在于：这次退化的"伤害"集中在少数几个任务上，而不是均匀分布在整个测试套件里。从整体统计分布看，套件的平均可靠性变化没有触及阈值，规则于是认为"没问题"。

这个矛盾暴露了一个被混为一谈的关键区别。作者意识到，必须把评估拆成两个独立的问题：

• 整个套件的可靠性是否普遍变差了？（reliability broadly worse）
• 某个原本稳定可用的能力是否突然崩溃了？（a capability collapsed）

只用一条平均值规则，永远无法同时回答这两个问题。第一种问题需要看整体趋势，第二种问题需要盯住单点崩塌。

把PR当成实验，而不是确定性测试

作者最终的思路转变很有启发性：不再把PR看作一个确定性测试，而是把它当成一场实验来处理。

这套方法论融合了几个统计实验设计的核心要素：

重复运行（Repeated runs）

单次运行的结果不可信，必须多次运行来估计真实的成功率分布，把随机噪声和真实信号区分开。

实际效应阈值（Practical effect thresholds）

不追求任何微小差异都被检测出来，而是设定一个"有实际意义"的效应大小门槛，避免对无关紧要的波动过度反应。

统计显著性（Statistical Significance）与实际显著性（Practical Significance）的区分，是这套方法论的核心理念之一。传统假设检验只回答"观测到的差异是否可能由随机性造成"，而不回答"这个差异是否足够大到值得关注"。在样本量足够大时，哪怕0.1%的成功率下降也能达到统计显著，但这对实际应用毫无意义。实际效应阈值（也称为最小可检测效应，MDE）的设定，要求工程师事先定义"多大的退化才算真正有问题"——例如"成功率下降超过5个百分点才触发阻断"。这迫使团队在业务语境中思考质量标准，而非盲目依赖统计p值，从根本上避免了对Agent日常随机波动的过度响应。

不确定性与多重性（Uncertainty & multiplicity）

显式建模结果的不确定性，并处理跨多个能力维度同时比较时的多重检验问题（multiplicity）——这正是为了捕捉"单个能力崩溃"的场景。

多重检验问题（Multiple Testing Problem）是统计学中的经典陷阱：当你同时对多个假设进行检验时，即使每个单独检验的误报率只有5%，随着检验数量增加，整体误报率会急剧攀升。比如同时检验20个能力维度，即使Agent能力没有任何变化，平均也会有1个维度"看起来"显著退化。常见的校正方法包括Bonferroni校正（将显著性阈值除以检验数量）和Benjamini-Hochberg方法（控制假发现率FDR）。在Agent评估场景中，这个问题尤为突出——一个Agent往往需要在代码生成、工具调用、推理规划等多个能力维度上同时被评估，不加校正地逐一检验每个维度，必然导致大量假警报。AgentSeism显式处理这一问题，正是为了在多维度评估中仍能可靠地定位真实的单点崩溃。

显式的"证据不足"状态

这是最值得称道的设计。系统不是只有"通过"和"失败"两种结果，而是引入了第三种明确状态：证据不足（insufficient evidence）。当数据无法支撑一个可靠判断时，系统坦承"我不知道"，而不是强行给出一个可能错误的结论。

AgentSeism：开源的Agent回归检测工具

作者把这套推理和踩过的坑写成了博客，并将工具以AgentSeism之名开源到GitHub。工具名中的"Seism"（地震）颇为形象——它要做的正是检测Agent能力版图中那些真实的、结构性的"地震"，同时忽略日常的背景噪声。

对于任何在生产环境中运行Agent、并试图为其建立CI/CD流程的团队来说，这个问题都无法回避。作者在帖子结尾抛出的问题也直指行业痛点：

如果你今天在CI里跑Agent，你是如何判断一次分数下降"真实到足以"阻断合并的？

这个问题目前没有标准答案。传统软件工程的确定性思维在概率性的AI系统面前失效了，而如何在"漏报真实退化"和"误报正常波动"之间找到平衡，将是LLM应用工程化必须解决的基础设施难题。

对AI工程化的启示

这个案例的价值超出了工具本身。它揭示了一个更普遍的趋势：随着AI Agent进入软件开发的核心流程，我们的整个测试和质量保障范式都需要重构。

从确定性测试到统计实验，从二元判断到三态输出（通过/失败/证据不足），这些转变本质上是在承认AI系统的概率本质。任何试图用传统CI思路强套Agent评估的团队，迟早会遇到作者描述的这两类错误。AgentSeism提供的不只是一个工具，更是一套值得借鉴的思维框架。