离线测评全部通过，Agent 上线后仍然可能失败。
原因并不神秘。离线数据集只能覆盖团队已经想到的问题，真实用户会带来新的表达、新的任务组合和新的边界。工具接口会变化，模型服务会升级，业务数据也会漂移。
所以，Eval 不能在“发布通过”时结束。
完整闭环应该是：
发布前设门槛 → 灰度观察真实使用 → 收集和确认坏案例 → 回流数据集 → 修复并重新测评 → 再次发布。
测评真正积累的不是一份分数报告，而是一套持续减少重复失败的质量资产。
离线通过能证明什么
离线 Eval 可以证明：
- 当前版本在指定数据集上的能力；
- 对已知风险和边界的处理；
- 相对于旧版的改善与退化；
- 在指定模型、工具和环境下的稳定性；
- 是否达到团队预先设定的发布门槛。
它不能直接证明：
- 所有真实用户场景都已覆盖；
- 线上数据分布与离线数据一致；
- 业务采用、转化或效率一定改善；
- 模型和外部依赖以后不会变化；
- 未知风险不存在。
因此，离线 Eval 是发布证据，不是生产结果的替代品。
发布前先过四道门
发布结论不应只依赖总分。可以按顺序设置四类门槛。
第一门：结果是否有效
运行是否完成？案例、模型、版本和评分器是否正确？大量工具异常是否让本次数据失效？
无效实验不能产生有效发布结论。
第二门：底线是否守住
安全、权限、敏感信息、严重事实错误、不可恢复操作和虚假完成等硬要求是否通过？
底线失败不能被其他高分抵消。
第三门：核心任务是否达标
主要用户任务是否达到最低成功率？关键场景和高风险分组是否可接受？相对于旧版是否出现重大退化？
第四门：成本和运行条件是否可接受
延迟、Token、工具调用、人工接管和维护复杂度是否在预算内？
通过四道门之后，仍可以根据风险选择内部试用、小流量灰度或正式开放，不必把发布处理成非黑即白。
上线后需要观察什么
传统监控通常关注报错、延迟和资源。Agent 还需要观察任务质量和用户行为。
系统信号
- 模型和工具错误；
- 超时、重试和限流；
- Token、调用次数和成本异常；
- 文件、数据或状态写入失败。
任务信号
- Agent 是否完成目标任务；
- 是否频繁追问或提前终止；
- 工具选择和关键步骤是否异常；
- 同类任务成功率是否下降。
用户信号
- 用户重新改写问题；
- 人工接管或手工修正；
- 结果被放弃、重做或投诉；
- 用户是否实际采用生成产物。
风险信号
- 越权和未授权操作；
- 敏感信息暴露；
- 严重事实错误；
- 产生不可恢复副作用。
代理指标不能永久代表真实质量。比如“用户没有投诉”可能是因为用户已经放弃使用。线上信号仍需要与人工抽样和真实业务结果定期对齐。
不是所有线上失败都能直接进入回归集
把全部生产对话塞进数据集，看起来最贴近真实用户，实际会制造新的问题：
- 包含隐私或敏感信息；
- 同一个失败模式被重复记录；
- 用户输入本身可能超出产品范围；
- 无法确认失败来自模型、数据、工具还是使用方式；
- 没有明确预期，后续仍然无法评分。
一个线上坏案例进入回归集前，至少需要完成五步。
确认
判断它是否真的是产品失败，而不是用户误用、外部系统故障或超出能力范围。
脱敏
删除或替换个人信息、商业敏感信息和不必要上下文。
归因
初步判断问题发生在触发、Prompt、模型、检索、工具、状态、评分还是需求定义。
补充预期
写清正确行为、必须满足项、禁止行为和评分方法。
去重与分类
检查是否已有同类案例，为它添加场景、风险、难度和来源标签。
经过处理之后，坏案例才从一条投诉变成可重复执行的质量资产。
能力集和回归集不要混在一起
回流数据通常会进入两类集合。
回归集
用于守住已经修复和已经承诺的能力。
理想状态是接近全通过。任何失败都需要明确解释，因为它代表旧问题可能复发。
能力集
用于观察复杂能力和改进空间。
其中可以包含当前仍然困难的任务，不要求全部通过。随着某项能力成熟，稳定通过的关键案例可以进入回归集。
如果两者混在一起，团队很难解释 80% 通过率究竟代表“有 20% 回归”，还是“仍在挑战能力上探索”。
哪些变化需要重新测评
影响 Agent 行为的对象远不止代码。
- 模型或模型版本；
- Prompt；
- Skill 描述、步骤和脚本；
- 工具、接口和权限；
- 检索数据和知识库；
- 上下文、记忆和工作流；
- 评分模型和 Rubric；
- 关键运行环境。
不同变化可以触发不同范围的复测。
| 变化 | 建议复测范围 |
|---|---|
| 小幅措辞调整 | 目标坏例 + Prompt 回归集 |
| Skill 描述变化 | 正例、负例、边界和混淆触发集 |
| 工具参数或接口变化 | 工具测试 + 关键过程与状态案例 |
| 主模型升级 | 完整核心集 + 多次运行 + 关键风险 |
| 评分模型变化 | Gold 校准集 + 历史结果抽检 |
| 工作流重构 | 分层测试 + 端到端验收 |
风险越高、影响范围越大，复测范围越广。每次变化都应记录版本、影响对象、评估结果和回滚基线。
谁来维护持续 Eval
Eval 不是某一个角色可以独立完成的工作。
产品经理
定义用户任务、成功标准、优先级和发布决策。确保指标仍然服务产品问题。
业务专家
校准专业事实、质量标准和高风险边界，维护关键 Gold 样本。
测试团队
保证案例覆盖、环境可复现、确定性断言、回归执行和发布门槛。
研发或平台团队
提供版本、批量执行、Trace、Artifact、状态证据和线上观测能力。
发布负责人
决定是否接受剩余风险，批准灰度、例外或回滚。
每个关键对象都要有 Owner：
- 谁维护数据集；
- 谁批准成功标准；
- 谁校准评分器；
- 谁调查线上坏例；
- 谁可以修改发布门槛；
- 谁对例外发布负责。
没有 Owner 的用例会过时，没有校准的评分器会漂移，没有责任人的 Gate 会逐渐失去约束。
最小持续闭环
小团队不需要一开始建设大型 Eval 平台，可以先固定一套简单节奏。
每次修改
- 记录修改假设；
- 运行受影响的开发集和回归集；
- 检查硬门、核心能力、成本和坏例；
- 保存版本对比结论。
每次发布
- 完成关键模型和风险场景验收；
- 明确灰度范围与回滚条件；
- 记录批准人和剩余风险。
每周或每个运营周期
- 复盘线上失败和人工接管；
- 选择需要进入数据集的案例；
- 检查成本、延迟和质量变化；
- 分配修复与补测责任。
每次重大依赖变化
- 检查模型、工具、数据和评分器的影响；
- 重新运行对应能力集与回归集；
- 更新支持范围和基线。
做到这一步，Eval 就不再是上线前临时组织的一次考试，而是产品持续学习的机制。
Agent 不会因为测评而永远不失败。但一套有效的闭环，可以让已经发生过、已经理解并已经修复的失败，不再反复以相同方式出现。
Agent 测评入门系列
- 【Eval】Agent测评不是简单给回答打分
- 【Eval】测试同学别焦虑，Eval也不是替代品
- 【Eval】第一次Eval，先干小事情
- 【Eval】测Skill，不只是盯结果
- 【Eval】分数变高，不代表版本真的变好
- 【Eval】规则、AI裁判和人工怎么成为铁三角
- 【Eval】离线全通过，上线仍会失败的原因到底是啥（本文）