AWS介绍了一套基于Amazon Bedrock AgentCore的九阶段评估框架，实践来自通过Amazon Quick服务一线销售人员和管理层的内部多智能体系统。系统按销售区域和用户角色限定回答范围。其中，Performance Insights负责销售分析，Customer Insights汇总客户信息，Data Insights支持把自然语言请求转换为SQL。评估同时覆盖这些智能体调用的工具及它们之间的协作。

上线前，评估发现系统曾将410.08美元表述为410.08百万美元，还出现指标标签错误、缺乏依据的经常性收入估算，以及将自行计算的结果当作来源事实的情况。与此同时，运行监控仍显示正常。这些案例说明，在AWS所描述的系统中，服务运行状态与答案内容的正确性需要分别检查；延迟和错误监控正常，并不能说明收入数字或客户范围也正确。

把业务目标转换为可检查的标准

框架包含Foundation、Experiment、Merge（CI）、Gate（CD）、Canary、Adversary、Drift、Pulse和Feedback Loop九个阶段，覆盖安全、质量、性能、成本和运行控制。工具、单个智能体及多智能体系统分别拥有基准测试集、评估器和晋级标准。AWS报告，一次投产前的数据、工具及提示词变更未能相互匹配，使测试通过率从78%降至38%。这一案例对应的不只是单个组件，还包括组件组合后的行为。

Foundation阶段将业务目标落实为评估阈值、告警、安全政策、延迟目标、单次查询成本预算和运行服务级别协议。AWS定义了六类准确性错误：指标混淆、时间范围错误、实体错误、纯粹幻觉、符号错误和未经授权的计算。出现其中任何一种，回答就被判定为不准确。框架还检查相关性、对依据材料的忠实度、有用性、指令遵循情况及工具选择准确性，避免仅用一个总分描述所有问题。

具体评估结合AgentCore内置评估器、六个领域专用评估器、第三方DeepEval和AutoEval，以及与已知正确结果进行确定性比较的检查。对不存在唯一正确答案的品质，则由大语言模型按评分规则判断。受版本控制的基准集来自生产查询、已观察到的失败和合成边界案例，覆盖工具正确性、四类智能体问题、多智能体交互、安全、延迟与成本。这样，已发生的问题也能进入之后的重复检查。

实验比较与发布前把关

Experiment阶段通过AgentCore On-Demand Evaluation比较候选变更，使用相同基准集和评估器组合，同时考虑质量、延迟、成本及token上下文。输入、输出、检索到的上下文、分数和评分理由保存在S3及数据湖中。保留这些材料，使比较不仅呈现最终分数，也保留产生该分数的回答和依据。

AWS报告，经过三个月迭代，测试通过率由93%提高并稳定在96%；每一万条回答中的纯粹幻觉由138次降至不足52次，未经授权的计算由59次降至不足44次。这些数字描述的是该内部实现的迭代结果，不能据此断言其他系统也会获得相同改善，更不能理解为此类错误已经消失。

Merge阶段在每次部署到预发布环境时自动运行一个含15个案例的哨兵测试集。超出容忍范围的质量退步和安全违规会阻止部署，延迟及token成本变化也纳入检查。工具、智能体和编排层分别设置哨兵检查，分数发布到CloudWatch。AWS称，工具层的实体识别测试曾阻止一项规范化变更，因为该变更会返回错误客户的数据。

Gate阶段在发布前评估完整基准集。经过验证的工具响应被固定下来用于重放，从而将智能体推理问题与实时工具输出变化分开。端到端的大语言模型评审还覆盖200个预留问题。候选版本如果比自身上次测试退步、未能胜过生产版本，或低分问题占比超过允许范围，就无法通过发布关卡。AWS举例称，这一过程发现了系统用母公司收入回答仅涉及子公司的问题：数字的企业范围同样是正确性检查的一部分。

生产中的持续评估与安全检查

Canary阶段使用AgentCore Batch Evaluation，以30分钟为窗口轮换运行基准集，在24小时内完成全面覆盖，并每天按发布关卡阈值再运行一次完整测试。一次窗口失败属于运行信号，呼叫值班人员则要求连续三个窗口越过阈值。因此，首次发现问题与升级为值班通知是两个不同环节，不能将它们合并描述。

AWS报告，在延迟正常且没有运行错误时，第一个窗口就发现回答对检索材料的依据性下降，随后将问题追溯到检索工具。这与上线前的错误收入案例相呼应：质量评估关注回答是否得到材料支持，而运行指标关注的另一些方面可能仍然正常。该案例中的首次发现，并不意味着当时已经触发值班呼叫。

Adversary阶段针对滥用，但安全检查贯穿全部九个阶段。AWS表示，Amazon Bedrock Guardrails会对100%的流量同步检查输入和输出，并在回答交付用户前完成处理。输入检查关注请求范围和提示词注入；输出检查关注未经授权的敏感数据披露及政策违规。所述防护还包括有害内容过滤，以及针对越狱、提示词注入和提示词泄露的保护。这些是AWS报告的防护安排，并非错误披露绝不会发生的保证。

Drift阶段通过AgentCore Online Evaluation持续抽样评估10%的实时流量。分数送入Quality-State Calculator，用于跟踪质量、延迟和成本。AWS称，股票代码与简写暴露了实体识别缺口，扩充基准集并规范化输入后，准确性在下一个周期恢复。这里的基准集会随着实际查询中发现的问题而更新，并非只在最初开发时建立一次。

通过质量关卡后，AgentCore Gateway将一部分流量分配给当前智能体和候选智能体进行比较。只有候选版本在每个评估维度上都胜出或持平，才满足全面推出的条件。这个要求将生产流量中的比较与前面的测试衔接起来；它描述的是AWS这套内部流程的发布标准，不能视为所有AgentCore部署的统一默认规则。

可观测性、反馈与结果边界

Pulse阶段将评估信号与AgentCore Observability结合。对于托管在AgentCore上的智能体，AWS描述了自动OpenTelemetry埋点，并在启用Transaction Search后将执行遥测发布到CloudWatch。评估器分数使用另一条日志管道，因此执行轨迹和质量评分的收集路径有所区别。S3及数据湖中的输出支持对话式查看和Amazon Quick仪表板，并提供按角色区分的视图。AWS报告，平均发现问题的时间从数天或数周缩短到不足四小时。

Feedback Loop阶段依据执行轨迹和目标评估器生成的AgentCore优化建议，调整系统提示词及工具描述。低分轨迹被转为回归测试案例，让已经发现的失败能够在后续变更中再次受检。AWS称，将少样本示例中写死的数值替换为占位符后，幻觉有所减少，对依据材料的扎根率由93%提高到96%，提示词迭代时间也从数天缩短为数分钟。

需要区分的是，文章同时报告了测试通过率和扎根率从93%升至96%，但所给材料并未证明两者是同一个指标。文章列出了按需、批量和在线评估，并将数据集评估标为公开预览，不能将其写成已正式全面可用。部分图注还明确说明数字仅作示意，不能据此增加实测成果。

以上流程和成效均来自AWS这一单一主要来源，所提供的证据没有独立验证这些改善，也没有证明其他部署会取得同样结果。15个哨兵案例、200个预留问题、10%的在线抽样比例及告警阈值，都应理解为该实现的具体选择。这套框架展示了AWS如何将业务要求、发布检查、生产评估和失败反馈连接起来，而不是对消除幻觉、回归或未授权披露的承诺。