Agent 评测体系学习笔记：是什么、为什么、怎么做#

1.1 Agent 评测与 LLM 评测的本质区别#

传统 LLM 评测聚焦单轮生成质量：给定输入，看输出好不好，本质是评”一张试卷”。而 Agent 是具备自主规划、工具调用、环境交互能力的闭环系统，它的行为是一个多步骤的执行过程，评测必须覆盖四个面：

一句话概括：Agent 评测是对”数字员工”的端到端绩效考核，而不是对”答题者”的打分。这也解释了为什么不能直接把 LLM 评测那套（困惑度、单轮准确率）搬过来用。

1.2 评测体系的基本组成要素#

一套自动化评测系统，无论用什么框架实现，都由这几个概念组成：

• 任务（Task）：具有明确输入与成功标准的测试项。一个任务 = 输入 + 通过/失败判定标准。
• 试验（Trial）：任务的一次执行。Agent 行为有随机性，同一任务要跑多次才能得到稳定结论。
• 评分器（Scorer）：依据预设标准，对执行结果或行为轨迹量化打分的判定工具，是整个体系的核心。
• 评估框架 / 评估套件：统筹任务执行与评分的工程骨架；聚焦某类能力的多任务集合则构成评估套件。

其中评分器按实现方式分三类，各有明确的适用边界：

通用的组合策略：能用确定性评分器的场景尽量用确定性，开放式任务再用 LLM 评分器补位，人工评审用于校准前两者，而不是反过来。

1.3 分层评测架构：把”测不准”拆解成”哪一层不准”#

Agent 出问题时，根因可能在自己，也可能在底层组件。不做分层，就只会得到”整体不行”的模糊结论。通用做法是把评测拆成三层：

第 3 层存在的意义是避免把基础设施缺陷误判为本体能力问题——检索没召回导致答错，和 Agent 自己推理错，改法完全不同。

再往上看，从质量工程的视角，一套完整的生产级评测体系还应该在”能力评测”之外再加两层：安全验证（红队测试，主动找漏洞而不是等被发现）和演进闭环（用数据驱动迭代而不是靠直觉）。于是完整的质量体系 = 能力评测 + 安全验证 + 演进闭环，三者缺一就会对应下文的三大痛点。

1.4 五大评测维度#

具体评什么，可以归纳为五个维度，每个维度都有可量化的指标：

1. 任务规划与推理能力：任务拆解准确率、模糊需求追问率（该问不问是重大隐患）、推理链完整度、异常恢复率（出错后能否自救）。
2. 工具使用与执行能力：这是 Agent 区别于 LLM 的核心能力。工具选择准确率、参数填充正确率、调用步数效率（步数不是越多越好）、无效调用占比。
3. 多轮交互与记忆能力：短期记忆召回率、长期记忆复用率、跨轮上下文一致性、交互自然度（人工评分）。
4. 知识应用与生成质量（带 RAG / 知识库的 Agent）：上下文精准度、知识忠实度（幻觉率的反面）、答案相关性、多来源信息整合质量。
5. 安全、鲁棒性与成本效率：Prompt 注入绕过率、敏感信息泄露率、危险操作执行率（均应趋近 0）；异常环境下的存活率；响应时延；单任务成本与 Token 利用率。

注意一个方法论细节：成本和时延是一等公民指标，不是附加项。一个全对但每单烧几块钱、等一分钟的 Agent 在生产上等于不可用。

2.1 三大痛点#

没有系统化评测的团队，通常会陷入三个相互叠加的坑：

• 评测失真：指标与业务价值脱节。刷公开榜单分数很高，真实业务场景一塌糊涂；或者只测”理想化问法”，用户稍微换个说法就崩。
• 安全盲区：防御停留在已知攻击模式。没被攻击过 ≠ 安全，只是没被测过。
• 演进停滞：改进依赖直觉而非数据。改一版、上线、看用户骂不骂，循环往复，故障越改越糟。

对应的工程后果也很直接：有行业统计称，大部分 Agent 项目因为缺乏系统化评测，在用户验收测试阶段反复返工，平均交付延期数月。“上线即盲盒”不是段子，是常态。

2.2 反面模式：没有评测时的三种工作状态#

• 忽视基准：上线前没做过严格评测，凭几个 Demo 场景就判断”差不多了”。
• 自我感觉良好：改完 Prompt 自己看着顺眼就合入，没有回归手段。
• 盲目调试：一次改动可能影响数百种场景，但没有自动化测试，只能改哪儿测哪儿，按下葫芦浮起瓢。

2.3 评测体系的真正价值#

反过来说，评测体系带来的价值远不止”打分”：

1. 信任的来源：对 Agent 的信任来自对能力的精准度量。能说出”核心评测集准确率从 50% 提到 70%、一次通过率从 42% 到 68%、单轮成本降 23%“，和能说出”感觉变好了”，是两种完全不同的工程成熟度。
2. 迭代的加速器：有了评测，每次改动都能在几分钟内知道对几百个场景的净影响，敢于高频迭代；没有评测，每次改动都是赌博。
3. 团队的对齐语言：产品、工程、算法对”什么算好”的分歧，可以落到一组共享的评测任务和指标上讨论，而不是各说各话。
4. 质量门禁：版本准入、上线前回归、线上退化检测，都需要评测体系作为底座。

一句话：评测不是上线前的一次性考试，而是 Agent 全生命周期的仪表盘。

3.0 先立设计原则#

动手之前，四条原则决定整个体系的成色：

1. 结果与过程并重：要区分”蒙对了结果”和”正确地执行”。只看结果会奖励侥幸，只看过程会奖励表演。过程数据（轨迹）同时是归因诊断的关键。
2. 场景真实性优先：用真实业务任务替代理想化静态题目，防止评测集被”刷分”——Agent 对评测集过拟合、真实场景失灵。
3. 分层递进：从输出到轨迹到组件逐层拆解，才能精准定位根因（对应 1.3 的三层架构）。
4. 成本与效率纳入：Token、工具费用、时延是生产级核心指标，写进门禁。

3.1 第一步：构建评测数据集（用例库）#

数据集是评测体系的地基，通用构建流程五步：

1. 收集：从真实来源大规模收集候选任务（业务历史问题、用户真实查询日志、线上失败案例）。
2. 过滤：用 LLM 辅助筛选，剔除不符合目标任务定义、无法判定成败的条目。这一步可以用便宜的大模型批量做。
3. 分类：按一套意图/主题体系给任务归类（自建或借用成熟的分类法），保证覆盖面可视化。
4. 压缩采样：按真实用户需求的分布比例，把候选集压缩到一个小而精的基准集（几十到一二百个任务），关键约束是采样后的分布要和真实世界一致，不能全挑难题也不能全挑简单题。
5. 人工质检：专家逐条验证质量、清晰度、复杂度，把好最后一道关。

每个任务必须满足三个硬性要求：答案可复现、专家判断一致、有清晰的通过/失败标准。模糊的题目（“写一篇好的报告”）必须先翻译成可判定的标准，才能进库。

另外两条工程纪律：

• 用例库要覆盖常规、边界、异常三类场景，异常用例（恶意输入、残缺数据、中途变更目标）往往比常规用例更能暴露问题。
• 数据集必须版本化、可追溯：哪个版本的 Agent 在哪个版本的数据集上跑出什么分数，要能对上账，否则历史数据全部作废。

3.2 第二步：搭建评分器#

评分器设计的通用要点：

• 以环境的真实状态为准，而不是以 Agent 的自我报告为准。判断任务是否完成，去看数据库里有没有那条记录、文件有没有真的生成，而不是看 Agent 回答”我已经完成了”。这条同时天然具备防作弊能力。
• 只评结果，不限制路径：不要规定 Agent 必须走哪几步——限制路径会把评测变成脚本回放；评终态和关键中间产物即可。
• 多环节任务设部分得分：四级判定（完全/部分/错误/未完成）比二元通过率更能体现能力连续性，也能让迭代效果在指标上可见。
• 开放式任务用评分细则（Rubric）+ 加权：先用 LLM 把”好”拆成若干独立维度（如全面性、深度、指令遵循、可读性），各维度按重要性赋权，裁判模型逐维度打分后加权汇总。权重可以按任务类型动态生成，而不是全局一套。这是 LLM-as-a-Judge 从”拍脑袋打分”进化到”按细则评审”的关键。
• 可验证性优先于主观性：凡是能原子化验证的陈述（如”报告里的每个引用是否真实支撑了对应论断”），尽量拆出来用确定性方法核验，主观评分只留给无法客观判定的部分。
• 校验评分器本身：通过人工阅读执行轨迹，区分”Agent 真失败”和”评分器误判了有效解”。评分器有 bug 时，所有结论都是错的，这一步不能省。

3.3 第三步：选择评测实施方式#

四种方式按”离真实场景的距离”排序，各有分工：

落地时按分层流程组合使用：日常自动化回归（沙箱）→ 重大版本人工抽检 → 上线前灰度验证。三者是流水线关系，不是三选一。

3.4 第四步：安全评测（红队测试）#

安全不是评测的可选模块，而是独立的一层：

• 用 LLM-as-attacker 做自动化红队：让一个模型扮演攻击者，自动化、规模化地生成注入、越权、诱导类攻击样本，替代昂贵的人工渗透。
• 红队要分层、常态化：覆盖提示注入、敏感信息泄露、危险操作执行等类别；不是上线前跑一次，而是和普通回归一样进日常流程——每次改 Prompt、换模型、加工具，攻击面都会变化。
• 核心安全指标趋近于零：注入绕过率、敏感信息泄露率、危险操作执行率，目标不是”低于某个比例”，而是 0。

3.5 第五步：闭环与持续演进#

评测体系最大的浪费是建完只用一次。要让它转起来：

1. 缺陷归因体系：每类失败按根因归类——规划错误、工具调用错误、知识缺失、幻觉、系统异常。归因决定改进方向，否则修 bug 全靠碰。
2. 监控评测饱和度：100% 通过的评测项已经失去区分度，要定期淘汰或升级难度，防止指标”通货膨胀”。
3. 用例库持续更新：把线上真实失败案例不断回流进库，这是最有价值的增量用例来源。
4. 让贴近用户的人贡献用例：产品、客户成功、销售掌握的真实痛点，比算法工程师的想象更接近真实分布，以评测驱动开发。
5. 线上反馈去噪、可行动：线上信号（点赞点踩、会话放弃率）噪声很大，必须清洗并转化为具体的评测任务，才能进闭环。
6. 能力退化检测实时化：上线后持续跑轻量探针用例，模型供应商的隐性变更、依赖接口的变化都可能造成无声退化。
7. 质量门禁自动化、不可绕过：门禁挂进 CI/CD，指标不达标就 block 发布，留后门的门禁等于没有门禁。

3.6 落地节奏：小样本、尽早启动#

最容易被忽视也最重要的一条：不要等体系完美了再开始。通用建议是从真实失败案例和高频场景中提取 20～50 个核心任务，立刻搭起最小评测回路。延后启动会大幅增加后续建立评测与迭代的难度——因为缺乏基线，所有后续改动都失去了参照系。

配套的演进路径：先让小评测集跑起来 → 打磨评分器的可靠性（读轨迹校验）→ 扩充数据集与维度 → 引入红队与线上闭环。每一步都产生即时价值。

自建成本高的话，可以先借助现成框架：Harbor、Promptfoo、Braintrust、LangSmith、Langfuse 等开源/商用评测框架，都提供任务编排、评分器、轨迹记录与指标看板的基础设施。