Agent 评测集别照抄,5 类来源可选

本篇是系列第 2 篇。上一篇确定了评 Agent 要评轨迹和端到端，本篇解决「拿什么评」，也就是任务集从哪来。

照搬公开基准是最省事的错误做法

第一版 Agent 评测集，大多数团队的做法是下载一个公开基准，跑一遍，截图发群。这步很省事，也很容易给出错误的安全感。

三个问题：

• 公开基准的任务分布和你家业务不一样。它在代码仓库、网页浏览、桌面操作上很强，但你的客服退款流程、报销审批、库存查询，它一条都没有。
• 公开基准的分数依赖 scaffold。同样的任务，换一套 prompt 和工具栈，分数能差两位数。你跑出来的分，反映的是"你的外壳 + 它的任务"，不能外推。
• 基准本身会腐化。2026 年已有研究指出，多个主流 Agent 基准存在可被 reward hacking 的空间，问题包括评测环境把答案泄漏到环境变量、评分用例本身有错、只报单次运行掩盖随机性。

所以任务集得自己建。这篇讲怎么建，5 类来源怎么挑，以及每条任务必须写清的三件事。

来源比较与选型

任务从哪来，决定了集子能覆盖什么、漏掉什么。5 类来源对比：

表里一条主线索：真实性越高的来源越依赖你自己的业务数据，覆盖长尾越高的来源越依赖人为定向。没有一行能同时满足这两条，所以真实做法是组合，不是单选。

阶段怎么选

任务集的核心不在条数，在每条任务是否可复现、可判定。 一条任务如果每次跑的初始状态不同、或者验收标准要人来判断，它产生的分数就没有可比性。

一、每条任务必须写清三件事

这是本篇最该记住的部分。一条 Agent 任务不是一句"帮我退款"，它由三块组成：

1. 初始状态：环境长什么样。用户是谁、订单什么状态、知识库哪篇文章、可用工具清单。没有初始状态，两次运行根本不可比。

2. 目标：用户要什么。要具体到可判定，比如"把这笔 89 元的订单按原支付方式退款并告知到账时间"，而不是"处理这个退款问题"。

3. 验收标准（success criteria）：怎么算成。最可靠的是可程序化判定的断言，比如数据库里订单状态变成已退款、最终消息包含退款金额与到账时间、工具调用序列包含退款接口。

一条任务的验收标准如果是"回答让人满意"，那它就是人工评测任务，不能进自动集。

一个踩过的坑：我们第一版有 30 条任务，验收标准全写自然语言描述，跑出来 82% 通过率。后来把标准改成可判定的断言，同一批任务只剩 61%。多出来的 21 个点全是"看着像做成了"，实际状态没改。验收标准松，分数会虚高，而且松在哪你不知道。

二、环境可复现：sandbox、mock 与快照

Agent 会调外部工具，工具会返回真实数据，真实数据会变。这是评测不稳定的头号来源。

三条对策：

• 能 mock 就 mock：把外部依赖（支付、物流、库存接口）换成固定的假实现，返回值写死或用 fixture 文件。工具行为稳定，评测才可复现。
• 不能 mock 就快照：必须连真实系统的部分，跑之前先把数据库、知识库、配置恢复到固定快照，跑完再还原。
• 随机性要钉死：模型温度、随机种子、工具返回的随机字段（时间戳、订单号）都要固定或替换成占位符。

业界基准也在做同样的事。比如 GAIA 提供 466 条真实任务并按难度分层，SWE-bench Verified 请 93 名工程师对抽样出的 1699 条逐条复核，剔掉了 68.3%（说明含糊、测试不公平、harness 有问题），只留 500 条人工校验过的。连公开基准都要靠"剔除坏任务"来保证可信度，自建集子更没有理由跳过这一步。

三、任务分层：别让平均分骗你

把不同难度的任务混在一起算平均分，会同时掩盖两类问题：简单任务的高分掩盖困难任务的崩塌，困难任务的低分掩盖简单任务的退化。

建议按三层分（可沿用公开基准的思路，比如按工具步数分）：

• L1 单工具：一步调用就能完成，看工具选择和参数正确性。
• L2 多工具链：需要串 2 到 5 次调用，看规划能力和中间结果的处理。
• L3 长程：5 步以上或需要错误恢复，看上下文保持和放弃策略。

报告必须分三层给分，不要只报总平均。一个版本 L1 从 95% 掉到 80%，是发布事故；L3 从 40% 掉到 35%，可能是噪声。混在一起你只看到"平均分掉了 5 个点"，两边都判断不了。

四、5 类来源怎么组合：一个可落地的配比

不建议只用一类。按阶段配：

• 起步期：人工设计 70% + 生产采样 30%。先把流程跑通，同时开始积累真实样本。
• 成长期：生产采样 50% + 人工设计 20% + 合成 30%。合成专门补生产里难采到的边界。
• 成熟期：生产采样 40% + 合成 30% + 红队 20% + 人工 10%。红队集独立跑，不进主集算分。

两个必须守的规则：

• 留出集要隔离
  拿来做评测的任务，不能拿去调 prompt 和工具描述。一旦调过，分数就没意义了。留出集只在发布前跑一次。
• 每条任务要有唯一 ID 和版本号：改了任务内容就升版本，历史分数的对比才有意义。

配比之外还有两条决定集子寿命的规则。

第一条，比例由风险决定，不按频率决定。高频主链路保证日常水位，但高风险样本一旦出问题，代价远大于一百条常规问题，所以边界样本和安全样本在回归集里的权重必须高于它们在真实流量里的占比，不能靠线上捕获了多少来决定建多少。

第二条，集子要持续保鲜。prompt 迭代、工具返回结构变化、业务目标调整，都会让旧样本失效：输入不再真实，结论自然不再可信。所以要按版本管理集子，定期剔除失效样本并重跑基线。07 篇讲的基准腐化，根子就在这里。

五、三个坑，以及怎么对抗

坑一，验收标准写太松。 现象是分数虚高，上线就露馅。对抗：每条任务的验收标准必须含至少一条可程序化判定的断言；纯语义判断的任务单独标出来，走人工或裁判，不计入自动集。

坑二，环境不稳定导致 flaky。 现象是同一版本两次跑分差 10 个点以上。对抗：先跑一遍环境自测，同一版本连跑 3 次，分差超过阈值就判定为环境不稳定，先修环境再谈评测（后续讲如何用方差识别）。

坑三，任务泄漏进 prompt。 现象是分数很好但一换说法就崩。对抗：每条任务准备 2 到 3 种等价表述（术语不同、顺序不同、加礼貌语），跑分时全部覆盖，取最低分而不是平均分。

一句话收尾

Agent评测集的保质期取决于它离真实有多近，以及它有多可复现。你现在那批任务，每条都能说清"初始状态是什么、怎么算做成了"吗？

英文术语释义

• success criteria（验收标准）：判定任务是否达成的规则，优先用可程序化断言。
• golden trajectory（参考轨迹）：人工标注的标准完成路径，用于比对（详见 03 篇）。
• holdout set（留出集）：只在最终验收时使用的隔离数据集，不参与调优。
• flaky：同一版本重复运行结果不一致的现象。
• reward hacking：Agent 找到拿高分却没真解决问题的捷径。