Agent 评测落地实践 - Digest

一句话结论

评测不是上线前的一次打分，而是从 PRD 定义门禁、将任务和评分器版本化、复用生产 Run 记录，再由问题中心和持续回归把失败接回优化的闭环。

七个分析角度

1. 评测前置到 PRD

• “先写成功标准和发布门禁，评测才不会在上线前临时补作业。”
• “正确、完整、格式、过程、延迟、成本和安全应共同定义成功。”
• “真实业务任务、工程边界案例和线上问题应汇入同一用例资产。”

2. 不只验最终答案

• “多答案正确不等于过程可接受，工具链和副作用也要被检查。”
• “任务完成、工具调用、Skill 使用、执行过程和非功能指标应分维度观察。”
• “拆分任务类型有利于定位，但端到端用例不能被局部指标替代。”

3. 评分器按风险分层

• “可确定的规则先用断言、Schema 和正则，不把简单判断交给 LLM。”
• “开放题用 Rubric 驱动的 LLM 裁判，并让它输出可审计的结构化理由。”
• “高风险和争议案例保留人工复核，重复运行则用于识别随机波动。”

4. 数据集是版本化产品

• “开发集、回归集和保留集分开，避免调参反馈污染最终判断。”
• “每条用例应同时携带上下文、预期、评分方式、标签和优先级。”
• “线上失败经脱敏、去重和审核后进入回归集，才会形成真实质量飞轮。”

5. Run 必须可复现

• “一次分数没有解释力；数据、Prompt、模型、工具、Skill、知识库和评分器都要入快照。”
• “外部副作用要禁用、Mock、录制回放或放进受控环境。”
• “评测复用生产 Runtime 与 Trace，才能避免离线好看、线上失真的双运行时。”

6. 报告应指导决策

• “只报平均分会掩盖波动，至少同时看通过率、方差、成本和延迟。”
• “每次优化都与固定基线比较，才能识别提升、回归和代价转移。”
• “给用例和批次设时间、Token、成本预算，防止评测吞掉工程资源。”

7. 失败要进入问题中心

• “问题中心应同时查看 Agent Trace 和评分器 Trace，先区分系统问题与评测问题。”
• “失败归因到 Prompt、模型、知识库、工具、环境或评分器，再分配负责人和修复版本。”
• “修复后的重测与 CI 回归，才把一次事故转成长期门禁。”

可执行最小闭环

1. 选一个高频任务，写出结果、过程、成本和安全四类门禁。
2. 建立开发集、回归集和保留集；每条样本绑定断言或 Rubric。
3. 记录完整 Run 快照，先禁用或 Mock 真实副作用。
4. 用固定基线比较通过率、方差、Token、成本和延迟。
5. 把失败送进问题中心，修复后重新评测，并将确认的线上问题纳入回归。

证据边界

这是公众号作者的实践性框架，未给出可独立复现的平台代码、数据规模或基准结果。文中的平台组成和流程可作为设计清单，不应被视为已验证的通用效果承诺。