前面几篇把评测引擎讲完了：Rubric 如何定义，分数如何约束，LLM-as-judge 如何稳定输出结构化结果，评测前如何还原上下文和拆解 Agent 输出。
但评测系统真正交付给团队的，不是数据库里那几张表，也不是一堆 JSON 结果，而是一份报告。
报告这一层很容易被低估。工程师天然会想：既然评分、红线、规则遵循率、问题簇和行动项都已经算出来了，把它们展示出来就行。但 PM 打开报告时，脑子里不是字段结构，而是三个问题：这个 Agent 现在是否健康？问题主要在哪里？下一步该怎么优化？
如果报告不能按这三个问题组织，它就只是一个查询页面。数据很全，但读者仍然要自己在图表和表格之间建立联系。
这一篇讲怎么把 Agent 评测报告设计成 PM 能用的决策工作台。
一、报告的读者不是只有工程师
评测系统至少有三类读者。
第一类是工程师。他们关心字段是否完整、规则是否命中、模型输出是否可靠、失败行为什么失败。
第二类是产品经理和运营。他们关心 Agent 是否健康、哪里影响体验、哪些问题值得排期。
第三类是业务负责人。他们不看明细，只想知道有没有红线、整体质量趋势如何、这次优化是否有价值。
这三类读者需要的不是同一种信息密度。
| 读者 | 关心问题 | 需要的信息形态 |
|---|---|---|
| 业务负责人 | 是否可接受，有无风险 | 健康结论、红线数量、核心指标 |
| PM / 运营 | 先改什么，为什么 | 问题簇、优先级、行动项、证据 |
| 工程师 | 怎么定位和复现 | 原始对话、规则依据、验收案例、导出 |
报告的信息架构要让不同读者能停在自己的层级。首页给结论，详情给证据，导出给工程分析。
二、三问叙事：是否健康、问题在哪、怎么优化
评测报告最稳的阅读路径，是按三个问题组织。
Agent 是否健康？
→ 有什么问题？
→ 如何优化？这三个问题有先后关系。读者先要知道整体状态，再看问题分布，最后才看行动建议。如果页面一上来同时摆平均分、红线表、意图图、行动项、数据质量、导出入口，读者会迷路。
首页可以拆成四块：
- 评测结果：健康结论、平均分、健康率、红线数、覆盖率。
- 优化建议：本期建议优先处理的行动项。
- 问题定位：问题分布、意图评分、规则遵循率。
- 报告附录：数据质量、版本信息、导出入口、观察区。
这不是简单的版面排序，而是在帮读者建立判断路径。
健康块回答「能不能放心」；优化建议回答「下一步动什么」；问题定位回答「为什么这么建议」；附录回答「这份报告的边界是什么」。
三、健康结论要显式，不要让读者自己算
如果报告顶部只有一排指标：平均分 4.2、健康率 82%、红线 3 条、覆盖率 96%，PM 仍然要自己判断这到底算不算健康。
更好的方式是给出显式结论，比如：
- 健康；
- 需关注；
- 需干预。
这个结论不要让 LLM 现场生成，而应该用确定性规则产生。比如：
存在红线实例 → 需干预
无红线，但问题占比超过阈值 → 需关注
其余情况 → 健康规则可以随着业务调整，但必须显式。显式规则有三个好处：可解释、可复现、可校准。
覆盖率要放在健康结论旁边，但不要参与 Agent 质量打分。覆盖率低只说明报告可信度不足，不说明 Agent 表现差。报告文案要区分这两件事：
基于已完成诊断，本次 Agent 状态为需关注。当前覆盖率偏低，结论仅供参考。这类措辞比单纯展示数字更安全，也更符合真实决策场景。
四、分数视图和规则视图要并存
Rubric 评测报告需要两套视图。
第一套是分数视图，用来快速判断整体质量：
- 平均分；
- 健康率；
- 评分分布；
- 红线实例数；
- 各意图均分；
- 诊断覆盖率。
第二套是规则视图，用来解释质量问题：
- 违反最多的规则；
- 各规则类别遵循率；
- 红线类型分布；
- 每个问题簇对应的规则；
- 规则下的代表样本。
只有分数视图，报告会像黑盒裁判。PM 知道 3.8 分，但不知道为什么。只有规则视图，报告又太细，读者很难快速判断整体状态。
两套视图的关系应该是：分数视图负责概览，规则视图负责解释。读者先看分数，再沿着某个低分意图或高频规则下钻到证据。
五、红线报告要独立出来
红线不应该藏在评分分布里。
如果 1 分样本只有 3 条，而 2 分样本有 80 条，普通柱状图会让红线显得很小。但红线的意义不是频次，而是风险。
红线报告至少要展示：
- 红线总实例数；
- 红线类型分布；
- 每类红线对应的 rowId；
- 红线是否集中在某个意图；
- 红线样本是否有用户负反馈；
- 对应的问题簇和行动项。
红线的视觉层级也要高于普通问题。比如在优化建议列表里置顶，使用独立标签，在详情里展示触发的 critical 规则。
这不是为了制造紧张，而是为了避免低频高危被高频轻微问题淹没。
六、证据下钻决定报告可信度
评测报告最容易被质疑的地方是：这些结论是不是模型编的？
解决这个问题的方法不是写更长的解释，而是让每个结论都能下钻到证据。
点击平均分，能看到评分分布和样本；点击某个意图，能看到该意图下的低分对话；点击某条规则，能看到违反它的所有 rowId；点击某个行动项，能看到代表失败样本和成功对照。
一次下钻最好能展示这些字段：
- rowId；
- sessionId；
- 用户问题；
- Agent 回答；
- 前序上下文；
- 分数；
- 红线类型；
- 评分解释；
- 未满足规则；
- 用户反馈。
这样读者可以从任何指标回到原始对话。报告的信任不是靠「相信模型」，而是靠「每个结论都能复核」。
七、行动项要从问题簇来，不要从单条样本来
报告里的优化建议应该对应问题簇，而不是单条 badcase。
单条 badcase 可以作为证据，但不能直接变成行动项。否则报告会产生大量碎片化建议，比如「这一条要说清楚一点」「那一条要多安抚」。这类建议难以排期，也难以验收。
问题簇行动项应该包含：
- 违反的规则；
- 影响实例数和会话数；
- 代表样本；
- 成功对照；
- 根因假设；
- 建议修改对象；
- 具体动作；
- 预期影响；
- 验收案例。
修改对象要尽量明确，比如：
KNOWLEDGE_BASE：知识库缺规则或事实；PROMPT：提示词约束不清；TOOL：工具能力或参数有问题；FLOW：业务流程顺序错误；INTERACTION_STRATEGY：追问、安抚、引导策略不稳定；DATA_QUALITY：输入数据或日志口径问题。
行动项越具体，越容易进入真实需求池。
八、首页只给建议，详情页再做决策
报告里可以有人工决策状态，但不要把决策控件塞满首页。
首页的职责是帮助读者理解：健康吗，问题是什么，系统建议先处理什么。真正做「本期处理 / 继续观察 / 暂不处理」这类判断，需要看详情：根因假设、证据样本、影响范围、验收案例。
所以更好的交互是：
首页：展示行动项列表和优先级
详情：展示证据、建议、验收案例和决策控件这个边界能避免 PM 在没有看证据前就被迫拍板。系统给建议，人做决策；报告承担理解，详情承担确认。
九、导出不是附属功能
评测报告里的导出能力很容易被当成附属功能，但它其实是闭环的一部分。
至少需要两类导出。
第一类是诊断明细导出。它包含每条样本的分数、意图、红线、未满足规则和解释，方便工程师离线分析或与业务专家复核。
第二类是验收案例导出。它来自行动项，每个问题簇生成典型失败、边界样本和成功对照，用于后续回归。
没有导出，评测结果只存在于一次报告阅读里。能导出，问题就能进入外部流程：需求评审、研发修复、人工验收、版本对比。
十、一个报告页面的推荐结构
把上面的内容拼起来，一份评测报告可以这样组织：
评测结果
- 健康结论
- 平均分 / 健康率 / 红线数 / 覆盖率
- 评分分布
优化建议
- 红线行动项
- 主问题行动项
- 建议修改对象汇总
问题定位
- 意图评分
- 违反最多的规则
- 规则类别遵循率
- 红线类型报告
评分与规则细节
- Rubric 信息
- 规则遵循明细
- 推荐问题 / 卡片专项检查
报告附录
- 数据质量
- 覆盖率与失败行
- 版本信息
- 导出入口
- 观察区问题这个结构不是唯一答案，但它遵循一个原则：先让人理解状态，再让人看到建议，最后提供证据和细节。
十一、总结
Agent 评测报告不是把字段展示出来，而是把评测结果翻译成决策路径。
好的报告应该回答三件事：Agent 是否健康，问题主要在哪里，下一步怎么优化。平均分、规则遵循率、红线报告、问题簇、证据下钻和验收案例，都应该服务这条路径。
当报告能从管理结论一路下钻到原始对话，再从行动项导出验收案例，评测系统才真正从「分析工具」变成「决策工作台」。