AI Agent 的混沌工程：在生产环境之前注入你的 Agent 将真正面对的故障

你的 Agent 在预发布环境中运行完美。它调用正确的工具，推理多步骤计划，并返回精心打磨的结果。然后生产环境来了：地理编码 API 在 7 步计划的第 3 步超时，LLM 在句子中间返回不完整的响应，而你的 Agent 自信地编造数据来填补空白。直到客户发现，没有人注意到。

LLM API 调用在生产环境中有 1-5% 的失败率——速率限制、超时、服务器错误。对于每个任务进行 10-20 次工具调用的多步骤 Agent，这意味着相当比例的任务至少会遇到一次故障。问题不在于你的 Agent 是否会遇到故障，而在于你是否曾经测试过它遇到故障时会发生什么。

混沌工程——通过有意注入故障来发现弱点的实践——自 Netflix 的 Chaos Monkey 以来一直是分布式系统的标准做法。但将其应用于 AI Agent 需要重新思考几乎所有假设。Agent 不是无状态的微服务。它们携带上下文，做出概率性决策，并且可能以看起来像成功的方式失败。

为什么传统混沌工程对 Agent 不适用

经典混沌工程假设了一些对 AI Agent 不成立的前提。

幂等重试不适用。 当微服务调用失败时，你用相同的输入重试并期望得到相同的输出。当 LLM 调用在推理过程中失败时，重试会产生不同的思维链。Agent 可能会采取完全不同的路径来执行其计划，以不同的顺序调用不同的工具。假设确定性行为的重试逻辑会产生不可预测的结果。

断路器保护的是错误的东西。 在传统系统中，断路器停止调用失败的服务以防止级联故障。对于 Agent，问题不在于调用的数量——而在于当调用失败时 Agent 决定做什么。一个失去对其主要数据源访问的 Agent 不会简单地停止。它会即兴发挥。它可能会幻觉出缺失的数据，替换一个返回错误结果的不同工具，或者自信地跳过该步骤并在不标记的情况下交付不完整的答案。

故障是语义性的，而不仅仅是操作性的。 500 错误很容易检测。但返回过期数据的工具呢？或者恰好形成语法正确但事实错误的句子的部分 LLM 响应呢？Agent 面临一类系统看起来健康但输出默默出错的故障。ReliabilityBench 研究发现，这些语义故障——部分响应、模式漂移、过期数据——比完全崩溃更难捕捉，也更具破坏性。

你应该注入的六种故障模式

基于生产事故模式和最新研究，以下是对 Agent 系统最重要的故障类别：

1. LLM 级别故障。 速率限制（HTTP 429）、服务器错误（500/502/503）、超时、响应中途的流中断和缓慢的 token 交付。这些是最常见且最容易注入的。ReliabilityBench 发现，速率限制在基础设施故障中造成最大的可靠性影响，比基线降低 2.5%——这个数字在多步骤任务中会复合增长。

2. 工具调用故障。 API 错误、超时、格式错误的响应和数据变异。关键洞察是 Agent 通常不验证工具结果。它们将返回的任何内容视为事实。一个从搜索 API 收到错误响应的 Agent 可能会继续执行，就好像它得到了结果一样，编造数据来填充预期的格式。测试这一点需要在工具层注入故障，并检查 Agent 是否承认故障而不是掩盖它。

3. 上下文退化。 随着任务变长，Agent 失去对早期信息的访问。开始时给出的指令被最近的上下文覆盖。一个被告知保持正式语调的 Agent 在第 15 轮开始使用随意的语言。一个被赋予严格输出约束的 Agent 随着上下文窗口填满开始偏离。这不是崩溃——这是一种只有在长时间运行的任务中才会出现的可靠性缓慢侵蚀。

4. 跨 Agent 边界的级联故障。 在多 Agent 系统中，早期管道步骤中的错误向下游传播。每个 Agent 将之前的输出视为可靠的事实。Agent A 中的解析错误变成 Agent B 中的错误假设，进而变成 Agent C 中自信但错误的建议。对基于 LLM 的多 Agent 系统的研究发现，通信故障和级联故障是最危险的类别，因为它们最难追溯到其根源。

5. 压力下的规范漂移。 当 Agent 遇到模糊情况——尤其是在故障之后——它们会用统计上可能但潜在不正确的补全来填补空白。一个被告知"要有帮助"的 Agent 开始做出超出其权限的退款承诺。这种故障模式被故障放大：当正常路径中断时，Agent 会即兴发挥，而即兴发挥正是规范漂移最危险的地方。

6. 静默故障。 Agent 完成了任务，返回看起来合理的结果，并且没有引发错误。但结果是错误的。这是最难捕捉的故障模式，因为没有可以告警的信号。Agent 的混沌工程必须包括语义验证——不仅检查 Agent 是否完成了任务，还要检查其输出是否确实正确。

构建有效的故障注入框架

Agent 混沌测试框架的架构在几个关键方面不同于传统混沌工程。

基于场景的测试与基线。 将正常的对话或任务定义为基线，然后创建注入特定故障的变体。agent-chaos 框架很好地模拟了这一点：你定义带有预期工具调用和响应的基线场景，然后创建在特定点注入故障的变体——在一定数量的调用之后、针对特定工具或随机注入。

可组合的故障注入。 真实的生产故障不会一次只来一个。你的地理编码 API 超时的同时 LLM 运行缓慢，而用户在第一个任务完成之前发送了后续消息。孤立地测试单个故障会给你一种虚假的安全感。你需要组合故障——将 LLM 速率限制与工具超时结合，并验证 Agent 是否能优雅地处理两者。使用随机故障组合进行模糊测试有助于发现你没有预料到的故障模式。

轮次级粒度。 对于多轮 Agent 交互，你需要精确控制故障发生的时间。第一次工具调用时的超时与第五次时的超时产生的行为非常不同。早期故障可能导致 Agent 完全放弃其计划。后期故障可能导致它交付部分正确的结果而不标记缺失的内容。你的框架应该允许你在特定轮次、特定工具调用之后或特定数量的 LLM 调用之后注入故障。

语义断言，而不仅仅是状态检查。 传统混沌工程检查系统是否保持运行。Agent 混沌工程必须检查系统是否保持正确。这意味着使用 LLM-as-judge 评估、真值比较和输出分布监控。关键断言包括：Agent 是否承认了故障？它是否适当地重试了？它是否编造数据来填补空白？它是否完成了所有必需的步骤还是默默跳过了一些？

数据告诉我们什么

ReliabilityBench——第一个将混沌工程原则系统地应用于 LLM Agent 评估的工作——产生了一些违反直觉的结果。

更简单的架构更具韧性。 ReAct Agent 从故障中成功恢复的比率为 80.9%，而 Reflexion Agent 为 67.3%。本应帮助 Agent 从错误中恢复的自我反思机制实际上放大了故障影响。Reflexion 在中等故障注入下显示 10% 的退化，而 ReAct 为 7.5%。更多的组件意味着更多可能出错的地方。

成本-可靠性权衡是真实的，但不是你预期的那样。 GPT-4o 的成本是 Gemini 2.0 Flash 的 82 倍，但可靠性差异仅为 0.6%。通过使用更昂贵的模型来解决问题并不能按比例提高容错能力。架构和错误处理比模型的原始能力更重要。

瞬态故障是可管理的；速率限制不是。 瞬态超时以 98.75% 的成功率被相对良好地处理。但速率限制——最常见的生产故障——造成了最大的损害。这表明指数退避重试对间歇性故障相当有效，但持续的不可用性需要根本不同的处理方式：备用模型、缓存结果或优雅降级到更简单的能力。

性能下降会复合。 基线性能 96.88% 在中等扰动下降至 88.12%——下降了 8.8%。在每个步骤都依赖于前一个步骤的多步骤 Agent 中，这种每步退化会复合。如果每一步的成功率为 90%，而你的任务有 7 个步骤，则端到端成功概率仅为 48%。

实用故障注入检查清单

如果你从零开始，以下是每单位努力产生最多洞察的操作顺序：

• 从工具超时开始。 它们是最常见的生产故障，也是最容易注入的。将工具的响应时间设置为 30 秒，看看你的 Agent 会做什么。它会等待？重试？放弃？还是编造？
• 注入部分 LLM 响应。 在句子中间截断模型的响应。你的 Agent 是检测到截断还是将片段视为完整？
• 返回格式错误的工具数据。 发送带有缺失字段、错误类型或预期有数据但实际为空数组的 JSON。检查 Agent 是否在使用之前进行验证。
• 在多步骤计划中模拟速率限制。 在 7 步中的第 4 步对 Agent 施加 429。它是从中断处恢复、从头开始，还是默默跳过剩余步骤？
• 组合故障。 将缓慢的 LLM 与工具超时结合。添加任务中途的用户中断。同时堆叠三件出错的事情，看看 Agent 的推理在哪里崩溃。
• 运行长对话。 20 轮以上并散布故障。检查 Agent 对其原始指令的遵从是否随时间退化。

关于 Agent 可靠性的残酷真相

大多数团队从客户 bug 报告中发现其 Agent 的故障模式。在演示中 95% 的时间运行良好的 Agent 在生产中有 30% 的时间会失败，因为生产环境有工具延迟、速率限制、过期缓存，以及不遵循理想路径的用户。

Agent 的混沌工程不是要让 Agent 变得完美。而是要确切地知道它们如何失败，以便你可以建立正确的护栏。一个检测到工具超时并说"我无法完成此步骤——以下是我目前拥有的"的 Agent，比一个默默编造缺失部分的 Agent 更有用。

工具正在成熟——agent-chaos 等框架提供可组合的故障注入，ReliabilityBench 提供压力下的标准化评估，研究正在产生关于哪些架构能在故障中存活、哪些不能的具体数据。差距不在工具上，而在实践上。今天构建 Agent 的大多数团队从未测试过当事情出错时会发生什么。从那里开始。