AgentCore 生产评估：发现隐蔽错误

日落时分海岸悬崖上的灯塔 — 海岸悬崖上的灯塔（Photo by Vincent Yap on Unsplash）

本文根据 AWS 的 AgentCore 生产案例整理。案例中的数字和做法属于 AWS 团队的实践，具体标准要结合自己的业务制定。

核心结论： Agent 能返回答案，不代表答案正确。要发现那些“看起来没问题”的错误，需要检查工具、单个 Agent 和多个 Agent 的协作；在上线前测试，上线后继续观察，并把发现的错误加入下一轮测试。

一个数字错了，监控却显示正常

AWS 的销售团队使用一个多智能体系统回答业务问题。一次上线前的测试中，系统把某客户在一项服务上的三个月营收 410.08 美元，写成了 410.08 百万美元。答案照常返回，常规运行监控也没有报警。

这就是“静默失败”：系统没有崩溃，回答也很流畅，但内容已经错了。销售人员如果带着这个数字去见客户，后果远比一次请求报错严重。

问题还不只出在模型。AWS 记录过一次预生产测试：数据、工具和提示词的更新没有配套到位，通过率从 78% 降到 38%。这些数字只说明该案例的情况，却提醒我们：即使代码没变，上游数据或工具发生变化，答案也可能变差。

先弄清楚：错误可能出在哪里

这个系统会让不同的子 Agent 分别处理业绩、客户信息和数据查询，再合成最终答案。假如结果错了，只检查最后那段文字，很难知道错误从哪一步开始。

AWS 因此把检查分成三层：

检查哪里	要问的问题	例子
工具	查到的数据和调用参数对吗？	查的是不是同一个客户、同一时间段？金额单位对吗？
单个 Agent	它有没有正确使用数据并回答问题？	数据是 410.08 美元，回答有没有擅自加上“百万”？
多 Agent 协作	任务分配和答案拼接对吗？	一个 Agent 查母公司，另一个查子公司，最终答案有没有混用？

这三层回答“查哪里”。另外还要从安全、答案质量、速度与稳定性、成本、问题处理能力五个角度看“查得怎么样”。例如，数字正确但越权泄露客户数据，依然不能上线。

九个阶段，用四个问题记住

AWS 把评估分成九个阶段。名字多，但实际是在反复回答四个问题：什么算好？改动有没有变差？上线后有没有出错？发现问题后怎么办？

什么时候	AWS 的阶段	通俗地说
开始做之前	1. 定义（Foundation）	先写清楚什么叫正确，以及哪些错误绝不能接受。
比较方案时	2. 实验（Experiment）	用同一批问题比较不同提示词、模型或工具。
合并改动时	3. 合并检查（Merge / CI）	用一小组高风险案例，快速挡住明显退步。
准备发布时	4. 上线门槛（Gate / CD）	用更完整的测试集，决定候选版本能否上线。
刚上线及运行中	5. 持续抽查（Canary）	定期检查线上回答，发现没有发布也发生的退步。
面对恶意输入时	6. 对抗测试（Adversary）	测试越权提问、提示注入等攻击。
用户问题变化时	7. 漂移检查（Drift）	看新说法、新客户、新数据有没有让旧测试失效。
日常运营中	8. 状态观察（Pulse）	把评分、执行过程、耗时和成本放到一起看。
修复之后	9. 反馈改进（Feedback Loop）	把真实错误变成测试案例，避免下次重犯。

第 1 至 4 步主要防止改动带来退步。例如，改了提示词后，先跑少量重要案例，再用完整测试集决定是否发布。不能只看平均分：即使整体变好，某个关键客户场景答错，也可能要拦下发布。

第 5、7、8 步负责发现线上新问题。数据刷新、用户换了一种问法、工具返回格式变化，都可能让原本通过测试的 Agent 出错。第 6 步关注恶意输入，对抗测试应贯穿开发和运行过程。

第九步让这些检查接上改进：找到错误，查清原因，修复，再用相同案例验证。这样，线上遇到的问题会成为下次发布的保护网。

用什么来判断答案对不对

先准备“标准题库”。 AWS 把它叫作 golden set：一组经过核对的问题、预期结果和边界案例。它既用来比较版本，也用来决定是否发布。题目可以来自真实用户提问、过去出过的错，以及团队主动设计的难题。

比如“查询客户近三个月营收”这道题，标准题库不能只放一个正确数字，还要覆盖客户名称相似、母子公司混淆、时间范围变化、货币单位错误等情况。线上出现新错误后，先确认原因和正确答案，再把它加进题库；低分会话不能未经核实就直接加入。

再按问题选择检查方法。 对于营收、日期、合同状态、权限和单位，正确值通常可以核对，就用明确的规则或真实数据检查。对于回答是否切题、是否说清楚、是否遵循指令，可以用模型评估器辅助判断。AWS 在 AgentCore Evaluations 中组合了内置评估器、按业务错误定制的评估器、第三方评估器和确定性检查。涉及关键事实时，模型给出的“看起来合理”评分不能代替核对。

报警之后，还要找到是哪一步错了

假设线上评分突然下降，只看到“通过率降低”仍不足以修复问题。团队还需要查看一次回答经过了哪些步骤：调用了哪个工具、拿到了什么数据、交给了哪个子 Agent、最后怎样拼出答案。这份执行记录通常叫 trace。

在 410.08 美元的例子里，检查记录可以帮助区分：原始数据就错了，工具把单位弄错了，还是 Agent 在写答案时加上了“百万”。定位到具体环节，才知道该修数据、工具还是提示词。

AWS 的做法是保存评估结果与执行记录，并连同工具调用、耗时和成本一起观察。记录帮助定位原因；答案是否正确，仍要靠题库、明确规则和必要的人工核对。

如果换成写作 Agent

同样的问题也会出现在写作中：文章读起来顺畅，却把数字抄错、引用放错，或者把来源观点写成作者观点。可以按同样的三层检查：

检查哪里	写作场景中的问题
工具	搜索到的来源真实吗？引用链接和图片路径有效吗？
单个 Agent	事实和来源对得上吗？结构、观点和语气符合要求吗？
多 Agent 协作	研究材料有没有传到写作环节？审稿意见有没有落实？

把常见错误做成标准题库，再把发布后的返工和读者反馈补进去，就能持续改进。不过，文章是否真正表达了作者的观点、证据是否足以支持结论，仍需要作者和编辑判断。这一段是将 AWS 的评估思路迁移到写作场景，属于本文的延伸分析。

借鉴这个案例时，先抓住两件事

第一，先列出业务最怕的错误。 销售系统要核对金额、客户、时间和权限；别的 Agent 应从自己的高风险场景出发。然后决定每种错误该在哪一层检查，用什么方法检查。

第二，让真实错误回到测试中。 从少量高风险案例和上线抽查开始，逐步补齐发布门槛、执行记录和反馈流程。AWS 的九阶段展示了一套完整做法，不要求每个团队一开始就照搬全部流程。

AWS 报告的通过率、监测周期和成本阈值都属于其业务场景。原文也没有给出可直接复制的完整评估器实现和题库。可借鉴的是“定义正确答案、分层检查、持续发现、修复后回归”的方法；具体标准仍要自己验证。