一份实用维护计划，用来让 AI Agent 评测数据集在上线、模型变更、prompt 变更和工作流漂移后仍然有用。
为什么维护很重要
评测数据集不是一次性归档材料，更像生产依赖。AI Agent 一接触真实用户，工作流就会开始漂移：客户换一种提问顺序，客服团队重命名政策，产品团队增加字段，工程团队调整 prompt、工具、路由或检索配置。上线时有效的数据集，几周后就可能误导团队。最危险的不是明显坏掉的数据集，而是看起来干净、还能通过测试，却已经无法反映生产问题的数据集。维护计划的作用，是让数据集持续连接真实失败、产品变更、风险决策和用户真正要完成的任务。
先明确负责人
每个严肃的评测数据集都需要负责人。这不意味着一个人写所有用例，而是有人负责保证数据集持续有用。负责人需要知道新工作流何时上线、prompt 何时变化、模型何时升级、客服升级是否暴露了缺失场景，以及客户是否报告了现有评测没有覆盖的问题。没有负责人，维护就会变成模糊的共同责任，最后通常没有人真正负责。
使用变更日志
数据集应该记录为什么增加、修改或删除用例。某个用例来自客户事故，就标清楚；某个用例因为产品不再支持该流程而移除，也要记录。变更日志能防止团队把每个失败都当作噪音，也能帮助新人理解这个 Agent 的历史：它在哪里失败过，业务不能接受什么，以及哪些取舍是有意接受的。
区分稳定门槛和观察用例
不是所有用例都有同一个目的。有些应该是稳定发布门槛，例如权限边界、prompt injection、高风险动作、必须拒绝的情况。另一些属于观察列表，因为预期行为还在演进。把两类用例混在一起，会让团队要么过度反应，要么因为噪音太多而忽视整个评测。
从生产反馈喂养数据集
最好的维护来源是生产证据：客服工单、失败工具调用、人工覆盖、客户投诉、搜索查询、放弃会话和事故复盘。当生产环境教会团队一个昂贵教训，就把可复现模式转成测试。测试不必复刻事故每个细节，但要抓住关键模式。
按工作流检查覆盖，而不是按 prompt
工程师容易按 prompt 或模型调用组织评测，因为这些最容易看到。但客户体验的是工作流，不是 prompt。更好的维护评审应该问： onboarding、退款、账号更新、知识库回答、客服分流、报告生成和工具审批这些工作流是否被覆盖？
保留旧失败
团队经常修掉一个失败，庆祝一下，然后忘记把它留成回归用例。这就是同样问题六周后换个模型或 prompt 又回来的原因。任何高影响失败都应该成为持久 fixture，除非对应工作流已经移除。旧失败不是负担，而是组织记忆。
谨慎淘汰用例
数据集也需要清理。产品变化、政策重写、工具移除或客户群变化时，旧用例可能失效。但删除不能随意。移除前要问风险是否以另一种形式仍然存在。如果存在，就更新用例；如果不存在，就记录淘汰原因。
设置复盘节奏
早期 AI Agent 通常每周或每两周复盘一次即可。复盘要短而具体：新增生产失败、新产品变化、新增或修改用例、当前通过/失败状态、噪音用例和上线阻塞项。会议不是讨论 AI 质量哲学，而是回答运营问题：什么变了、什么坏了、哪里覆盖不足、下一次发布能不能走。
让非工程团队也能使用
只存在代码里的评测数据集也有价值，但往往无法支持产品、客服和管理层决策。保留一份人能读懂的摘要：覆盖工作流、已知缺口、最近新增失败、高风险门槛和当前上线建议。这样更容易解释为什么推迟发布，或为什么窄范围上线更安全。
如何使用这份资源
把这篇文章当作工作评审辅助，而不是法律认证、正式渗透测试或安全保证。真正有用的下一步，是把每个部分转成可复查的证据：trace、策略、测试样例、负责人、阈值和上线决策。
相关 IBBS 资源
可复制的分享文案
AI Agent 评测数据集维护计划：一份实用维护计划，用来让 AI Agent 评测数据集在上线、模型变更、prompt 变更和工作流漂移后仍然有用。 阅读链接：https://ibbs.ai/zh/2026/07/08/ai-agent-evaluation-dataset-maintenance-plan-cn/
如果需要更完整的评审，可以先做 AI Agent 就绪度自评，或查看 样例审计报告。