AWS AI Agent测试通过却漏检：一次真实实验复盘

AI Agent 生成的代码测试全绿，就等于任务完成了吗？一位开发者在个人 AWS 实验室里做了一次小实验，结果发现：测试通过，并不代表需求被完整覆盖。

实验背景：从一份部署历史开始

开发者没有连接任何生产环境，而是准备了一份自制的 CSV 文件。这份文件记录了 12 次部署检查，每次间隔 5 分钟，包含时间戳、健康状态、期望版本、运行版本、健康实例数、期望实例数以及活跃告警数等字段。

数据是虚构的，没有任何真实生产事故作为背景。

任务本身不复杂：计算两个数字——不健康检查的总数，以及每一段已完成的不健康持续时长。第二个数字需要一个明确的规则：不健康周期从第一个不健康检查开始，到其后第一个健康检查结束；如果文件结束时仍处于不健康状态，则该周期视为未完成。

开发者特意在把任务交给 Agent 之前，自己先手工算了一遍。以 10:10 的第一个不健康检查为例，下一个健康检查出现在 10:25，因此该周期为 15 分钟。这一步很关键：先建立独立预期，才能判断 Agent 的输出是否真的可靠。

Agent 怎么写代码、怎么跑代码

模型使用的是 Amazon Nova 2 Lite，通过托管 Agent 环境调用。开发者向模型提供了计算规则、三个小型测试用例以及目标 CSV，但没有给任何实现代码。

模型自行生成了 Python 程序，并将其发送到 Amazon Bedrock AgentCore Code Interpreter，在一个独立的执行环境中运行。整个流程可以概括为：

提供的 CSV → 模型生成 Python → Code Interpreter 执行 → 返回结果

开发者做了两件事：一是把返回的数字与自己预先算出的结果比对；二是阅读模型生成的测试代码。保留的执行流显示，只有一次 Code Interpreter 调用，其中包含生成的程序，工具输出中带有测试通过标记和计算结果。这意味着可以做一次真正的核验：看实际运行了什么，而不是信任模型对运行的总结。

Amazon Nova 2 Lite 是亚马逊在 2024 年 re:Invent 大会上发布的基础模型系列之一，定位为低延迟、低成本的中小型模型，适合代码生成、数据分析等对响应速度敏感的场景。Bedrock AgentCore 是 Amazon Bedrock 的扩展能力，为 AI Agent 提供托管运行环境，包含 Code Interpreter（代码解释器）等沙箱工具。Code Interpreter 会在与主模型隔离的容器中执行模型生成的代码，避免脚本影响宿主系统，同时允许 Agent 通过工具调用获取真实的执行结果。这种「模型生成 + 沙箱执行」的架构是当前 Agent 完成计算类任务的常见形态，也是本次实验中能够保留执行流水、核验实际运行内容的基础。

数字全对，测试却有缺口

在 Agent 运行之前，开发者已经独立算出了预期结果，输出完全匹配：

检查项	结果
总样本数	12
不健康样本数	5
不健康样本占比	41.7%
已完成的不健康周期数	2
周期时长	15 分钟和 10 分钟

41.7% 是 12 个样本中有 5 个不健康，并不代表应用有 41.7% 的时间处于宕机状态。程序还打印了 MODEL_GENERATED_TESTS=PASS。

问题出在测试覆盖范围上。开发者的提示词要求针对每一个声明的测试预期都写断言，也就是那些在预期不满足时会让程序停止的检查。但生成的测试只覆盖了周期数量和时长，并没有显式检查每个预期的开始和结束时间戳。

目标输出中的时间戳是正确的，所以答案本身没有错。缺口在于测试实际证明了什么。

“测试通过”意味着已写出的断言通过了，并不意味着每一项需求都被测试过。比对结果和阅读断言，回答的是两个不同的问题。

测试覆盖率（test coverage）通常衡量测试代码执行了多少行或多少分支，但这里所说的「缺口」不是行覆盖率，而是需求覆盖率——即提示词中声明的每一项断言是否都有对应的测试存在。两者容易混淆：即使行覆盖率达到 100%，如果测试本身没有检查开始与结束时间戳，那条需求仍处于未被验证的状态。在 AI 生成代码的场景中，模型倾向于围绕最核心、最显眼的输出（如周期数量、时长）编写断言，而容易忽略边界条件或辅助字段。因此阅读生成的测试代码，本质上是在做一次需求追溯（requirement traceability），把每条原始要求映射到具体的断言上。

这次运行能说明什么，不能说明什么

这次实验展示了：Agent 能够生成并执行分析代码，且输出与开发者独立计算的结果一致；同时也展示了为什么必须阅读生成的测试代码。

但它不能说明未来每次运行都能成功。畸形输入、访问限制、会话行为以及重复运行检查，都还有待后续评估。

对于这类分析任务，开发者建议把三样东西放在一起保留：输入、实际运行的代码，以及它的输出。然后在信任“通过”标记之前，把生成的测试与原始需求逐条对照。