10 月 16 日，AWS 在官方博客发了一篇很长的工程实践文章，标题是《Building trust in AI agents: A production-ready evaluation framework with Amazon Bedrock AgentCore》。作者是 Rui Li、Alok Singh 等六人，内容不是发新模型，而是把「Agent 评测」这件事拆成了九个阶段，并说明每一段挂在 AgentCore 的哪个能力上。
这篇值得单独写，不是因为它来自大厂，而是因为它把一个行业里含糊了很久的问题说清楚了：Agent 不是崩溃给你看的，它是安静地答错的。
一、事件：AWS 把评测写成了一条流水线
先说清楚发的到底是什么。AgentCore Evaluations 提供 13 个内置评估器，覆盖正确性、忠实度、有用性、相关性、简洁性、连贯性、指令遵循、拒答、目标达成率、工具选择准确率、工具参数准确率、有害性和刻板印象；同时支持自定义评估器，以及 DeepEval、AutoEval 这类第三方评估器。
三种跑法对应三个场景：按需评估用于实验和 CI，批量评估用于金丝雀窗口，在线评估抽 10% 线上流量做漂移采样。再加上 CloudWatch 的指标与追踪、S3 与 Redshift 做结果持久化，评测第一次被接成了「持续运行的东西」，而不是上线前跑一次的脚本。
文章里也写明了未完成的部分：数据集评估（dataset evaluation）仍在公开预览阶段，部分图表标注了「数字为示意值」。这两点后面还要提。
二、为什么盯上「软失败」
传统监控看三件事：接口是不是 200、延迟高不高、错误率涨没涨。Agent 的坏法恰恰不在这三件事里——接口 200、p95 延迟平稳、错误率为零，但它在胡说。
AWS 举的例子很具体：一个客户洞察 Agent 在发布前的测试里，把三个月合计 410.08 美元的收入报成了「410.08 百万美元」，把「销售收入」标成了「扣除调整后的销售收入」，还给了一个数据里根本不存在的 ARR 估算，最后把自己的计算过程当成了「有据可查的事实」呈现。整个过程中，监控面板全是绿的。
他们把这类错误归成六种：指标错位、时间段错误、实体混淆、纯幻觉、货币与单位符号错误、未授权计算。这里面有两类特别值得注意——「指标错位」和「未授权计算」不是答错，是答对了别的东西，靠人眼扫一遍根本发现不了。
三、九段到底在管什么
九个阶段各自对应一个问题，顺序就是 Agent 的生命周期：
- 基础：什么才算「好」？——先把失败类型和评分标准定义出来。
- 实验：哪个版本更好？——小样本对比，不追求统计显著，追求方向。
- 合并（CI）：我是不是弄坏了什么？——哨兵集每次提交必跑。
- 发布门禁（CD）：能不能上线？——200 道留出题端到端跑一遍。
- 金丝雀：有没有静默故障？——小流量真跑，30 分钟一个窗口。
- 对抗：有人故意搞它呢？——畸形输入、越界请求、模糊指令。
- 漂移：线上质量在滑吗？——抽 10% 流量持续比对。
- 脉搏：现在到底好不好？——实时看板与告警。
- 反馈闭环：怎么自己变好？——把线上失败变成新的评测样本。
这套划分不算新，新的是它把每一段都配了阈值和触发条件。评测最难的部分从来不是「知道要测」，而是「测到什么程度该拦」。
四、四组参数：哨兵集、门禁、金丝雀和漂移
文章里最有价值的是这些具体数字，可以直接拿去对照自己的流水线：
- 哨兵集 15 题：只放 15 个案例，几分钟跑完，每次部署必跑。质量或安全越界直接阻断部署；延迟翻倍或成本激增则要求「刻意决策」而不是自动放行。
- 门禁三重关闭条件：候选版本的聚合得分不得低于自己此前的运行、必须超过当前生产基线、200 道留出题中低于单题阈值的比例不得超过规定值。第三条是为了防「均值变好、更多单题变差」。
- 金丝雀 30 分钟窗口：15 分钟的窗口误报太多，60 分钟又曾让退化跑了两小时才被发现。要连续三个窗口（90 分钟）越界才叫 oncall，单窗口失败只作为运维信号；每分钟轮转采样，24 小时覆盖完整金丝雀集。
- 漂移抽 10% 流量：在线评估持续采样，每天再跑一次全量金丝雀集，作为当天的权威评分卡。
另外两个指标也挺狠：护栏延迟的 p99 目标压在 50 毫秒以内（安全不能拖慢主链路）；每次成功响应成本 = 每次查询成本 ÷ 通过率——这个口径一改，靠降低通过率来省钱的优化立刻现原形。成本口径的更细算法可以参考成本怎么算。
五、四个真实案例
光有参数不够，看它抓到了什么更有说服力：
- 发布不同步，通过率 78% → 38%：数据、工具和配套提示词本该同步上线，结果错开了。这一条几乎每个团队都犯过。
- 金丝雀集太「干净」，识别率 98% → 81% → 80%：金丝雀集用的是合成的边界用例，线上用户却用股票代码（如「AMZN」）、简称和错拼来查。连续三个窗口下滑后才叫醒人，定位到是消歧工具的问题，修完再补样本。
- 少样本示例被照抄，幻觉 138 → 52 以下（每万次响应）：模型把 few-shot 示例里硬编码的「420 万美元」「Acme 公司」当成了真实数据。改法很土——把示例里的具体值换成占位符。grounding 率从 93% 升到 96%。
- 「正确的数字，错误的范围」：母公司和子公司各有一套都正确的收入数字，候选版本没按查询语义和用户角色推断范围，被质量门禁拦下。
四个案例里，只有第一个是「坏了」，剩下三个都是「看起来没坏」。这就是软失败的定义。
六、影响分析：评测正在变成平台原语
这件事的意义不在功能清单，在位置变化。
第一，评测从「项目」变成「运行时」。以前评测是一个季度做一次的专项，现在它是每条请求都要过的一道工序。站内写过的评测框架讲的是怎么搭，这次是把搭好的东西托管化，差别类似「自己装机」和「买云主机」。
第二，门禁前移到 CI。15 题哨兵集进流水线，意味着评测集要和代码一起版本化。谁改了提示词、谁换了模型、谁动了检索库，都要跑一遍。这件事组织上的阻力比技术大——很多团队连评测集归谁管都没定。
第三，成本口径被改写。「每次成功响应成本」把通过率拉进了成本公式。这意味着降本不能靠砍重试，得靠提高一次通过率，方向完全不同。
第四，云厂商在抢「评测」这个入口。这和之前两朵云同时产品化 Agent 运行底座是同一个逻辑：运行、网关、评测、注册表，谁占住控制面，谁就掌握了迁移成本。
七、老达点评：软失败是 Agent 的沉默故障
我一直觉得，Agent 上线后最贵的故障不是崩溃，而是「看起来在工作」。崩溃至少会报警，软失败不会——它安安静静地给你一个格式漂亮、语气自信、数字错误的答案，然后这个答案进了周报、进了给客户的方案、进了管理层的决策会。
这篇东西最值得抄的不是九段，是三个动作：
一是 15 题的哨兵集。这个设计的精髓在「小」——小到几分钟能跑完，才可能真的每次都跑。大部分团队的评测集有几百条，跑一次二十分钟，结果只有发版前才跑，平时根本不用。评测的价值和它的执行频率成正比，不和它的规模成正比。
二是「连续三个窗口才叫人」。这是纯工程直觉：单点越界大概率是噪声，连续越界才是趋势。但反过来，这也意味着你要接受「最多 90 分钟才发现」的代价。这个取舍必须提前定，不能等出事再吵。
三是「均值变好、单题变差」也算不通过。这条最容易被忽略。平均值是个温柔的指标，它会把少数场景的严重退化藏起来，而线上投诉永远来自那少数场景。
说点不好听的：这套框架再完整，也替代不了你自己的失败样本。AWS 的内置评估器能告诉你「答案是否忠实于检索到的内容」，但它不知道你们行业里「含税」和「不含税」混了会死得多惨。先把最近三个月真实翻车的 30 条案例整理出来，比研究九段重要得多，具体做法可以看从真实失败样本开始建评测集和评测样本怎么建。
八、三个提醒
- 数据来自厂商自述：通过率 93%→96%、幻觉 138→52 这些数字都是 AWS 自己统计的，没有第三方复现。参考可以，别当基准。
- 部分能力还在预览：数据集评估是 public preview，整套框架也没明确宣布 GA。生产上要留降级方案。
- 评估器本身要校准：用模型当裁判，位置偏差、长度偏差、自我偏好一个都不少。评分器自己的准确率不达标，门禁就是随机数，校准方法见评分器设计与偏差校准。
九、总结
这件事值得记一笔，因为它标志着 Agent 评测从「手艺」变成了「基础设施」：以前靠一个懂行的人写几十道题，现在有平台把按需、批量、在线三种评估、门禁、金丝雀、漂移串成一条线。
但要清醒：平台能给你的是管道，不是标准。什么算「答对了」、什么算「不能上线」，仍然得你自己定。如果你们现在还没有一份写下来的失败类型清单，那这套东西装上去也只是多了一个绿色的看板。
能马上做的三件事：把质量门禁的关闭条件写清楚（参考质量门禁怎么设）、挑 15 条最典型的失败做成哨兵集、给线上加一条「抽 10% 比对」的链路。三件事加起来，一周能做完，比等一个完整平台现实得多。顺带一句，观测层要跟上，否则评测挂了都没人知道，可参考可观测性怎么搭和运行监控看什么。
