Agent 的演练日：排演那些无法复现的故障

传统的混沌工程建立在一个默认的假设之上：如果你两次注入同样的故障，你会得到两次同样的失败。停掉 pod，观察故障转移，修复漏洞，再次停掉 pod 以进行确认。整个学科——假设、爆炸半径、稳态指标——都假定系统具有足够的确定性，使得实验是可重复的。

智能体系统从根本上打破了这一假设。在智能体运行过程中注入工具超时，模型会重新规划路径——有时它会重试，有时它会换一个工具，还有时它会自信地编造一个从未获取到的结果。针对相同的提示词运行相同的故障，你最终会得到不同的轨迹，因为故障路径是通过一个随机规划器（stochastic planner）运行的。上周二你在生产环境中看到的故障永远不会以完全相同的形式再次发生。而这恰恰就是你必须对其进行演练的原因。

领悟到这一点的团队不再询问“我们能否复现该事件？”，而是开始问一个更好的问题：“当这类故障发生时，我们的员工和工具是否做出了正确的反应？”对于这个问题，SRE 领域有一个老练的答案——演练日（game day）——但为智能体系统运行演练日需要重新思考你注入的内容、观察的内容，以及你实际想要产出的产物。

为什么当故障路径是随机的时，回放（Replay）会失效

在确定性服务中，事故会留下复现方案。事后分析会说“当缓存节点在写入爆发期间宕机时，回退路径会发生死锁”，你可以构建一个回归测试来永久锁定该行为。

智能体事故不会留下方案。它们留下的是分布中的一个样本。追踪记录显示，模型在收到搜索工具的 503 错误后，决定根据陈旧的上下文进行回答，并跳过了它通常执行的验证步骤。但这个决定是一个概率分支。在相同的 Temperature 下回放相同的上下文，模型可能有十分之九的情况会走安全路径。你的事故恰好是那第十次。

这对传统的可靠性实践有两个侵蚀作用：

• 回归测试腐化为虚假的信心。 你可以固定追踪并断言修复，但你只是在数千个轨迹空间中固定了一个。下一次事故会走一条你的测试从未覆盖的相邻路径。
• 事后分析的行动项偏向于具体细节。 团队会针对他们看到的具体编造行为、具体超时的工具或泄露的具体措辞添加防护栏。产生故障的分布本身并未改变。

针对基于大语言模型（LLM）的多智能体系统的混沌工程研究证实了从业者在追踪中看到的情况：最危险的故障是通信故障和智能体之间的连锁故障，正是因为它们最难追溯到源头，也最不可能以相同的形式再次发生。你无法通过回归测试来摆脱分布的影响。你只能构建一个团队和工具栈，来处理分布中可能出现的任何情况。这是一个演练问题，而不是复现问题。

注入什么：智能体系统的四类演练方案

演练日是一个预定的、有时间限制的练习，你在其中故意降级系统，并针对其运行真实的事故处理流程——相同的轮值人员、相同的仪表板、相同的升级路径。AWS Well-Architected 可靠性支柱多年来一直建议对基础设施进行此类操作。对于智能体系统，注入面有所不同。以下四类涵盖了大部分空间。

工具层故障注入。 这是与传统混沌工程最相似的方案：将智能体的工具调用封装在一个代理（proxy）中，该代理可以注入超时、429、500、慢响应，以及最有趣的——看起来合理但错误的结果。最后一点是智能体特有的变化。基础设施工程师担心工具宕机；智能体工程师更应担心工具返回陈旧记录，而模型将其编织成一个自信的回答。现在已经存在专门做这类拦截的智能体混沌开源工具，但演练日不需要太复杂：一个在一小时内使 20% 的检索服务调用失败的代理标志（proxy flag）就是一个完整的实验。

模型降级演练。 在演练中途静默地将智能体路由到较弱或较旧的模型，看看谁会注意到，以及如何注意到。这同时演练了两个真实的生产场景：供应商发生局部故障（brownout）导致你切换到备用模型，以及模型更新后出现的隐蔽质量回退。可怕的结果不是质量下降，而是发现当质量下降时，你的仪表板上没有任何变化。如果你的操作人员无法从外部区分旗舰模型和备选模型，那么你的监控也无法区分。

污染上下文场景。 在检索语料库中植入一个受污染的文档，在智能体记忆中植入一个错误的事实，或者在智能体读取的源中植入一条对抗性指令。然后观察它在被 (a) 检测到、(b) 追踪到它触达了哪些输出，以及 (c) 被清除之前，传播了多远。这种演练几乎总能暴露同样的缺陷：团队可以删除污染源，但没人能回答“过去 4,000 条响应中，哪些受到了它的影响？”这个答案需要追踪记录中的出处（provenance）信息，而你宁愿在周三下午发现这个缺失，也不愿在真实的污染事件中才发现。

人工介入演练。 触发本应传呼人工介入的条件——智能体即将执行不可逆操作、置信度低于阈值、需要按下停机开关（kill switch）——并计算人工端的响应时间。谁会被传呼？他们知道如何在不杀掉整个产品的情况下暂停智能体集群吗？停机开关是真的停止了正在运行的任务，还是仅仅阻止新任务的启动？运行过演练日的事故响应团队报告说，演练的价值集中在这里：在操作手册（runbook）中看起来没问题的流程，在人工计时执行时往往会崩溃。

每次演练日选择一类。结合使用看起来很周全，但会破坏信号——当一切都坏了的时候，你无法判断是哪个漏洞导致了哪次失误。

加载中…