agentQuake：主动制造工具故障测试代理

天气接口返回空结果，AI agent 却回答了「Forecast for undefined」，原有测试没有发现。作者因此做了 agentQuake：主动让工具调用变慢、报错或超时，再观察 agent 会不会重试、陷入循环，甚至宣称一个从未发生的成功。

它关注的是工具出故障后，agent 如何收场。对正在用 Node 开发 agent 的程序员，这个切口很实用。不过，原文提供的主要证据是一个天气查询演示，还不足以证明它能可靠覆盖复杂业务。

工具调用结束，不代表任务已经完成

agentQuake 的做法是故障注入：有意干扰 agent 使用的工具，再记录 agent 的后续行为。所谓混沌测试（chaos testing），在这里可以理解成提前制造坏情况，检查系统如何应对。

原文列出的故障包括响应缓慢、错误和超时。演示还展示了工具返回空结果的情况。它们需要分别处理：慢响应可能需要等待或超时控制，错误可能触发重试，空结果则要求 agent 判断数据是否足够支持回答。

真正要检查的，是 agent 有没有把失败包装成成功。

作者希望通过记录区分几类行为：妥善处理、重试、循环，以及错误地宣称成功。不过，原文没有解释这些行为具体如何判定，也没有给出判定准确率。

同一个空结果，暴露了两种回答方式

天气演示对比了两种 agent 写法。面对空的工具响应，简单版本输出「Forecast for undefined」，被 agentQuake 标为 LEAKED GARBAGE；谨慎版本则承认无法获取天气预报。

这个例子暴露的是数据校验与回答生成之间的漏洞。工具调用没有提供有效天气数据，agent 却仍然拼出了一个看起来像答案的句子。对于用户而言，承认查不到，比交付带有 undefined 的结果更可信。

但演示只能说明这个具体案例。标题称原有测试没有发现问题，正文却没展示测试覆盖范围、断言或失败原因，因此不能据此认定普通测试发现不了这类缺陷。

可以从测试接入，但原文示例并不完整

agentQuake 支持从现有测试开始使用，不需要服务器和数据库。安装命令是：

npm i -D agentquake

这里的 -D 将它作为开发依赖安装，符合测试工具的用途。原文标注的环境是 Node.js 22.12+ 和 TypeScript 6，同时明确标记项目处于 early 阶段。

作者还提供了无需 API key 的天气示例运行命令：

npm ci && npm run example

要注意，npm run example 依赖项目提供的示例脚本；原文没有给出获取示例项目的完整步骤，不能把它当成任意目录下都能执行的命令。

测试片段展示了从 agentquake 导入 quake，通过 quake({ preset: 'flaky', seed: 42 }) 创建运行对象，再用 run.agent 包住 weatherAgent 调用，查询内容是 Cairo 的天气，并开始接入 getWeather。

但输入中的代码到 getWeather: run 就截断了。后续如何包装工具、读取记录、编写断言，都没有展示。preset: 'flaky' 和 seed: 42 是值得保留的配置线索，具体故障分布与复现保证则不能从这段材料中确认。

我的判断

我认可作者选择的测试边界：工具发生故障之后，业务才真正考验 agent 是否可靠。只断言正常响应能得到正确答案，确实覆盖不到异常输入下的行为。

不过，天气案例里的空值问题，用 mock 返回空数据，再断言输出中不能出现 undefined，同样有机会发现。agentQuake 的潜在价值，是把故障制造和行为记录整理成可复用流程。它能比手写 mock 节省多少工作、能否发现更多问题，原文没有对照数据。

还需要区分两种判断：识别 LEAKED GARBAGE，和判断某项业务究竟有没有成功。后者通常需要核对实际状态。原文没有说明它如何完成这一步，所以目前更适合把它视为一个值得试用的早期工具。

能拿来做什么

• 给现有 Node agent 测试补上空结果、错误和超时场景，并明确断言失败时应返回什么，避免只检查正常回答。
• 对需要重试的工具调用，检查 agent 是否能结束执行，并保留足够的失败信息，便于定位循环或错误重试。
• 试用 agentQuake 时，先复现天气演示，再阅读完整的工具接入与断言方式；当前材料中的代码不足以直接复制运行。
• 把「有没有回答」与「任务有没有完成」分开验证；涉及实际操作的任务，应核对操作结果，不能只相信 agent 的成功表述。