企业官网建设流程全解析

STRATUS: A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds

状态: Finished
Publisher: NeurIPS
Publishing/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 Chen；Jiaqi Pan；Jackson Clark；Yiming Su；Noah Zheutlin；Bhavya Bhavya；Rohan Arora；Yu Deng；Saurabh Jha；Tianyin Xu
数据集是否开源: 开源
数据集链接: https://github.com/microsoft/AIOpsLab；https://github.com/itbench-hub/ITBench
机构（完整）: University of Illinois Urbana-Champaign；IBM Research；IIIS, Tsinghua University

读前先问

这篇论文要解决的不是“LLM 能不能看懂日志”，而是“一个会犯错的 AI，能不能安全地替线上系统做改变”。

1. 大方向的任务是什么？Task

自治 SRE（站点可靠性工程）：让 AI 自动完成云服务故障的发现、定位、根因分析和修复。

通俗地说：云服务像一座由很多小服务组成的城市。一个数据库连接异常，可能沿着调用链扩散成接口超时、页面打不开，最后变成整个平台不可用。传统做法依赖人工工程师轮流查看告警、日志、链路和指标，但云系统规模太大，人工很难一直跟上。

云服务故障为什么难处理

2. 这个方向有什么问题？是什么类型的问题？Type

这是一个高风险的连续决策问题。检测和诊断主要是“读”；缓解则要“写”，例如修改 Kubernetes 配置、重启服务、迁移节点或回滚部署。

如果 AI 的第一步判断错了，第二步可能会在更糟的状态上继续操作。因此，问题不只是准确率，还包括：

• 修复动作会不会引发新的故障？
• 失败后能不能恢复到原来的状态？
• 能不能判断“这次修复真的让系统变好了”？
• 多个 AI 是否会同时修改同一份资源？

3. 为什么会有这个问题？Why

过去的 AIOps 研究很多是在帮助人工工程师：汇总日志、预测根因、推荐排障文档。但自治 SRE 要更进一步：AI 不只是给建议，还要直接改变线上系统。

论文原意：对高风险系统而言，静态规则或提示词无法覆盖所有运行时副作用。一个动作当下看似合理，后续几步才可能暴露问题。

我的理解：作者真正研究的是“如何让一个不一定每次都猜对的 AI，仍然可以被允许行动”。

4. 作者是怎么解决这个问题的？How

论文提出STRATUS：由多个专门智能体组成，并由确定性的状态机控制它们的行动边界。核心安全机制叫Transactional Non-Regression（TNR，事务化无回退）。

把它想成“带撤销按钮的分阶段维修”：

• 先记住系统当前状态；
• 只执行一小段修复动作；
• 检查系统健康度；
• 变好或不变差就提交；
• 变差就撤销，再尝试另一条路径。

5. 怎么验证解决方案是否有效？

作者在 AIOpsLab 和 ITBench 两个自治云 / SRE 基准上测试 STRATUS，与 ReAct、Flash、AOL-agent、ITB-agent 等方案比较。指标包括成功率、时间、步数和成本，并专门做了“无重试”和“无回滚重试”的消融实验。

6. 实验结果怎么样？What

GPT-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 可以用一句话解释：

系统内部可以尝试，但系统对外不能变得比原来更糟。

一个事务包含三步：

1. 记录检查点：保存修复前的状态s_pre；
2. 执行一小段动作：得到修复后的状态s_post；
3. 健康度检查：
   • 如果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 自己完成排障并承担行动后果”。

这要求系统同时具备两种能力：

• 推理能力：理解复杂观测数据并提出修复计划；
• 安全能力：限制权限、记录检查点、验证结果并支持撤销。

创新点

1. TNR 安全规格：把事务、健康度量和回滚组合成可解释的 no-regression 约束。
2. 读写职责分离：检测和诊断只读，缓解负责写，撤销负责恢复。
3. 安全探索：允许智能体尝试多条路径，但失败路径不对外暴露为更坏状态。
4. 端到端闭环：从观测、定位、修复、验证到终止都有系统级控制。

一句话理解创新点：不是要求 AI 一开始就猜对，而是让 AI 猜错时也有机会安全地改正。

核心方法

STRATUS 的完整流程可以简化为：

观测 → 检测 → 诊断 → 规划 → 有界执行 → 健康度检查 → 提交 / 回滚 → 再尝试

这条流程在论文和代码里是一一对应的：

1. 检测 / 初始分析：先缩小搜索空间
   • 论文把检测、定位、RCA 和缓解拆开；代码里initial_analysis_task明确要求先调用GetFilteredTracesTool，先找出有异常的 service、component、Pod 或 node。
   • 这不是让模型一上来读所有日志，而是用链路把“可能有问题的实体”过滤出来，再把结果传给后续诊断任务。
2. 诊断：把提示词变成可复用的取证流程
   • agents.yaml的诊断提示词要求模型找出完整 fault propagation chains，并解释每个实体为何受影响；还明确提醒“错误通常向告警反向传播、流量下降可能向前传播”，避免把最显眼的告警误当根因。
   • 代码把 traces、logs、metrics、alerts 和 kubectl 查询分别封装成工具；任务提示词要求每次查询尽量只针对一个实体，复杂查询拆成多轮。这种限制减少了工具参数含糊和上下文污染。
   • 最终由DiagnosisJSONReportCustomTool把自然语言判断整理成结构化 JSON，方便缓解智能体消费，而不是让下一个 agent 重新猜测上一轮结论。
3. 缓解：让 LLM 负责计划，让工具负责执行
   • 缓解提示词不是要求模型直接输出 shell，而是先给出“具体、原子、可翻译成命令”的 remediation steps，再由NL2KubectlCustomTool转成单条 kubectl 命令。
   • 提示词中还规定：每一步都要说明上一步结果和当前动作；一个工具调用只处理一个实体；例如先查 service selector，再根据 selector 找 Pod，最后读取 Pod 日志。这些规则本质上是在降低动作粒度和误操作范围。
   • ITBench 路径还会先调用MitigationCustomTool生成计划，再把计划交给缓解 agent；AIOpsLab 路径则通过 benchmark 的 submission tool 和 oracle 检查结果。
4. TNR 执行器：把“可回滚”落实到每一个写动作
   • NL2KubectlCustomTool._run的顺序是：生成命令 → 确认以 kubectl 开头 → 检查命令类型 → server dry-run → 检查是否允许不安全命令 → 执行。
   • 对 create/delete/patch/scale/rollout 等会改变状态的命令，_gen_rollback_commands会生成逆操作；删除资源前先把 YAML 状态写入kubectl_states，随后把RollbackNode压入ActionStack。
   • RollbackTool逆序弹栈：命令型动作直接执行反向命令，文件型动作按资源依赖顺序重新 apply YAML。这样第二次尝试是在干净检查点上开始，而不是在第一次失败的残局上继续。
5. 健康度与重试：由 oracle 决定提交还是回滚
   • 代码里的GetAlertsOracle检查告警是否持续触发；WorkloadOracle通过 wrk2 请求是否出现非 2xx/3xx 来验证业务；ClusterStateOracle检查 Pod、PVC 等集群状态。AIOpsLab 还可以叠加额外 workload oracle。
   • StratusAgentBase.run在 validation retry 模式下把本轮结果、上轮思考和 oracle 发现的问题组合成previous_run，再交给下一轮 agent；dropout_threshold会定期清空旧思考，避免模型在错误路径上过拟合。
   • 论文中的 (K=20) 风险窗口对应代码里的“每次只推进有限动作、验证后再继续”的策略；它牺牲一些时间和成本，换取失败路径可撤销。

核心模块与性能贡献的判断

• 最关键的不是某个单独的 prompt，而是TNR 执行器 = dry-run + 回滚栈 + oracle + 有界重试这组组合。论文的 Table 3 直接印证了这一点：完整 STRATUS 成功率 69.2%，去掉重试降到 15.4%，保留重试但去掉 undo 只有 23.1%。
• 四类 agent 解决“谁负责什么”；状态机和写者互斥解决“什么时候能写”；动作栈与 oracle 解决“写错后怎么恢复、如何确认恢复”。这三层共同把“LLM 可能犯错”转化为“错误可以被发现并回收”。
• 代码中的提示词是流程约束，不是安全证明本身：真正的安全边界由命令分类、dry-run、状态快照、回滚栈和验证 oracle 强制执行。因此创新点与实现是匹配的，但也暴露出边界——不可逆的外部副作用、错误 oracle 或无法完整保存状态的资源，仍然不能被简单回滚覆盖。

实验分析

数据集和指标

• AIOpsLab：13 个缓解、32 个检测、28 个定位、26 个 RCA 问题；
• ITBench：18 个缓解问题；
• 模型：GPT-4o、GPT-4o-mini、Llama 3.3；
• 指标：成功率、平均时间、步数和美元成本。

主实验结果

GPT-4o 版本在两个缓解 benchmark 上表现最好，但需要更多步骤和更长时间。原因不是系统低效，而是它会在失败后安全回滚，再探索另一条路径。

TNR 消融结果

论文原图：Figure 5 重试次数分布

论文原图：Table 3 TNR 消融结果

论文中的真实数据是：

通俗结论：只增加“重试”不够；必须先回到干净的原始状态，再开始下一次尝试。

论文还观察到：

• 80% 以上的问题至少重试一次；
• 30% 以上的问题重试不少于五次；
• Detection 成功率明显高于 Localization 和 RCA；
• RCA 结果会受 benchmark 标签不互斥的影响。

下游任务

1. 可靠撤销是强假设：数据库、外部 API、消息和计费动作不一定能恢复。
2. 健康度量不完美：告警减少不代表所有业务风险都消失。
3. 串行写者影响吞吐：安全证明更简单，但并发处理能力下降。
4. 仿真环境与真实生产有差距：某些 benchmark 问题可以利用故障注入器的特殊行为。
5. 耗时和成本增加：安全探索需要更多动作、上下文和模型调用。
6. 实验规模仍有限：缺少长期生产运行、跨系统副作用和修复后稳定性的证据。

如果只记住一件事：STRATUS 不是让 LLM 永远不犯错，而是让错误被限制在可回滚、可观测、不可对外回退的小事务里。

FAQ

Q1：每一步措施的“故障程度”怎么量化？

论文用状态严重度 μ(s) 表示系统在状态 s 下有多糟。实现上不是一个单一传感器，而是把三类可观测结果组合起来：当前告警数量、SLA/业务请求违反数量，以及不健康节点带来的容量损失。每个事务开始时记录 μ(s_pre)，执行一小段动作后重新计算 μ(s_post)：若 μ(s_post) ≤ μ(s_pre)，事务可以提交；若变大，就调用撤销操作回到检查点。

论文在代码层面还把“是否彻底修好”拆成几个 oracle：告警是否清除、工作负载请求是否恢复且没有非 2xx/3xx、Pod/卷等集群状态是否健康。也就是说，严重度既用于 TNR 的“不变差”门槛，也通过多个 oracle 落成可执行的通过/失败判断。需要注意的是，这是一种工程化的代理指标，不等于完整刻画用户体验；论文也承认 oracle 和 benchmark 标签仍可能有歧义。

Q2：四个智能体是不是必须用四个不同的模型？

不是。论文和仓库都支持直接替换模型；四个 agent 的重点是权限和职责隔离，而不是模型异构。检测/诊断可以使用同一个只读模型，缓解和撤销也可以共享模型，但状态机仍要限制谁能写、谁能撤销。