STRATUS: A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds状态: FinishedPublisher: NeurIPSPublishing/Release Date: 2026年3月19日Summary: STRATUS 用检测、诊断、缓解、撤销四类智能体和状态机编排实现自治 SRE以 Transactional Non-Regression (TNR) 约束可回滚、无回退的修复事务让智能体能够安全探索并在 AIOpsLab 与 ITBench 上提升故障缓解成功率。Score /5: ⭐️⭐️⭐️⭐️Type: Paper链接: https://arxiv.org/abs/2506.02009代码是否开源: 开源代码链接: https://github.com/xlab-uiuc/stratus作者完整: Yinfang ChenJiaqi PanJackson ClarkYiming SuNoah ZheutlinBhavya BhavyaRohan AroraYu DengSaurabh JhaTianyin Xu数据集是否开源: 开源数据集链接: https://github.com/microsoft/AIOpsLabhttps://github.com/itbench-hub/ITBench机构完整: University of Illinois Urbana-ChampaignIBM ResearchIIIS, Tsinghua University读前先问这篇论文要解决的不是“LLM 能不能看懂日志”而是“一个会犯错的 AI能不能安全地替线上系统做改变”。1. 大方向的任务是什么Task自治 SRE站点可靠性工程让 AI 自动完成云服务故障的发现、定位、根因分析和修复。通俗地说云服务像一座由很多小服务组成的城市。一个数据库连接异常可能沿着调用链扩散成接口超时、页面打不开最后变成整个平台不可用。传统做法依赖人工工程师轮流查看告警、日志、链路和指标但云系统规模太大人工很难一直跟上。云服务故障为什么难处理2. 这个方向有什么问题是什么类型的问题Type这是一个高风险的连续决策问题。检测和诊断主要是“读”缓解则要“写”例如修改 Kubernetes 配置、重启服务、迁移节点或回滚部署。如果 AI 的第一步判断错了第二步可能会在更糟的状态上继续操作。因此问题不只是准确率还包括修复动作会不会引发新的故障失败后能不能恢复到原来的状态能不能判断“这次修复真的让系统变好了”多个 AI 是否会同时修改同一份资源3. 为什么会有这个问题Why过去的 AIOps 研究很多是在帮助人工工程师汇总日志、预测根因、推荐排障文档。但自治 SRE 要更进一步AI 不只是给建议还要直接改变线上系统。论文原意对高风险系统而言静态规则或提示词无法覆盖所有运行时副作用。一个动作当下看似合理后续几步才可能暴露问题。我的理解作者真正研究的是“如何让一个不一定每次都猜对的 AI仍然可以被允许行动”。4. 作者是怎么解决这个问题的How论文提出STRATUS由多个专门智能体组成并由确定性的状态机控制它们的行动边界。核心安全机制叫Transactional Non-RegressionTNR事务化无回退。把它想成“带撤销按钮的分阶段维修”先记住系统当前状态只执行一小段修复动作检查系统健康度变好或不变差就提交变差就撤销再尝试另一条路径。5. 怎么验证解决方案是否有效作者在 AIOpsLab 和 ITBench 两个自治云 / SRE 基准上测试 STRATUS与 ReAct、Flash、AOL-agent、ITB-agent 等方案比较。指标包括成功率、时间、步数和成本并专门做了“无重试”和“无回滚重试”的消融实验。6. 实验结果怎么样WhatGPT-4o 版本的 STRATUS在 AIOpsLab 的缓解任务上成功率为69.2%9/13在 ITBench 的缓解任务上成功率为50.0%9/18相比第二名成功率约提升1.5 倍和5.4 倍。代价是更慢、更贵因为它会安全地多次尝试。论文的重点不是“每次都一次成功”而是“失败尝试不会把系统推入更坏的状态”。论文精读引言为什么自治修复比自动诊断难云系统故障频繁发生且服务之间存在复杂依赖。检测失败通常意味着“没发现问题”但缓解失败可能意味着“系统被修得更糟”。STRATUS 把自治 SRE 拆成四类工作检测从日志、链路、指标和系统状态中发现异常定位找出受影响的服务、Pod 或资源根因分析推测是配置、软件、硬件还是依赖问题缓解执行真正改变系统状态的动作。论文特别强调RCA 不一定是缓解的前置条件。很多故障可以先通过重启、迁移或回滚恢复服务再离线分析根因。通俗例子家里的路由器断网时你可以先重启让网络恢复不一定要先证明到底是 DNS、网线还是运营商线路出了问题。方法一四类智能体各司其职STRATUS 当前使用四个智能体STRATUS 的四类智能体检测智能体负责发现故障不能修改系统诊断智能体负责定位和 RCA仍然只读缓解智能体规划并执行写操作撤销智能体事务失败后按记录恢复状态。这种拆分还有一个重要作用状态机可以明确规定谁什么时候运行。检测和诊断可以读缓解和撤销是写者不能同时执行。我的理解多智能体的核心价值不是让几个 AI 聊天而是把权限、责任和安全边界拆开。方法二TNR 到底是什么TNR 可以用一句话解释系统内部可以尝试但系统对外不能变得比原来更糟。一个事务包含三步记录检查点保存修复前的状态s_pre执行一小段动作得到修复后的状态s_post健康度检查如果s_post的严重度不高于s_pre提交如果更糟调用撤销操作恢复s_pre。TNR 事务执行后提交或回滚论文把系统故障严重度记为 μ(s)它综合考虑告警数量、SLA 违反数量和不健康节点造成的容量损失。TNR 的安全要求可以用通俗语言表达为所有外部可见状态的严重度都不能超过最初故障的严重度。方法三为什么一定需要撤销和重试如果第一次修复失败但不回滚第二次修复就不是从原问题开始而是在“第一次失败留下的残局”上继续。失败后回到原点再尝试另一条路径STRATUS 依赖三个实现假设写者互斥同一时刻只有一个智能体可以修改系统可靠撤销每个允许执行的动作都有对应的恢复操作风险窗口有界一个事务不能无限执行论文实现中最多约 20 个命令。这也是论文的现实边界如果一个动作会发送不可撤回的外部消息、扣款、删除用户数据或者影响无法恢复的第三方系统那么简单的状态回滚就不够了。方法四状态机和工具如何落地论文原图中的控制流是检测 → 诊断 → 缓解缓解失败或需要恢复时进入撤销再回到缓解而不是让四个智能体自由并发。论文原图Figure 2 状态机控制流在代码仓库中这个控制流落在src/stratus/crew.py和两套 YAML 配置里而不是由 LLM 自己决定StratusCrew用 CrewAI 注册sre_diagnosis_agent、sre_mitigation_agent、sre_rollback_agent并把任务按“初始分析 → 诊断 → 缓解 → 撤销”串成上下文依赖AIOpsLab 与 ITBench 通过BENCHMARK切换工具集和任务配置。config/agents.yaml是角色级提示词诊断智能体被要求沿故障传播链反向追根因并按“链路 → Pod 状态 → 服务 → 事件 → 指标 → 日志”的顺序取证缓解智能体被要求每次只问一个实体、把复杂查询拆成原子步骤并在每一步写出“上一步得到什么、这一步要做什么”。config/tasks.yaml是任务级提示词诊断任务要求输出独立的 fault propagation chains 和每条链唯一的 root cause缓解任务要求先给 remediation plan再逐步执行撤销任务要求持续调用 rollback tool直到返回“没有更多可撤销动作”。NL2KubectlCustomTool是写操作的安全闸门自然语言先转成单条 kubectl 命令再做命令白名单/黑名单检查和 server dry-run若启用回滚栈就在执行前保存资源状态成功后把对应的RollbackNode压入ActionStack。ActionStack是线程安全的 LIFO 栈RollbackTool每次弹出最后一个动作按命令或保存的 YAML 恢复资源所以“撤销”不是让模型重新猜一条反向命令而是执行事先记录的逆操作。观测侧把 Grafana 告警、Prometheus 指标、Jaeger 链路和 Loki 日志分别封装成工具终止侧用告警清除、工作负载请求成功、集群状态健康等 oracle 组合判断是否真的修好。实践上可以把一次调用理解成下面这条链自然语言计划 → 单实体工具调用 → dry-run/约束 → 执行并记录逆操作 → oracle 验证 → commit 或 rollback → 反思后重试。因此STRATUS 的创新并不只在“用了四个 agent”而在于把提示词中的纪律要求、代码中的权限边界、动作栈和验证 oracle 叠成一条可审计的执行链。读后回顾动机传统 AIOps 解决的是“帮助人排障”STRATUS 解决的是“让 AI 自己完成排障并承担行动后果”。这要求系统同时具备两种能力推理能力理解复杂观测数据并提出修复计划安全能力限制权限、记录检查点、验证结果并支持撤销。创新点TNR 安全规格把事务、健康度量和回滚组合成可解释的 no-regression 约束。读写职责分离检测和诊断只读缓解负责写撤销负责恢复。安全探索允许智能体尝试多条路径但失败路径不对外暴露为更坏状态。端到端闭环从观测、定位、修复、验证到终止都有系统级控制。一句话理解创新点不是要求 AI 一开始就猜对而是让 AI 猜错时也有机会安全地改正。核心方法STRATUS 的完整流程可以简化为观测 → 检测 → 诊断 → 规划 → 有界执行 → 健康度检查 → 提交 / 回滚 → 再尝试这条流程在论文和代码里是一一对应的检测 / 初始分析先缩小搜索空间论文把检测、定位、RCA 和缓解拆开代码里initial_analysis_task明确要求先调用GetFilteredTracesTool先找出有异常的 service、component、Pod 或 node。这不是让模型一上来读所有日志而是用链路把“可能有问题的实体”过滤出来再把结果传给后续诊断任务。诊断把提示词变成可复用的取证流程agents.yaml的诊断提示词要求模型找出完整 fault propagation chains并解释每个实体为何受影响还明确提醒“错误通常向告警反向传播、流量下降可能向前传播”避免把最显眼的告警误当根因。代码把 traces、logs、metrics、alerts 和 kubectl 查询分别封装成工具任务提示词要求每次查询尽量只针对一个实体复杂查询拆成多轮。这种限制减少了工具参数含糊和上下文污染。最终由DiagnosisJSONReportCustomTool把自然语言判断整理成结构化 JSON方便缓解智能体消费而不是让下一个 agent 重新猜测上一轮结论。缓解让 LLM 负责计划让工具负责执行缓解提示词不是要求模型直接输出 shell而是先给出“具体、原子、可翻译成命令”的 remediation steps再由NL2KubectlCustomTool转成单条 kubectl 命令。提示词中还规定每一步都要说明上一步结果和当前动作一个工具调用只处理一个实体例如先查 service selector再根据 selector 找 Pod最后读取 Pod 日志。这些规则本质上是在降低动作粒度和误操作范围。ITBench 路径还会先调用MitigationCustomTool生成计划再把计划交给缓解 agentAIOpsLab 路径则通过 benchmark 的 submission tool 和 oracle 检查结果。TNR 执行器把“可回滚”落实到每一个写动作NL2KubectlCustomTool._run的顺序是生成命令 → 确认以 kubectl 开头 → 检查命令类型 → server dry-run → 检查是否允许不安全命令 → 执行。对 create/delete/patch/scale/rollout 等会改变状态的命令_gen_rollback_commands会生成逆操作删除资源前先把 YAML 状态写入kubectl_states随后把RollbackNode压入ActionStack。RollbackTool逆序弹栈命令型动作直接执行反向命令文件型动作按资源依赖顺序重新 apply YAML。这样第二次尝试是在干净检查点上开始而不是在第一次失败的残局上继续。健康度与重试由 oracle 决定提交还是回滚代码里的GetAlertsOracle检查告警是否持续触发WorkloadOracle通过 wrk2 请求是否出现非 2xx/3xx 来验证业务ClusterStateOracle检查 Pod、PVC 等集群状态。AIOpsLab 还可以叠加额外 workload oracle。StratusAgentBase.run在 validation retry 模式下把本轮结果、上轮思考和 oracle 发现的问题组合成previous_run再交给下一轮 agentdropout_threshold会定期清空旧思考避免模型在错误路径上过拟合。论文中的 (K20) 风险窗口对应代码里的“每次只推进有限动作、验证后再继续”的策略它牺牲一些时间和成本换取失败路径可撤销。核心模块与性能贡献的判断最关键的不是某个单独的 prompt而是TNR 执行器 dry-run 回滚栈 oracle 有界重试这组组合。论文的 Table 3 直接印证了这一点完整 STRATUS 成功率 69.2%去掉重试降到 15.4%保留重试但去掉 undo 只有 23.1%。四类 agent 解决“谁负责什么”状态机和写者互斥解决“什么时候能写”动作栈与 oracle 解决“写错后怎么恢复、如何确认恢复”。这三层共同把“LLM 可能犯错”转化为“错误可以被发现并回收”。代码中的提示词是流程约束不是安全证明本身真正的安全边界由命令分类、dry-run、状态快照、回滚栈和验证 oracle 强制执行。因此创新点与实现是匹配的但也暴露出边界——不可逆的外部副作用、错误 oracle 或无法完整保存状态的资源仍然不能被简单回滚覆盖。实验分析数据集和指标AIOpsLab13 个缓解、32 个检测、28 个定位、26 个 RCA 问题ITBench18 个缓解问题模型GPT-4o、GPT-4o-mini、Llama 3.3指标成功率、平均时间、步数和美元成本。主实验结果GPT-4o 版本在两个缓解 benchmark 上表现最好但需要更多步骤和更长时间。原因不是系统低效而是它会在失败后安全回滚再探索另一条路径。TNR 消融结果论文原图Figure 5 重试次数分布论文原图Table 3 TNR 消融结果论文中的真实数据是配置成功率平均时间成本完整 STRATUS69.2%811.9 秒0.877 美元无重试15.4%72.6 秒0.163 美元无回滚重试23.1%1221.5 秒0.929 美元通俗结论只增加“重试”不够必须先回到干净的原始状态再开始下一次尝试。论文还观察到80% 以上的问题至少重试一次30% 以上的问题重试不少于五次Detection 成功率明显高于 Localization 和 RCARCA 结果会受 benchmark 标签不互斥的影响。下游任务可靠撤销是强假设数据库、外部 API、消息和计费动作不一定能恢复。健康度量不完美告警减少不代表所有业务风险都消失。串行写者影响吞吐安全证明更简单但并发处理能力下降。仿真环境与真实生产有差距某些 benchmark 问题可以利用故障注入器的特殊行为。耗时和成本增加安全探索需要更多动作、上下文和模型调用。实验规模仍有限缺少长期生产运行、跨系统副作用和修复后稳定性的证据。如果只记住一件事STRATUS 不是让 LLM 永远不犯错而是让错误被限制在可回滚、可观测、不可对外回退的小事务里。FAQQ1每一步措施的“故障程度”怎么量化论文用状态严重度 μ(s) 表示系统在状态 s 下有多糟。实现上不是一个单一传感器而是把三类可观测结果组合起来当前告警数量、SLA/业务请求违反数量以及不健康节点带来的容量损失。每个事务开始时记录 μ(s_pre)执行一小段动作后重新计算 μ(s_post)若 μ(s_post) ≤ μ(s_pre)事务可以提交若变大就调用撤销操作回到检查点。论文在代码层面还把“是否彻底修好”拆成几个 oracle告警是否清除、工作负载请求是否恢复且没有非 2xx/3xx、Pod/卷等集群状态是否健康。也就是说严重度既用于 TNR 的“不变差”门槛也通过多个 oracle 落成可执行的通过/失败判断。需要注意的是这是一种工程化的代理指标不等于完整刻画用户体验论文也承认 oracle 和 benchmark 标签仍可能有歧义。Q2四个智能体是不是必须用四个不同的模型不是。论文和仓库都支持直接替换模型四个 agent 的重点是权限和职责隔离而不是模型异构。检测/诊断可以使用同一个只读模型缓解和撤销也可以共享模型但状态机仍要限制谁能写、谁能撤销。