智能体坏的方式和传统软件不一样。它不会抛异常、不会超时、延迟平平稳稳，错误率为零——它只是开始安静地答错。10 月 16 日，AWS 在机器学习博客发了一篇长文，把自己内部一套生产多智能体系统的评估实践整理成九阶段框架，骨干是 Amazon Bedrock AgentCore Evaluations。这套产品能力今年 3 月已全面可用（AWS 官方公告），站点 891 当时从 DevOps 智能体监控的角度记过一笔；这次值得单独写，因为 AWS 交出来的不是产品发布，是内部战报加方法论。
九阶段里值得抄的作业
逐阶段照抄的成本高，但几个设计值得抄。CI 门用 15 个案例的 sentinel 集做快速闸口，CD 质量门用 200 个留出问题做全量考卷；金丝雀阶段用 30 分钟一个评估窗口——15 分钟误报太多，60 分钟真实劣化要两小时后才发现，连续三个窗口破阈值才呼叫 on-call；漂移检测持续采样 10% 实时流量；护栏对输入输出做全量同步检查，p99 延迟目标压在 50 毫秒以内；所有评估记录全量落 S3 与 Redshift，提示词迭代周期从数天缩到数分钟。这套设计的共同点，是把「评估」从发布前的一次性动作，改成每个阶段都有触发器的常设流程。
内部战报的三个数字
框架服务的是 AWS 自家销售体系的多智能体系统：性能洞察、客户洞察、数据洞察三个子智能体，给一线销售回答营收与客户问题，数据查询那个直接把自然语言翻成 SQL。战报里有三个数字。其一是约三个月迭代的成绩单：整体通过率从 93% 抬到 96%，每万次响应里的纯幻觉从 138 次压到 52 次以下，未授权计算从 59 次降到 44 次以下。其二是故障发现时长：从数天到数周，压到 4 小时以内。其三是个反面教材——一次没对齐的发布窗口里，数据先落、提示与工具后到，通过率从 78% 直接跌到 38%。最能说明问题的是那个错法：客户三个月服务收入 410.08 美元，被客户洞察智能体报成「410.08 百万美元」——单位错一位，数字全灭，而接口一切正常。
该怎么定位这篇博客
先说边界：框架、数字、产品组合都出自 AWS 自家系统，无第三方独立复核；九阶段也不是行业标准，是一份写得好的内部实践被公开。它的产品属性同样明显——AgentCore Evaluations、Guardrails、CloudWatch、S3、Redshift、Quick、Lambda 一整套，评估记录与看板都长在 AWS 服务里，搬到别家云上，这套流程得重新搭。但这不妨碍它成为当下关于「智能体软失败」最完整的一手材料：连「数据比提示先上线会掉 40 个点」这种程度的细节都写了出来，还顺带提到了 DeepEval 与 AutoEval 两个第三方开源评估库。
放进台谱里看
评估这条线今年在站点反复出现：1991 拆过 Anthropic 把代码评审机器化的完整战报，2001 记过 Claude 平台把可观测性接进 OpenTelemetry 标准，1943 写过 ServiceNow 给智能体签发运行时护照，1976 分析过「按层收费」里评估与审批的位置。AWS 这篇的增量在于把评估放到了生命周期正中间——不是上线前质检，不是事后审计，是每一层都有考卷的运营系统。配合同周的另外几篇读（本期 2010 的管理台、2005 到 2008 的四篇技术拆解），一条线逐渐清晰：智能体工程的重心，正从「让它跑起来」转向「让它持续跑对」。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。