AI Native 下的混沌工程：Agent 军团如何重新定义系统韧性验证

日常测试只能解决功能是否正确，但无法解决故障后能否自恢复

在专有云 IaaS 场景下，系统面临着节点掉电、磁盘故障、网络异常、GPU 掉卡等各类基础设施风险。这些故障不是可能会发生，而是“一定会发生”——关键在于系统能否在故障发生后自动恢复，而不影响业务连续性。

传统的混沌工程实践存在三个核心痛点：

• 前期 — 用例设计成本高：
  人工设计固定场景，重复劳动，经验散落在个人记忆中难以复用；真实故障往往是多场景叠加，人力无法穷举；各产品线各自为战，故障经验无法跨团队沉淀；故障实验缺乏随机性，难以覆盖真实的故障组合
• 中期 — 执行与诊断依赖人工：
  测试过程中数据采集不及时、不准确，难以获取全量准确数据；故障诊断高度依赖人工经验：手动查监控、读日志、判断根因，容易遗漏重要细节；恢复过程多次尝试，参与人多时协调困难，关联链路容易断裂
• 后期 — 分析缺失，结果难复用：
  缺乏完整的注入过程数据分析，关键细节容易遗漏；恢复过程难以形成标准化预案，无法复用到真实故障场景；人工恢复过程中的 hack 和临时方案无法沉淀为可复用的知识

与此同时，现有的混沌工程工具几乎都停留在“注入恢复”环节——注入后的观测分析、诊断定位、报告输出主要还是依赖人来操作，缺乏闭环。具体表现为：

• 数据监控和获取依赖人工或者编写脚本，耗时且难获取全量准确数据
• 数据依赖人工分析，遗漏重要细节
• 现存故障实验方案简单缺少可验证性，编排新的故障方案耗时耗力

这些痛点叠加起来，导致一个更深层的业务后果：韧性验证只能作为阶段性的专项演练存在，无法高频、常态化开展。 而故障不会等演练排期——真正的风险往往在两次演练之间的空档里，以线上事故的形式暴露给客户。验证频率上不去，系统韧性就始终是一个抽检结果，而非持续保障。

我们需要一种全新的范式：让 AI 驱动从触发到恢复的全链路闭环，而不是简单地用 AI 替代某个环节。 目标是让专有云 IaaS 产品具备故障后能否自恢复的自动化验证能力，从人工驱动升级为 AI Native 闭环。

对业务而言，这套系统的价值不在于“把一次混沌实验做得更快”，而在于把“系统故障后能否自恢复”这件事，从依赖专家经验的一次性人工判断，变成 可持续运行、可规模复制、可沉淀复用的平台能力。具体体现在四个层面：

高频、自动化的验证之所以重要，是因为它背后对应着两条真实的风险处置路径：

• 能修复的：定位并修复故障来源缺陷。
  高频验证会持续暴露系统在故障态、降级态、恢复态下的韧性缺陷，每发现一个可修复的根因，就通过工单闭环推动产品团队修复，从源头消除隐患。
• 暂时无法修复的：提前准备预案 + 全量客户排查，提前规避规模化风险。
  对于短期无法根治的架构性缺陷，提前沉淀标准化恢复预案；同时基于故障特征在全量客户环境中排查同类风险点，在问题规模化爆发前完成预警和处置，把“事后救火”变成“事前布防”。

单次验证闭环提效数十倍、人力从专职 SRE 全程投入降到仅做触发与确认。效率的数量级提升不只是省时间，更关键的是它让高频验证从奢望变成日常——只有当单次成本足够低，持续、大规模的韧性验证才具备可行性。

过去每次演练的用例设计、诊断思路、恢复手法都散落在个人记忆里，人一走经验就流失。平台把这些沉淀为结构化的故障用例库、诊断证据链和恢复预案，形成可复用、可传承的组织级韧性资产。

通过标准化的 Agent 接入协议，新产品接入像“插 USB 设备” 一样简单，平台无需为每个产品重写诊断、报告、编排逻辑。韧性验证能力得以从单个 IaaS 产品，快速复制到专有云的更多产品线。

明确了业务价值，接下来的问题是：为什么必须 AI Native，而不是用自动化脚本 + 传统混沌工具拼一套？因为混沌工程真正耗时的环节——方案生成、环境安全判断、异常观测、根因分析、恢复验证、报告闭环——都高度依赖上下文理解和专家经验，传统脚本只能解决“执行快一点”，却啃不动这些认知密集型环节。所以我们没有把 AI 当作一个辅助问答工具，而是把它放进混沌工程的核心链路，重新定义整条验证流程。

在动手之前，我们先定义了 AI Native 的三条硬性标准。这三条标准不是口号，而是方案设计和验收时的“北斗星”——任何一个环节是否达标，都回到这三条来检验。

落到可量化的验收目标上，就是：

• 替代人工执行与诊断：单 Case 全链路 0 人执行干预，人仅做触发与结果确认
• 大幅提升验证效率：单次闭环压缩到半小时以内
• 持续发现未知缺陷：主动发现架构韧性缺陷，而非被动暴露
• 闭环分析结果可复用：诊断报告完整覆盖注入全过程，恢复方案可沉淀为标准化预案

我们没有采用常见的单 Agent 方案，也没有直接在现有混沌工程工具上做自动化补丁，而是从头设计了一套多Agent 军团协作 + 自研 Harness 平台的架构。之所以选择多 Agent 而非单 Agent，核心原因有三：

• 混沌工程涉及注入、观测、诊断、报告、工单等差异很大的能力域，单一 Agent 的上下文窗口难以承载全部知识和工具；
• 多 Agent 天然支持分治和并发，每个 Agent 在独立上下文中执行，复杂度更可控；
• 多 Agent 架构允许不同团队各自负责自己擅长的 Agent（如产品团队负责诊断 Agent），实现真正的分布式协作。

整个系统围绕三个核心概念构建：

• Agent 军团
  多个 Agent 各司其职，按职责分为决策层、入口层、策略层、执行层、观测层、认知层、输出层、闭环层、知识层共九层，分层协作。每个 Agent 拥有独立的上下文窗口和工具集，避免单一 Agent 的认知过载
• 共享黑板
  这是 Agent 之间唯一的交互媒介。除指挥 / 哨兵 Agent 外，所有 Agent 通过黑板交换数据，互相不知道对方的存在。这种设计使得 Agent 之间完全解耦——可以随时增删 Agent 而不影响其他 Agent 的运行
• 双进化回路
  经验反馈回路（知识进化）+ AI 飞轮回路（权重进化），让系统不是静态的工具，而是越用越聪明的智能体

上层 — 触发与编排控制：多个触发来源（如 CICD等）经哨兵 Agent 统一归一化后，由指挥 Agent 基于状态机驱动全流程，并在关键节点执行安全闸门。框架层通过 Registry + 路由实现 Agent 的自动注册、心跳检活与统一路由——内部 Agent 走直接调用，外部 Agent 走 A2A 协议。

中层 — Agent 工作区：每个 Agent 配备三类能力，形成完整的能力三角：

• Tool（可执行工具）：Agent 能“做”什么，如执行命令、文件读写、黑板操作
• Skill（领域技能）：Agent 能“用”什么方法论，如异常检测算法、根因分析流程
• Knowledge（知识资产）：Agent 能“知”什么信息，如产品故障域定义、历史基准阈值

Agent 按归属分为两组：

• 内部 Agent（编排、执行、环境、报告、工单）：由平台开发维护，通过Dispatch 直调，直接读写共享黑板
• 外部 Agent（诊断、产品）：由接入的合作方 / 产品方独立部署，通过 A2A 协议交互

这种内外分离的设计，使得产品团队可以独立迭代自己的 Agent（如升级诊断算法），而不需要修改平台。

下层 — 基础设施层：六大模块横向支撑整个系统运行

• 工具层：环境注入执行器、文件操作等基础工具
• 监控与告警：通过 Skill 接入产品自有监控等
• 协作与工单：Bug 工单创建、查询、追踪全链路
• 知识平台：支持文档向量化 → MCP 语义检索输出
• AI 能力：主模型为 Qwen 系列，同时支持 OpenAI / Anthropic 双协议，上层 Agent 代码无感知切换
• 数据存储：Redis 为共享黑板基座

黑板是整个系统的“中枢神经”——所有 Agent 的输入输出、实验状态、诊断结论都通过黑板流转。基于 Redis Hash 实现，字段按职责分为四大类：

• 实验元数据：experiment_id、product_id、状态机当前状态、触发来源等
• 业务数据：product_profile、case_config、baseline 数据、流式采样结果等
• 输出与反馈：诊断结论、实验报告、action_recommendations、evolve_strategy 等
• 调试与审计：LLM 调用记录、Agent 执行轨迹、错误日志等

关键设计：Agent 之间互不知道对方的存在，只需要知道黑板的数据结构。 这意味着可以随时增删 Agent 而不影响其他 Agent。新增一个 Agent，只需要让它读懂黑板上它关心的字段，并将自己的输出写入约定字段即可。

并发安全方面，通过 Lua 原子写入 + 乐观锁（version 字段）保障多 Agent 同时写入时的一致性。当 version 冲突时，写入方自动重试，确保数据不会丢失或覆盖。

实时性方面，黑板支持 SSE 字段变更推送——任何字段被修改时，前端和订阅方 Agent 都能实时收到通知，无需轮询。同时通过按角色的读写隔离（Redis ACL），确保每个 Agent 只能写入自己负责的字段前缀，防止越权操作。

这是我们最核心的设计——9 个（目前）Agent 按职责分层，形成完整的故障验证闭环。之所以设计为多个Agent，是因为每个 Agent 的能力域差异很大：注入需要环境连接和进程控制能力，诊断需要监控分析和根因推理能力，报告需要结构化生成能力——这些能力很难塞进一个 Agent 的上下文窗口而不互相干扰。

每个 Agent 都通过 JSON 卡片（AgentCard）标准化暴露自己的能力，包括 capability_id、输入输出 Schema、安全等级和超时配置。这使得平台具备通过统一的协议调度和发现 Agent 的能力，而不需要硬编码的调用关系。

设计亮点：

• 权限分层：只有执行 Agent 拥有破坏性操作权限（环境变更），其他 Agent 只能读写黑板和文件，从工具层面防止误操作
• 内外分离：内部 Agent 通过 Dispatch 直调，低延迟、高可控；外部 Agent 通过 A2A 协议交互，支持跨团队独立部署和迭代
• 上下文隔离：每个 Agent 在独立上下文中执行，避免单一 Agent 上下文过长导致的 LLM 质量下降

一次完整的混沌工程实验，经历四个阶段。整个过程由指挥 Agent 基于状态机严格驱动，每个阶段转换都伴随安全闸门校验和黑板状态更新，前端通过 SSE 实时展示当前进度。

1. 阶段一：任务发起与编排，哨兵 Agent 接收触发事件（手动 / CICD Hook / 定时任务等）后，将其标准化为统一的触发事件结构，指挥 Agent 随即启动编排流程：
2. 阶段二：预检与监控，这个阶段的核心目标是 “确保注入环境是安全的”——避免在已经有问题的环境上叠加故障，导致不可控的影响。此时执行环境预检、基线采集，并做出最终预检决策（通过则进入注入阶段，失败则中止并返回详细错误信息）。
3. 阶段三：注入与恢复：这是整个实验的核心阶段——故障注入、实时观测、安全恢复，全程由 Agent 自主完成。
4. 阶段四：故障报告，实验结束后的分析和闭环阶段，全部由 Agent 自动完成——从根因分析到工单创建，无需人工介入。

实验完成后，指挥 Agent SSE 广播完成事件通知前端，并触发各 Agent 异步反思。

混沌工程最重要的原则是严格圈定故障范围，避免影响扩大——虽然是在研发环境故意制造故障，但是一旦失控后果仍较为严重（如影响其他产品研发调试等）。我们设计了三道递进式安全闸门，每一道都是决策点：

• 第一道：参数校验
  确保注入参数是真实的、范围是最小的、环境是可验证的。环境白名单硬规则不受任何开关控制，即使 LLM 判断通过也不能绕过。这道闸门的核心目的是防止在不该做实验的环境上做实验
• 第二道：安全预检
  破坏性操作白名单 + 双签确认，爆炸半径评估，黑名单检查。只有经过审批的故障类型 + 环境 + 产品三元组才能执行。这道闸门还会检查最大并发数、历史失败率等指标，确保实验风险可控
• 第三道：恢复判定
  注入后基于基线数据对比确认系统可安全恢复，防止在系统已经异常的情况下继续注入。恢复判定不仅检查注入目标的恢复状态，还要确认整个集群的健康度没有受到连锁影响

除了三道闸门，还有多层安全机制贯穿全流程：

• 破坏性操作:强制双签确认——执行 Agent 是唯一拥有环境变更权限的 Agent，其他 Agent 无法直接执行注入
• 安全逻辑：内嵌各 Agent 而非外挂模块（安全左移）——每个 Agent 在自身决策流程中就包含安全检查，而不是事后审计
• 紧急停止机制：随时可通过前端按钮或 API 调用取消进行中的任务
• 权限控制矩阵：不同层级的 Agent 拥有不同的工具权限，指挥 / 编排 / 报告等 Agent 只有文件读写和黑板操作权限，只有执行 Agent 拥有环境变更权限
• LLM 并发限流：控制并发 LLM 调用数，防止 API 429 限流导致系统不稳定
• 状态机严格校验：9 正常状态 + 1 异常状态（failed），任何活跃状态可转 failed，complete/failed 为终态，确保流程不会进入不可控状态
• 分派权限控制：通过配置 dispatch_rules.json定义每阶段可调度的 Agent 白名单，防止 Agent 在不该被调用的阶段被调用
• 操作人权限控制：通过接入内部权限控制，仅对特性人员开放操作权限

这是区别于传统混沌工程工具的核心差异化能力——两条回路进化的对象完全不同：一条进化知识（用例怎么编排更准），一条进化权重（哪些故障场景更值得反复验证）。

回路一：经验反馈回路 —— 让「用例知识」越用越准

1. 诊断 Agent 完成根因分析后，输出正常 / 疑似缺陷 二态判定，附带完整证据链
2. 产品 Agent 依据判定结果，决定该次实验方案是否有价值 → 写入用例库
3. 下一轮实验发起时，编排 Agent 优先从用例库扫描匹配用例，命中则直接复用注入/恢复命令和监控配置，未命中才回退到 LLM 模板生成
4. 进化效果：随着实验轮次增加，用例库覆盖的故障场景越来越多，命中率持续提升，方案生成从现场生成逐渐变为检索复用

回路二：AI 飞轮回路 —— 让「编排策略权重」越用越精

1. 报告 Agent 生成实验报告时，附带结构化的行动建议（如建议创建工单）
2. 工单 Agent 据此创建 Bug 工单，并持续跟踪该缺陷的修复进度和结果
3. 修复结果回传给编排 Agent：如果确认是真实缺陷且修复生效，说明这类故障场景验证价值高；如果是误报或已知无效注入，说明验证价值低
4. 编排 Agent 据此调整不同故障类型/参数组合的编排权重
5. 进化效果：低价值场景（误报、重复无效注入）权重下降、逐渐被抑制，高价值场景（真实缺陷高发区）权重上升、被更频繁验证，编排决策逐轮向高发现率收敛。

另一个重要设计理念是 “新产品接入应该像插 USB 设备一样简单”。传统混沌工程工具每接入一个新产品，都需要定制 attack 定义、监控适配、报告模板等大量工作。而在我们的架构中，产品接入被分解为两个角色的标准化工作：

产品接入方 — 聚焦A2A能力实现：

1. 定义 AgentCard：编写标准化的能力声明 JSON，包含 Agent 名称、描述、所有 capability（含输入输出 Schema、安全等级、超时配置）
2. 实现三个 HTTP 端点 + 业务逻辑：能力描述 GET /agent_card、JSON-RPC 2.0 调用 POST /api/{capability_id}、健康检查 GET /health
3. 心跳健康检查：注册后心跳保活
4. 产品 Agent 能力（领域知识）：如产品方有了自己的现成的 Agent，直接参考 A2A 协议接入平台即可；如无产品 Agent，需要实现产品 Agent 能力；

平台方 — 聚焦接入支撑：

1. Registry 注册 + Redis ACL 配置：为外部 Agent 创建专用 ACL 用户
2. 路由 + 白名单 + dispatch 规则：确保指挥 Agent 在正确阶段调用正确的外部 Agent
3. 监控适配：根据产品需求适配监控采集 Skill

核心原则：双方通过 A2A 协议 + 共享黑板实现解耦协作。产品方聚焦“能力实现”，平台方聚焦“接入支撑”，中间通过标准化协议衔接。

接入节奏：新产品接入时，产品方提供基础故障用例，包含注入 / 恢复命令和预期表现、监控等（可由产品方 Agent 生成），运营期通过 AI 飞轮持续积累，逐步扩大用例规模。

我们联合了存储团队进行工程共建，实现内外部Agent的故障注入实验流程闭环。自项目启动至今，已完成大量实验，覆盖单点故障、多点故障、网络异常、磁盘故障、服务故障等多种场景。

以下数据对比传统人工混沌工程流程与 AICP 平台的全链路自动化流程：

其中最关键的变化是人力投入的质变：过去每次混沌工程实验需要 SRE 全程参与——手动注入、盯监控、读日志、写报告、提工单，现在人只需要做两件事：触发实验和确认结果。同时截止文档发布，已经发现多条产品稳定性问题并向负责的产品团队提交了缺陷详情和复现方式。

目前平台还在持续进化中。

下表从六个维度对比了我们的方案与业界主流混沌工程工具（Chaos Mesh、ChaosBlade、Gremlin 等）的差异：

当前混沌工程平台已在存储产品上跑通了有限的端到端闭环，但这才刚刚开始。以下是我们正在规划和探索的方向：

• 智能记忆系统
  更智能的自动判断和知识沉淀，让系统不仅能记住 “做了什么”，还能理解 “为什么这样做” 和 “下次应该怎么做”。当前的知识回路已经实现了基础的案例入库和策略进化，但记忆和知识库的边界还需要进一步探索——哪些知识应该固化为 Agent 的长期记忆，哪些应该作为临时上下文在实验结束后清理。
• 运维场景拓展
  从故障注入扩展到升级等运维操作场景，支持多故障并行注入，验证运维操作的韧性。升级、迁移等运维操作往往比故障注入更复杂，涉及多步骤、长时长、多组件协同，AI Agent 军团在这些场景下的价值将更加显著。

迁移不是自动化，而是互补。 自动化意味着替代，互补意味着各自做不同的事。AI 并不是复制人类认知，它提供的是另一种能力：模式匹配、规模、速度。人类擅长的是问题界定、品味判断和伦理推理。这种不对称很重要。

在混沌工程领域，AI 不会替代 SRE 的经验判断，但它能把 SRE 从重复的 “注入 - 盯盘 - 写报告” 中解放出来，专注于更有价值的架构韧性决策。

把 AI 当成 “我会做的事它替我做”，那叫认知卸载，它适合语法、格式、记忆这类负担。但如果你把 AI 当成“我不再需要理解这件事”，那就变成了认知外包，危险也从这里开始。认知栈迁移保留的，正是这种差异化：让机器做机器擅长的，人类守住不能被外包的判断。

千问AI平台-为Agent而生，驱动AI生产力
扫描下方二维码，直达千问AI平台体验