大模型AI-Agent 评测

部分内容可能来自网络或者由AI生成。
如有雷同，纯属巧合，仅供学习参考之用。

Agent 评测全景：从方法论到工程落地

一份系统梳理 Agent 评测的技术文档：为什么评、评什么、怎么评、如何工程化落地，以及业界前沿与经典 Benchmark。

摘要

大模型让"搭一个 Agent"的门槛降到最低，但一个残酷的现实是：90% 的 Agent 开发时间花在评测和调优上，而不是初始搭建上。Agent 与传统软件最大的不同在于三道门槛——非确定性（同样输入不一定同样输出）、黑盒化（内部决策不透明）、错误级联放大（前一步小错会被后续放大）。这决定了"跑几条 case 感觉还行"远远不够，必须把不稳定的智能行为持续收敛成可发布的工程质量。

本文的核心观点可以浓缩为几句话：

评测不是上线前的抽查，而是嵌入研发全流程的持续实践（CE/CD）；

评测要分层，能用脚本精确算的绝不用模型去"估"，需要语义判断的才交给 LLM，高风险的再交给人；

评测对象要从"只看最终答案"扩展到"看整条执行轨迹"；

评测体系最终沉淀下来的核心资产是评测数据集（定义评什么）和评测 Skill/Rubric（定义怎么评），而平台只是执行引擎。

一、为什么 Agent 评测是真正的难题

Harrison Chase（LangChain CEO）反复强调：Agent 评测是整个 AI 应用领域最大的未解决问题之一。吴恩达则更直接：判断一个团队做 Agent 项目进展快慢，不看用了什么新技术，而看效果评估与错误分析的能力。

没有评测体系时，团队通常会陷入三种被动：

一次跑通不代表稳定可用；

每次改模型、改 Prompt、改工具参数都可能悄悄改坏原本好用的场景；

多步链路里前面一个小偏差会在后面被放大成错误结论。

更隐蔽的是假阳性——最终答案看起来对，但执行路径已经偏离或带风险，这类问题在生产里迟早暴露。

一套成熟的 Agent 评测体系至少要回答三类问题：

Agent 评测 vs 传统软件测试

一个绕不开的理论：验证者定律（Verifier's Law）

Jason Wei（OpenAI/Meta）在 2025 年提出的"验证者定律"给出了理解评测困境的底层框架：训练 AI 解决某个任务的难易程度，和这个任务的可验证程度成正比。所有可解且易验证的任务，最终都会被 AI 攻克。

其中的关键是验证不对称性：数独解题要 20 分钟、验证只要 2 秒（高度不对称，AI 进步飞快）；两个 900 位数相加，计算和验证差不多费劲（近乎对称）；事实核查一篇夹带大量引用的文章，验证比写作更耗时（反向不对称，AI 进展缓慢）。这解释了为什么 SWE-bench 能成为黄金标准——代码世界完美符合"客观真相、快速验证、可规模化、低噪声、连续奖励"五条标准；也解释了为什么 DeepResearch、医疗等领域评测极其昂贵。

同时要警惕 Goodhart 定律："当一个指标变成目标，它就不再是好指标。" MMLU 三年从天堑变入门考试、SWE-bench 一年分数翻倍，都是 benchmark 被 RLVR（可验证奖励强化学习）快速攻克、逐渐无法区分"真学会"和"学会考试"的例证。

二、评测什么：粒度、质量属性与 Agent 类型

2.1 两种粒度：端到端 vs 中间过程

端到端评测（E2E）是黑盒评测，关注从用户输入到最终输出的整体表现，用于验证业务需求、评估用户体验、建立质量基线，是必选项。

中间过程评测是白盒评测，深入 Agent 内部的规划、执行、记忆、工具调用等模块，需要访问执行日志和中间状态，用于深度调试、性能优化、模块质量评估，是可选项。

二者关系是：端到端发现问题，中间过程定位到具体模块；中间过程的改进最终体现在端到端结果提升上。

2.2 五大质量属性

2.3 先分清 Agent 类型，再定指标

类型不分，评测结果基本不可用。不同类型的 Agent 评测重点和参考 Benchmark 不同：

2.4 对话型 Agent 的特殊性

客服、导购、售后等对话型 Agent 不能只看单轮答案，必须把"整段会话是否解决问题"作为主评判对象。它至少有五个特殊难点：上下文依赖（单轮 OK、整段像失忆）、目标动态变化（用户中途改需求）、业务流程约束（要按 SOP/合规话术推进）、情绪与体验（客诉时不能机械回答）、人机协同（该转人工时要转，并带上问题摘要）。

正确做法是同时看 Turn（单轮）、Session（整段）、Trace（轨迹）、Outcome（最终结果） 四个层次，而不是简单平均每轮分数。

三、指标体系设计

指标的作用是把业务目标和专家经验拆成可观察、可打分、可追踪的检查项。建议分五大类，并按优先级用于不同场景：P0 用于上线门禁（不达标不能发），P1 用于版本比较和工程优化，P2 用于体验改善和长期观察。

设计三原则：

可量化（每个指标有明确评分标准，避免"感觉好不好"）、

可复现（相同输入不同执行得到一致结果）、

可迭代（指标随业务演进）。

评分需归一化到 [0,1]，例如分制用Score=(实际得分-1)/(N-1)、比例制直接取比例值、阈值制达标记 1.0 超标按梯度折算。

3.1 一致性度量：Pass@k vs Pass^k

对任务执行型和生产级对话型 Agent，要特别重视"多次运行的一致性"，同一任务重复跑 N 次，观察两类结果：

• Pass@k（k 次至少成功一次）：衡量能力上限——Agent 是否具备完成该任务的可能性。

• Pass^k（k 次全部成功）：衡量稳定可靠性——生产系统（支付、退款、合规、医疗）更关心这个。用户不会接受"多试几次总有一次成功"。

举例：一个模型 Pass@10 是 95% 但 Pass^10 只有 60%，意味着它有 40% 概率在连续 10 次查询中至少犯一次错——对安全敏感应用不可接受。

3.2 版本对比要做统计检验

在版本对比场景，不能把随机波动误判为能力变化。报告中建议同时给出：关键指标的置信区间、与基线版本的显著性判断、最小可感知变化阈值（提前定义"至少提升多少才值得发布"）。门禁不只看"差了多少"，还要看"这个差异是否超过统计噪声"。

四、评分器（Grader/Scorer）：三层评估体系

不管评测哪个场景，都遵循同一套分层方法论。核心原则一句话：脚本产出事实，LLM 基于事实判断。 能写成代码的确定性指标绝不让 LLM 去"估算"。

┌─────────────────────────────────────────────────────────┐ │ 第一层 · 确定性计算（规则/脚本 Scorer） 覆盖 60-70% │ │ JSON Schema 校验、工具参数合法性、状态变更、敏感词 │ │ → 快速、便宜、可复现、零争议 │ ├─────────────────────────────────────────────────────────┤ │ 第二层 · 语义判断（LLM-as-Judge，切片评估） │ │ 相关性、完整性、情绪承接、策略合理性、事实忠实性 │ │ → 基于第一层产出的"事实"做判断，而非凭空推理 │ ├─────────────────────────────────────────────────────────┤ │ 第三层 · 门禁（Gate，对抗性校验） │ │ 一致性门禁、置信度门禁、Schema 校验、边界校验 │ │ → 挑战 Agent 的输出，不通过就拦截/重试/标记低置信 │ ├─────────────────────────────────────────────────────────┤ │ 第四层 · 人工抽检（Human Scorer，校准锚点） │ │ 高风险、低置信、规则与 Judge 冲突、业务口径未固化的样本 │ │ → 黄金标准，反向校准 Judge 的 Prompt 和根因标签 │ └─────────────────────────────────────────────────────────┘

三类评分器对比：

4.1 LLM-as-Judge 的偏差与治理

LLM-as-Judge 并非银弹。已知问题包括：位置偏差（倾向选先出现的答案）、自我偏好（倾向给自己风格的答案高分）、长度偏差（更长的回答获得更高分）、校准困难（不同 Prompt 下评分分布差异大）。

一个能用的 LLM Judge 至少需要：

明确的评分标准（每档有可执行标准）、输出 reason（便于定位和 badcase 聚类）、few-shot 示例（含边界样本和判定 COT）、周期性校准。缓解策略包括多轮投票、成对比较（A vs B 且交换位置消除位置偏差）、校准锚点、分层评测、引入多个不同 LLM 对抗打分。

校准指标：定期抽取 50-100 个判定案例交由领域专家盲审，计算 Judge 与人类的一致性（Cohen's Kappa）。Landis & Koch (1977) 的经典分级可作行动依据：

业界共识（Hamel Husain）："Start with assertions, graduate to LLM-as-Judge only when you must." 先从最简单的、基于断言的评测开始，只有当简单方法不够用时才引入 LLM-as-Judge。同时建议先做 error analysis 再搭基础设施——每次重大改动后花 30 分钟人肉看 20-50 条输出，往往比纠结技术栈选型更有价值。

4.2 过程型 / 风险型检查：抓假阳性

对"最终回复看起来对、但过程有问题"的假阳性 case，追加四类检查：

评分结果不应只输出 pass/fail，还应输出问题分类、问题现象、置信度、判定依据，这样后续根因定位才能基于"现象入口"收敛候选模块。

五、评测数据集建设

评测集不是线上数据的随机抽样，而是围绕高风险路径、关键逻辑和失败模式设计出来的质量资产。纯随机采样有明显幸存者偏差——正常流程占多数，真正让 Agent 出错的边缘场景占比很低，报告"看起来不错"但关键问题被漏掉。

数据集四类来源：

落地建议：先做 50-200 条高质量 golden set（基线集，用于版本对比和发布门禁），覆盖核心业务路径和高风险边界；成熟后再扩展到分类采样集、长尾集、对抗集、线上回流集。用例数量可按 Agent 等级分档：

所有用例必须完成打标，覆盖正常场景、边界场景和异常场景。历史 Bad Case 必须沉淀为评测用例。

六、Badcase 分析与根因定位

根因定位的核心是把错例稳定追到责任模块和可修复原因。端到端失败通常只是表象，真正原因可能来自意图识别、上下文记忆、检索召回、工具选择、参数构造、业务规则理解、模型推理、回复生成、Guardrail 拦截或外部系统异常。

RCA 通用链路（"先收集证据、再收敛范围、最后定责落盘"）：

① 证据汇总 → ② 范围收敛 → ③ 分模块诊断 → ④ 责任判定 → ⑤ 结构化落盘 按 traceId 问题现象×模块 逐模块读 规则+模块结论 写入任务记录 汇总全链路日志 映射表缩圈 input/output +根因知识库定责 支持看板查询

第二步"范围收敛"是关键——不要对全部模块无差别分析，而是维护"问题现象 × 功能模块"映射表：

根因标签体系（要稳定、可统计、能指向明确 owner）：Intent 识别错误、Context 记忆错误、Retrieval 召回不足、Tool 选择错误、Tool 参数错误、Reasoning 错误、Policy/SOP 错误、Response 生成问题、System 异常。每类绑定解决角色（运营可配置 / 算法需优化 / 工程需修复 / 业务需定口径），并支持 badcase 聚类——同一根因、同一场景、同一工具的失败自动聚成问题簇，报告里产出"退款已发货场景中 Agent 23 次跳过订单状态校验，主要集中在 v1.8 Prompt"这样的可行动结论。

七、Agent-as-Judge：从"函数调用"到"Agent 执行"

当评测对象是自由文本或复杂多步骤行动序列时，纯 LLM-as-Judge 有四个结构性局限：

只能推理不能执行（无法主动取文件、跑脚本、补证据）、上下文是硬约束（多文件信息一个 Prompt 装不下）、多维度互相干扰（一次调用评多维，每个都马马虎虎）、确定性指标不该用推理来做（相似度、覆盖率有公式，让 LLM 估算是误用）。

Agent-as-Judge 把评测流程的编排权从平台硬编码的 workflow 交给 Skill 文件，让 Agent 在运行时自主执行。三个核心组件：

┌──────────────────────────────────────────────────────┐ │ Agent-as-Judge │ │ │ │ ┌────────────┐ ┌────────────┐ ┌─────────────┐ │ │ │ Sandbox │ │ Agent │ │ Skill │ │ │ │ 隔离执行环境 │◄─►│ 推理+行动内核│◄─►│ Markdown 评测│ │ │ │ Bash/Python│ │ 多步决策 │ │ 逻辑载体 │ │ │ │ 文件系统 │ │ 异常处理 │ │ 可 diff/回滚 │ │ │ │ 用完即销毁 │ │ │ │ 能力可插拔 │ │ │ └────────────┘ └─────┬──────┘ └─────────────┘ │ │ │ │ │ ┌───────────┴───────────┐ │ │ │ SubAgent 多任务并行 │ │ │ │ 代码评审 / 知识召回 / │ │ │ │ 确定性指标脚本 分头干活 │ │ │ └───────────────────────┘ │ └──────────────────────────────────────────────────────┘

SubAgent 并行的收益不只是省时间，更重要的是把判断隔离开——每个 SubAgent 只处理一个窄问题，上下文更干净、Prompt 更短、互相污染更少。复杂评测从"一个模型憋出一个总分"变成"一组评测工程师分头干活再开会对结果"。

Skill 模式相比硬编码 workflow 的宽容度优势：LLM-as-Judge 是一锤子买卖，错了就是错了；Agent-as-Judge 有试错空间——结果矛盾可以自查，门禁不通过可以换路径。评测系统最重要的两样核心资产随之明确：评测数据集（定义评什么，决定覆盖面上限）+ 评测 Skill（定义怎么评，是可 diff、可 code review、可 rollback 的 Markdown 文件，决定准确度和一致性）。

代价要认清：慢（沙箱冷启动 3-5 分钟，单条样本 10-20 分钟）、贵（沙箱资源 + 多次 LLM API）、Skill 工程是手艺活、Agent 行为有不确定性。什么时候用：需要"做点什么"（跑代码、查数据、对比文件）才能给结论 → Agent-as-Judge；"看一眼"就能判断（文本流畅度、语法、情感分类）→ LLM-as-Judge，又快又便宜。

八、工程落地：全链路过程数据采集（以 AgentScope 为例）

评测的前提是拿到 Agent 执行全链路的过程数据。AgentScope Java 框架基于 ReActAgent 范式，将"推理→行动→再推理"循环抽象为 ReasoningPipeline 和 ActingPipeline 两条管线，并在关键节点暴露 Hook 扩展点。核心设计原则是主链路零干扰：Hook 只读事件数据不修改 Prompt/工具/Memory，全局 try-catch 吞掉所有异常（评测挂掉不能阻断 chat），执行耗时相对 LLM 推理微乎其微。

Hook 接口与生命周期事件：

public interface Hook { /** 优先级，数值越小越先执行，默认 100 */ int priority(); /** 事件处理入口，返回 Mono<T> 支持响应式编排 */ <T extends HookEvent> Mono<T> onEvent(T event); } // 生命周期事件： // PreCallEvent —— 输入消息列表，记录开始时间、提取用户输入 // PostReasoningEvent—— 推理消息（Thinking/Text/ToolUse Block）、Token 用量 // PreActingEvent —— 即将执行的工具（工具名、参数、调用 ID），开启计时 // PostActingEvent —— 工具 + 执行结果，封装完整调用记录 // PostCallEvent —— 调用链路结束，组装评测数据并投递 // ErrorEvent —— 异常信息，标记后阻断上报

统一的评测数据模型（结构化封装，供 Judge Model 评判）：

@Data public class LLmAsJudgeSyncMessage { private Msg currentMessage; // 当前用户输入 private List<Msg> historyMessages; // 历史会话 private String sysPrompt; // 系统提示词 private List<Skill> skillCandidates; // 挂载技能集（评"意图/技能选择"合理性） private List<Tool> toolCandidates; // 挂载工具集 private String thoughts; // 思考过程（思维链） private String knowledge; // 知识库内容（评"忠实性/幻觉"） private List<ToolCallRecord> toolCalls; // 实际工具调用轨迹 private String output; // AI 最终回复 private Long firstTokenCostMs; // TTFT 首 Token 耗时 private Long totalCostMs; // 链路总耗时 private Long inputTokens, outputTokens, totalTokens; // Token 消耗 private String judgeScene; // 评测场景（技能组合等效替代） }

分场景采样控制成本：一次调用加载的技能 ID 组合按字典序|拼接作为"业务场景"（无技能加载则为 DEFAULT），每个场景独立配置采样率，通过配置中心动态调整、无需发布。这样既保证覆盖所有场景，又控制评测成本：

private static boolean shouldSample(String scene) { int rate = SystemSwitch.getEvalSamplingRateByScene(scene); if (rate <= 0) return false; if (rate >= 100) return true; return ThreadLocalRandom.current().nextInt(100) < rate; }

配套的六大评测维度（覆盖"理解→检索→执行→生成→安全→业务价值"完整链路）：认知理解（问题提取准确、意图/技能选择准确）、检索推理（知识准召率、是否幻觉）、工具执行（工具调用准确率、成功率、耗时）、生成质量（回复易读、指令遵从）、安全围栏（过度承诺检测、安全风险检测）、业务端到端（问题解决率、首字响应延迟）。

九、流量采集与回放：解决评测环境稳定性

Agent 评测有一个独特痛点：上下文依赖的底层数据会变化。Agent 执行工具调用时查询单据数据，而单据状态随业务流程不断变化（待发货→已发货→已签收），相同用例在不同时间执行会因数据状态不同产生不同结果，导致评测结果不可复现。

解法是流量录制 + Mock 回放：录制线上真实流量自动生成评测用例（大幅降低构造成本），把录制的方法调用输入输出作为 Mock 数据在评测时回放（确保数据状态一致、结果稳定可复现）。Mock 执行结果可视化为四种状态：绿色（成功且顺序正确）、黄色（成功但顺序不对）、红色（入参有误）、灰色（未执行），便于排查 Agent 执行逻辑。

十、经典 Benchmark 对照

SWE-bench 之所以成为黄金标准，正因为代码世界完美符合验证者定律的五条标准。其数据集结构清晰：

Input 是repo + base_commit + problem_statement，

Expected 是FAIL_TO_PASS + PASS_TO_PASS两组需通过的单测；

评估器逻辑极简（跑单测看红转绿），但为不同 Repo 构建可运行的隔离环境（不同语言、版本、依赖）成本极高——这也印证了"验证责任不会凭空消失，只会被推到另一层"。

十一、前沿趋势

Meta-Harness（自进化评测）：如果 Agent 可以自我改进，评测系统本身也应能自我进化。反馈循环为"Agent 执行 → 轨迹采集 → 评测打分 → 优化器分析 → Agent 更新 → 再评测"，核心模块包括 Eval Engine、Optimizer（DSPy/TextGrad）、Test Case Evolver、Trace Store、Env Sandbox。

SkillsBench（把 Skill 作为独立变量评测）：过去 benchmark 把"模型 + Harness + 提示词工具配置"当整体，只回答"系统做得好不好"，却不回答"Skill 本身是否真带来增益"。SkillsBench 显式拆出 No Skills / Curated Skills / Self-Generated Skills 三种条件，实验显示精选 Skill 把平均通过率从 33.9% 提升到 50.5%。关键新指标包括负迁移率（多少任务加 Skill 后反而变差）——并非所有 Skill 都正收益，边界模糊的 Skill 会把原本做对的任务带偏。

Rollout Cards（可复现性标准）：只汇报"成功率 80%"会掩盖大量真相——模型是否在文本伪装安全却乱调工具、失败重试是否烧爆算力、长序列搜索是否在做无用功。执行轨迹记录才是 Agent 研究可复现性的基本度量单位。

姚舜禹《AI 的下半场》：评测与现实世界存在两个根本差异——评测假设 iid 独立同分布（但真实任务是顺序解决、可积累熟悉度）、评测假设自动化无人介入（但真实 Agent 需与人持续交互）。下半场需要的不是"更难的考试"，而是"让 Agent 作为实习生入职，考察实际工作表现"。

十二、全链路闭环：从 Bug 到生产反馈

评测平台的终点不是报告，而是把线上失败持续转化为可复用的研发资产。一条 badcase 至少可以生产三类反馈：回归用例（防止同类问题再现）、Prompt/工具改进建议（修复当前行为）、业务规则/知识库修订（修正源头）。

反馈生产要有入库标准，不能把所有失败都无差别塞进回归集：失败可复现、期望行为明确、根因标签清楚、样本有代表性、已完成脱敏。同时做样本治理避免回归集无限膨胀：同簇样本保留代表例、P0/P1 长期保留、稳定多版本通过的低风险样本降级为抽样集。

发布阶段要把离线门禁和线上灰度联动，跟踪三类信号：离线质量信号（核心场景通过率、P0 风险数）、线上体验信号（转人工率、重复追问率、投诉率）、业务结果信号（任务完成率、工单闭环率）。如果离线提升但线上关键信号恶化，应触发回滚或降级。

评测优化建议要落到明确 owner、修复动作和回归验证，可分四个等级：L0 只报告 → L1 生成工单（带样本、Trace、owner、验收标准）→ L2 生成配置建议（可审阅的规则/知识/Prompt 变更）→ L3 自动修复候选 PR（仍需人审和回归）。

十三、接入 SOP（五阶段）

裁判规则选择速查：意图识别 → 简单裁判「等于」；结构化主答案 → 简单裁判「等于/部分包含」；自然语言主答案 → LLM 裁判「文本相似度」；关键信息提取 → 简单裁判「部分包含」；布尔判断 → 简单裁判「等于」。

十四、结语

Agent 的开发本质上是一场与不确定性博弈的过程，而评测是这场博弈中最关键、也最容易被低估的能力。几条务实共识值得反复强调：

探索阶段（0→1）用 vibes-based 快速试错足够，优化阶段（1→N）必须建立系统化评测，生产阶段需要全自动化流水线 + 在线监控；

能用脚本算的绝不用 LLM 估，能自动化的绝不长期依赖人工，人工只用于定标准、校准 Judge 和高风险终判；

评测不是项目交付物，而是长期资产——用例库、Trace 库、根因标签库、修复建议库、Judge 校准集、回归集，质量资产越厚，Agent 迭代越不靠个人经验和临时救火。

正如 Eugene Yan 所言："Evals aren't static artifacts or quick fixes; they're practices that apply the scientific method." 好的评测体系，是对可验证性边界的诚实承认，也是让每一次 Agent 迭代都"看得见质量变化"的底层能力。

参考来源

• Anthropic, Demystifying Evals for AI Agents / Building Effective Agents — anthropic.com/engineering

• Jason Wei, Asymmetry of Verification and Verifier's Law / Successful Language Model Evals — jasonwei.net/blog

• Hamel Husain, Your AI Product Needs Evals / LLM Evals: Everything You Need to Know — hamel.dev

• Eugene Yan, An LLM-as-Judge Won't Save The Product / Task-Specific LLM Evals — eugeneyan.com

• Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena, NeurIPS 2023

• Jimenez et al., SWE-bench: Can Language Models Resolve Real-World GitHub Issues?, ICLR 2024

• Bean et al., Measuring what Matters: Construct Validity in LLM Benchmarks, NeurIPS 2025

• 姚舜禹, The Second Half — ysymyth.github.io/The-Second-Half

• MASEval / SkillsBench / Rollout Cards — arXiv 2026