大多数团队做混沌工程，跑过一次 GameDay、杀掉一个 Pod 就停了。原因不在工具——Chaos Mesh 五分钟就能装好——而在于设计一个好实验太繁琐：你得清楚服务的冗余结构、它承载的 SLO 是什么、对“稳态”的定义又是什么，然后把这些全部写下来。这是一件阅读加起草的活儿，恰好是语言模型擅长的。对生产注入故障，反而不是。

智能体只负责提议，不负责执行

这个混沌工程智能体负责挑选下一个值得运行的实验，并写出假设——它没有权限去执行。它通过只读工具读取每个服务的拓扑信息，包括副本数、PodDisruptionBudget、探针、上游依赖，以及 SLO 状态，然后从固定目录里提议一个 Chaos Mesh 实验：杀掉 checkout-api 的一个 Pod，给 checkout-api 到 payments 的调用增加 100 毫秒延迟，或者在一个副本上烧 CPU。提议里必须包含可证伪的假设和中止条件。人类批准后，运行器应用 CRD，一个确定性的看门狗在 SLO 燃烧率一动时就终止实验。模型手里从来没有持有任何具备写权限的 kubeconfig。

命名空间过滤是第一道边界

安装 Chaos Mesh 时必须开启命名空间过滤，这样它才会拒绝触碰任何你没有显式加入的命名空间。安装命令里要设置 controllerManager.enableFilterNamespace=true，然后只给智能体可能提议实验的命名空间打上注解，比如 checkout 和 catalog。这个注解是第一条爆炸半径边界，而且完全在智能体之外：一个针对 payments 命名空间的 PodChaos 无论谁创建，都会被控制器忽略。智能体自己的允许清单是第二道冗余检查——对于任何故意注入故障的东西，纵深防御才是正确姿态。

目录是代码，智能体只填空

模型从来不会自己写 YAML。它选择一个模板，提供少量有界参数，由包装器渲染出 CRD。三个模板就能覆盖大多数第一年的混沌项目：pod_kill_one 杀掉一个 Pod，模式固定为 one，绝不使用 all 或百分比，宽限期为零；upstream_delay 注入网络延迟，模式同样为 one。每个实验都带有最大持续时间限制，瞬时类实验直接设为零秒。这种设计把模型的输出空间压缩到最小，让它只能做选择，不能做创造。

为什么是“提议”而不是“执行”

把故障注入生产这件事，风险模型和生成文本完全不同。语言模型擅长阅读和起草，但把写权限交给它，等于把爆炸半径交给一个无法完全预测的系统。这个智能体的架构把决策权和执行权彻底分开：模型只负责把已知的冗余信息、SLO 状态和稳态定义整理成一个可审查的实验提案，人类批准后才进入执行链路。看门狗则保证即使实验跑起来，SLO 一旦出现异常燃烧，实验立刻被终止。整个设计里，模型离生产最近的一步，就是它写下的那几行假设。