混沌工程从支付到 AI Agent：三个假设改写，四条纪律照抄

本文基于 InfoQ 中文站 9 月 15 日发布的技术实践稿《在金融支付系统中实施混沌工程：来自企业级 ECS 部署的经验教训》整理与延伸，原文见 InfoQ 中文站。原文把某支付处理商在 ECS 上跑混沌工程踩过的三类 AWS 特有故障、四阶段推进流程、以及"审批优先"模式讲得很扎实。我们要做的不是复述这套支付方手册，而是把它拉到另一类越来越多的现场——AI Agent、批量推理、RAG 索引重建、Fine-tune 任务——看看这套手册哪些前提失效、哪些纪律仍然照抄不误。

原文最反常识的一句话

原文最值得单独拎出来的一句话不是任何配置参数，而是这句："实验可以干净利落地终止"是标准混沌工程的隐含假设，而支付系统在设计上违反了这个假设。

这句话为什么重要？因为 Netflix 那套 Chaos Monkey 手册在互联网技术圈流传了十几年，几乎所有介绍文章都默认它是通用的：注入延迟 → 观察 → 回滚 → 走人。但支付系统的实测数据把这个假设撕开了：Route 53 TTL 配 60 秒，实测故障转移用了 93 秒（JVM 默认 DNS 缓存 30 秒 + VPC 解析器缓存叠加），每秒 400 笔交易的场景下这 33 秒差量就是 3.7 万次错误请求；Spot 结算任务在第 58 秒被中断，导致 1.4 万笔交易卡在"结算已启动、下游未收到提交"的模糊状态，人工清账 6 小时。

中断实验的动作，救不回已经在飞行途中的交易。 这才是原文的核心观察。它不只适用于支付——任何带在飞状态的子系统都要重新审视这条隐含假设，AI 系统里这类子系统比大多数团队默认的多。

三个假设：AI Agent 团队一条都不成立

原文列了标准混沌手册在支付系统上违反的三个假设。把镜头切到 AI Agent 系统，三个假设同样一条都不成立——但失效的方式和支付方不一样，值得逐条重写。

假设一：实验可以干净停止。 LangGraph、AutoGen、Claude Agent SDK 这类多步 Agent 跑一半被中断，你面对的是什么状态？工具调用 A 完成、B 完成、C 正在跑第 3 分钟——这些副作用（数据库写入、第三方 API 调用、发出的邮件、扣掉的 token 配额）不会因为你 kill 掉主进程而回滚。批量推理 job 处理 100 万条数据到 40 万条被杀，恢复逻辑是"从头跑"、"跳过已完成"、还是"重试所有 pending"？如果你的 Agent 系统没有把这类"部分执行"当成一等公民设计过，那你和 2026 年初那家支付方一样，正在假装自己是无状态服务。

假设二：影响范围可以按实例比例算。 支付方的痛点是"10% 的任务"这个表述反映不了实际影响范围，因为一个批量结算任务虽然只是集群里的一小部分，却是几千笔交易的关键路径。AI 系统的痛点更隐蔽：大部分 Agent 都共享同一个 LLM 网关、同一份 embedding 服务、同一个 RAG 索引。你随机停 10% 的 pod 什么事都没有，但把 embedding 服务的响应延迟从 100ms 推到 3s，全系 Agent 立刻集体退化——不是"10% 出错"，而是"100% 变慢"。按实例算影响范围会得到一个非常好看的报告，然后在真出事的那天完全失效。

假设三：混沌实验可以在生产环境自由运行。 支付方受制于 PCI DSS 和 SOC 2。AI 系统的约束换了名字但没变宽：上游 API 的配额和成本。你想在生产 Agent 上跑一次"OpenAI 网关注入 30% 5xx"的实验，先算算这一小时会烧掉多少 token 重试预算；你想模拟 Anthropic 全线降级到 Claude Haiku，先想清楚下游客户的 SLA 里有没有"模型质量"这条。原文那句"混沌实验会产生审计问题"，在 AI 场景里翻译成"混沌实验会产生账单问题和质量投诉问题"。

四条纪律：可以直接抄，但要换指标

原文给了四阶段推进 + 三条通用纪律，这部分反而几乎可以照单全收——但每一条落到 AI 系统时都要换一套指标。

纪律一：先定义稳态，不是模糊感觉。 支付方用的是"授权成功率 > 99.5% / P99 < 200ms / 未解决交易为零"这个三元组。AI Agent 系统的稳态三元组应该是**"任务成功率 + 首 token 延迟 + 每任务 token 花费"——只测延迟会漏掉"模型在悄悄退化到更便宜版本但延迟没变"的场景，只测成功率会漏掉"用了 3 倍 token 才完成一个任务"的成本失控。稳态定义不清就没法区分"实验发现"和"日常波动"，AI 系统的日常波动比支付系统大得多（同一个 prompt 不同天答案不同是常态），所以稳态基线必须用统计分布而不是单点阈值**。

纪律二：影响范围按业务风险打标，不按实例数。 支付方给 ECS 任务打 role=auth-primary / auth-secondary / audit-writer 标签，从 audit-writer 开始试。AI 系统直接对应：先动"评分类、日志类、离线报表类"Agent，再动"推荐辅助、内容标注"这类可降级 Agent，最后才碰"合同审核、客服对外应答、代码修改并合并"这类不可降级的核心链路。这个标签体系不是画出来的，是要落到 kubernetes label、Agent 元数据、告警路由里的——支付方那套 Terraform 配置里显式带了 role 标签，AI 团队要做的是同样的事。

纪律三：书面回滚条件，自动触发。 支付方的书面回滚是"交易失败率超过阈值或未解决状态超过 X 分钟"。AI 系统的等价物是"任务失败率超阈值 / 单任务 token 花费超基线 3 倍 / 出现关键词黑名单"。——不能等值班工程师人工判断。AI 系统这里有个新增困难：。一个 Agent 开始给出格式对但内容错的回答，你的监控可能什么都看不到。所以书面回滚条件里必须包含（LLM as judge、正则检测、embedding 相似度对比历史优质回答），这一层如果没建，混沌实验的自动回滚就是空的。