Agent 评测数据集设计：从真实任务切片，而不是收集漂亮 Demo

很多 Agent 项目在上线前都有一组“看起来不错”的测试问题：帮我查订单、总结文档、创建工单。它们往往由开发者在系统最顺的时候写下，因此只能证明模型会做理想任务，无法证明系统能处理真实用户的模糊表达、缺失权限、脏数据和工具故障。评测数据集的价值不在于题目数量，而在于它是否覆盖真实决策成本。

从生产工作流切片

先列出用户真正要完成的工作流，而不是列出模型能力。以客服 Agent 为例，工作流可能是“核对订单状态后解释延迟”“识别退款资格并生成草稿”“把无法解决的问题升级给人工”。每条工作流再拆成输入、所需工具、关键约束、预期状态变化和不可接受结果。

抽样时保留困难样本：短句、错别字、同义表达、相互矛盾的上下文、过期文档、权限不足和跨租户资源 ID。真实历史请求可以提供分布，但必须先脱敏、去除密钥和个人信息，并得到适当的数据使用授权。不要把原始用户对话直接复制到测试仓库。

传统问答评测常有一条标准答案，Agent 更适合用可验证的结果标签。例如一个任务的标注可以包含：是否选择了正确工具、是否带了正确参数、是否拒绝越权请求、是否在失败后停止重试、是否给用户解释了下一步。这样即使模型生成的自然语言不同，也能判断业务行为是否正确。

为每条样本记录风险等级。读取公开文档和创建外部付款的失败成本完全不同，不能让它们在一个平均分里互相抵消。高风险样本应有更严格的通过条件，并在版本升级时优先回归。

一个成熟数据集通常至少有四组切片：正常成功、输入歧义、权限或策略拒绝、下游失败后的恢复。只测成功路径会让工具调用准确率看起来很高，却遗漏最昂贵的错误。比如导出数据失败时，正确行为可能是提示缺少 scope，而不是尝试其他工具、编造结果或连续重试。

对多步骤任务，标注中间检查点。不要只看最终文字是否流畅，要检查 Agent 是否先查到正确实体、是否在写操作前得到确认、是否使用了最新的工具结果。中间轨迹能帮助工程师定位是检索、规划、工具 schema 还是模型推理出了问题。

给每条样本一个稳定 ID、创建来源、所属工作流、风险等级和最后验证日期。每次新增工具、改权限策略或换模型时，记录数据集版本与评测版本。删除样本也应有原因，例如业务流程下线、原始数据不再可用或样本与新策略冲突。

数据集不能只由模型团队维护。支持、运维、安全和产品人员最清楚哪些失败真正影响用户，应定期贡献“本周最不应该再次发生的事故”。把这些事故转成脱敏回归样本，评测集才会随着产品成长，而不是停留在 Demo 阶段。

开始时不必追求统计学上的完美分布，但要避免全部样本来自最常见的低风险路径。可以按工作流价值与风险分层抽样：一部分覆盖高频成功任务，一部分专门覆盖高损失失败，一部分保留最近上线功能和最近事故。每个批次都记录采样时间窗口，防止团队在产品改版后仍用过时输入评估新系统。

同一任务还应保留多个表达版本。用户可能说“帮我看看订单”，也可能提供订单号、截图摘要或一段混乱的上下文。将这些变体归到同一个任务族，可以测出系统是否只记住了测试措辞。任务族中至少保留一条最小信息样本和一条冲突信息样本，用来验证 Agent 是否会主动澄清而不是强行猜测。

评估器也要分层。能通过数据库状态、工具轨迹或 schema 校验判断的结果优先自动化；涉及解释质量、风险沟通和多条合理路径的样本，再交给人工抽样或经过校准的 LLM judge。把评估器本身的版本和置信度写入结果，避免把不稳定的判断误当成模型回归。

一个可启动的最小集不必很大，但每个工作流都要有成功、澄清、拒绝和依赖故障四种样本。先让这些样本在 CI 中稳定运行，再逐周从线上反馈扩充。能稳定维护的 80 条高价值样本，通常比无人负责的 800 条通用问题更能防止生产回归。

发布前随机抽查新样本的来源和标注，确认题目没有泄露答案、没有重复使用敏感用户数据，并且 reviewer 能独立理解通过条件。数据集质量本身需要审核，不能因为它只用于测试就放弃治理。