大厂 Evals 经验系列 · EDD 专题
多 Agent 方案的验收常被拆成几场演示：资料助手找得到信息，排期助手能列出时间，通知助手能生成邀请。三个模块都表现不错，串起来却可能邀请错客户，或者只给出了建议，实际日程没有创建。
AWS 的一篇官方博文用虚构的 AnyCompany Retail 演示了一个协调 Agent 和四个专职 Agent。方案把通用质量、业务有效性和可解释性分别检查，其中优化接口使用模拟返回。这是一份参考实现，本文没有运行它，也不据此推定生产收益。AWS 原文
我赞同把这些检查分开。产品经理还需要追问：每一个分数究竟检查了哪一段执行？不同 Agent 之间，谁负责保存并验证共同条件？
三种“好”，需要不同证据
AWS 示例把解释质量独立评估，检查是否说明理由、引用工具证据、披露限制与假设。原文可解释性部分
精选译句：“一条建议可以准确，却无法解释。”原句：“A recommendation can be accurate but unexplainable”。
原创批注｜业务规则通过、信息有用、解释清楚，支持的是不同判断。把它们平均成一个总分，会让团队难以知道该修动作、补信息，还是改表达。
本文用另一条假设任务展开：为客户 C17 安排一次已获授权的产品演示；只能选择其可用时段；邀请必须发给该客户的联系人；创建后返回日程编号。设定资料、排期和邀请三个专职 Agent，由协调 Agent 汇总。
在这个例子里，tool correctness（工具使用正确）要检查对象和参数，进一步核实返回状态；helpfulness（有帮助）关注客户能否据此完成下一步；explainability（可解释性）关注选择时段的理由能否指向已知条件。这是本文的验收划分，不是三个官方评测器名称。
假设回答写得很清楚，选中了有效时段，但邀请仍停在草稿状态。它可以在说明质量上表现好，任务却未完成。反过来，日程创建正确，但联系人不知道如何加入，也需要单独记录信息缺口。
局部检查之外，要验收 Agent 之间的交接
资料 Agent 返回 C17 的联系人；排期 Agent 返回一个有效时段；邀请 Agent 也成功创建了一条日程。若最后一条使用了旧上下文里的 C18，单看三个局部输出，都可能找不到明显格式错误。
我建议给整个任务保存一份共享条件：客户 ID、联系人 ID、可用时段、授权动作和已有日程状态。每次交接都检查这些值有没有被改写或遗漏。它不是要求三个 Agent 复制同一段长提示词，而是给共同业务对象保留可对照的证据。
还可以设计三种定向扰动：资料返回同名客户；排期记录来自旧日期；邀请工具仅返回“草稿已保存”。预期分别是保持 ID 一致、识别过期条件，以及避免宣布日程创建完成。
这几道题测试的重点是信息在链路中的使用。它们需要隔离环境和固定返回，实际跑完才有能力结论。看到一个失败后，也不能立即归因于某个 Agent：协调 Agent 传错条件、接口漏字段和专职 Agent 忽略字段，都可能产生同一种结果。
读分数前，先看它拿到了什么上下文
AWS 文档把 session 定义为相关交互的逻辑分组，一个 session 可以包含多个 trace；trace 记录一次执行，内部操作形成 span。评测术语
官方模板进一步区分评分范围：GoalSuccessRate 检查 session；Helpfulness 检查 trace 中当前回答；工具选择和参数检查针对工具调用。对应的 context 范围也不同：会话级包含多轮记录，回答级包含此前轮次及当前输入、调用，工具级通常截止到被评工具调用之前。内建评测模板
这意味着，同一段任务可能得到多种粒度的分数。对本文的演示安排，邀请 Agent 的当前回答获得高帮助度，不能直接推出“客户收到了有效邀请”。至少还要核实前序客户身份、最终创建状态和对外交付内容。
我的检查顺序是先列评分对象，再列裁判可见字段，最后读结论。假设工具日志没有记录最终日程状态，裁判就没有这份证据；此时补采集或查业务对象，比要求裁判更自信地判分更有意义。
跨 Agent 的记录是否完整关联，也应实际检查。仅有同一个 session ID，不足以证明每段交接都被收集进裁判输入。若专职 Agent 的工具结果没有进入记录，某些协作失败会超出评分可见范围。
内建评测器和自定义规则，各负责哪一部分
AWS 的内建评测器使用预设模型、模板和标准，配置不可直接修改；自定义评测器可以定义模型、指令和评分方式，也支持用代码执行检查。评测器类型
对本文场景，我会用通用评测先检查信息是否切题、是否遵守已给指令；客户 ID 是否一致、日程状态是否生效、是否重复创建，则优先写成读取明确字段的规则。代码检查仍依赖真实字段、正确权限和正确判分逻辑，不会自动消除数据问题。
AWS 的代码评测器允许用 Lambda 函数实现确定性检查或访问外部 API。代码评测器文档 这为核对实际业务对象提供了实现入口；具体业务是否接入、怎样保持测试数据可比较，仍需要团队建设并验证。
我会另外留一组裁判校验样本：一段解释漂亮但邀请错客户的回答，一段表达简短但任务完成的回答，一段缺少状态证据的回答。检查裁判能否区分它们，再决定分数能用于提醒、回归，还是发布门槛。这是本文提出的校验设计，没有实际跑分。
可解释性检查的是交付证据
在假设任务里，合格解释可以是：“客户只在周四下午可参加，因此选择该时段；联系人为资料接口返回的指定联系人。”再把这两项对照实际返回，检查解释有没有遗漏或伪造依据。
这能评价说明是否与可见记录相符。它不能证明模型内部真实思考过同样步骤，也不能排除先得到答案、随后生成理由的情况。把“解释通顺”写成“推理真实可测”，会扩大证据能支持的范围。
还要允许“无法确定”。如果客户资料过期，直接给一个时段，再写一段自洽理由，会掩盖缺口。我建议将明确披露缺失信息与提出补充动作，作为单独检查，避免逼迫系统对没有证据的条件作肯定解释。
开发和运行可以闭环，证据要留到同一业务对象
AgentCore 文档说明，执行记录会转为统一格式，使用模型裁判进行内建及模型式自定义评测。服务概览 在线配置还需要指定评测器、数据源和参数。在线评测
据此，我会在开发阶段固定数据和任务，比较改动前后；运行阶段把失败记录送回回归集，同时保留客户 ID、日程 ID和失败位置。测试修复后，需要用同一组条件确认旧问题被解决，再补相邻场景检查副作用。
如果只抽查一部分运行记录，报告应交代抽样范围和未覆盖场景。平均分提高只能说明该样本、该评测版本下的表现变化；生产质量还要核对真实任务结果与遗漏的失败。
下一次看多 Agent 演示，可以选一条任务，从客户请求一路核对到最终业务对象。逐段问：条件是否一致，交接是否完整，评分覆盖哪里，结果是否生效。把这条链路的证据补齐，才有依据决定增加 Agent 后，系统是否更能完成任务。
核心来源：Kanishk Mahajan，2026-10-05，AWS 官方博文；补充 AWS 官方文档，访问于 2026-10-11。本文保留一条精选译句，演示安排为原创假设，未验证线上效果。
系列相关阅读
本专题阅读顺序：完整理解 EDD → Google 的提示词实验 → OpenAI 的评测位置 → 微软的需求断言 → MLflow 的回归任务 → AWS 的协作验收 → 美团的双环评测。
评测基础可回读再读A社博文：怎样建立可信的 Agent 评测；判断评分可靠性，可继续阅读谁来给 AI 裁判打分与Agent 分数涨了，能力真的变强了吗。