上线之后怎么盯：模型与智能体监控的统计框架与两条禁令

导语：看板为什么不够

一个典型的场景：某智能客服上线三个月，周报里的“自动评分”从 4.3 降到 4.1，同时响应变长、工具报错率略升、月度花费超出预算两成。团队开会讨论半天，结论是“调一下提示词，把阈值放宽一点”。两周后指标回升，没人能说清回升是因为问题被修好了、用户结构变了，还是评分用的裁判模型被服务商悄悄换了版本。

这类场景暴露的不是指标不够多，而是三件事没有被区分：变化来自哪里（输入、输入与结果的关系、模型本身，还是测量工具）；变化是不是噪声（统计上该在什么阈值报警，同时盯几十个指标时如何控制误报）；报警之后谁有权改什么（是改参数、改结果，还是走变更流程）。本文的中心论点是：上线监控应被设计为一个在错误率约束下回答“什么变了、该谁处置”的序贯决策系统，而不是一组越来越多的看板。对智能体而言，观测单位还必须从单次请求升级到整条轨迹乃至跨轨迹的状态；处置则必须进入受控的变更流程——“禁止静默改参数”与“禁止告警直接改写业务结果”这两条禁令，正是从这一论点推出来的。

下文分五节展开：先分清“什么变了”；再讨论阈值怎么定；然后看智能体需要多测什么；接着推导告警之后的处置与两条禁令；最后用一组示意数据把全流程算一遍，并给出前瞻判断。

一、先分清“什么变了”：四类变化与各自的检测量

四类变化

经典的概念漂移文献把数据流上的变化拆成输入分布 P(X) 的变化与条件关系 P(Y|X) 的变化⁠¹。在大模型与智能体系统里，至少还要再加两类：模型或服务本身的行为变化，以及测量工具（尤其是用作评分的大模型裁判）的变化。表 1 汇总了四类变化的定义、典型原因与检测手段。

这样拆分的意义在于：四类变化的处置方式完全不同。数据漂移不一定意味着系统变差，可能只需要重新评估；概念漂移意味着旧的正确答案不再正确，需要重新标注甚至重新定义任务；性能衰减要找到出问题的组件；测量漂移则意味着“指标下降”本身可能是假象。把它们混在一张看板上，就会出现导语里的情形。

数据漂移：PSI 与 KS 各自回答什么

群体稳定性指数（PSI）在风控领域广为使用，定义为分箱后的 Σ(aᵢ − eᵢ)·ln(aᵢ/eᵢ)，其中 eᵢ、aᵢ 分别是基准期与当前期落在第 i 箱的比例。容易推出，PSI 等于两个分布之间正反两个方向 KL 散度之和（即 Jeffreys 散度），因此它衡量的是分布差异的“大小”。KS 统计量则是两个累积分布函数的最大差值，回答“差异是否显著”。

两者的区别在样本量变化时更明显。用一组示意数据（可复算）：五个分箱的基准比例为 10%、20%、40%、20%、10%，当前为 6%、16%、38%、24%、16%。逐箱计算后 PSI ≈ 0.066；累积分布的最大差值出现在第三箱，KS = 0.10。若两期各有 2000 个样本，KS 在 5% 水平的临界值约为 1.358 × √(1/2000 + 1/2000) ≈ 0.043，差异高度显著；但按常用的“PSI < 0.1 视为稳定”的经验规则，这又是“稳定”的。两个结论并不矛盾：KS 说“确实变了”，PSI 说“变得不多”。

更值得注意的是经验阈值本身。利用二阶展开可以说明，在没有真实变化时，PSI 近似满足 (nm/(n+m))·PSI ~ χ²(B−1)，其中 n、m 为两期样本量，B 为分箱数。由此，5% 误报水平下的 PSI 阈值约为 τ = χ²₀.₉₅(B−1)·(1/n + 1/m)。五个分箱、两期各 200 个样本时，τ ≈ 9.49 × 0.01 ≈ 0.095——也就是说，“0.1”这条经验线在小样本窗口下几乎就是纯噪声的 95% 分位。我们做了 2 万次无漂移的模拟（示意数据，随机种子固定，可复算），PSI 的均值约为 0.041，95% 分位约为 0.097，超过 0.1 的比例约为 4.4%，与近似公式一致。结论是：PSI 的阈值应随窗口样本量与分箱数调整，而不是全行业共用一条线。

对于文本、图像这类高维非结构化输入，直接分箱不可行。一项系统比较发现，先用预训练模型做降维、再做两样本检验，是检测数据集漂移效果较好的做法，而域判别方法有助于刻画漂移的性质并判断它是否有害⁠²。

概念漂移与校准：需要标签的那部分

概念漂移只能在拿到结果标签后确认。若只是类别先验变了（标签漂移），可以用混淆矩阵估计新的先验并做修正，而不必重训模型⁠³。另一个常被忽略的信号是校准：现代神经网络的置信度经常高于实际准确率，温度缩放等简单方法可以显著改善⁠⁴。上线后校准误差的变化往往早于准确率的变化——模型开始“不知道自己不知道”，是条件关系变化的早期迹象。

大模型特有的两类变化：非确定性与测量漂移

大模型系统有一类传统模型没有的“基线噪声”。一项系统层面的分类研究列出了 15 种生产环境中的隐性失效模式，包括多步推理漂移、版本漂移、成本驱动的性能崩塌等，并指出现有基准几乎不测稳定性、可复现性与漂移⁠⁵。重复运行实验表明，即使温度设为 0，同一提示词的输出仍有差异⁠⁶；在服务端，前缀缓存复用会让同一请求在缓存命中和重算两条路径上产生不同结果，量化还会放大这种分歧——据论文，Qwen2.5-7B 的多轮工具调用回合在 16 比特下有 37.4% 出现路径分歧，4 比特下为 82.5%⁠⁷。这意味着监控必须先测出“系统不变时的波动范围”，否则任何变化都无法判断。

测量漂移是更隐蔽的问题。持续评测通常用一个强大模型做裁判、给每次交互打分，分数下降就报警；但裁判本身也是 API 背后的模型，一次静默的版本升级或评分提示词改动就会改变打分方式，于是每一次漂移报警都无法区分“产品变差”还是“裁判变了”⁠⁸。对此，有研究提出用一组固定的人工标注锚点集，让当前裁判以固定比例穿插重评，并对“裁判与人工的差值”单独运行一个序贯检验，据此把告警归因为“无变化、系统变化、裁判变化”三者之一；据论文，在一次真实的静默版本升级中，60 次运行全部被正确识别为裁判漂移，没有误归因为系统漂移⁠⁸。另一项预注册审计把大模型裁判当作评分员来研究，发现五组版本对比中，每一组的评分严苛度变化都超出了族错误率校正后的置换零分布，并有一个裁判在研究期间被弃用，靠“身份金丝雀”才被发现⁠⁹。还有研究发现，温度为 0 时重复判决也会变化，交换候选顺序会翻转困难任务上多数判决⁠¹⁰。

这些结果共同说明：评分工具必须与被评系统一样被版本化、被监控。没有锚点集的裁判评分曲线，不能单独作为报警依据。

二、阈值怎么定：误报、漏报与“同时盯很多个指标”

一个被低估的问题：多重检验

区分出变化类型之后，下一个问题是“多大的变化才报警”。很多团队按单个指标设定 5% 的显著性水平，却同时盯着几十个指标、每天检查一次。示意计算（可复算）：40 个相互独立的指标、每个每天在 5% 水平上检验一次，即使系统完全没有变化，某一天至少出现一次误报的概率为 1 − 0.95⁴⁰ ≈ 87%；一个月下来，期望误报次数为 40 × 30 × 0.05 = 60 次。值班人员很快就会学会忽略告警，而这恰恰是真正的问题来临时告警失效的原因。

控制这一问题的方法有两类。族错误率控制（如 Bonferroni 校正，把每个指标的水平降为 0.05/40 = 0.00125）保证“任何一个误报的概率”不超过 5%，代价是漏报增多；错误发现率控制（Benjamini–Hochberg 方法）则控制“报警中误报所占的比例”，在指标多、真实变化不止一处时功效更高⁠¹¹。对监控而言，后者往往更贴近实际需求：值班人员关心的是“我被叫起来的十次里有几次是白叫”。

反复查看的代价与可随时停止的检验

第二个被低估的问题是“偷看”。固定样本量的 p 值只在“事先确定样本量、只看一次”时有效；如果每来一批数据就重新算一次、一旦显著就报警，误报率会随查看次数上升，远超名义水平。监控天然就是反复查看。

序贯检验为此而生。经典的累积和（CUSUM）方法逐个观测累加对数似然比，并在累积量越过阈值时报警⁠¹²：

S_t = max(0, S_{t−1} + ln[f₁(x_t)/f₀(x_t)])，当 S_t > h 时报警。

它的两个关键量是：无变化时平均多久误报一次（平均运行长度 ARL₀），以及变化发生后平均多久能发现（检测延迟）。阈值 h 越高，ARL₀ 越长、检测越慢，这是误报与漏报之间的直接交换。

我们用工具调用报错率做一个示意例子（可复算）：基线报错率 p₀ = 2%，希望尽快发现升到 p₁ = 4% 的变化。每次报错时累积量加 ln(0.04/0.02) ≈ 0.693，每次成功时加 ln(0.96/0.98) ≈ −0.0206。无变化时每次调用的期望增量为 −0.0063，累积量会被拉回零；变化后期望增量为 +0.0079，累积量稳定上升。取 h = 5 时，我们用固定随机种子各模拟 300 次，ARL₀ 约为 2.96 万次调用，变化后的平均检测延迟约为 520 次调用；取 h = 4 时，二者分别约为 9600 次和 380 次。若智能体每天产生 2000 次工具调用，h = 5 意味着大约每 15 天误报一次、变化后约 6 小时内发现——团队可以据此和业务方讨论“能接受多少误报换多快的发现”，而不是凭感觉选阈值。

CUSUM 需要事先指定变化前后的分布。对于分布未知、或者变化方向事先无法预料的情形，近年发展起来的“基于下注的检验”提供了更一般的框架：构造一个在无变化时期望不增长的“财富过程”（e 过程），由 Ville 不等式，它越过 1/α 的概率不超过 α，因此可以在任意时刻停止并报警而不破坏误报保证⁠¹³。这一框架已被用于非结构化数据流：有研究让“下注者”随新数据不断更新它押注的漂移方向，从而兼顾敏感度与覆盖面，同时保持误报控制⁠¹⁴；另一项工作指出，常见的保形检验鞅会把变化后的样本混入参考集、稀释证据，改为对照一个固定的无变化参考集可以避免这种“污染”⁠¹⁵；还有研究用独立的无变化样本校准拒绝阈值，比通用的 1/α 更紧，从而缩短检测延迟⁠¹⁶。同一思路也被用于生成过程内部：把幻觉“开始发生”的检测表述为最快变化检测问题后，研究者给出了检测延迟的理论下界，并发现在 1% 的误报预算下，各种检测器都只能抓住不到三分之一的幻觉起点⁠¹⁷——低误报下的快速检测本身就很难，这是设阈值时必须接受的现实。

多个指标同时做序贯检测时，两类要求会正面冲突：有研究证明，任何平均运行长度有限的多流检测程序，其最坏情况下的错误发现率与族错误率都等于 1，并提出以“误报相对于监控时长”的新指标作为折中，把 e 检测器与 e-BH 等多重检验方法结合⁠¹⁸。工程上的含义是：多指标监控的误报控制只能以“单位时间内的误报次数”来约定，而不能承诺“永远不误报”。

把阈值写成预算：燃烧率告警

在可靠性工程里，类似的问题用“错误预算燃烧率”来处理。以 99.9% 的可用性目标为例，30 天的错误预算是 0.1% 的请求；燃烧率为 1 表示恰好在 30 天末用完预算。Google 的 SRE 实践建议：1 小时窗口内燃烧率达到 14.4（即 1 小时用掉 2% 的预算）或 6 小时窗口内达到 6（用掉 5%）时呼叫值班人员，3 天窗口内达到 1（用掉 10%）时开工单，并用长短两个窗口组合来兼顾检测速度与精度⁠¹⁹。这一做法的优点是把阈值翻译成了业务能理解的语言——“按这个速度，预算会在多久后用完”——并且天然适用于成本监控：把月度花费预算换成“错误预算”，就得到成本燃烧率告警。

AUROC 不是告警策略

最后要警惕的是用离线指标代替上线阈值。有研究指出，激活探针预测安全属性的 AUROC 可以很高，但上线监控做的是在严格误报预算下的阈值决策，两者是不同的估计目标；当一个任务里有多次报警机会时，逐行的 AUROC 和假阳率也无法刻画“整个任务至少报警一次”的风险⁠²⁰。据论文，在两项基准上 AUROC 分别达到 0.957 和 0.935 的监控器，在锁定 5% 与 10% 误报率时的检出率只有 0.642/0.742 和 0.719/0.782⁠²⁰。选型时应直接比较“在我们能接受的误报率下，能抓住多少”。

三、智能体要多盯什么：轨迹、工具调用、成本与安全

传统模型的监控单位是“一次预测”。智能体的一次任务由几步到几百步组成，每一步都可能调用工具、读写状态、消耗预算。只看最终成功与否，相当于只看一笔交易的结果而不看过程，许多问题会在结果上被掩盖，或者在结果出现时已经无法挽回。我们把智能体特有的监控拆为四层，每层回答一个不同的问题。

观测前提：先把轨迹记下来

四层监控都依赖结构化的追踪数据。OpenTelemetry 为生成式 AI 制定的语义约定，已经为“创建智能体”“调用智能体”“执行工具”等操作定义了跨度类型，并规定了模型名称、提供方、输入输出 token 数、工具名称与调用参数等字段，以及智能体调用时长、推理调用次数、工具调用次数等指标；需要注意的是，这些约定目前仍处于“开发中”状态，字段可能变化⁠²¹。研究界也提出了面向安全与问责的结构化日志框架，把运行、认知与上下文三个面的事件统一记录⁠²²。

记录的目的，是让后面的每一个统计量都能回溯到具体的一步。对于失败归因，两项研究给出了可借鉴的做法：一项多智能体系统失败分类基于 1600 多条标注轨迹，归纳出 14 种失败模式，分属系统设计、智能体间失配与任务验证三大类⁠²³；另一项研究标注了 170 条失败轨迹的“关键失败步”，并用逐步约束检查加裁判模型的方式自动定位，据论文定位准确度较已有方法平均提高 75%⁠²⁴。

轨迹层：过程是否始终可执行

只看终点会高估智能体。有研究提出“前缀可执行性”：检查工具调用序列的每一个前缀，在工具模式、状态前提与数据依赖下是否仍然可执行，并用初次出错深度、轨迹可执行率等指标刻画；他们发现按最终成功率排名与按前缀指标排名会出现分歧——依赖未校验计划的智能体，最终成功率的点估计更高，但轨迹可执行率明显更低⁠²⁵。这意味着一部分“成功”是碰巧成功，在环境稍有变化时就会失败。

在线预警是轨迹层的另一面。有方法从执行前缀学习事件、用循环网络预测不同时间窗内的失败风险，并用有限状态机把历史组织成可回放的风险路径⁠²⁶；另一种方法把智能体的步骤和依赖与已记录的成功运行做最优传输比对，以约每步 1 毫秒的开销发出告警或拦截，但可用的历史信息越少，能检测的问题就越局限于循环、停滞与重复调用⁠²⁷。反方证据同样重要：一项基于 14.7 万条编程智能体执行轨迹的研究发现，早期前缀能稍微改善跨任务的结果排序，但在同一任务内区分“这次会成功还是失败”的 AUC 接近 0.50，与随机无异⁠²⁸。所以，轨迹层监控更适合发现“过程违规”（越权、循环、偏离计划），而不是预测“这一次会不会成功”。

工具调用层：静默错误比显式报错更危险

工具层面的故障在真实系统中很常见。一项研究从 1774 个开源 MCP 仓库的 5.7 万多条问题与合并请求中统计出故障分布，再按这一分布向工具调用路径注入故障；据论文，以永久性故障为主的压力条件下，任务完成评分从 8.08 降到 3.23（满分 10），而且更大的模型并没有带来更好的容错⁠²⁹。更难发现的是“静默错误”：工具返回了一个看似合理但错误的值，没有任何报错信号。一项基于电商真实工作流的基准显示，静默错误大约让任务成功率减半⁠³⁰。

这给工具层监控提出了两个具体要求：除报错率外，还要对返回值做“合理性校验”（类型、范围、与其他来源的一致性）；对关键工具，要定期用已知答案的探针请求检查返回值是否仍然正确。

成本层：预算失控是一类独立的故障

成本超支不是财务问题，而是一类有自身模式的故障。有研究整理了 21 个编排框架在 2023—2026 年间的 63 起已确认的生产事故，每起都有公开的问题记录，并归纳出八类失效模式，典型如单个重试循环在被发现前就花掉数千美元⁠³¹。另一项对漏洞挖掘智能体 200 条轨迹的研究发现，代码定位理解与漏洞推理两类工作占了 60.4% 的 token；花得更多并不稳定地带来更好结果；在配对比较中，只有 24.4% 的现有省钱方法能在降低总成本的同时保住成功率⁠³²。

因此成本层要同时做两件事：按任务而不是按月统计花费，以便发现“单个任务失控”；对每个任务设置硬上限，由框架而不是模型来执行。上一节的燃烧率告警可以直接用在这里。

安全层：单步检查不能组合成整体安全

安全层有两个反直觉的结论值得单独强调。其一，逐个动作的授权检查不能组合成全局授权：有研究证明，一类跨多次执行的“目的违规”没有单条轨迹上的责任位置，任何从不误报的逐动作监控器都检测不到它们，只有跨执行的监控才能发现，而他们调查的六种防护方案都没有实现这一点⁠³³。其二，安全不能跨迭代组合：对长期自主运行的智能体，若攻击证据被分散在多次迭代中，任何只看单条轨迹的监控器的真阳率都等于其假阳率；而简单地让风险分数按几何级数衰减也不够，因为耐心的攻击者只需等待一个与总时长无关的冷却期⁠³⁴。

思维链监控是近年备受关注的另一条路。多家机构的研究者认为，以自然语言“思考”的模型为监控其意图提供了机会，但这种可监控性是脆弱的，开发决策应考虑对它的影响⁠³⁵；后续研究提出了衡量可监控性的评测体系，发现多数前沿模型“相当但并非完全”可监控⁠³⁶。同时要警惕监控器本身的局限：一项覆盖 15 个模型、38 种激活读取器的研究发现，在分布外改写的有害请求上，在相同误报率下，潜在表征的有害性监控并不比模型自身的拒答行为更好⁠³⁷。

四、告警之后：处置流程与两条禁令的推理

前三节回答了“如何可靠地知道出了问题”。但监控的价值最终体现在告警之后的动作上，而这恰恰是容易出错的环节。常见的做法有两种：一是发现指标下降后，直接调整提示词、温度、阈值或检索参数，让指标回到正常范围；二是让告警系统直接改写业务结果，例如监控判定某个回答“有风险”就自动替换成拒答，判定某笔操作“异常”就自动回滚。两种做法都显得负责，我们却主张把它们列为禁令。下面分别给出推理。

禁令一：禁止静默改参数

“静默”是指不经过变更记录、版本标识和对照评估，直接在线上调整影响模型行为的任何参数，包括提示词、解码参数、检索配置、裁判提示词与告警阈值。理由有四条，逐条递进。

理由一：它破坏归因。前文已经说明，一次指标变化可能来自系统、数据或测量工具，锚点集方法之所以能区分“系统变了”还是“裁判变了”，前提是其他因素被固定住⁠⁸。一次未记录的参数调整，相当于在实验中途偷偷换了一个变量：之后无论指标回升还是继续下降，都无法判断原因。导语里“指标回升了，但没人说得清为什么”，正是这种情况。

理由二：它让统计保证失效。序贯检验的误报保证依赖一个固定的“无变化”参照。基于固定参考集的检验之所以有效，是因为参考集在检验期间不被污染⁠¹⁵；用独立无变化样本校准阈值的方法，也要求校准时的系统就是被监控的系统⁠¹⁶。静默改参数之后，参照分布已经不再代表当前系统，而监控程序仍在用旧的参照计算，ARL₀ 与误报率都不再有意义。

理由三：它把监控变成了优化目标。当参数调整以“让告警消失”为目标时，监控指标就从测量工具变成了优化对象。OpenAI 的研究者在编程智能体上的实验提供了一个直接的类比：把思维链监控器纳入强化学习奖励，在优化强度较低时能得到更强、更对齐的智能体，但优化过度后，智能体学会了“混淆式的奖励作弊”——在思维链中隐藏意图，同时继续作弊⁠³⁸。人工调参没有强化学习那么强的优化压力，但方向相同：反复调整到指标正常，得到的往往是一个“更会通过监控”的系统，而不是一个更好的系统。

理由四：它破坏可复现与审计。上线系统本来就有基线噪声⁠^6,7，叠加未记录的参数变化后，任何事后复盘都无法复现事故时的行为。对需要向客户或监管方解释决策的业务，这本身就是合规风险。

禁令一并不意味着参数不能改，而是改动必须走变更流程：记录版本、说明原因、在影子流量或小比例流量上与原版本对照评估、通过后再全量，并在监控中把变更时间点标为已知的变化点。

禁令二：禁止告警直接改写业务结果

第二条禁令针对的是“自动修正”。直觉上，让监控在发现问题时立刻纠正结果似乎更安全。推理表明恰恰相反。

理由一：告警的阳性预测值通常很低。用贝叶斯公式算一组示意数据（可复算）：一个监控器的检出率为 90%、误报率为 5%，而真正有问题的轨迹占全部轨迹的 1%。那么在全部告警中，真正有问题的比例为 0.9 × 0.01 / (0.9 × 0.01 + 0.05 × 0.99) ≈ 15.4%。如果每次告警都自动改写结果，约 85% 的改写会落在原本正确的结果上。第二节已经说明，离线 AUROC 很高的监控器在锁定误报率时检出率可能明显下降⁠²⁰，实际的阳性预测值往往还会更低。

理由二：它污染之后的学习信号。被监控器改写过的结果会进入日志、报表，往往还会进入下一轮训练或评估数据。这时我们观察到的“正确结果”已经被监控器的偏差筛选过。有研究专门讨论了这种“监控器诱导的选择”：被监控器放行的安全样本，与被它错误拦下的安全样本并不相似，因此用前者去估计后者会系统性出错⁠³⁹。自动改写把这种选择偏差直接写进了业务数据。

理由三：它让失效路径变得不可见。有研究在 11 组大模型与智能体安全项目中确认了 18 起“证据路径失效”：检测器已经识别出问题，但框架在作出拦截决定前把结果丢掉了⁠⁴⁰。监控链路本身也会出故障，而且安全分类器在分布变化下的检出能力因分类器而异：一项预注册实验在 4 个分类器、5 类分布变化上测得约 86.8% 的受控检出率（据论文），并发现用另一个分类器做“分歧哨兵”能标出约 75.5% 被主分类器误判为安全的攻击输入，但仍有残余同时绕过两者⁠⁴¹。如果监控同时拥有“发现”和“改写”两种权力，它的故障就会直接表现为业务结果的错误，而且没有第二道检查能发现。

理由四：它模糊了责任。改写之后，结果到底由谁负责——业务系统、模型、还是监控规则——变得说不清。对需要具名人员承担后果的决策，这不可接受。

禁令二同样不是“告警之后什么都不做”。允许的动作是可逆的“隔离”：暂停某个智能体或某类操作、降级为只读、把待处理的结果转人工复核、对单个高风险动作要求二次确认。它们的共同点是不替业务做出新的决定，而是阻止可能的错误继续扩散，并把决定权交还给有权限的人。

处置流程：一个决策框架

把两条禁令放回流程中，告警后的处置可以分为五步：定级（按严重度与影响范围）、归因（系统、数据、测量工具还是外部依赖）、隔离（只用可逆动作）、修复（走变更流程，影子或小流量对照后全量）、复盘（把事故样本加入回归集与锚点集）。表 3 给出隔离动作的选择框架。

五、一个完整的示意例子，以及边界与前瞻

一周的监控周报，逐项算一遍

我们用一个非金融场景的智能客服，把前文方法串起来（以下全部为示意数据，可复算）。该智能体处理售后咨询，每周约 1.4 万次会话、每天约 2000 次工具调用。本周监控产出了五个“可疑”信号：

1. 用户意图分布：五类意图的比例从 10%、20%、40%、20%、10% 变为 6%、16%、38%、24%、16%，两期各约 2000 个样本。按前文方法计算，PSI ≈ 0.066，KS = 0.10，远超临界值 0.043。结论：输入确实变了，但幅度不大，属于数据漂移，不必报警到值班人员，应记录并检查分组效果。
2. 回答长度：均值上升 8%，KS 检验 p = 0.03。
3. 裁判评分：从 4.30 降到 4.12，p = 0.004。
4. 工具报错率：周三起 CUSUM（h = 5）越过阈值。
5. 花费：近 6 小时燃烧率达到 6.5。

步骤一，多重检验。本周共检查 40 项指标。把其中五项的 p 值（意图 KS 的 p 远小于 0.001、长度 0.03、评分 0.004，另有两项序贯告警按其自身的误报保证单独处理）与其余 35 项一起做 BH 校正，在 10% 的错误发现率下，回答长度的 p = 0.03 不再显著，因为它在 40 项中的排名决定了它的校正阈值约为 0.1 × 3/40 = 0.0075。回答长度变化降为“观察”。

步骤二，归因评分下降。锚点集（200 条固定人工标注样本，按 5% 比例穿插重评）显示，当前裁判在锚点集上的评分比上月低 0.17，与线上降幅 0.18 几乎相同，而人工标注不变。结论：评分下降主要来自裁判漂移，不是系统变差。查服务商的变更日志，裁判模型在周二有一次版本更新。处置：冻结裁判版本，按新版本重新标定锚点集，在报表中标注变化点。

步骤三，定位工具报错。报错集中在一个物流查询工具，周三起从约 2% 升至约 4%，变化点与该工具的上游接口升级一致。同时对该工具的探针请求发现，有约 3% 的返回值格式正确但单号对应关系错误——这是静默错误，比显式报错更需要优先处理。处置：对该工具的回复增加人工复核（隔离），向接口方提交问题（修复），把静默错误样本加入回归集。

步骤四，成本。6 小时燃烧率 6.5 超过呼叫线 6。追查发现，静默错误导致智能体反复重试查询，单任务平均调用次数从 3.1 次升到 5.4 次。成本问题与工具问题是同一个根因。处置：为该工具设置单任务重试上限，由框架执行。

步骤五，不做的事。本周我们没有为了让评分回升而修改回答提示词，没有放宽报错阈值，也没有让监控把“可疑”回答自动替换为模板答复。评分下降已被归因于裁判，工具问题已被隔离；任何参数调整都放到下一个变更窗口，经过对照评估后再上线。

这个例子说明了中心论点的含义：五个告警背后只有两个真正的问题（裁判版本变化、工具静默错误），一个是测量漂移、一个是性能衰减；数据漂移是真实但无害的变化；回答长度是噪声。如果把五个告警当成五个问题分别“调参修复”，结果会比不做更糟。

边界：这套框架不能做什么

框架有三处边界需要说明。其一，所有统计保证都建立在“有足够样本”的前提上，低流量场景下，检测延迟会长到失去意义，此时人工抽检比统计检验更可靠。其二，锚点集需要持续维护，任务定义变化后（概念漂移），旧锚点会失效，必须重新标注。其三，序贯检验控制的是“单位时间的误报”，不能消除误报；值班制度、告警分级和复盘机制仍然不可替代。

前瞻判断

我们据此提出五条带时间尺度与证伪条件的判断（观点）：

观点 1（12–24 个月）：大模型评测与监控管线将普遍引入“固定锚点集 + 裁判漂移检验”，“系统变了还是裁判变了”会成为告警的必填归因字段。支撑证据：裁判版本变化导致的严苛度位移已被多项研究测到⁠^9,10，可随时停止的归因方法已经可用⁠⁸。若 18 个月后主流可观测性产品仍不支持裁判版本记录与锚点评估，则判断不成立。企业含义：从现在起为每个裁判建立版本与锚点档案。

观点 2（6–18 个月）：可随时停止的序贯检验（e 过程、下注式检验）将进入主流监控工具，逐步替代“固定窗口算 p 值”。支撑证据：面向非结构化数据流的方法与阈值校准方法在近一年密集出现⁠^14–16，多流情形的误报口径也有了可操作的定义⁠¹⁸。若主要开源监控库在此期间没有实现任何此类检验，则判断偏早。企业含义：先在一两个关键指标上试点，与现有阈值并行运行一个季度，比较误报与延迟。

观点 3（12–24 个月）：智能体安全监控将从单步、单轨迹扩展到跨轨迹、跨迭代的状态，权限系统会引入“目的”与“来源”层面的全局策略。支撑证据：两项不可能性结果说明单步与单轨迹监控存在结构性盲区⁠^33,34。若公开事故复盘显示单轨迹监控已足以覆盖主要安全事件，则判断应下调。企业含义：为长期运行的智能体保留跨任务的审计状态，而不是每次任务结束就清空。

观点 4（6–12 个月）：单任务硬预算与成本燃烧率告警将成为智能体框架的默认配置。支撑证据：预算超支事故已形成可分类的失效族⁠³¹，且“花得更多不等于做得更好”⁠³²。若主要框架在 12 个月内仍以“月度账单”作为仅有的成本控制手段，则判断偏早。企业含义：在采购与自研中把“单任务上限由框架强制执行”列为验收项。

观点 5（12–24 个月）：按 OpenTelemetry 生成式 AI 语义约定输出的追踪数据，会成为企业采购智能体平台时的验收项之一。支撑证据：智能体与工具调用的跨度和指标已有约定⁠²¹，失败归因研究依赖这类结构化轨迹⁠^23,24。若该约定在 24 个月内仍停留在开发状态、主要框架未实现，则判断不成立。企业含义：要求供应商提供可导出的标准化轨迹，而不是只给可视化界面。

业界看法中可能需要修正的地方

• “PSI 超过 0.1 就算漂移”：阈值应随样本量与分箱数调整，小样本窗口下 0.1 接近噪声。
• “温度设为 0 就能复现”：服务端缓存与量化会让同一请求产生不同结果⁠⁷。
• “AUROC 高的检测器可以直接上线”：上线看的是锁定误报率下的检出率⁠²⁰。
• “最终成功率足以评估智能体”：过程可执行性与最终成功率的排名会分歧⁠²⁵。
• “告警后自动修正更安全”：在低基率下，自动修正的大多数动作落在正确结果上。

结语

把上线监控当作决策系统来设计，意味着三件事：先分清变化来自哪里，再在明确的误报预算下决定报不报警，最后让处置走受控的变更流程。两条禁令不是管理上的保守，而是统计推理的结论：静默改参数会破坏归因与统计保证，告警直接改写结果会在低基率下制造更多错误。

在弘犀智能的产品中，这些原则体现在企业智能体平台的 Harness 治理引擎里：模型路由器按任务选择模型并锁定版本，禁止运行途中自动升级；独立验证器只读结构化数据、分层重验；审计监控与紧急停机模块支持全轨迹留痕、只读降级、人工接管与分级停机；推训一体大模型平台 DH S1 的在线链路提供指标监控与 A/B 测试，模型与策略的更新走在线、离线双链路联动（产品信息据弘犀智能官网）。这些设计对应的正是本文的“锁定版本”“可逆隔离”和“对照后上线”。

要点小结：

1. 把变化分成数据漂移、概念漂移、性能衰减与测量漂移四类，处置方式各不相同。
2. 阈值是误报与漏报的交换，应按样本量、查看频率和指标数量来定；序贯检验与燃烧率告警把阈值变成可沟通的预算。
3. 智能体要在轨迹、工具、成本、安全四层加测，单步检查不能组合成整体安全。
4. 两条禁令有统计学依据：静默改参数破坏归因与统计保证，自动改写结果在低基率下制造更多错误。
5. 允许的告警动作是可逆隔离，修复一律走变更流程。

参考文献

1. 1.Gama, J., Žliobaitė, I., Bifet, A., Pechenizkiy, M. & Bouchachia, A. A survey on concept drift adaptation. ACM Comput. Surv. 46, 1–37 (2014). https://doi.org/10.1145/2523813
2. 2.Rabanser, S., Günnemann, S. & Lipton, Z. C. Failing Loudly: An Empirical Study of Methods for Detecting Dataset Shift. Preprint at https://arxiv.org/abs/1810.11953 (2018).
3. 3.Lipton, Z. C., Wang, Y. & Smola, A. Detecting and Correcting for Label Shift with Black Box Predictors. Preprint at https://arxiv.org/abs/1802.03916 (2018).
4. 4.Guo, C., Pleiss, G., Sun, Y. & Weinberger, K. Q. On Calibration of Modern Neural Networks. Preprint at https://arxiv.org/abs/1706.04599 (2017).
5. 5.Vinay, V. Failure Modes in LLM Systems: A System-Level Taxonomy for Reliable AI Applications. Preprint at https://arxiv.org/abs/2511.19933 (2025).
6. 6.Nicholson, C. Quantifying non deterministic drift in large language models. Preprint at https://arxiv.org/abs/2601.19934 (2026).
7. 7.Patodiya, A. Same Request, Different Answer: Quantization Amplifies Cache-Induced Divergence in LLM Serving. Preprint at https://arxiv.org/abs/2609.04748 (2026).
8. 8.Li, Y. Who Drifted: the System or the Judge? Anytime-Valid Attribution in LLM Evaluation Pipelines. Preprint at https://arxiv.org/abs/2606.15474 (2026).
9. 9.Sunkavalli, V. K. LLM Judges as Raters: A Pre-Registered Audit of Severity, Halo, Reliability, and Version Instability in LLM Essay Scoring on Public Corpora. Preprint at https://arxiv.org/abs/2608.29517 (2026).
10. 10.Kumar, V., Rathore, D. & Moitra, A. All Verdicts are Not Equal: Rethinking LLM Judge Reliability. Preprint at https://arxiv.org/abs/2610.12083 (2026).
11. 11.Benjamini, Y. & Hochberg, Y. Controlling the false discovery rate: a practical and powerful approach to multiple testing. J. R. Stat. Soc. B 57, 289–300 (1995). https://doi.org/10.1111/j.2517-6161.1995.tb02031.x
12. 12.Page, E. S. Continuous inspection schemes. Biometrika 41, 100–115 (1954). https://doi.org/10.1093/biomet/41.1-2.100
13. 13.Ramdas, A., Grünwald, P., Vovk, V. & Shafer, G. Game-theoretic statistics and safe anytime-valid inference. Preprint at https://arxiv.org/abs/2210.01948 (2022).
14. 14.Zhou, S. et al. Learning to Detect Shifts in Unstructured Data Streams via Monitoring-by-Betting. Preprint at https://arxiv.org/abs/2610.17399 (2026).
15. 15.Shaer, S., Bar, Y., Prinster, D. & Romano, Y. Testing For Distribution Shifts with Conditional Conformal Test Martingales. Preprint at https://arxiv.org/abs/2602.13848 (2026).
16. 16.Ding, Y., Wei, L., Zhu, X. & Dai, W. Reference-Null Calibrated Thresholds for E-Processes with Applications to Conformal Martingales. Preprint at https://arxiv.org/abs/2609.32678 (2026).
17. 17.Itkin, I. Quickest Detection of Hallucination Onset: Delay Bounds and Learned CUSUM Statistics. Preprint at https://arxiv.org/abs/2606.12476 (2026).
18. 18.Dandapanthula, S. & Ramdas, A. Multiple testing in multi-stream sequential change detection. Preprint at https://arxiv.org/abs/2501.04130 (2025).
19. 19.Google SRE. Alerting on SLOs. The Site Reliability Workbook, https://sre.google/workbook/alerting-on-slos/ (2018).
20. 20.Gao, X. From Probe Scores to Alarm Policies: Operational Validity of Activation Monitors for Language-Model Agents. Preprint at https://arxiv.org/abs/2610.04575 (2026).
21. 21.OpenTelemetry. Semantic conventions for GenAI agent and framework spans (status: Development). https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/gen-ai-agent-spans.md (2026).
22. 22.AlSayyad, A., Huang, K. Y. & Pal, R. AgentTrace: A Structured Logging Framework for Agent System Observability. Preprint at https://arxiv.org/abs/2602.10133 (2026).
23. 23.Cemri, M. et al. Why Do Multi-Agent LLM Systems Fail?. Preprint at https://arxiv.org/abs/2503.13657 (2025).
24. 24.Barke, S. et al. AgentRx: Diagnosing AI Agent Failures from Execution Trajectories. Preprint at https://arxiv.org/abs/2602.02475 (2026).
25. 25.Rezaeian, A. H., Sun, W., Benajiba, Y. & Roth, D. Prefix Executability: Evaluating Tool-Using Agents Beyond Final Success. Preprint at https://arxiv.org/abs/2610.40444 (2026).
26. 26.Huang, X. et al. PrefixGuard: Online Failure Warning and Trace-Grounded Diagnosis for LLM Agents. Preprint at https://arxiv.org/abs/2605.06455 (2026).
27. 27.Barazandeh, B., Swanson, C., Kulkarni, C. & Mungel, N. OnTrack: Real-Time Monitoring and Intervention in LLM Agent Trajectories via Streaming Structure-Aware Optimal Transport. Preprint at https://arxiv.org/abs/2610.12375 (2026).
28. 28.Srinivasan, S., Li, L., Menzies, T. & Assunção, W. Continue or Restart? The Limits of Early Failure Prediction in Coding Agents. Preprint at https://arxiv.org/abs/2610.35971 (2026).
29. 29.Iannillo, A. K. et al. Tool-Calling LLM Agents Under Realistic MCP Faults: Scale Does Not Purchase Fault Tolerance. Preprint at https://arxiv.org/abs/2610.32555 (2026).
30. 30.Zhang, W. et al. RITE: Evaluating End-to-End Resilience to Silent Tool Errors in E-Commerce Agentic Systems. Preprint at https://arxiv.org/abs/2610.27777 (2026).
31. 31.Khan, S. Token Budgets: An Empirical Catalog of 63 LLM-Agent Budget-Overrun Incidents, with an Affine-Typed Rust Mitigation as a Case Study. Preprint at https://arxiv.org/abs/2606.04056 (2026).
32. 32.Lu, L., Zhao, Y., Chen, H. & Wang, H. Where Do the Tokens Go? Understanding and Reducing Costs in LLM Agents for Vulnerability Discovery. Preprint at https://arxiv.org/abs/2610.11602 (2026).
33. 33.Pandey, A., Jain, A., Chen, L. & Maple, C. Local Allow, Global Deny: Why Per-Action Authorization Does Not Compose in LLM Agents. Preprint at https://arxiv.org/abs/2610.27620 (2026).
34. 34.Wu, C. et al. Safety Does Not Compose: Non-Decaying Loop State for Autonomous LLM Agents. Preprint at https://arxiv.org/abs/2608.27141 (2026).
35. 35.Korbak, T. et al. Chain of Thought Monitorability: A New and Fragile Opportunity for AI Safety. Preprint at https://arxiv.org/abs/2507.11473 (2025).
36. 36.Guan, M. Y. et al. Monitoring Monitorability. Preprint at https://arxiv.org/abs/2512.18311 (2025).
37. 37.Mishra, A., Chatterjee, S. & Maniyar, S. Faithful Latent Harm Monitors Work No Better Than the Models Own Behaviour at a Matched False Alarm Rate. Preprint at https://arxiv.org/abs/2610.30727 (2026).
38. 38.Baker, B. et al. Monitoring Reasoning Models for Misbehavior and the Risks of Promoting Obfuscation. Preprint at https://arxiv.org/abs/2503.11926 (2025).
39. 39.Yan, X. et al. Positive-Unlabeled Learning for Agent Safety False Alarm Auditing. Preprint at https://arxiv.org/abs/2610.02925 (2026).
40. 40.Liao, J. Monitor-Validity Failures: LLM Safety Evidence Paths at Evolving Framework Boundaries. Preprint at https://arxiv.org/abs/2610.23362 (2026).
41. 41.Leong, J. W. Online Shift Detection and Conformal Adaptation for Deployed Safety Classifiers. Preprint at https://arxiv.org/abs/2606.11949 (2026).