大厂 Evals 经验系列 · EDD 专题
收到一条 Agent 失败样本，团队可能立刻准备改提示词。但同一条样本也可能说明：评分规则把合理做法判错了，测试缺少必要上下文，或用户已经提出了旧测试没覆盖的新任务。
这几种问题需要不同的修改。美团的评测文章给出了一种组织方式：把改 Agent 和改评测体系作为两条迭代路径。本文沿着这个区分，讨论一次失败怎样分派、怎样积累为资产，以及离线通过后还剩什么问题。
先为失败做一次裁定
美团《Agent 评测白皮书》将案例挖掘与归因作为两条迭代路径的共同入口：既检查 Agent，也检查样本和评分标准。白皮书原文
下面使用一个本文设计的经营分析场景，不对应美团的实测项目。用户让 Agent 比较两家门店的经营情况，报告没有给出完整建议，评分器判为失败。
打开记录后发现，第二家门店只有部分日期的数据。Agent 明确指出日期不足，避免直接比较，并请求补充数据；评分器却要求每次都给出确定建议。这里应先修正什么叫合格。强迫系统补一段确定结论，可能让报告更像标准答案，却减少事实依据。
换一种记录：两家门店日期齐全，Agent 合并时把门店字段丢了，结果把两家的收入当成一家。此时评分器发现数字错误，确有系统问题，需要修复合并逻辑。再一种情况，测试环境只预置了一家门店，生产环境两家都有，则先修复测试条件。
这三种记录的外观都可以叫“报告失败”，处理方向却不同。我建议在修复任务之前增加一项裁定：问题出在哪项约定、哪份证据支持这个判断、还有什么未确认。证据不够时允许暂缓归因，避免把推测写成研发责任。
一次案例也可以触发两种修改。例如系统合并错误需要修复，而测试从未覆盖跨门店数据，也需要新增任务。这两条工作应互相关联，但各自有验收：系统修改要执行验证，新增任务要确认能够揭示原问题。
标准需要负责人，也需要被反例修正
美团较早的《Agent评测漫谈》强调人工标准对齐，并将模糊指标拆成可判断的细则。方法文章
我的理解是，评测负责人应负责维持同一套约定，但不能用身份消除合理争议。前面的经营报告，业务方可能希望“必须给建议”，数据负责人则要求“不能在数据缺失时作判断”。需要裁定的是输入不足时允许哪些行为，而不是哪个部门分数权重更大。
可以先定义可观察的条件：是否说明缺失范围；是否避免把部分日期当成完整周期；是否给出补数据的办法。然后再讨论建议是否有用。没有必要把所有审美和专业判断硬压成二分类；无法判断的部分应留下原因，供规则修订。
一个反例也要认真对待：Agent 列出大量数据缺口，却对现有数据能支持的结论一概不答。如果评分规则只奖励谨慎，它可能拿高分，却不能完成任何工作。我的建议是在约定中区分“当前不能支持的判断”和“已经能够支持的判断”，要求前者说明限制，后者正常交付。
这套细则是本文的设计建议。它适用于有明确数据依据的分析任务，不能直接搬到创意策划、谈判或其他允许多种优秀策略的任务中。
一条案例成为资产之后，仍会过期
美团把评测标准与样本看作可复用资产。评测资产章节 我想补上的是维护成本：资产要有人更新，也要允许退出当前验收范围。
为前面的门店任务，我会设计四个状态。刚发现时是线索，保存反馈和执行记录；完成核验后成为案例，写清数据与约定；重建输入、预期和环境后成为回归任务；业务条件改变后重新审核，继续使用、修订或归档。这是本文提出的管理办法，不是美团公布的固定流程。
线索不能直接进入门禁。用户投诉有价值，却可能遗漏关键信息；重复投诉也不代表新增了许多不同任务。先按根因与输入条件整理，才能判断是在反复遇到同一个错误，还是覆盖了新的边界。
进入回归后的任务要记录政策或口径依据。假设门店后来调整经营周期，旧任务要求按自然月比较，新业务按结算周期比较。旧任务无需删除，但它不再适合判断当前版本。否则系统越遵守新规则，越容易在旧评分中失败。
同样重要的是保留成功做法。对一个数据不足的请求，什么程度的澄清能够让用户继续工作？只收集错题会缺少这个参照。我会保存几种已确认的合理处理，并明确它们允许哪些差异，不把某一份报告措辞固定为唯一答案。
资产数量增加后，维护负责人应该能回答：哪些任务覆盖当前业务，哪些专门防止历史错误，哪些还无法稳定执行。任务过期或暂不可执行，需要显式标注，不能用悄悄跳过来维持漂亮的通过率。
离线回测与线上 AB 各自回答什么
白皮书把固定任务与环境用于版本回测，并将线上 AB 用于观察业务效果。离线与在线章节 AB 指让可比较的用户组使用不同版本，再比较结果。
对本文场景，离线可以检查新版是否合并正确、是否在数据不足时适当澄清。若两轮用的日期范围、权限、接口返回值不同，就难以解释结果差异。测试环境也不必复制生产全部细节，但影响目标行为的条件需要保留，替代部分要写明。
例如用一份固定数据快照比较合并逻辑，能回答算法在这份输入上的差别。它无法回答真实接口超时后，Agent 能否恢复。需要测试恢复行为时，应补对应环境故障任务，不能拿快照通过替代接口可靠性证据。
线上则可能出现另一个问题：报告事实准确，但用户找不到重点，仍要手动返工。离线的正确性分数没有直接表示这种工作成本。可以把待验证假设写成“新版报告减少人工整理”，再设计用户组和观察指标；不要先把它当作已兑现收益。
具体 AB 还要排除明显的混杂条件。若新版只给熟悉产品的用户，旧版给全部用户，观察到的差别可能来自用户构成。样本不足、流量分配不清或同期业务变化未记录时，只能保留观察结果，暂不归因为版本收益。
因此，离线合格可以支持进入下一阶段验证，线上改善可以补充业务证据。即使 AB 表现更好，也不能替代已明确要求的权限和数据检查；某个业务指标上升，可能同时伴随另一类用户的问题。
把修改记录带进下一轮复盘
这篇材料对产品管理的独立价值，在于让失败后的工作分派更准确。一条案例可以指向系统修改、评分修订、环境补齐，也可以暂时只保存证据，等待裁定。
下一轮复盘时，我会先取出案例的处理记录：改了什么，依据是什么，哪份任务完成了验证。若同时改了 Agent 和标准，还要让新旧系统在修订后的同一标准下重新比较，避免把放宽规则造成的涨分算成系统进步。
对前面的门店报告，复盘最终应留下两个可查结果：系统是否正确合并了数据，标准是否允许对缺失数据作有依据的澄清。两项都要分别核验，才能知道这次讨论具体修好了什么。
来源说明：MT01 为美团图灵Agent评测团队的体系文章，MT02 为履约技术团队的方法介绍。本文只提取少量框架线索，其余场景、资产状态和管理安排均为原创建议；这些建议没有实测收益保证。
系列相关阅读
本专题阅读顺序：完整理解 EDD → Google 的提示词实验 → OpenAI 的评测位置 → 微软的需求断言 → MLflow 的回归任务 → AWS 的协作验收 → 美团的双环评测。
评测基础可回读再读A社博文：怎样建立可信的 Agent 评测；判断评分可靠性，可继续阅读谁来给 AI 裁判打分与Agent 分数涨了，能力真的变强了吗。