Agent 评测

摘要

这篇笔记回答三个问题：

• 评测是什么——一种工作方式：Build → Look → Understand，标准从数据中生长；
• 评测什么——一个行动系统，不只是一个答案：Task / Trial / Trace / Outcome / Grader / Harness 六对象；
• 怎么落地——三层指标搭桥、客观主观并行、人人一致人机一致、数据飞轮。

合起来是一条完整评测观：用工作方式定态度，用六对象定对象，用工程体系定做法。

---

一、评测是什么

核心循环：Build → Look → Understand

阶段	动作	目的
Build	搭建工具、代码、Prompt、规则	有东西可看
Look	对比观察、标注、发现 Bad Case	看见问题
Understand	理解边界、形成标准、发现结构	定义“好”是什么

传统开发是“先明确需求 → 构建 → 测试验证”，评测是独立环节。AI 产品反过来：不知道需求是什么，先构建观察工具，看见数据之后需求才浮现。评测因此嵌进产品、研发、测试的共同过程。

Build to Look

AI 产品的数据没法直接看，每 build 一个工具，就多看见一层东西：

• 拉索对比页面 → 看见“对比”
• Gemini 评审 → 看见“扩展观察覆盖面”
• rule_trace → 看见“中间决策”
• 标签体系 → 看见“场景化切片分析”

需求从数据中生长

层次	是否预先定义
产品层面（为什么做、解决什么问题）	预先定义
实现层面（判断标准、边界、“好”的定义）	从数据中生长

“花瓶和酒瓶怎么区分”没法预先定义，只能在 bad case 面前被定义出来。实现层的判断标准占比更大、更关键，因为情况穷举不完。

Logging ≠ Observability

logger.info("prompt generated")     → 只知道"发生了什么"
rule_trace 结构化输出                → 每一步判断都可见

看日志只知道发生了什么，看不见每一步怎么判断。

Pipeline 是被反推出来的

我在高途做讲义转课件时走过一遍。最早做的是通用 Agent：给模型配脚本能力、文件读写等工具，让它自己读 Word、分析结构、决定每页版式、现场写脚本现场跑。跑下来撞上两个问题：

层级	问题
决策层	“哪块内容去哪个版式、一道题拆几页”讲义本身不携带、也没有标准答案，AI 现场决策等于自由发挥，教研拿到要从头改到尾
执行层	占位符编号是不携带语义的物理 ID，“编号 → 语义”的映射没有机器可读载体，AI 只能盲猜；失败还被静默吞掉，找不到版式就降级成空白页，输出全白课件却提示“生成成功”

被这两个问题逼出来的分工：需要智能的过程交给 Skill（接新模板、确认映射、修规则），需要确定的过程交给脚本（批量出课件）。决策挪到产前由教研确认写死，执行交给脚本，失败必须可见、可阻断。

架构不是先想清楚再写代码，而是先跑起来、从 bad case 里发现缺什么节点。

---

二、评测什么（评测对象：行动系统，不是答案）

六大核心对象

对象	定义	说明
Task	一个具体的测试任务（测试用例）	如“帮我审查这个 JS 接口代码的问题”
Trial	同一 Task 的一次执行	模型有随机性，一个 Task 要跑多次，不能只看单次
Transcript / Trace	完整执行轨迹	模型输出、工具调用、中间结果、交互记录
Outcome	最终环境状态	不能只看 Agent 说了什么，要验证外部系统状态真的被改变——客服说“退款成功”，要查系统里是否真的生成了退款单
Grader	评分器	代码规则 / LLM Judge / 人工评审
Eval Harness	评测运行框架	批量跑任务、记录过程、调用评分器、聚合结果

Task → Trial → Transcript/Trace → Grader → Outcome

为什么 Agent Eval 比单轮问答复杂

多轮行动（任何一步都可能影响结果）、工具调用（正确使用直接影响成败）、改变环境状态（行为真实改变外部系统）、错误传播与累积（早期小错误被放大）。

随机性决定了 Trial 的必要性

同一测试用例跑 10 次看通过率：9/10 算稳定，5/10 不稳定需排查。LLM 不是确定性系统，单次结果不可靠，必须看统计意义上的稳定性。

Grader 分层设计

能用代码评就用代码评，代码评不了的再用 LLM Judge，关键业务场景人工抽检校准：

评分器	适用	示例
代码评分器	结构化、可断言指标	格式、字段、工具调用、数据库状态
模型评分器（LLM Judge）	软性、语义指标	语气、完整性、逻辑质量
人工评分器	关键场景校准	抽样读 transcript，校准 LLM Judge

我在讲义转课件里用的就是这套：脚本层的 WPS 兼容、字体、行距、版式用机器硬评，FAIL 即阻断；PPT 层好不好看靠代表页截图软评；内容是否可用由教研逐件验收。代码评得了的绝不上模型和人。

评结果，不评路径

写死结果断言，不要写死执行顺序。

案例：用户问订单物流，AI 跳过“问手机号”直接查物流、发现卡件主动道歉并给补偿券，3 轮搞定无投诉——

• 按写死的路径评（第 1 步没执行）→ 判定失败 → PM 逼 AI 必须先问手机号 → 聪明 AI 被改傻
• 按结果断言评（状态准确告知 / 异常道歉补偿 / 语气得体 / 不超 5 轮）→ 判定通过 → 聪明路径保留，skill 越用越聪明

两个例外必须查路径：安全合规节点（退款必须验证身份，verify_identity 不可跳过）、数据真实性（物流必须调真实接口，不许编）。

对照组是证明价值的唯一方式

同时跑 with_skill 与 baseline（新 skill 对照无 skill，旧 skill 对照旧版本）：

if 不带 skill 也能通过 → skill 没必要存在
if 模型升级后变差了   → skill 退化，要改

配套检验：检查项要有区分度——不带 skill 跑 10 次、带 skill 跑 10 次，差距 > 30% 才算有区分度。“输出是否中文”这种两边都 100% 通过的检查等于没写。

两套测试集，目标相反，缺一不可

测试集	目标	通过率基准
能力测试	测还不擅长的，推动进步（向前看）	30% 起步，涨到 60% 算胜利
回归测试	测已通过的，防止改一处坏一处（向后看）	保持原指标，不下降

测试集要 20–50 条（视情况上百条），来自真实业务场景或 badcase（用户投诉、客服工单、bug tracker），不要凭空写。

黑盒诊断：中间过程不可观测是根本约束

简历生成 Skill 输出了“准确率提升 18%”，但这个数字不在 PRD 里。四种可能（没读懂 PRD / 提取提示词没写清 / 幻觉 / 数字混淆）全部无法验证——中间过程是黑盒。

解法（按优先级）：

1. 把“思考”拆成“工具调用”：extract_numbers(PRD) → 返回所有数字 → match_project_metrics(数字列表, 项目名) → 生成时只能用列表里的数字。18% 不在列表里，立刻能定位违反约束发生在哪步。推理从黑盒变成可观测、可追踪、可断言。
2. 同一用例跑 10 次，看通过率（应对概率性错误）。
3. 输出强制结构化，用代码自动校验（三要素不齐就告警）。

简历问答 Agent 的落地也是这条路：来源标注、只读知识库、reasoning 可见，把中间过程做成可观测、可断言。

三个进阶原则

• 负例要有迷惑性：差一点就该触发的负例才是好负例。“帮我评估这份简历”（评估≠生成）比“今天天气怎么样”有用得多。
• 迭代要修根因，不打补丁：“简历里没数字”→ 加硬规则“必须含 3 个数字”会让模型硬编数字；挖根因发现是数据提取步骤太弱，升级提取逻辑才能泛化。
• 评测投入匹配阶段：原型期 6 条触发测试 + 几个维度检查即可；规模化期才需要能力+回归两套独立测试集、A/B、跨模型验证。

---

三、怎么落地（怎么建体系）

评测方法的三阶段演进

阶段	评测对象	核心问题	典型方法
机器学习模型评测	单模型	预测得准不准	准确率、召回率、AUC、RMSE
大模型评测	基座模型能力	能力强不强	多维 Benchmark、人评、机评
Agent 评测	任务系统	任务能否稳定完成	全链路观测、分层指标、过程评测、自动化回归

Agent 评测真正要回答的是：当模型被放进真实系统，和 Prompt、Skill、工具链、记忆、状态管理、业务流程耦合在一起后，能不能稳定交付好的结果。

至少覆盖四层

结果层（任务完成没）｜过程层（规划合理、步骤稳定）｜效率层（耗时/Token/调用次数）｜风险层（越权、误操作、安全隐患）。

两个 Agent 可能都“做对了”，但一个路径清晰可复现、一个反复试错偶发命中——工程价值完全不同。评测正在从“答案评测”走向“行为评测”。

观测是评测的基石

大模型带来泛化能力的同时带来随机性。弥合随机性与可靠性的鸿沟要回归工程视角：看不见的问题，几乎不可能被稳定解决。Trace 把黑盒内部的全路径披露出来，这是评测的前提。

体系的核心不是堆指标，而是“搭桥”

模型指标和业务指标之间有天然鸿沟（推理能力 ↔ 用户留存），中间必须有一层面向任务系统的桥梁指标：

层级	关注问题	示例指标
业务目标层	是否创造业务价值	DAU、留存、转化、人工节省时长、完单率
Agent 能力层	是否把用户任务做成	任务完成率、一次成功率、交付可用率、Tool/Skill 调用成功率、纠错成功率
模型能力层	基座能力是否足够	推理、遵循、检索、长文本、代码

讲义转课件每期节省 300+ 小时落在业务目标层，选题率 57%→70% 落在 Agent 能力层。

客观保下限，主观提上限

• 客观评测：规则清晰、可自动化、可规模执行，解决“准不准”；
• 主观评测：解决“好不好”，标准难建立、贵，但贴近真实体验；
• 现实做法：主观评测校准客观评测和 AI 评测，再把规模化部分交给自动化。

“人人一致、人机一致”对齐主观标准

• 人人一致：1 个“独裁者”好过 10 个“民主者”——需要一位最懂业务的角色拉齐产品/运营/研发/QA 的标准，评测员背靠背标注拉齐。高方差的危害远大于高偏差：分不清指标变化是真实提升还是评测波动。
• 人机一致：机器评测结果与人工一致才可置信，意义在于规模化提效。

题库提质里的 500 题金标抽检就是这个对齐动作：每轮教研抽 500 题人工标注，AI 判精品的确认率就是正确率口径。

具体方法：指标下钻 + Rubric 二元化

把“大而模糊”拆成清晰维度，把打分规则收敛成是/否/未知（0/1/unknown），用 unknown 占比反查 Rubric 定义是否合理，迭代到人人一致率、人机一致率达到可信阈值（如 85%、90%）。

案例	错误示范	二元化改法
骑手外呼“口语化”	“判断回答是否口语化，0–10 分打分”	是否用“您”指代骑手？是否有“甭客气”“明儿见”等口语词？是否含“吧”“呢”等语气词？
初中作文（40 分）	—	主旨 30%（偏题没/覆盖要求没）＋逻辑 30%＋语言规范 20%＋内容深度 20%，每维拆成可判定评分点

标注是一种动作，评测是一套目标导向的判断流程。

数据飞轮：五环节实践科学

环节	内容
采集	采集线上或沙箱中的原始任务数据
清洗	去重、归类、补上下文、修复脏数据
评测	人工评测、AI 评测
质检	检查标准是否稳定、结果是否可信
分析/归因	定位问题归因，形成优化建议和回归任务

起步路径：高频核心场景 + 少量关键指标 → 生产环境收 Bad Case → 沉淀 Good Case 定义“好” → 转成标准评测样本 → 评测结果反哺 Prompt/Skill/策略 → 从新线上表现持续抽样。Bad Case 价值更高（暴露能力边界），Good Case 的作用是定义高质量完成的范式。

题库提质基本是这套流程完整走一遍：SQL 取数 → 规则预清洗 → AI 质检 → 人工卡点 → 漏报/误报回流到下一轮提示词。

垂域冷启动靠行业专家定义“好”：旅行规划找网红、AI 电销找销冠、客服找金牌客服。

---

四、我的落点

• TraceLens 的理论根基：Build→Look→Understand 和“标准从数据中生长”就是 TraceLens“看见 → 指认 → 沉淀”三步的来源；Logging ≠ Observability 是轨迹工具的存在理由。DSH 官方视图的证据链止于 Completed/Error——不判断“这次调用该不该发生”，素材齐备而判断缺失，诊断规则补的就是把主观标准沉淀为规则这一步。
• 题库质检的印证：500 题金标抽检 = 人机一致对齐 + 数据飞轮；“宁严勿宽”= 错升与漏升的代价不对称。评测方法论先于 TraceLens 存在，评测体系（理论）→ 题库质检（工业实践）→ TraceLens（作品）是一条连续的线。
• 简历问答 Agent 的印证：来源标注、只读知识库、reasoning 可见，本质是“把中间过程做成可观测、可断言”在产品侧的应用。

---

关键要点

• 评测是工作方式不是验收动作：Build→Look→Understand，实现层的标准从数据中生长
• Logging ≠ Observability；看不见的问题几乎不可能被稳定解决，观测是评测的基石
• 评测对象是行动系统：Task / Trial / Trace / Outcome / Grader / Harness 六对象；Outcome 要验证环境状态真的被改变
• 随机性决定一个 Task 要多 Trial，看通过率不看单次
• 评结果不评路径（安全合规与数据真实性节点除外）；对照组是证明 skill 价值的唯一方式
• 三层指标搭桥：业务目标层 / Agent 能力层 / 模型能力层
• 客观保下限、主观提上限；主观标准靠人人一致（独裁者+背靠背）与人机一致对齐，方法是指标下钻 + Rubric 二元化
• 数据飞轮五环节：采集 → 清洗 → 评测 → 质检 → 分析归因；Bad Case 价值更高
• 中间过程不可观测是根本约束——把思考拆成工具调用，让推理可观测、可断言

---

来源

• 宋张丹《AI 产品评测：建的过程就是理解的过程》（微信公众号）
• Anthropic《Demystifying evals for AI agents》+ Skill Creator 2.0
• 美团图灵团队《Agent 评测漫谈》