智能体的失败方式很特别。传统软件坏了会报错，智能体则常常软失败：延迟不高、错误率不涨，答案却看起来自信、读起来通顺、实际上是错的。材料里给出了真实例子，Customer Insights Agent 把某客户某项服务三个月的 410.08 美元收入报成 410.08 Million，把含调整项的销售收入标注为不含调整项，给出数据中并不存在的年度经常性收入估算，还把自己的计算当成有据可查的事实。监控全程绿灯，因为它只说明系统响应了，没有说明答案对不对。这就是评估框架要解决的问题。
从软失败说起：它是什么
AgentCore Evaluations 是 Amazon Bedrock AgentCore 的一项能力，用作为智能体提供一条从第一次提交到生产响应的连续评估面。材料中的落地对象是 AWS 销售、营销与全球服务运营团队构建的生产级多智能体系统，面向全球 AWS 现场销售。系统里有多类专职子智能体：Performance Insights Agent 负责区域范围的收入与业绩叙事，把原始指标转成可行动的销售洞察；Customer Insights Agent 汇总产品使用、支持历史、合同状态与互动数据，形成客户的 360 度视图；Data Insights Agent 是 text-to-SQL 智能体，让账户团队用自然语言查询结构化分析数据，不必写 SQL。这些答案被用于账户策略规划和客户会议准备，数字必须正确。
评估覆盖五个维度：安全、质量、性能、成本、运营控制。安全优先，材料明确说，不符合安全门槛的智能体不上线，也不继续运行；质量最难，也最需要专门框架。评估同时有三个层级：工具层、智能体层、多智能体层。工具层的每个能力，例如客户消歧工具、图检索工具，都有自己的评估契约；每个子智能体做端到端评估；多智能体层评估编排路径的连贯性、路由正确性和跨智能体边界的综合准确性。每个层级都有自己的黄金集、评估器和晋级标准。多数团队只评估智能体层就停下，但智能体层的质量受工具层制约，多智能体系统又引入前两层都看不到的第三类失败面。可以推断，这套结构的价值在于把评估对象从单次模型输出扩展到完整智能体栈。
九阶段闭环与三层评估：关键能力与原理
九个阶段覆盖从第一次提交到生产运行：一是基础，定义什么算好；二是实验，哪个版本更好；三是合入，我改坏了吗；四是门禁，它能不能上生产；五是金丝雀，有没有东西静默坏掉；六是对抗，如果有人试图攻破它会怎样；七是漂移，线上质量是否在漂移；八是脉搏，此刻怎么知道它正常；九是反馈闭环，如何自动变好。材料强调，九个阶段不是事后拼接的独立工具，而是同一评估面上的九个点，由 AgentCore Evaluations 从第一次提交贯通到生产响应。
定义质量是最关键的一步。答案必须来自客户，而不是来自模型，而且这是一个迭代过程。先把业务结果说清楚：对销售，成功是带着准确、最新、粒度合适、时机合适的情报走进客户沟通；对领导层，成功是可靠地拿到每周与跨业务复盘输入，不用大量手工准备。再把业务指标翻译成评估指标，每个信号对应一个带明确阈值和告警条件的追踪指标：准确的账户情报对应实体解析准确率与接地率，销售信任对应忠实度与幻觉率，销售行动对应有用性与范围遵循，领导层复盘可靠性对应准确率通过率与响应覆盖。翻译要覆盖五个维度：除质量阈值外，还要定义安全护栏策略、每个工具和每个智能体的 p50、p90、p99 延迟目标、每次查询成本预算，以及决定何时触发告警、触发哪本运行手册的 SLA。
准确率方面，材料给出六类失败类型，任何一类都判为不准确。指标替换，客户和周期正确、指标错误，按每 100 条响应出现次数追踪；错误周期，把同比数据当作环比呈现或反过来，按引用正确时间窗的百分比追踪；错误实体，账户名或子公司混淆，按实体解析准确率追踪；纯幻觉，没有可追溯来源的无据数字，按接地率追踪；错误符号，指标正确但货币或单位符号错误，按范围遵循率追踪；未授权计算，源数据中不存在的自行推导数字，按每 100 条响应出现次数追踪。总体准确率通过率是头条指标，分维度追踪才让它可行动。此外还追踪响应相关性、忠实度、有用性、指令遵循、工具选择准确率。一个正确答案埋在三大段里，或者来得太晚，同样没有通过。
评估器栈由四类组合而成。AgentCore 内置评估器提供基线覆盖，相关性、忠实度、有用性可以直接映射到原生模板；自定义评估器按失败类型逐个构建，材料中的六类失败类型没有一个被原生模板覆盖；第三方评估器，部署了 DeepEval 和 AutoEval 两个开源库的托管评估器；确定性评估器，用在标准答案完全已知的场景，例如收入、续约日期、合同状态。凡是推理质量和有用性没有唯一正确答案的地方，就用 LLM-as-judge 评分表，内置相关性与忠实度、有用性评分表，并支持完全自定义的评分表。AgentCore Evaluations 原生同时提供标准答案与 LLM-as-judge 两条评估路径。可以理解为，把可判定的部分交给确定性检查，把不可判定的部分交给带评分标准的模型评审，再用领域自定义评估器补齐领域特有的失败模式。
和传统监控、MLOps 的差异
传统软件是确定性的，同样输入得到同样输出。机器学习引入了概率性输出，于是有了 MLOps 来管理训练、版本、监控和重训。智能体增加了第三层运营复杂度：自主的多步推理。问题从有没有坏，变成整条推理链上