Agent 双轨评测3步搭起来,避免上线就失控

本篇是系列第 7 篇，也是收口的一篇。前面六篇分别解决了评什么（01）、任务从哪来（02）、怎么打分（03、04）、分数算不算数（05）、安全怎么测（06），本篇把它们全部接进一条能自动跑起来的流程。

离线全绿上线翻车，是结构性问题不是运气问题

这是本篇要解决的最后一个，也是最普遍的一个落差。

三个具体原因：

• 离线评测集评的是你想象中的用户。集子里的任务是人想的，真实用户的问法、上下文、脏数据都比集子野得多。
• 评测集会腐化。业务变了、接口变了、参考答案变了，集子没跟着变，它就从"准"变成"假准"，而且很难自查。
• 离线跑得越勤，偏差越隐蔽。每次发版离线都绿，团队会越来越相信它，等到线上数据打脸时，信任已经透支了。

所以闭环的答案不是"多跑几次离线"，是离线和在线两条轨一起跑，并且让样本在两条轨之间流动。

5档闭环方案横向比较与阶段选型

闭环怎么搭，有 5 档方案，自动化程度和覆盖面对照如下：

方案	触发方式	线上数据	门禁	成本	适合阶段
手动跑	人记得就跑	无	无	极低	起步
定时脚本	每天定时	无	无	低	起步
CI 集成	变更触发	无	单次通过率	中	成长
双轨（离线 CI + 在线 trace）	变更触发 + 线上持续采样	有	pass^k	中到高	推荐主力
自愈闭环	自动回流 + 自动补难负	有	pass^k + 漂移监测	高	规模较大后

• 手动跑：靠人记得就跑，没有门禁，只存在于团队还没有 CI 的极早期。
• 定时脚本：每天定时，同样没有门禁，起步阶段只为让「有没有回归」每天可见。
• CI 集成：变更触发，门禁是单次通过率，能拦住大部分回归，但单次通过率会高估（见 05 篇）。
• 双轨（离线 CI 加在线 trace）：变更触发加线上持续采样，门禁按 pass^k，表里标的是推荐主力。
• 自愈闭环：自动回流加自动补难负，门禁是 pass^k 加漂移监测，成本最高，适合规模较大之后。

注意前两档没有门禁，所以它们只是「跑评测」，不是闭环；从 CI 集成这一档开始才有门禁，从双轨这一档开始才有线上数据回流。判断自己在哪一档，看这两列就够了。

阶段怎么选

一、离线 CI：变更触发，门禁按 pass^k

离线轨要解决的第一件事是触发方式。凡是靠人记得跑的评测，最后都会变成不跑。

触发点至少三个：

• prompt 或工具定义变更：这是最高频也最容易引入回归的变更。
• 模型版本变更：包括供应商侧的无声升级。
• 依赖接口变更：工具返回结构变了，Agent 行为会跟着变，而你可能完全不知情。

门禁阈值直接沿用稳定性评测的结论：按 pass^k 设，不按单次通过率设。具体建议核心任务 pass^5 不低于 80%、普通任务 pass^3 不低于 85%，成本类指标（调用次数中位数）涨幅不超过 20%。三类阈值任一不满足即阻断。

还有一个容易被忽略的配置：裁判与评测器要锁版本。裁判模型升级、评分脚本改动，都会让分数不可比。把评测器版本写进评测报告，否则你会发现两次发版的分差根本说不清是 Agent 变了还是尺子变了。

回归范围要和变更的影响域对齐，不是所有变更都跑全量。prompt 局部小调整只跑受影响的指令遵循子集；模型替换是全局变更，必须跑完整基准；裁判或评分脚本的变更最容易被漏掉，但它会让所有评测结论的可信度一起变，反而要优先验证。范围估窄了风险漏出去，估宽了回归成本压垮流程，两边都要平衡。

门禁之外还有两段不能省：灰度和监控。灰度建议三桶并行，对照桶、实验桶、稳定性验证桶，后者跑的是上一版策略。三桶的意义不只是比效果，更是把「策略本身的问题」和「环境引入的噪声」分开：如果稳定性验证桶的指标同样异常，说明问题来自外部环境，比如流量结构变化或大促扰动，这时触发熔断就是误判，先排除环境因素再决策。

二、在线 trace 评测：抽样加裁判面板

在线轨不重复评正确性的离线部分，它评的是三件离线评不了的事：

1. 真实输入分布：用户实际怎么问、上下文有多脏、有多少情况根本不在集子里。

2. 真实环境噪声：超时、限流、脏数据、并发，这些离线环境都模拟不全。

3. 长尾与组合：离线集子里的任务是人拆过的，线上是连着来的。

做法上两个组件：

• 抽样：按固定比例抽生产 trace，比例建议 5% 到 10%，高价值场景可以更高。抽样要分层，不能只抽成功的，失败的和重试过的一次都要抽。
• 裁判面板：抽到的 trace 用裁判打分（维度沿用 03 篇的三层指标），结果进面板按天看趋势。

坑在于用在线分数当门禁。在线数据是真实分布，但它有选择偏差（抽到的样本不代表全部），而且波动大。在线轨的用途是发现问题和提供样本，不是卡发版。

三、基准会腐化，你的评测集也会

这一节是双轨之外最该记住的一条风险。

公开基准会腐化：命令行任务基准 Terminal-Bench 升到 2.1 时，修正了 2.0 里 89 个任务中的 28 个，其中 9 个是外部依赖漂移、8 个是资源预算卡死了正解、其余是指令与测试对不上。也就是说，上一个版本里接近三分之一的题目本身有问题，而不是模型不行。

更严重的是基准可以被主动攻击。2026 年 4 月加州大学伯克利分校的研究显示，8 个主流 Agent 基准全部可以被 reward hacking 手段刷到接近满分，攻击面有三类：

• harness 泄漏：Agent 从运行环境里拿到了本不该看到的评测信息。
• 评分缺陷：评分器本身的判定逻辑有漏洞，可以被针对性绕过。
• 单次运行上报：只跑一次就上报最好结果，用随机性掩盖真实水平。

第三类和 05 篇直接相关：只跑一次上报，本质就是拿 pass@k 冒充可靠性。

对你的自建评测集，这三条同样成立。所以评测集需要定期体检，体检动作四条：

1. 每季度复核参考答案：业务变了没有，接口变了没有，golden 轨迹还成立吗？

2. 随机抽查被判失败的用例：看是不是评分器判错了，假负例会污染整个度量。

3. 检查是否有泄漏：评测环境里有没有 accidentally 暴露答案或标签。

4. 强制多次运行上报：禁止单次运行报数，这一条写进流水线。

四、双轨对齐：让样本在两条轨之间流动

双轨的价值不在"跑两遍"，在于互流。

在线流回离线（补集子）：在线 trace 里发现的失败、漂移、badcase，定期回流进离线评测集。这一条直接承接评测实操的难负构造，回流时要抽检，避免把垃圾样本灌进去污染集子。

离线流到在线（补判据）：离线沉淀的评分卡、裁判 prompt、关键步骤断言，直接复用到在线 trace 打分上，保证两轨口径一致。两轨口径不一致是最大的浪费，会导致离线涨、在线跌却无从归因。

对齐的量化检查：每月抽一批任务，同时看离线分和在线分，算两者相关性。相关性持续偏低，说明离线集子已经偏离真实分布，该换样本了。

五、告警与处置：闭环不能停在"发现了"

发现问题之后没有处置动作，闭环就断在最后一步。

三类告警阈值：

• 在线通过率日环比下降超过 5 个百分点：立刻告警，人工看 trace。
• 成本类指标（调用次数中位数、token）周环比上涨超过 20%：告警，通常是 prompt 或工具返回结构变了。
• 高危动作拦截数突增：安全告警，按 Agent 安全评测4 类攻击面的流程走。

处置动作要预先定义好，不要等出事再想：

1. 降级：切回上一版 prompt 或关闭某个工具。

2. 熔断：某工具错误率超阈值时自动禁用，走兜底路径。

3. 回滚：版本级回滚，前提是发版时保留了上一版可回滚状态。

4. 挂起待确认：高危动作默认挂起，沿用 安全评测的闸门设计。

告警接在哪里也要提前定：接在能看见的地方，并且指定到人。无人认领的告警等于没有告警。

处置之前还有一个判断要先做：这是 Agent 问题还是结构性问题。做法是看同一个输入在所有桶下是否一致劣化，如果是，问题多半在外部环境、数据缺失或大盘异常，不在 Agent 决策本身。把结构性问题误判成模型能力不足，后面所有优化动作都会打偏。这个判断放在归因第一步，成本几乎为零，能挡掉一半的无效排查。

一句话收尾

离线管能不能发，在线管发了之后是不是真的好。你现在有没有一条线上的数据，能告诉你昨天上线那版真实表现如何？

英文术语释义

• CI（持续集成）：代码变更时自动跑测试与评测的工程实践。
• trace（调用链）：一次请求从入口到结束的完整记录，含每一步工具调用。
• online eval（在线评测）：在生产流量上抽样打分，反映真实分布。
• sampling（抽样）：按规则从生产流量中选取部分样本，需分层避免偏差。
• reward hacking（奖励劫持）：用投机方式刷高评测分数而非真正提升能力。
• benchmark rot（基准腐化）：基准题目或评分随时间失效，分数失去意义。
• drift（漂移）：线上数据分布相对评测集发生变化。
• circuit breaker（熔断）：错误率超阈值时自动停用某组件的保护机制。
• canary release（灰度放量）：先放小比例真实流量验证，再逐步扩大。
• stability bucket（稳定性验证桶）：灰度中跑上一版策略的对照桶，用于区分策略问题与环境噪声。