AI Agent Evaluation
AI Agent Evaluation 是把“Agent 是否可靠”从主观感觉转化为可复现、可追踪、可比较、可回归的工程体系。它不仅评测模型，也评测模型外部的 Harness：工具、上下文、记忆、沙盒、权限、可观测性和业务验证器。
核心问题
传统软件测试回答的是：给定输入，代码分支是否按预期执行？
Agent 评测要回答的是：
- Agent 在真实用户表达、真实上下文和真实工具环境下，是否能完成目标？
- 失败时，问题来自模型、提示词、工具、记忆、环境、权限还是业务验证器？
- Prompt、模型、工具或上下文升级后，效果是变好还是变差？
- 系统是否能把线上 bad case 沉淀为长期回归资产？
从测试用例到 Eval 数据集
Agent 测试方法论 的关键区分：
| 项目 | 传统测试用例 | Agent Eval 数据集 |
|---|---|---|
| 起点 | 系统设计、代码分支 | 真实用户行为和线上翻车场景 |
| 覆盖对象 | 功能分支、边界条件 | 行为边界、上下文状态、工具链失败 |
| 期望输出 | 通常确定 | 可能多样，但要有可判断标准 |
| 价值来源 | 覆盖率 | 代表性、真实性、可回归性 |
一条好的 Eval 至少包含：
- 输入：用户原始请求、上下文、工具状态、必要环境快照。
- 期望行为：不是死板字符串，而是 Agent 应满足的业务约束。
- 评估标准：可操作、可判断，例如“工具返回空数据时，必须说明数据缺失，不得编造结论”。
评测系统六步法
来自 AI Evals 实践：
- 业务目标 → 评测维度：把“好不好”拆成可独立打分的维度。
- 打造黄金数据集：先用 10 个高频典型场景校准评分器，不必等几百条 case。
- 人评 + 机评：人工建立基准，LLM-as-Judge 承担规模化评分。
- 校准 AI 评分系统：让评分模型输出客观观察、维度分、理由，方便与人评对齐。
- 从黄金集到生产评测集：引入线上真实流量、bad case、边缘场景。
- Bad Case → 反推策略：把失败归因到数据、Prompt、工具、模型、产品逻辑或业务规则。
评分方式选择：
| 方式 | 适用场景 | 特点 |
|---|---|---|
| GSB | 新旧版本或模型 A/B 对比 | 判断成本低，只回答哪个更好 |
| MOS | 主观体验总分 | 简单但诊断粒度粗 |
| Likert | 多维诊断 | 适合定位问题和指导迭代 |
可复现 Agent 测试四步法
统一沙盒测试体系 强调：Agent 评测首先要锁定系统变量，否则分数会被提示词、记忆、工具、外部环境污染。
- 构建确定性沙盒：Docker 编排工具、数据库和外部 API；动态数据改为静态快照；固定随机种子。
- 统一 Agent 系统组件：推理接口、系统提示词、规划策略、工具协议、记忆格式全部版本化。
- 执行多维评估：结果、过程、效率三维同时评估，并对失败原因分类。
- 接入 CI/CD 长期守护：每次模型/Prompt/工具变更自动回归，基线偏离即告警。
EDD：Evaluation Driven Development
Litefuse 提出的 EDD（Evaluation Driven Development）可以理解为 Agent 时代对 TDD 的扩展。
TDD 关注代码逻辑能否通过测试；EDD 关注 Agent 的行为是否持续满足业务目标。
EDD 闭环：
Observe → Evaluate → Improve → Regression
观测 评估 优化 回归验证Agent Trace 应记录：
- 用户输入、系统提示词、上下文、检索结果
- 模型调用、工具调用、参数、返回值、错误和重试
- 中间状态、规划路径、最终输出
- Token 成本、延迟、模型版本、工具版本
- 评估分数、判分理由、bad case 标签
Benchmark 趋势：从答题到长程任务
SaaS-Bench：真实办公长流程
SaaS-Bench 将 23 个真实开源 SaaS 系统放入 Docker，构建 106 个跨应用长流程任务。它的核心启示：Agent 可以完成局部检查点，但很难端到端完成真实办公任务。
关键设计：
- 保留真实前后端逻辑、数据库状态和业务约束。
- 任务跨软件研发、财务业务、医疗管理、团队协作、农业供应链、独立媒体等领域。
- 区分 Resolved Score（全部检查点通过）和 Checkpoint Score（部分完成）。
Frontier-Eng Bench：无标准答案的工程闭环
Frontier-Eng Bench 关注“没有标准答案”的工程优化任务。它不看 Agent 能否一次答对，而看它能否长期提出方案、跑仿真、收反馈、调参数、持续逼近约束下的更优解。
这意味着下一代评测会更像真实研发：
- 长周期反馈闭环
- 多轮实验与自我修正
- 目标函数和约束下的持续优化
- 人设目标，Agent 执行实验循环
失败归因框架
Agent 失败不应只归因于“模型不够强”。建议至少按以下层级归因：
| 层级 | 典型问题 | 处理方式 |
|---|---|---|
| Model | 推理错误、幻觉、能力不足 | 换模型、降温、增加判别器 |
| Prompt | 目标模糊、约束缺失 | 改系统提示词、引入规范模板 |
| Context | 检索不准、上下文污染、记忆腐化 | RAG 评估、上下文压缩、记忆版本化 |
| Tool | Schema 不清、参数错误、工具失败 | 工具契约、参数校验、重试与降级 |
| Environment | 外部状态变化、网络/API 波动 | 沙盒、静态快照、mock 服务 |
| Workflow | 缺少规划/复核/回滚 | Planner/Executor/Reviewer 分工 |
| Governance | 权限过宽、不可审计 | 审批、审计、最小权限 |
| Business Validator | 验证标准缺失 | 检查点、规则验证器、人工复核 |
与 Harness Engineering 的关系
Agent Evaluation 是 Harness-Engineering 的 Verification + Observability 层，也是治理层的前置条件：没有 Trace 和 Eval，就无法知道 Agent 是否可靠；没有可复现沙盒，就无法判断优化是否真的有效。
因此，生产级 Agent 的基本公式可以写成：
Reliable Agent = Model + Harness + Eval Dataset + Observability + Governance下一步建设建议
- 从最近 20 条真实任务/线上失败中选出 10 条黄金 Eval。
- 为每条 Eval 写明确评估标准，而不是只写“答案要准确”。
- 把模型、Prompt、工具、记忆和环境版本号写入 Trace。
- 引入 LLM-as-Judge，但必须保留判分理由，并定期用人评校准。
- 将核心 Eval 接入 CI/CD；每次 Prompt、模型、工具升级必须回归。
- 每次线上事故修复后新增一条 Eval，形成“失败资产库”。
[2026-07-20] CursorBench 与 验证器层级
来源：Fable 5 × CursorBench / Kimi K3 与 Agent 三重悖论综述（2026-07-17/18）。
CursorBench：还原”混乱真实提示”的内部基准
CursorBench 是 Cursor 自建的内部基准，因公开基准分数与开发者真实接受度脱钩而生。设计哲学对本主题既有方法论是有力的补充：
- 刻意还原定义不明确的真实提示：如只粘贴一段堆栈跟踪 + 一个”修复”（模型须自行推断意图、找根因、验证修改）；或故意指向错误模块，测试模型是会质疑用户假设还是顺着走进死胡同。
- 正确答案只是门槛，真正评估”模型是否理解了被问的问题”——模型须完成”推断意图 → 识别根因 → 修复 → 验证 → 汇报”全链路。
- 对高分保持怀疑（“要么非常聪明，要么在作弊”），通过阅读追踪记录与实际推理过程核验；同时关注 token 效率。
- 已知结果：Claude Fable 5 最大努力模式 72.9%（创新高）。
- 方法论提醒：CursorBench 为单方内部基准、无第三方复现；与 Artificial Analysis 智能指数（Kimi K3 = 57）方法论不同，跨基准分数不可直接通约。
验证器层级（verifier tier）：评估器决定自我改进成败
来自 RSI 综述（调研 1250 篇 arXiv）的核心诊断工具，把本主题”LLM-as-Judge / 人评校准”提升为结构性规律：
- 自我改进的持久性与验证器层级强相关：低层级自评指标作反馈 → 退化循环（模型学会自我表扬而非自我改进）；高层级外部验证 → 持久改进。
- 无精确诚实的验证机制，任何优化循环都滑向奖励黑客（Reward Hacking）。
- 评估器悖论：评估器越强越易被”破解”，越弱改进方向越不可靠。
- 破局：NVIDIA Polar 用真实环境反馈（代码能否通过测试，不可伪造）；OpenAI confessions 用独立于任务目标的诚实通道。详见 AI Agent 自我改进。
对接：本页”失败归因框架”的 Business Validator 层、Anthropic”生成 vs 评估分离”、Claude Code Loops 的”评估模型检查停止条件 / judge 对抗性审查 / 第二 agent code review”，都是验证器层级思想在不同抽象层的落地。
[2026-08-07] 美团图灵 Agent 评测实践：从答案评测到行为评测
来源：Agent 评测漫谈（美团图灵 Agent 评测团队两年 BP 各业务线的内部博客公开版）。
评测四层与观测基石
- Agent 研发公式：观测 + 评测 = 持续迭代。Trace 系统源于”想看 Case 却发现没打日志”的朴素痛点；看不见的问题几乎不可能被稳定解决。
- 评测须覆盖四层：结果层（任务完成、输出可用）、过程层（规划合理、步骤稳定）、效率层（耗时/Token/工具调用次数）、风险层（越权/误操作/安全隐患）。两个”都做对了”的 Agent 工程价值可能完全不同（路径清晰可复现 vs 偶然命中不可复现）。
- 评测从”答案评测”走向”行为评测”：Response Evaluation + Trajectory（Trace）Evaluation 并行。
桥梁指标：不是堆指标，是搭桥
模型能力指标与业务结果指标之间有天然鸿沟，中间必须建桥梁指标（业务指标 → 系统指标 → Agent 任务指标；以 AI 搜索为例：DAU/留存/点击 → 召回率/点击率 → 意图识别/检索/结果整合可信度）。桥梁必须由真正懂业务流程的人共建，才能回答”为什么业务指标变差""模型能力提升为何没带来业务收益”。
人人一致、人机一致：主观评测对齐
- 人人一致：一位强有力的”独裁者”角色拉齐产品/运营/研发/QA 的评测标准，避免各自为政；评测员背靠背标注对齐。
- 人机一致：机评结果须与人评一致方可信，意义在规模化提效。
- 三步落地：模糊指标下钻为 Rubric（术语对齐 Arize AI）→ Rubric 尽可能二元化（是/否/未知）→ 用 unknown 占比反查定义，迭代至单条 Rubric 的人人/人机一致率达到可信阈值（如 85%/90%）。
- 自报成效：数字站长人机一致率 99%；Beam 经二元化改造从 62% 提升到 92%。
？ 一致率数字为美团内部自报，无第三方验证。
评测是实践科学：数据飞轮先于精妙指标
- 五环节链路：采集 → 清洗 → 评测 → 质检 → 分析/归因，与线上 AB、持续观测共同构成数据飞轮。
- 起步最佳实践：从高频核心场景定义少量关键指标，而非先设计复杂精妙的指标体系；评测体系靠 Good/Bad Case 喂养（Bad Case 更易暴露能力边界与系统短板，Good Case 定义”好”的范式）。履约数字站长业务一年内从 20 多个指标扩展到近 200 个。
- 垂域冷启动引入行业专家知识补足模型语料缺口；专家意见的分歧部分可转化为 Agent 的风格/策略分支，在不同 Benchmark 中独立评测。
长程 Agent 对评测的改造
- 借鉴 Anthropic 2026-01-09《Demystifying evals for AI Agents》的面向 Task 的评测：(prompt, expected_behavior, trace) 三元组取代短程时代的 (query, ground_truth, answer)。
- ChatAgent 评测问”说得好不好”，长程 Agent 评测问”事情做成没有，以及是怎么做成的”。
- 人评主导 → 机评主导：长程轨迹信息密度高使人成为卡点、Skill 数量激增使人工标注不可持续；人工退守高价值标准设计与 Rubric 对齐，AI 承担规模化初筛与回归验证——AI 评测放大的不是”机器打分”，而是核心评测员的判断标准。
- 评测基建七能力：全链路回放、Case 管理、执行沙箱（只读/可写/高风险分层隔离）、AI 评测引擎（Rubric 驱动、简单易接入）、报告与归因（定位到规划/工具/环境/Skill）、回归机制（版本升级自动回归历史 Case）、准入准出门禁（嵌入开发发布流程）。
对接：本节”四层评测”与本页”统一沙盒体系”的结果/过程/效率多维评估互为印证；数据飞轮与”评测系统六步法”的 Bad Case → 反推策略是同一闭环的不同表述；“人机一致”与 LLM-as-Judge 的偏差缓解手段互补（前者对齐上游标准，后者治理下游判官）。
[2026-08-10] 腾讯两基准的结论：场景化选模型阶段
来源：腾讯 Agent 评测 WorkBuddy-Bench 与 E-Bench（WorkBuddy Bench 260 题 + E-Bench 323 任务，2026-07 一周连发）。
- 无全能冠军：代码赛道 Claude Opus 4.8 领先、办公赛道 GPT-5.5 最高 86.05（一套环境）、安全赛道 GLM-5.2 双环境第一、E-Bench 总分 Kimi-K3 73.79% 居首——每个前沿模型都有自己的主场。
- 换执行环境排名互换：7 模型 × 2 环境 = 8 张成绩单；代码赛道 GPT-5.5 与 GLM-5.2 排名随环境互换——选模型不能只看分数，还要看用什么工具链跑它。
- 可靠性与成本成为一等指标：E-Bench 无模型 Pass³ 超 60%；同时统计单任务 API 成本（DeepSeek-V4-Pro 0.028 美元/47.7% vs Kimi-K3 0.634 美元/73.8%）。
- 方法论输出：逆向改写防背题 + 确定性程序打分（不用大模型裁判）+ “出题者全知、解题者半盲”信息差设计——一套可自证选型对错的公开方法。
⚠️ 矛盾 [2026-08-10] “模型分数”并非模型的固有属性，而是”模型 × 执行环境/工具链”的组合属性——与把 benchmark 分数当作模型绝对能力指标的常见用法冲突。
“单榜全能排名 → 场景 × 环境 × 可靠性 × 成本多维成绩单”的范式演变，见 Agent 评测范式演变；两个基准的完整档案见 Agent 评测基准。
[2026-08-10] 因果推断归因：评测的下一层
- 传统评测只看相关性（“用了新版 Prompt 成功率更高”），但混杂变量（新版恰好分到更简单的 Query）会把退化误判为改进；LLM / Runtime / Tools 的组件级归因属于 Pearl 因果阶梯的干预/反事实层。
- 三种按数据可得性分层的策略：① 有完整 Trace 的组件级归因（工具序列基线 → 参数质量+规划评估 → SHAP 贡献权重）；② 无中间数据的扰动式黑盒归因（贡献度 =（基线分 − 扰动后分）/ 基线分；实测 JSON 格式约束贡献 58.3% > Few-shot）；③ 控制混杂的因果推断 A/B（Temperature 0.7→0.3 表面 +18%，PSM 匹配后净效应仅 5%）。
- 辛普森悖论实例：V2 Prompt 整体 +5%，分层后简单 +8.9% / 中等 −4.0% / 困难 −10.8%——测试集结构掩盖复杂任务退化，须分层随机化。
- 与本页”失败归因框架”衔接：因果推断提供”归到哪个组件”的统计工具；与 古德哈特定律源页并置为”哲学层（别把指标当目标）+ 技术层（剥离混杂）”。
[2026-08-12] 两维分类法：评什么 × 怎么评
KDD 2025 综述 Evaluation and Benchmarking of LLM Agents 提供了可作为本页上位目录的两维 taxonomy：
- 评什么：行为（完成度、质量、成本/时延）、能力（工具、规划、记忆、多 Agent）、可靠性（稳定/鲁棒）、安全对齐（公平/解释、伤害/偏见、合规/隐私）。
- 怎么评：离线/在线交互、数据/Benchmark、代码或 Judge/HITL 指标、工具链与具体部署上下文。
企业场景还需单列 RBAC、动态长程交互、合规和多次运行可靠性。pass@k 回答“多试几次能否至少成功一次”，而生产承诺更接近 pass^k：是否能连续稳定成功。
[2026-08-12] 工具分类与协议审计
工具全景 区分三件常被混用的事：Evaluation 判断是否达标，Observability/Tracing 解释一次运行发生了什么，Monitoring 发现生产分布和异常怎样变化。工具采购应覆盖数据/Prompt/模型/代码版本谱系与持续回归，而不是只看一个 Judge 面板。
两期日报把“协议审计”提升为评测前置条件：
- 08-11 AutoML 案例说明测试集偷看、超时不强制与算力不公平足以把 59.4% 的胜率重跑成 34.3%。
- 08-12 SWE-Bench ProMax、UNSPECIFIC 等从题面重写、测试双向审计、可解 witness 和混合评分入手，先修基准再谈模型排名。
因此每份评测报告都应同时回答：测试集是否只用一次、预算是否外部强制、环境是否等价、任务是否可解、运行时是否泄漏、评分器是否校准。