核心论点：稳定性不能靠"上线后祈祷"，要靠主动注入故障验证系统真能降级——混沌工程的本质是拿"稳态假设"去撞"真实故障"，撞不过就说明韧性是假的。

问题定义：AI Agent 混沌工程的特殊性

传统混沌工程注入网络延迟、杀节点。AI Agent 还多一类模型层故障：模型返回格式错乱、超时、限流、给出矛盾结论。这类故障频率高、影响隐蔽（不 500 但答非所问），却很少被写进混沌实验。

更特殊的是：降级路径本身可能没被测过。你说"模型挂了走本地兜底"，但没人真杀过模型，那条路径可能根本跑不通——这就是混沌工程要揭的"纸糊韧性"。

稳态假设：先定义"什么是健康"

上一节定了故障类型，动手前必须先定义稳态——系统正常时长什么样，才能判断注入后是否偏离。

Shop-Agent 的八维降级矩阵（见博客系列《降级矩阵与 Token 限流》篇）就是现成的稳态定义：最坏情况（Qwen 超时 + Milvus OOM + Redis 断连 + BGE 挂 + NebulaGraph 不可用）下，系统应退化到"本地小模型推理、无 RAG 直接回答"——不是完美答案，但不是 500。这条假设就是混沌实验的验收标准。

故障注入：从依赖到模型

按破坏面由外到内注入：

• 基础设施：Redis 断连（验证限流/历史/锁的降级，见《成本治理与限流》《分布式锁》篇）、Milvus OOM（验证无 RAG 兜底）。
• 依赖服务：订单/物流 API 超时（验证《工具调用部分成功》篇的并行降级）。
• 模型层：主模型限流/返回脏格式（验证《LLM 不确定性》篇的兜底与本地模型降级）。
• 网络：节点间延迟/分区（验证《Agent 间通信与协作》篇的任务接管）。

自动化实验与持续验证

混沌不是一次性演习，要常态化：

• 自动化实验：把故障注入写成可重复脚本（如用 benchmark/pipeline 脚本模拟各类退化），CI 或定时跑，防止"降级路径随重构悄悄坏掉"。
• 指标锚定：用追踪与监控体系（见《分布式追踪与可观测性》篇）观测注入期间的错误率/延迟，自动判断是否在稳态内。

实战：Shop-Agent 的混沌可演进点

Shop-Agent 当前没有独立混沌工程框架，但具备做混沌的底座：明确的降级矩阵（稳态假设）、各依赖的 Mock/Stub（如用 Mock API 模拟故障）、可观测链路。下一步是把"杀模型/断 Redis"固化成自动实验，持续验证八维降级真能兜住——把文档里的韧性变成可证伪的实验结论。

核心要点

• AI Agent 混沌多了"模型层故障"：格式错乱/超时/矛盾结论，高频且隐蔽。
• 动手前先定义稳态假设——Shop-Agent 的八维降级矩阵就是现成验收标准。
• 注入由外到内：基础设施→依赖服务→模型层→网络分区，逐层撞降级路径。
• 混沌要常态化自动化，用可观测指标锚定是否在稳态，防降级路径随重构悄悄坏。
• Shop-Agent 已有降级矩阵 + Mock/Stub + 链路底座，把故障注入固化成自动实验即可证伪韧性。