前面八篇把黑盒 Agent 评测系统拆开讲了一遍：为什么不能只看平均分，Rubric 怎么工程化，分数和红线怎么设计，LLM-as-judge 怎么稳定输出，评测前怎么还原上下文，低分样本怎么聚成问题簇，报告怎么变成 PM 决策工作台，长任务怎么可靠跑完。
如果到这里就结束，系统已经能产出一份不错的评测报告。但它的长期价值还没有完全释放。
一次评测只能告诉你「这批数据里有哪些问题」。持续评测才能回答更重要的问题：这一版比上一版好了吗？上次修过的问题有没有复发？新规则上线后影响了哪些场景？哪些 badcase 已经沉淀成回归集？Rubric 本身有没有误判和缺口？
Agent 质量治理不是一次性项目，而是一条持续循环。评测系统要从「报告生成器」变成「质量资产库」。
这一篇作为系列收束，讲如何把一次性黑盒评测变成持续优化体系。
一、一次性评测的价值和上限
一次性评测很有价值。它能快速暴露当前 Agent 的质量状态，尤其适合这些场景：
- 新 Agent 上线前做一轮验收；
- 某次用户投诉后做专项排查；
- 某个业务线怀疑质量下降时做抽样评估；
- 新模型、新 Prompt、新知识库上线前做离线比较。
但一次性评测也有明显上限。
第一，它很难判断趋势。单次平均分 4.1 到底好不好，要看上一版是多少、同类业务是多少、红线有没有下降。
第二，它容易变成报告归档。问题被发现了，但如果没有后续验收案例和版本对比，修复后也不知道是否真的改善。
第三，它无法沉淀标准。人工复核发现某条规则误判，如果只是改了这份报告，下一次还会再错。
所以评测系统的目标不是「每次生成一份报告」，而是让每次评测都反哺四类资产：规则、样本、问题簇和验收案例。
二、质量闭环的四类资产
一套长期运行的 Agent 评测体系，应该不断沉淀四类资产。
业务标准 → Rubric 规则包
真实对话 → 评测样本
低分结果 → 问题簇
优化动作 → 验收案例第一类是 Rubric 规则包。它保存业务专家对质量的定义，包括意图、硬性要求、红线、评分策略和不可观测边界。
第二类是评测样本。它来自真实对话，也可以来自人工构造的边界样例。真实样本帮助发现线上问题，构造样本帮助覆盖高风险低频场景。
第三类是问题簇。它把大量低分样本聚合成可追踪的问题类型，比如某意图下某条规则反复失败。
第四类是验收案例。它来自问题簇，用于验证修复是否生效，也用于防止后续版本回退。
这四类资产彼此连接，形成循环：
真实对话发现问题
→ 问题簇推动优化
→ 优化项生成验收案例
→ 验收案例进入回归评测
→ 复核结果修订 Rubric
→ 新 Rubric 继续评测真实对话闭环一旦跑起来，评测系统就不再是旁路工具，而会成为 Agent 研发流程的一部分。
三、上线前：用验收案例做回归
Agent 每次改版前，都应该跑一轮回归评测。
回归集可以由三类样本组成：
| 样本类型 | 来源 | 作用 |
|---|---|---|
| 历史典型失败 | 旧报告的问题簇 | 验证曾经的问题是否修复 |
| 边界样本 | 规则专家构造 | 验证红线和规则边界 |
| 成功对照 | 高分真实样本 | 防止改坏原本稳定场景 |
很多团队只保留 badcase，这还不够。只有失败样本会让系统不断朝修复坏例子倾斜，却不知道原本正确的能力有没有退化。成功对照同样重要，它是防回归的底线。
上线前评测要回答几个问题：
- 历史红线是否清零；
- 上一轮主问题是否明显下降；
- 新版本有没有引入新的红线；
- 成功对照是否仍然保持高分；
- 平均分和健康率是否稳定提升；
- 是否有某个意图明显退化。
如果这些问题都能自动从报告里读出来，评测就开始真正参与发布流程。
四、上线后：从真实对话里持续抽样
上线前评测再充分，也覆盖不了真实用户的全部表达。
上线后需要从生产对话里持续抽样，按天、周或版本生成评测任务。抽样策略可以分几层：
- 随机样本：观察整体质量趋势；
- 负反馈样本：优先发现用户已经表达不满的问题；
- 高风险意图样本：持续监控安全、合规、售后等关键场景；
- 新版本样本：对比版本切换前后的变化；
- 长尾样本：发现 Rubric 还没有覆盖的新问题。
抽样不一定一开始就很复杂。早期可以每周导出一批对话手动上传，等流程跑顺后再接自动采样。关键是建立固定节奏，让评测不是事故后的临时动作。
持续抽样还能帮助识别规则缺口。如果某类问题经常出现在模型解释里，但没有稳定映射到现有规则，就说明 Rubric 需要新增或拆分规则。
五、版本对比要同时看三种版本
Agent 评测里的「版本」不只指 Agent 自己。
至少有三种版本需要记录：
| 版本 | 说明 |
|---|---|
| Agent 版本 | 被评测系统的 Prompt、知识库、工具或流程版本 |
| Rubric 版本 | 评测标准本身的版本 |
| Judge 模型版本 | 执行评测的 LLM 模型和 prompt 版本 |
如果不区分这三者，版本对比很容易失真。
比如本周平均分从 3.8 涨到 4.2，可能是 Agent 真的变好了，也可能是 Rubric 变松了，或者 judge 模型换了以后判分更宽。反过来，分数下降也可能是规则收紧带来的，不一定是 Agent 退化。
所以每次任务都应该保存：
agentVersion
rubricVersion
rubricSnapshot
judgeModel
promptVersion
analysisVersion对比报告时，最好先保证 Rubric 和 judge 版本一致，再比较 Agent 版本。否则对比结论要明确标注「评测口径已变化」。
六、Rubric 迭代应该像代码评审一样严肃
Rubric 会持续变化，但不能随意变化。
每一次规则调整都会影响分数、红线、遵循率和问题簇。如果没有流程，评测体系很快会变成一套不断漂移的标准。
比较稳的 Rubric 迭代流程是：
- 从真实误判、业务规则变更或新问题簇提出规则变更；
- 在草稿版本里修改规则；
- 用历史样本和边界样本试跑；
- 对比新旧 Rubric 的分数和红线变化；
- 由业务专家和工程负责人评审；
- 发布新版本；
- 新任务引用新版本，旧报告继续保留旧 snapshot。
这和代码评审很像。规则不是随手改一句 prompt，而是会改变系统行为的配置代码。
Rubric 的 changelog 也要认真写。不要只写「优化规则」，而要说明：新增了哪些意图，收紧了哪些红线，哪些规则从不可观测变成可观测，哪些命中分调整了。
七、人工复核不是替代自动评测，而是校准自动评测
自动评测不可能完全正确，尤其是语义边界复杂的场景。人工复核仍然需要，但它的角色要变。
过去人工复核是主流程：人逐条看样本，给分，写结论。自动评测上线后，人工复核应该变成校准流程：抽查模型判断是否符合 Rubric，发现系统性偏差，然后修规则或修 prompt。
推荐的复核样本包括：
- 每个分数段的样本；
- 每类红线样本；
- 高优先级问题簇的代表样本；
- 低置信度或修复后才成功的样本；
- 新增规则命中的样本；
- 历史上容易误判的边界样本。
人工复核的产物也不应该停在批注里。它应该进入三个地方：
- 修订 Rubric 规则文本；
- 增加边界验收案例；
- 标记 judge prompt 或输出协议需要调整的地方。
这样人不是在和自动评测重复劳动，而是在提升自动评测系统本身。
八、问题簇要有生命周期
问题簇不是一次报告里的静态条目，它应该有生命周期。
可以定义几种状态：
- 新发现：本次首次出现或显著上升；
- 已确认：人工复核确认问题成立；
- 修复中：已经进入需求或研发排期；
- 已修复：新版本评测中显著下降或消失；
- 观察中：样本不足或优先级暂低；
- 暂不处理：业务接受当前风险或成本过高。
如果问题簇有生命周期，报告就能从「本次有哪些问题」升级为「这些问题现在处于什么状态」。
这对持续优化很重要。否则每次报告都会重新发现一批问题，团队很难知道哪些是老问题、哪些是新问题、哪些已经修过但复发了。
问题簇生命周期还可以连接项目管理工具。比如红线问题自动创建跟进项，主问题进入需求池，观察区积累到阈值后提醒复核。
九、质量指标要服务行动，不要制造仪表盘幻觉
持续评测很容易走向另一种极端：指标越来越多，仪表盘越来越复杂，但真正能推动行动的指标很少。
建议长期追踪的核心指标不要太多：
- 平均分；
- 健康率；
- 红线实例数；
- 各意图平均分；
- 高频违反规则；
- 规则类别遵循率；
- 已确认问题簇数量；
- 已修复问题簇复发率；
- 验收案例通过率。
这些指标都要能连接到行动。如果一个指标变差了，团队应该知道下一步看哪个报告、哪个问题簇、哪批样本。不能连接行动的指标，最多作为背景信息，不要放在主视图里制造噪音。
评测系统不是为了证明「我们有很多指标」，而是为了减少从发现问题到修复问题的摩擦。
十、从内部工具到质量治理
当这套闭环跑起来后，Agent 评测平台会经历一个角色变化。
第一阶段，它是分析工具。用户上传一批对话，系统给一份报告。
第二阶段，它是优化工具。报告里的问题簇进入需求池，每个行动项有证据和验收案例。
第三阶段，它是治理工具。Rubric 变成团队质量标准，评测任务接入发布流程，红线和规则遵循率成为上线门槛，历史问题簇可以追踪复发。
这三个阶段不需要一步到位。早期最重要的是让系统跑通：真实数据进来，评测结果可信，报告有人用。等业务开始依赖它做决策，再逐步加入版本对比、自动抽样、规则审批和问题生命周期。
不要一开始就把平台做成庞大的治理系统。质量治理是被使用长出来的，不是靠菜单堆出来的。
十一、一个完整闭环示例
假设某次上线后，评测系统发现「高风险咨询缺少分流」这个红线问题簇，影响 12 条对话。
第一步，报告把它列为红线问题，附带代表失败样本和规则依据。
第二步，PM 打开详情，确认问题成立，把决策状态改为「立即处理」。
第三步，工程团队根据行动项修改 Agent 流程：先识别高风险信号，再追问关键信息，最后给出安全边界和必要引导。
第四步，系统导出的验收案例进入回归集，包括典型失败、边界样本和成功对照。
第五步，新版本上线前跑回归评测，确认该问题簇不再命中，且成功对照没有退化。
第六步，上线后一周继续抽样真实对话，观察同类问题是否复发。
这条链路里，评测不是最后一步，而是下一轮迭代的起点。
十二、总结
一次评测发现问题，持续评测才形成质量体系。
黑盒 Agent 评测的长期价值，不是每次生成一份漂亮报告，而是不断沉淀四类资产：Rubric 规则包、真实评测样本、问题簇、验收案例。它们共同支撑上线前回归、上线后抽样、版本对比、人工校准和规则迭代。
这个系列反复强调的分工，到这里依然成立：模型负责语义判断，系统负责协议边界，人负责最终决策。三者各自站稳，Agent 评测才不会停在一次性打分，而能变成持续改进的工程链路。
对生产 Agent 来说，质量不是某一次评测报告里的数字，而是一套可以反复运行、持续校准、不断积累证据的机制。