大厂 Evals 经验系列 · EDD 专题
一个 AI 助手的答案越来越完整，系统却越来越难验收。它开始调用工具、分派任务、恢复上下文。用户看到的仍是一段回复，团队需要检查的决策已经增加。
我读 OpenAI 的评测指南时，更关心这个问题：架构每增加一种决策，验收需要补什么证据。下面用一条假设的会议行动项处理链路展开，未运行实验，也不引用官方示例为真实效果。
先说明时效边界。访问于 2026 年 10 月 11 日的官方指南写明：Evals 平台将在 10 月 31 日对现有用户变为只读，计划于 11 月 30 日关闭。本文借鉴方法，不提供该平台的操作教程。
五步流程里，需要先作的是业务决定
官方把评测流程概括为：明确目标、收集样本、定义指标、运行比较、持续评测。原文“设计评测流程”
以下是我对这五步的产品解释。
假设助手从会议记录提取行动项。目标写成“总结准确”太宽。一个更可核对的目标是：已作出的决定与待讨论建议能被区分；没有明确负责人时保留待确认；不把猜测写成承诺。
这会改变样本的选择。记录中既要有明确的“李明负责”，也要有“谁方便看一下”、中途撤销、同名参与者等情况。这些是为解释方法设计的假设样本，实际团队应核对自己会议里的语言和业务规则。
指标也要跟着目标走。如果最担心的是给人错误派活，负责人错误不能靠摘要写得流畅补回来。我建议把这项单独记录，并让业务负责人先确认什么算明确分配。否则产品团队和评分人员可能各用一套标准。
运行比较时，保留同一批输入和同一套判断，再看新旧输出如何变化。若本轮同时替换模型和评分规则，“分数提高”就有多种解释。可以做这种复合修改，但报告应说明无法单独归因，避免拿它宣称某一句提示词奏效。
持续评测的对象也不必只限于提示词。假如身份映射表、工具权限或会议转写方式变化，同一个输入可能产生不同后果。按我的建议，变更清单应该覆盖影响业务结果的依赖，并由负责人决定哪些变化需要重新运行对应样本。
沿着决策位置安排检查
OpenAI 按四种架构讨论评测：单轮交互看指令遵循和输出正确性；工作流可检查各步骤；单 Agent 增加工具选择与参数检查；多 Agent 增加交接检查。原文“识别评测位置”
对前面的假设助手，我会这样安排验收。表中的检查是我的示例设计。
| 系统形态 | 这时产生的决策 | 我会查看的证据 |
|---|---|---|
| 单轮提取 | 哪句话属于行动项 | 原句与提取结果能否对应；建议是否被误记为决定 |
| 固定工作流 | 识别人名后，如何连接人员记录 | 中间字段、映射结果和最终负责人是否一致 |
| 单 Agent 可调用工具 | 此时应查询、追问还是创建任务 | 实际选用的工具、参数及任务落库结果 |
| 多 Agent 分工 | 由谁接手，交接哪些上下文 | 转交原因、交接内容、接收方动作及最终结果 |
单轮提取即使通过，也不能证明后面的创建任务动作正确。反过来，最终任务创建成功，也不能说明负责人的来源可信。一次端到端检查给出业务结果，各节点的检查帮助解释失败发生在哪里。
我建议先画出实际处理路径，再标出每个由模型作决定的位置。固定程序规定的流程，与模型自由决定下一步，应该在图上有所区别。检查位置由实际自由度决定，不能仅从产品叫“助手”还是“Agent”推断。
例如人员查找失败后，固定流程直接返回待确认；另一种实现允许模型自行选择其他候选人。它们界面相似，风险和验收题却不同。后一种实现需要专门检查模型在信息不足时如何处理，而不只是查询工具能否工作。
多 Agent 是否值得，先把交接成本算进问题
指南有一句明确建议：
“The decision to use a multi-agent architecture should be driven by your evals.”
译：是否采用多 Agent 架构，应由评测驱动。原文“多 Agent 架构”
我的理解是，拆分之前需要说明现有系统到底在哪种任务上受阻。工具太多导致选错，专业规则混在一起导致冲突，或者上下文太长导致遗漏，分别需要不同的证据。
假设团队把会议提取、人员查询和任务创建交给三个 Agent。人员查询返回“有两个同名员工”，下一位接手者必须知道这个不确定性。如果交接只留下一个名字，创建者可能把未决事项当成确定数据。
这时，仅分别测试三个 Agent 的回答质量，会漏掉信息在交接中丢失的问题。我会加入整条链路的样本，检查待确认标记是否保留，是否向用户追问，以及在未解决前是否停止创建。这里的停止条件是我为这个假设业务设定的要求。
比较单 Agent 与多 Agent 时，还应记录完成任务所需的交互、耗时和人工介入。拆分后的局部得分更高，可能仍然伴随更多追问或转交。是否值得采用，要回到业务目标，不能从组件数推导质量。
也应允许评测支持维持较简单的架构。若主要失败来自不清楚的业务规则，把同一套含糊规则复制给更多 Agent，未必解决问题。先澄清什么情况下可以派活，可能比增加分工更直接。
持续评测需要维护一份变更后的解释
我建议把每次评测报告写成对一个变更的解释，而不只是一张曲线。报告至少说明版本、样本用途、具体错误类型、尚未覆盖的情形，以及负责人允许承担的剩余问题。
线上反馈进入题集前，还要核实失败。假设用户说“负责人错了”，可能是原始记录含糊，也可能是人员目录过期，或用户后来调整了责任。三种情况对应不同修复方向；都归入“模型幻觉”会让后续优化失焦。
样本增加时，历史总分也可能随题集难度变化。我会保留一组固定参照，同时单独报告新增问题的表现。这样可以区分“系统退步”与“开始看到过去没测到的问题”。两者都值得处理，但不能用同一个结论解释。
自动评分也需要可追问的依据。对于“是否明确指派”的争议样本，先让业务人员标明支持或否定分配的原句，再讨论评分规则。工具成功码、最终文本和真实任务状态应能对应，避免只检查其中一个就宣布完成。
对这条假设链路，下一次评审我会先看三个输出：待确认事项有没有被保留；写入的负责人是否有依据；发生转交时未决信息是否到达下一位接手者。模型升级、架构拆分和提示词修改，都应能回答这些具体问题。
OpenAI 的方法值得借鉴，采用哪种实现则需要自己的结果支持。业务任务变了，或系统新增了决策，评测就应说明这次新增了哪些检查，以及现有证据仍然无法覆盖什么。
系列相关阅读
本专题阅读顺序：完整理解 EDD → Google 的提示词实验 → OpenAI 的评测位置 → 微软的需求断言 → MLflow 的回归任务 → AWS 的协作验收 → 美团的双环评测。
评测基础可回读再读A社博文：怎样建立可信的 Agent 评测；判断评分可靠性，可继续阅读谁来给 AI 裁判打分与Agent 分数涨了，能力真的变强了吗。