AOI: Turning Failed Trajectories into Training Signals for Autonomous Cloud Diagnosis

本文提出了 AOI（自主运维智能）框架，通过结合基于 GRPO 的本地化诊断系统、读写分离的安全执行架构以及失败轨迹闭环演化机制，在保障数据安全与执行权限的前提下，将失败轨迹转化为训练信号，显著提升了大模型代理在自动运维任务中的诊断成功率与泛化能力。

要点

这篇论文介绍了一个名为 AOI（自主运维智能）的新系统。简单来说，它是一套专门用来帮大型科技公司（比如云服务商）自动“修电脑”和“查故障”的 AI 团队。

为了让你更容易理解，我们可以把整个系统想象成一家顶级的“医院急诊部”，专门治疗生病的服务器集群。

🏥 核心背景：为什么我们需要 AOI？

现在的云系统太复杂了，就像一座巨大的、由无数零件组成的精密机器。一旦机器坏了（比如网站打不开、数据丢了），传统的做法是叫人类专家（SRE 工程师）来修。但专家太累了，而且反应不够快。

于是，人们想用 AI（大语言模型）来自动修机器。但是，直接让 AI 动手有两个大麻烦：

1. 不敢乱动：AI 如果手滑删错了文件，整个公司可能瘫痪。
2. 学不会：如果 AI 第一次修失败了，它往往就“死机”了，不知道下次该怎么改，因为失败的数据通常被当作垃圾扔掉。

AOI 就是为了解决这两个问题而生的。

---

🛠️ AOI 的三大“独门秘籍”

AOI 不像是一个单独的超级 AI，它更像是一个分工明确的医疗团队，由三个角色组成：

1. 读写的“物理隔离”：医生、护士和药剂师

在传统的 AI 修电脑时，它既负责“诊断”（看哪里坏了），又负责“开刀”（执行修复命令）。这就像让同一个医生既负责检查病情，又负责直接动手术，一旦判断失误，后果不堪设想。

AOI 把这两个动作彻底分开了：

• 探针（Probe，像护士/检查员）：只负责看和听。它可以去查日志、看状态，但绝对没有权限修改任何东西。
• 执行者（Executor，像药剂师/手术刀）：只负责动手。但它很谨慎，必须等到“探针”收集了足够的证据，并且由“观察者”确认无误后，它才能执行修复命令。
• 观察者（Observer，像主治医生）：它是大脑。它看着护士（探针）带回来的报告，分析病情，决定下一步是继续检查还是让药剂师（执行者）动手。

比喻：这就好比核反应堆的控制室。操作员（观察者）可以查看所有仪表数据，但只有经过严格审批后，才能按下那个红色的“紧急停止”按钮。这种设计确保了 AI 即使犯了错，也只会停留在“思考”阶段，不会真的把系统搞坏。

2. 把“失败”变成“教材”：失败轨迹进化器 (The Evolver)

这是 AOI 最聪明的地方。
通常，如果 AI 修错了，我们只会说“这次失败了”，然后扔掉数据。但 AOI 有一个特殊的进化器。

• 它的逻辑是：失败并不是毫无价值的。如果 AI 修错了，说明它离成功只有一步之遥，或者它找对了病根但开错了药。
• 它的做法：进化器会把这些“失败的病例”拿回来，像一位老专家一样，仔细分析哪里错了，然后生成一个“修正版”的剧本。
• 结果：下次遇到同样的问题，AI 就会拿着这个“修正版剧本”去尝试。

比喻：想象你在学骑自行车。

• 普通 AI：摔倒了，爬起来，继续乱骑，下次还摔。
• AOI 的进化器：你摔倒了，旁边有个教练（进化器）立刻把你扶起来，指着刚才摔倒的地方说：“你看，刚才你转弯太急，下次这里要慢一点。”然后让你拿着这个“修正建议”再骑一次。
  通过这种方式，AOI 把每一次“摔倒”都变成了宝贵的“训练信号”，让它越骑越稳。

3. 记忆管理：双时态记忆

修电脑往往需要很长时间，AI 容易“健忘”（忘了前面查了什么）。AOI 给 AI 设计了一种特殊的记忆法：

• 短期记忆：刚才这一分钟发生了什么（比如刚查了某个日志）。
• 长期记忆：整个看病过程中的核心结论（比如“怀疑是内存不够”）。
  这样，AI 既能关注细节，又不会在漫长的检查过程中迷失方向。

---

🏆 效果如何？

论文在 AIOpsLab（一个专门测试 AI 修电脑能力的排行榜）上进行了测试，结果非常惊人：

1. 没训练过就赢了：AOI 系统刚上线，还没怎么学习，就比以前的最先进方法（STRATUS）强了 24.4%。这证明了“分工隔离”的设计本身就很强大。
2. 小模型打败大模型：他们用的只是一个中等大小的开源模型（14B 参数），经过训练后，在解决新故障的能力上，竟然超过了目前世界上最强的商业模型之一（Claude Sonnet 4.5）。
   • 比喻：就像是一个经过严格特训的本地诊所，在解决特定疑难杂症上，比国际顶级医院的专家还要快、还要准。
3. 越挫越勇：通过“失败轨迹进化器”，系统把 37 个原本会失败的案例都转化成了成功的经验，让整体成功率又提升了近 5%，而且每次修的结果更稳定了（不再忽好忽坏）。

📝 总结

AOI 的核心思想就是：

1. 安全第一：把“看”和“做”分开，让 AI 在安全的环境下大胆尝试。
2. 变废为宝：不抛弃失败，而是把失败变成教材，让 AI 从错误中进化。
3. 小模型也能做大事：通过精妙的架构设计，让普通的 AI 模型也能具备专家级的运维能力。

这就好比给云系统配备了一支既谨慎又爱学习、还能从错误中快速成长的“机器人维修队”，让未来的互联网服务更加稳定、可靠。

技术摘要

这篇论文提出了一种名为 AOI (Autonomous Operations Intelligence) 的框架，旨在解决大型语言模型（LLM）代理在企业级站点可靠性工程（SRE）和云故障诊断中部署所面临的三大核心挑战：专有运营数据访问受限、权限管理环境下的不安全执行，以及封闭系统无法从失败轨迹中学习。

以下是该论文的详细技术总结：

1. 研究背景与核心问题

在现代化的云基础设施中，SRE 团队正寻求自动化以减少停机时间。虽然 LLM 代理展现了自动化潜力，但在企业实际部署中面临以下瓶颈：

• 数据隐私与安全：企业无法将敏感的专有运营数据暴露给外部模型，且必须依赖本地部署的小参数模型（通常 <100B），这些模型缺乏专家级的推理能力。
• 执行安全：现有的自动化方案往往混淆了“诊断（读）”和“修复（写）”权限，导致在不充分证据下执行高风险操作，可能引发级联故障。
• 学习闭环缺失：传统系统难以利用失败的诊断轨迹作为训练信号，导致模型无法从错误中进化，只能静态地依赖有限的专家数据。

2. 方法论：AOI 框架

AOI 将自动化运维转化为一个受安全约束的结构化轨迹学习问题，其核心由三个关键组件构成：

A. 多代理运行时架构 (Multi-Agent Runtime)

为了解决安全问题，AOI 采用了严格的读写分离架构，包含四个专用代理：

1. Observer (观察者)：核心协调者。负责维护诊断任务队列、分析压缩后的证据、更新假设，并决定下一步行动（探测、执行或提交）。它不直接与环境交互，仅基于压缩信息进行推理。
2. Probe (探针)：负责所有只读操作（如 kubectl get, logs）。它执行多轮探索，收集原始环境输出，但无权修改系统状态。
3. Executor (执行器)：负责写操作（修复动作）。它在执行前必须经过白名单过滤，且仅在 Observer 确认证据充分后触发。它遵循“最小权限原则”。
4. Compressor (压缩器)：将原始输出（如完整的日志）压缩为语义摘要，解决长上下文中的注意力退化问题，并为 Observer 提供高效的信息输入。

关键创新：通过架构强制分离“读”与“写”，确保在积累足够证据前不会进行状态变更，从而在保障安全的同时允许更激进的探索。

B. 基于 GRPO 的可训练诊断系统

为了提升本地小模型（14B）的能力，AOI 引入了 Group Relative Policy Optimization (GRPO) 进行微调：

• Observer GRPO：在步骤级别优化决策。利用成功轨迹（经 Purifier 去重后）作为训练数据，通过 LLM Judge 对每一步的决策（格式、摘要准确性、动作类型、推理质量等）进行打分。
• 优势：无需价值函数（Critic-free），利用组内比较（Group Relative）来优化策略，使小模型能够蒸馏出专家级的诊断逻辑。

C. 失败轨迹闭环演化器 (Failure Trajectory Closed-Loop Evolver)

这是解决“数据稀缺”和“从失败中学习”的关键机制：

• 功能：收集诊断失败的轨迹，利用 GRPO 训练一个演化器（Evolver）。
• 修复与增强：
  • 修复 (Repair)：将失败轨迹转化为修正后的诊断计划（Corrected Plans），作为结构化提示（Prompt）提供给 Observer，指导其重试。
  • 增强 (Augmentation)：从成功轨迹中生成多样化的诊断变体，扩充训练数据。
• 价值：将原本被视为噪声的失败案例转化为高价值的监督信号，实现了在封闭环境内的持续数据增强和分布优化。

3. 关键贡献

1. 架构创新：提出了 Observer-Probe-Executor 的多代理架构，通过严格的权限分离（读/写分离）解决了企业级部署的安全顾虑，同时允许系统在不破坏生产环境的前提下进行深度探索。
2. 训练范式：证明了通过 GRPO 微调，本地部署的 14B 开源模型（Qwen3-14B）可以在特定任务上超越前沿闭源模型（如 Claude Sonnet 4.5），且无需多轮采样。
3. 失败利用机制：设计了 Trajectory Evolver，成功将失败轨迹转化为修正信号。实验表明，这一机制不仅提高了最终成功率，还显著降低了运行间的方差（稳定性）。
4. 双时间尺度记忆：引入了长短期记忆机制，既保留了历史假设的连贯性，又控制了上下文长度，支持长周期的故障诊断。

4. 实验结果

在 AIOpsLab 基准测试（86 个真实云故障场景）上的评估结果如下：

• 架构优势 (Runtime Only)：

  • 未经任何任务特定训练的 AOI 运行时，在 best@5（5 次运行中至少一次成功）指标上达到 66.3%，比之前的 SOTA (STRATUS, 41.9%) 高出 24.4 个百分点。
  • 在检测（Detection）和根因分析（RCA）任务上提升尤为显著。

• 模型性能 (Observer GRPO)：

  • 经过 GRPO 微调的 14B 模型，在 63 个未见故障类型的测试任务上，avg@1（单次运行平均成功率）达到 42.9%，超越了未采样的 Claude Sonnet 4.5 (41.3%)。
  • 这表明小模型通过学习诊断策略（而非死记硬背），具备了强大的泛化能力。

• 演化器效果 (Evolver)：

  • 演化器成功将 37 个原本失败的轨迹转化为有效的诊断指导。
  • 结合演化器提示后，端到端的 avg@5 提升了 4.8%，同时运行间的方差降低了 35%（best@5 与 avg@5 的差距从 29.2% 缩小至 18.9%），证明了系统稳定性的显著提升。

• 权衡分析：

  • 研究发现，深度探索策略（GRPO 带来的）显著提升了检测（Detection）和根因分析（RCA）的能力，但在故障定位（Localization）任务上略有下降。这是因为过度探索可能导致在多异常场景下混淆根因，揭示了“探索深度”与“定位精度”之间的权衡。

5. 意义与影响

• 安全与能力的统一：AOI 证明了严格的安全约束（如读写分离）不仅不会削弱代理能力，反而通过强制证据积累机制，防止了盲目操作，从而提升了复杂任务的成功率。
• 小模型的崛起：通过架构设计和强化学习（GRPO），本地部署的小参数模型可以弥补与超大参数闭源模型在推理能力上的差距，为企业私有化部署提供了可行路径。
• 从失败中学习：打破了“失败即噪声”的传统观念，展示了如何将失败轨迹系统化地转化为训练信号，为构建自进化的运维智能体提供了新范式。
• 生产落地潜力：该系统设计考虑了企业环境的实际限制（数据隐私、权限控制、模型大小），为解决云原生环境下的自动化运维难题提供了具有高度实用价值的解决方案。

综上所述，AOI 通过架构安全分离、强化学习微调和失败轨迹闭环演化三大支柱，成功构建了一个安全、高效且具备自我进化能力的自主云诊断系统。