核心命题：评测不是上线前的一次打分，而是从 PRD 写清任务边界与门禁，将用例和评分器版本化，复用生产 Run 证据，再由问题中心和持续回归把失败接回优化的工程闭环。
本文补足 [[01-ai-agents/Agent评测漫谈-由浅入深讲解Agent评测]] 的评测框架和长程基础设施视角，聚焦“评测平台怎样日常运行”：数据集如何分层，评分器如何绑定，Run 如何可复现，失败如何归因和重测。
| 节点 | 要解决的问题 | 可执行做法 |
|---|---|---|
| 评测前置 | 上线前才发现没有可验收标准 | PRD 中定义任务范围、成功标准和发布门禁 |
| 任务分型 | 同一套指标难以定位问题 | 查询、问答、生成、执行分型，同时保留端到端用例 |
| 多维评测 | 最终答案掩盖过程与风险 | 同时评结果、工具/Skill、轨迹、延迟、成本、安全 |
| 数据集分层 | 调参反馈污染最终判断 | 分离开发集、回归集、保留集并冻结发布版本 |
| 评分器编排 | 规则、LLM 与人工各自失准 | 确定性规则优先，Rubric LLM 补开放题，人工校准高风险/争议 |
| 运行快照 | 分数无法解释或复现 | 固化数据、Prompt、模型、工具、Skill、知识库、评分器与协议版本 |
| 问题中心 | 失败停留在报告里 | 结合 Agent Trace 与评分器 Trace 归因、分派、修复、重测 |
| 持续回归 | 修复后旧问题又回来 | 将线上失败和人工争议审核后纳入回归集，以 CI 或定时任务执行 |
评测最早应出现在需求设计，而不是发布前。对每个 Agent 任务，先写清：什么算正确，结果必须包含哪些信息，过程有哪些不可违反的约束，延迟和成本预算是多少，哪些权限或副作用不可接受。
用例来源应至少包含真实业务流程、工程侧的边界与异常、线上失败的脱敏回流。任务可按查询、知识问答、内容生成、执行四类分开建设，便于分别定义指标；但上线门禁仍要保留端到端样本，防止组件在局部得分提升、整体却失效。
Agent 的“完成”至少有三层：
这使评测从“答案对不对”变成“任务系统是否能以可接受代价、可解释过程和可控风险完成目标”。当多个答案都合理时，评分标准需要陈述业务约束，而非假设唯一参考答案。
优先把确定的要求写成断言：字段存在性、JSON Schema、正则、包含关系和精确值。再用轨迹评分验证关键步骤或工具调用是否出现、顺序是否满足约束。开放性内容适合 Rubric 驱动的 LLM 裁判，但其输出应是分维度、带理由的结构化结果，由服务端复算分数和门禁。
人工复核用于高风险、主观性强或裁判争议的场景，并反过来校准 Rubric。高价值样本要多次执行，报告同时看平均分、通过率和方差。每次系统改动都对照固定基线比较质量、延迟和成本，避免把代价转移误判为质量提升。
1
2
3
4
5
6
7
PRD 门禁
-> 版本化数据集（开发 / 回归 / 保留）
-> 用例绑定评分器与预算
-> 生产 Runtime 运行并采集完整 Run / Trace
-> 分数、通过率、方差、成本、延迟对比基线
-> 问题中心归因与修复重测
-> 已确认失败回流回归集和 CI
每一次 Run 都需要快照化：数据集版本、Agent 与 Prompt、模型和参数、工具、Skill、MCP、知识库、评分器和协议。外部副作用应采用禁用、Mock、录制回放或受控环境。用例和整批运行还需配置时间、Token、成本预算，预算耗尽立即停止。
关键原则是复用生产 Agent Runtime 和可观测性数据。否则离线评测在一套运行时内成功，线上在另一套运行时内失败，分数就失去解释力。
单次失败不能直接归因于 Agent。问题中心应同时呈现目标 Agent Trace、评分器 Trace 和失败类别，区分 Prompt、模型、知识库、工具、环境与评分器本身的问题；随后记录严重度、负责人和修复版本，修复后发起重测。
开发失败、人工争议、线上抽样问题经过脱敏、去重和审核后进入回归集。评分器也应利用人工标注校准。这样 CI 或定时回归验证的不只是“有没有跑”，而是过去已经确认的失效路径是否被重新打开。
本文是叶小钗对自身平台实践的经验整理。原文未给出可独立复现的实现、样本规模、对照实验或性能结果；本文将其作为评测平台设计清单，而不将平台能力或效果视为通用结论。