很多团队第一次做 Agent 评测，都会从一个看起来很自然的问题开始：这个 Agent 平均多少分？
这个问题当然重要。平均分能给出一个整体印象，也方便管理层快速判断趋势。但如果评测系统只围着平均分转，它很快会失效。生产 Agent 的质量问题不是一道考试题，分数高不代表风险低，分数低也不一定说明值得立刻排期。真正决定团队行动的，往往是另外几个问题：有没有红线？问题集中在哪些业务场景？哪些规则反复没遵循？本期最应该改知识库、Prompt、工具，还是流程？
我们在一个真实的黑盒 Agent 评测平台里踩过这个坑。最初系统更像诊断工具：上传对话数据，找出 badcase，再生成问题报告。后来业务方开始追问更明确的评测口径：不仅要知道哪里坏了，还要知道按既定业务标准到底得几分、违反了哪条规则、红线有没有、能不能复核。这时我们才意识到，Agent 评测的核心不是「把每条回答打一个分」，而是建立一套能把真实问题推到修复链路里的质量体系。
这一篇先讲这个系列的出发点：为什么平均分不够，以及一个面向落地的黑盒 Agent 评测系统应该回答哪些问题。
一、平均分是必要的，但远远不够
平均分最大的问题，是它会把风险抹平。
假设一个客服 Agent 本周评测了 1000 条对话，平均分 4.4。这个数字看起来不错，但它可能同时包含两种完全不同的情况。
第一种情况是：大多数回答都稳定，少数 3 分样本只是表达不够自然、信息略少。这类问题不紧急，适合放进长期体验优化。
第二种情况是：绝大多数回答 5 分，但有 10 条回答出现了高风险承诺、医疗越界、价格编造或错误转人工。这时平均分仍然可能很高，但系统绝不能被判为健康。
平均分把所有问题压成一个数，但生产系统不能只按一个数行动。一个低频红线问题，优先级可能高于一个高频轻微话术问题；一个集中在核心转化场景的问题，优先级可能高于一个分布在闲聊场景的问题；一个用户点踩率很高的问题簇，优先级也应该比纯自动诊断发现的问题更高。
所以平均分只能作为入口指标，不能作为评测结论本身。
更准确地说，平均分回答的是「整体表现大概如何」。而生产评测还需要回答：
- 有没有不可接受的红线风险？
- 哪类业务场景最容易出问题？
- 违反最多的是哪些具体规则？
- 问题影响多少条对话、多少个会话？
- 哪些问题值得本期排期修？
- 修完之后用什么样例验收？
只有这些问题被回答，评测才开始接近真实工作流。
二、黑盒约束：只能看输入和输出
理想状态下，Agent 评测当然想看白盒链路：检索命中了什么知识，工具调用参数是什么，Prompt 拼接结果是什么，中间状态如何变化。但现实里，很多团队拿不到这些东西。
原因很常见：Agent 是外部供应商交付的；内部 trace 不在同一个系统；日志字段不统一；数据权限很难打通；或者系统本身还没建设完整观测链路。
这时唯一稳定存在的数据，就是用户输入和 Agent 输出。
query 用户说了什么
answer Agent 回了什么这就是黑盒评测的起点。它不关心被测 Agent 内部用了 RAG、工具调用、多智能体协作，还是一段复杂工作流。只要能导出对话，就能开始评估。
这个约束听起来寒酸，但有一个很大的好处：通用。系统不需要侵入 Agent，不需要改线上链路，也不需要等所有日志治理完成。业务同学先导一批真实对话，评测平台就能跑出第一份报告。
当然，黑盒也有边界。你看不到内部检索，就不能断言「知识库命中了错误文档」；你看不到工具返回，就不能断言「工具参数传错了」。评测报告可以说「回答违反了某条要求」，但对根因只能给出假设，不能把推断写成事实。
这是一条很重要的纪律：黑盒评测要诚实。能从对话里观察到的严格评，看不到的明确标不可观测。
三、评测系统真正要产出的不是分数
如果让评测系统只输出一张分数表，它很快会变成没人看的附件。工程师会觉得它不够细，产品经理会觉得它不可行动，业务方会觉得它解释不了风险。
一套可落地的 Agent 评测系统，至少要产出四类结果。
第一类是健康度。它面向管理层和产品负责人，回答「这批对话整体表现是否可接受」。这里可以有平均分、健康率、覆盖率，但还必须有红线数量。没有红线维度的健康度是不完整的。
第二类是规则遵循率。它面向评测负责人和业务专家，回答「既定标准中哪些规则没被遵循」。这类指标不能从模型解释里临时抽取，必须建立在稳定的规则 ID 上。
第三类是问题簇。它面向产品和研发，回答「问题是不是反复出现，影响范围多大」。单条 badcase 很难排期，反复违反同一条规则的问题簇才值得进入改造池。
第四类是优化行动项。它面向真正要改系统的人，回答「该改哪里、为什么改、怎么验收」。这一步要把评测发现翻译成知识库、Prompt、工具、流程、交互策略或数据质量上的具体动作。
从这个角度看，分数只是中间态。它帮助排序和概览，但不能替代证据、规则和行动。
四、红线比均值更接近生产风险
在生产环境里，红线问题有一个特点：低频也必须高优先级。
比如某个 Agent 一周里回答了几万条，其中绝大多数是正常咨询，只有少数几条出现了严重误导、越界建议、违规承诺或后台暴露。按平均分看，它可能依旧很好；按风险治理看，这几条已经足够触发修复。
所以评测系统里应该显式区分两种信号：
| 信号 | 典型问题 | 决策含义 |
|---|---|---|
| 均值类信号 | 平均分、健康率、评分分布 | 判断整体体验趋势 |
| 红线类信号 | 安全、合规、虚假承诺、后台暴露 | 判断是否需要立即干预 |
红线不能只是模型理由里的一句「问题严重」。它必须被枚举出来，例如：
- 高风险场景缺少必要提醒；
- 越界给出专业诊断或处置建议；
- 编造价格、优惠或购买承诺；
- 暴露后台、知识库、检索、系统提示等内部信息；
- 承诺不存在的工具能力或人工服务结果；
- 提及不允许出现的竞品或内部敏感表达。
枚举之后，红线才可以被统计、聚类、置顶和追踪。报告里能回答「本次命中了几类红线」「分别影响哪些样本」「是否集中在某个业务意图」。这比一句「有严重问题」有用得多。
五、规则遵循率比主观理由更可复核
LLM 很擅长生成一段看起来合理的评测理由，但理由文本很难被稳定统计。
比如模型说：
回答没有充分解决用户问题，且缺少必要风险提示。这句话对单条样本有解释力，但对批量分析没有足够结构。系统很难知道「没有充分解决」对应哪条业务要求，也很难把它和另一条「未给出风险提醒」归并到同一个统计维度。
更好的方式是让每条诊断都回到规则 ID：
{
"score": 2,
"unmetRequirementIds": [
"HEALTH_FOLLOWUP_QUESTIONS",
"HEALTH_RISK_TRIAGE"
],
"scoreExplanation": "回答直接给出建议，但缺少必要追问和风险分流。"
}这样系统能继续生成：
HEALTH_FOLLOWUP_QUESTIONS违反了多少次；- 它在哪些业务意图里最常见；
- 是否经常伴随用户负反馈；
- 是否已经达到行动门槛；
- 有哪些代表样本和成功对照样本。
这就是规则遵循率的意义。它把「模型觉得不好」变成「某条业务规则被违反」。前者只能讨论，后者可以复核、统计和改造。
六、为什么要从诊断升级到 Rubric 评测
黑盒诊断和 Rubric 评测不是互相替代的关系。
黑盒诊断更像侦查：在没有明确标准或标准还不成熟的时候，让模型从对话中发现问题、总结失败模式、生成优化建议。它的优势是启动快，适合探索未知问题。
Rubric 评测更像审计：当业务已经有明确质量标准时，把这些标准结构化，让每条对话都按同一套规则判断。它的优势是可复核、可统计、可对比。
两者的关系可以这样理解：
黑盒诊断：这条回答哪里不对？
Rubric 评测：按既定标准，它违反了哪条要求？真实系统里，这两条能力应该合在一起。诊断发现新问题，反哺 Rubric；Rubric 评测发现高频违规，再进入问题聚类和优化行动项。久而久之，评测系统不只是一次性分析工具，而会沉淀成团队的质量标准库。
七、一个可落地的评测链路
完整链路可以抽象成这样：
对话数据上传
→ 数据质量检查
→ 会话上下文构建
→ Agent 输出解析
→ Rubric 驱动的逐实例评测
→ 结构化结果校验与修复
→ 问题聚类
→ 优化行动项生成
→ 报告展示、证据下钻、导出与人工决策这里每一步都承担一个边界。
数据质量检查负责定义分母。空问题、重复行、异常耗时、缺失会话标识都要被显式处理，否则报告里的比例没有意义。
会话上下文构建负责还原用户旅程。同一条回答孤立看可能没问题，但放回多轮上下文里，可能会暴露没有承接、重复追问或答非所问。
Agent 输出解析负责看懂回答结构。真实 Agent 输出里可能有正式答案、思考痕迹、卡片、推荐问题，它们不能混在一起评分。
Rubric 逐实例评测负责给每条对话打分，并标出意图、红线和未满足规则。
结构化校验与修复负责兜住 LLM 输出。模型可以判断语义，但字段合法性、枚举范围、规则 ID 是否存在，要由应用代码负责。
问题聚类负责把单条低分样本收敛成问题簇。聚类键最好来自业务规则，比如 intentKey::requirementId，而不是只靠语义相似度。
优化行动项负责把问题簇翻译成团队能排期的动作。比如改知识库、改 Prompt、改工具、改流程、改交互策略。
报告负责让不同角色读懂结果。管理层看健康度，产品看问题和优先级，工程看证据和验收案例。
八、不要让评测系统替业务拍板
评测系统可以给建议，但不应该越权替团队做最终决策。
比如一个问题簇影响了 30 条对话，系统判断它属于主问题，建议优先修。这不等于团队本期一定要做。团队还要考虑业务目标、开发成本、风险窗口、是否已有其他方案在路上。
所以报告里最好区分两层状态：
| 层次 | 由谁产生 | 含义 |
|---|---|---|
| 系统建议 | 评测系统 | 根据分数、红线、频次、反馈给出优先级 |
| 团队决策 | 人 | 本期处理、继续观察、暂不处理 |
这个边界很重要。系统负责把问题推到台面上，并给出足够证据；人负责结合上下文做取舍。
如果评测工具强行把所有建议都包装成「必须做」，很快就会和真实排期冲突。更好的做法是让系统保持克制：建议明确、证据充分、决策留给人。
九、从一次报告到持续优化
一次评测能发现问题，但持续评测才能建立质量体系。
当 Rubric、诊断结果、问题簇、行动项和验收案例都被结构化保存后，系统就可以支持更长期的工作流：
- 新版本上线前，用同一批验收案例做回归；
- 新版本上线后，抽取真实对话跑批量评测；
- 对比不同 Agent 版本的平均分、红线数和规则遵循率；
- 发现误判时，不是手工改报告，而是修订 Rubric；
- 新问题反复出现时，把它沉淀成新的规则；
- 团队每次优化后，都能回看问题簇是否缩小。
这时评测系统就不再是「找 badcase 的工具」，而是 Agent 质量治理的一部分。
它连接了四类资产：
业务标准 → Rubric 规则包
真实对话 → 评测样本
低分样本 → 问题簇
优化动作 → 验收案例有了这四类资产，团队就可以从被动响应用户投诉，转向主动运营 Agent 质量。
十、后续几篇准备讲什么
这一篇只是开场，重点说明为什么 Agent 评测不能只看平均分，以及为什么要从黑盒诊断升级到 Rubric 评测。后面八篇会沿着一条完整链路往下拆。
第一篇讲 Rubric 结构：把专家标准工程化成意图、硬性要求、红线、命中分、可观测性和版本快照。
第二篇讲问题聚类：怎么把逐条低分样本按 intentKey::requirementId 收敛成问题簇，再进入优先级和行动项。
第三篇讲评分协议：1-5 分如何和红线、规则遵循率、referenceBasis 对应，为什么分数必须能被规则重新约束。
第四篇讲结构化输出：如何用严格 JSON Schema 和服务端校验约束 LLM-as-judge，怎么补齐规则、修坏行、做失败隔离。
第五篇讲输出解析：评测前如何还原会话上下文，拆解思考痕迹、正式答案、卡片和推荐问题。
第六篇讲报告设计：把评分分布、规则遵循率、红线报告、证据下钻和行动项组织成 PM 能用的决策工作台。
第七篇讲长任务：不用消息队列，如何用数据库任务表、原子领取和阶段状态可靠地跑完批量评测。
第八篇讲持续闭环：把一次性评测接入发布前回归、上线后抽样和 Rubric 迭代，沉淀成质量体系。
十一、总结
Agent 评测不是给答案打分，而是把真实对话里的质量问题，推到团队可以复核、可以排期、可以验收的位置。
平均分可以作为入口，但它不是结论。红线、规则遵循率、问题簇、证据下钻和优化行动项，才是生产评测真正要交付的东西。
这也是 Rubric 工程化的价值：它把专家经验从一段自然语言，变成系统可以长期运行的质量协议。模型负责语义判断，应用负责协议边界；模型告诉我们这条回答违反了什么，系统保证这个判断有规则 ID、有版本、有分数、有证据、有后续动作。
只有这样，评测系统才不会停在「模型说它不好」，而会变成一条持续改进 Agent 的工程链路。