【智能体测评-07】自建测评集方法论：别再拿20条case自欺欺人了

20 条 case 的幻觉

几乎每一个做 Agent 的团队都经历过这个阶段：

产品发布前，工程师凑了 20 条“典型任务”，跑了一遍，18 条成功，成功率 90%，大家信心满满上线。上线一周后客诉涌来，用户反馈的问题五花八门，没有一个在那 20 条 case 里出现过。回去重跑那 20 条，还是 90%。

问题出在哪？出在那 20 条 case 从根上就不能作为测评集。它们的问题不是“太少”——虽然 20 条确实太少——而是它们的来源、分布、标注方式都决定了它们无法反映 Agent 在真实环境中的表现。

常见的“伪测评集”有这几种：

演示型测评集

工程师自己编的 20 条任务，每条都精心设计成“我们的 Agent 能做的事”。这就像老师出题学生考，题目全是学生昨天刚做过的原题。90% 的成功率说明不了任何问题——它测的不是 Agent 的能力，是出题人的想象力边界。

随机型测评集

从生产日志里随机抽 100 条用户请求。比演示型好一点，但有两个致命问题：一是简单任务占绝大多数（“帮我查个天气”、“今天几号”），成功率天然高，掩盖了复杂任务上的失败；二是缺少 ground truth——你不知道用户当时到底满不满意，也不知道“正确答案”应该是什么。

补丁型测评集

每次线上出一个 bug，就把那个失败 case 加进测评集。三个月后攒了 50 条，全是历史 bug 的集合。这个集合能保证“已知 bug 不复发”，但完全不能预测“未知 bug 会不会出现”。它是一个回归集，不是测评集。

Leaderboard 型测评集

直接拿公开 benchmark 的测试集来测自己的 Agent。第 4 篇我们详细讲过，公开 benchmark 有数据污染、过拟合、任务分布和你的场景不匹配等问题。在 GAIA 上跑 60 分不代表你的客服 Agent 能处理好退款投诉。

这四种“伪测评集”的共同问题是：它们看起来在测评，实际上没有产生有效的决策信号。 你根据它们的分数做版本判断，和抛硬币差不多。

好测评集的五个标准

在讲怎么建之前，先定义什么样的测评集是“好”的。我们用五个标准来衡量：

1. 代表性（Representativeness）

测评集中的任务分布应该尽可能接近 Agent 在生产环境中实际面对的任务分布——不是平均分布，而是按真实频率和重要性加权的分布。

如果你的 Coding Agent 线上 60% 的请求是修 bug、25% 是加小功能、10% 是重构、5% 是写文档，那测评集也应该大致是这个比例。修 100 道算法题测出的能力，和实际修 bug 的能力几乎不相关。

2. 区分度（Discrimination）

测评集应该能把能力不同的 Agent 区分开。如果所有 Agent 在你的测评集上都得 90 分以上，这个测评集就失去了测评功能——它太简单了。如果所有 Agent 都得 20 分以下，也一样——它太难了，或者评分方式有问题。

健康的测评集应该让不同水平的 Agent 拉开差距，分数有合理的方差。一个经验值：平均成功率在 40%-70% 之间的任务占比应该超过一半。太难和太简单的任务都可以保留（用于边界测试），但不应占主流。

3. 多样性（Diversity）

任务类型、难度、工具组合、失败模式都应该有足够的覆盖面。一个只包含“搜索+总结”任务的测评集，无法测出 Agent 在“多步推理+工具编排+错误恢复”上的能力。

多样性不是简单的数量堆砌——100 条高度相似的任务不如 30 条精心设计的、覆盖不同模式的任务有价值。

4. 抗泄漏性（Leak Resistance）

测评集的内容不应该出现在 Agent 的训练数据、few-shot 示例或公开可检索的语料中。一旦泄漏，Agent 可能靠记忆而非能力通过测试，分数就失真了。

这在 2026 年尤其困难——互联网上的内容越来越可能被下一轮模型训练爬取。好的测评集需要有持续更新机制，定期淘汰可能被污染的任务、补充新任务。

5. 可判定性（Determinism）

对于“正确答案”有共识的任务，不同评分者（人或模型）应该能给出一致的判定。如果一条任务连人类标注者都对“什么算成功”争论不休，那它就不适合作为自动化测评的一部分——它可能是一个好的探索性任务，但不应计入门禁分数。

三层测评集架构

我们在总纲中提过测评集的三层管理，这里展开讲每一层怎么构建、怎么用。

graph TB
    G["黄金集 Golden Set<br/>50-200 条 · 人工精标 · CI 门禁"]
    R["回归集 Regression Set<br/>500-2000 条 · 自动+人工 · 版本对比"]
    E["探索集 Exploration Set<br/>持续增长 · 开放标注 · 发现新问题"]

    G -->|每轮必跑 · 卡门槛| D["发布决策"]
    R -->|每轮必跑 · 看趋势| D
    E -->|定期跑 · 做分析| I["洞察与改进"]

    E -.->|验证通过后晋升| R
    R -.->|沉淀为核心 case| G
    E -.->|发现线上新失败| P["生产回采"]

    style G fill:#e8f5e9,stroke:#2e7d32
    style R fill:#e3f2fd,stroke:#1565c0
    style E fill:#fff3e0,stroke:#e65100

第一层：黄金集（Golden Set）

定位：最核心、最可信的测评子集，作为版本发布的硬门禁。

规模：50-200 条，宁可少而精。

来源：

• 从生产流量中筛选高频且高价值的任务类型（P0 场景）
• 团队集体评审，确保每条任务都代表一个真实的用户需求
• 由最懂业务的人编写或审核，附带详细的评分标准（rubric）

特征：

• 每条任务都有明确的、经过人工确认的 ground truth 或验收标准
• 覆盖所有 P0 能力维度，但不过度追求面面俱到
• 难度分布合理：约 20% 简单（保底）、60% 中等（区分主力）、20% 困难（探上限）
• 严格保密，不进公开代码仓库、不出现在 few-shot 中

用法：

• 每次代码/Prompt/模型变更必须全量跑
• 成功率低于阈值（如比上一版本低 3% 以上）直接阻断发布
• 每季度审查一次，淘汰过时任务、补充新场景

陷阱：黄金集最大的风险是“过拟合”。工程师反复看到同一批 case，有意无意地把 prompt 调到刚好能过这些 case。对策是：黄金集的具体内容对开发工程师保密（由 QA 或独立团队维护），并且每季度替换 10-20% 的题目。

第二层：回归集（Regression Set）

定位：覆盖面更广的测评库，用于版本对比和趋势监控，不卡硬门禁。

规模：500-2000 条，随时间持续增长。

来源：

• 历史上发现的所有 bug（每条修复的 bug 对应一条回归 case）
• 黄金集的超集——黄金集的题目全部包含在回归集中
• 从探索集中晋升上来的、经过验证的有效任务
• 按真实流量分布做加权抽样

特征：

• 评分可以部分自动化（规则 + LLM-as-Judge），人工只抽检
• 按能力维度、场景类型、难度打标签，支持切片分析
• 允许“已知失败”存在，但要标注为 known issue，不计入回归判断
• 可以包含一些“边缘 case”（异常输入、极端组合）

用法：

• 每个版本全量跑，产出多维度报告（总体成功率、各维度成功率、成本变化、失败聚类）
• 和上一版本做配对对比（同任务不同版本）
• 失败自动聚类，新增失败类型需要人工 triage

陷阱：回归集容易“只增不减”，越滚越大，跑到后来要几个小时、成本几百刀。对策是定期去重和裁剪——高度相似的 case 只保留代表性的几条，过时场景（API 已下线、业务已变更）及时清理。

第三层：探索集（Exploration Set）

定位：开放式的任务池，用于发现新问题、探索 Agent 能力边界，不用于版本评判。

规模：无上限，持续增长。

来源：

• 对抗性构造：团队头脑风暴“怎么让 Agent 出丑”
• 生产环境随机抽样（不只是失败 case，也包括成功 case）
• 新功能、新工具上线后的专项测试
• 红队测试（安全、越狱、prompt injection）
• 外部众包或用户反馈

特征：

• 不需要预先有 ground truth——可以跑完之后再标注
• 鼓励“野生”任务：模糊的、多意图的、信息不全的、矛盾的
• 评分方式灵活，可以纯人工审阅，也可以开放式讨论
• 标签体系可以自由扩展

用法：

• 定期跑（每周/每双周），重点不是分数而是发现新模式
• 跑完后做人工审阅，把有价值的发现记录下来
• 验证有效的任务晋升到回归集，核心任务晋升到黄金集
• 发现的系统性问题反馈给开发团队

陷阱：探索集容易变成“垃圾桶”——什么都往里扔，但没人分析。对策是固定节奏（比如每周五下午花一小时集体审阅探索集结果），并且要求每条进入探索集的任务都有明确的“想验证什么”的假设。

任务从哪来：五种来源与各自的坑

三层架构的骨架有了，血肉——具体的任务——从哪来？

来源一：生产日志挖掘（最推荐）

真实用户的请求是最好的任务来源，但挖掘时要注意：

• 分层抽样，不要纯随机：简单任务在日志中占绝大多数，纯随机会导致测评集被“查天气”类任务淹没。按任务类型、复杂度、用户满意度分层后抽样。
• 附带上下文：一条真实任务不只是一句用户输入，还包括用户的历史对话、当前环境状态、可用工具列表。脱离上下文的任务是失真的。
• 脱敏是硬要求：PII、商业机密、内部数据必须脱敏或替换为合成数据。不要为了做测评把用户隐私泄露给标注团队或第三方 API。
• 结果标注难：真实任务往往没有标准答案。需要结合用户后续行为（是否继续追问、是否采纳结果、是否投诉）和人工判断来标注质量。

来源二：失败回采

线上失败的 case 是最有价值的测评素材，因为它们代表了 Agent 当前能力的边界。

• 自动捕获：异常中断、用户显式负反馈（点踩/投诉）、重复追问（通常意味着不满意）、任务超时
• 每条失败 case 入库时标注：失败类型（参考第 2 篇的失败分类学）、根因、严重度
• 修复后转化为回归 case，确保同类失败不复发

注意：失败回采容易让测评集偏向“已知问题”。要和其他来源平衡，避免测评集变成“历史 bug 博物馆”。

来源三：对抗性构造

主动去找 Agent 的弱点，而不是等它在生产中暴露。

方法：

• 边界值测试：空输入、超长输入、特殊字符、矛盾指令
• 组合爆炸：把多个简单需求组合成复杂任务（“帮我查下深圳明天的天气，如果下雨就改约后天的会议室，同时通知参会人”）
• 干扰项注入：在任务描述中加入无关信息、误导信息、过时信息
• 角色切换：模拟不同类型的用户（新手、专家、不耐烦的、话多的、故意诱导的）
• 安全测试：prompt injection、数据泄露尝试、越权操作

对抗性构造的任务往往偏难，适合放在探索集。验证了其真实价值后再晋升。

来源四：领域专家编写

找最懂业务场景的人（产品经理、客服主管、资深工程师）编写“如果用户这样问，Agent 必须能处理”的任务清单。

• 优点：质量高、场景真实、验收标准明确
• 缺点：数量有限、专家时间贵、可能有盲区（专家倾向于出“合理”的题，而真实用户的提问方式往往不合理）
• 建议：专家编写的任务主要进黄金集，占黄金集的 50% 以上

来源五：合成生成

用 LLM 批量生成任务。这是 2025 年以来越来越流行的做法，但坑也最多。

• 正确用法：给定少量真实任务作为种子，让 LLM 做变体生成——改变表述方式、调整参数、替换实体、增减约束条件。可以快速扩充数量。
• 错误用法：让 LLM 凭空“想”出 1000 条任务。LLM 倾向于生成“像 AI 会出的题”——格式工整、逻辑清晰、缺乏真实用户的模糊和混乱。这些题对测评真实能力几乎没有信号。
• 必须人工审核：合成任务 100% 需要人工过一遍，剔除不合理的、重复的、泄露的，补充验收标准。

标签体系：让测评集可切片

一个无法切片分析的测评集，价值大打折扣。你不只想知道“成功率 75%”，你想知道：

• “多步工具调用类任务的成功率是多少？”
• “涉及退款的场景比上个月改善了吗？”
• “新版本在 P0 任务上有没有退化？”

这需要一套完善的标签体系。建议至少从四个维度打标签：

能力维度

对应第 1 篇提出的六维模型：感知、规划、工具、记忆、执行、反思。一条任务可能涉及多个维度，标注主要考察的 1-2 个。

场景维度

按业务场景分类：Coding、客服、检索、写作、数据分析、日程管理……场景分类要和 Agent 的实际业务对应，不要照搬别人的。

难度维度

建议用三级：

• L1 简单：单步或两步可完成，信息充分，有明确答案
• L2 中等：需要 3-6 步，涉及工具编排，有一定歧义但可解决
• L3 困难：7 步以上，需要错误恢复或多策略切换，答案开放或评判标准复杂

难度判定应该基于“最优轨迹需要几步”，而不是“当前 Agent 用了几步”——否则 Agent 变笨了难度反而降低。

优先级维度

• P0：核心场景，失败不可接受（黄金集主体）
• P1：重要场景，失败影响体验但可容忍
• P2：边缘场景，覆盖即可

有了这些标签，你就能做切片：能力=工具 AND 场景=客服 AND 难度=L2 AND 优先级=P0，看这个切片上的成功率变化，而不是看一个笼统的总分。

Ground Truth：怎么定义“正确”

任务有了，最关键也最容易被敷衍的一步是：定义什么算成功。

不同类型的任务需要不同的 ground truth 形式：

精确匹配型

任务有唯一正确答案，程序可以自动判定。

“查一下 2026 年 8 月 25 日深圳的最高气温是多少度？”

答案是一个确定的数字，工具返回的天气数据可验证。这类任务判定成本最低、一致性最高，但在 Agent 测评中占比通常不大。

状态校验型

任务要求 Agent 在环境中完成某个操作，最终状态可以被程序化检查。

“帮我在日历上创建明天下午 3 点的会议，邀请张三和李四。”

判定方式：检查日历中是否出现了符合条件的事件（时间正确、参与者正确）。SWE-bench 用的就是这种方式——跑测试用例看是否通过。WebArena 也是——检查目标网站的最终状态。

约束满足型

任务没有唯一答案，但输出必须满足一组明确的约束条件。

“帮我写一封给客户的道歉邮件，说明订单延迟的原因，语气要诚恳，不能承诺具体赔偿金额，字数 200-300。”

约束条件可以部分自动校验（字数、禁词、必须包含的关键信息点），部分需要 LLM 或人工判定（语气是否诚恳）。这是现实中最常见的类型。

质量评分型

任务的输出质量是多维度的、连续的，不能简单判对错。

“帮我调研一下 2026 年向量数据库的主要选项，给我一个选型建议。”

需要用 rubric 从信息覆盖度、推理质量、引用准确性、结论合理性等多个维度打分（参考第 5 篇 LLM-as-Judge 的方法）。

轨迹约束型

不只要求结果正确，还要求过程满足某些约束（第 6 篇轨迹测评的范畴）。

“最多调用 3 次搜索工具完成这个任务。”

判定方式：检查轨迹中搜索调用次数是否 ≤ 3，同时结果是否正确。

实践建议：每条任务在入库时就明确 ground truth 类型和判定方式，不要等跑完了才想“怎么判”。能用精确匹配和状态校验的，绝不用质量评分——自动化判定的一致性和成本远优于主观评分。

防止污染和过拟合

测评集失效的最主要原因不是题目不好，而是被污染或过拟合。

污染途径与对策

过拟合的信号

怎么判断你的 Agent 在“刷题”而不是真的变强？

• 黄金集分数持续上涨，但生产客诉率没有下降
• 在黄金集上分数很高，换一批新题分数骤降
• 改动 prompt 对黄金集分数影响巨大（改一个词涨 5%），但对随机抽样的新任务影响很小
• Agent 对黄金集中的特定措辞有异常精准的反应（像是记住了题）

出现这些信号时，该换题了。

测评集的维护节奏

测评集不是一次性工程，是持续维护的资产。建议的节奏：

最小启动方案

如果你现在什么测评集都没有，不要试图一步到位建一个 2000 条的完美集合。按这个顺序起步：

第一周：从生产日志中挑 20 条 P0 任务，人工写好 ground truth，作为最初的黄金集。目标是让 CI 能跑起来，哪怕覆盖很窄。

第二周：把过去三个月线上出过的 bug 各写一条回归 case，凑到 50-100 条回归集。目标是已知 bug 不复发。

第一个月：开始往探索集里扔任务——团队每个人每周贡献 5 条“想试试 Agent 能不能做”的任务，每周五跑一次集体审阅。

第三个月：黄金集扩展到 50-80 条，回归集 300-500 条，建立标签体系和自动化报告。

第六个月：黄金集 100+ 条，回归集 1000+ 条，有稳定的更新和晋升机制。这时候你已经有了一套真正能驱动质量提升的测评基础设施。

小结

自建测评集是 Agent 测评中最朴素也最被低估的一环。它不像 LLM-as-Judge 那样有技术新鲜感，也不像 benchmark 排行榜那样有话题性，但它决定了你的整个测评体系是否建立在可信的地基上。

核心要点回顾：

• 20 条 case 不是测评集——演示型、随机型、补丁型、Leaderboard 型测评集都会产生虚假信号
• 好测评集的五个标准：代表性、区分度、多样性、抗泄漏性、可判定性
• 三层架构：黄金集（门禁）、回归集（对比）、探索集（发现），任务在层之间流动
• 五种任务来源：生产挖掘 > 失败回采 > 专家编写 > 对抗构造 > 合成生成（合成必须人工审核）
• 标签体系让你能切片分析，而不是只看一个总分
• Ground truth 类型决定了判定成本和可靠性，优先选可自动化判定的类型
• 持续维护比初始质量更重要——不维护的测评集三个月后必然失效

下一篇【智能体测评-08】动手搭一套 Agent 测评流水线，我们把前面所有的方法论串起来：用开源工具链从零搭建一条可以跑的测评流水线——任务分发、Agent 执行、结果评分、报告生成，给你一个可以直接 clone 的最小 repo 模板。