1. 这篇论文想解决什么问题这篇论文研究的是微服务系统中的根因分析问题也就是当线上系统发生故障时如何快速判断“到底是哪一个服务、哪一个组件、哪一种故障类型导致了问题”。在真实的大规模微服务系统中一个故障往往不会只表现为一个简单报错。它可能同时体现在指标异常、日志报错、调用链延迟、网络异常等多个地方。SRE 工程师排查这类故障时通常需要结合经验、监控工具、历史案例和系统架构知识一步步分析。严重故障甚至可能需要多个专家花几个小时才能定位。SRE站点可靠性工程师专职负责线上服务稳定性、故障排查、运维保障的技术人员。近年来LLM Agent 被引入 RCA 任务。它的好处是可以像工程师一样进行“思考—调用工具—观察结果—继续分析”并且能输出比较完整的诊断过程。相比传统深度学习 RCA 方法只给一个结果LLM Agent 的解释性更强。但论文指出直接使用 ReAct 这类通用 Agent 框架做 RCA 会遇到两个核心问题第一LLM 容易幻觉导致工具调用不合理。比如参数写错、调用了无关 API、根据不充分的信息过早下结论等。RCA 是一个链式过程前一步错了后面很容易一路错下去。第二RCA 中的观测结果往往具有多义性同一个现象可能对应多个合理的下一步操作。在 LLM Agent 做根因分析时每一轮都会经历“调用工具—获得观测结果—决定下一步动作”的过程。这里的“观测结果”可以是日志报错、指标异常、调用链异常也可以是某个工具返回的执行结果。问题在于这些观测结果通常不是单义的不能直接告诉 Agent 下一步一定该做什么。也就是说同一个观测结果背后可能对应多个排查方向。通 ReAct 框架的问题在于它采用的是 “Thought → Action → Observation” 的模式。模型每次看到观测结果后都要立刻选择一个动作执行。但在 RCA 这种复杂场景中下一步往往不是唯一确定的。如果模型过早选择了错误动作后续诊断路径就可能逐渐偏离真实根因。因此论文提出 Flow-of-Action一个基于 SOP 增强的 LLM 多智能体根因分析系统。它的核心思想不是让 LLM 自由发挥而是把 SRE 的标准排障流程显式整理成 SOP然后用 SOP 来约束和引导 Agent 的动作选择。SOPStandard Operation Procedure标准作业流程将SRE专家沉淀的故障排查经验、标准化诊断步骤整理为规范流程用于在关键节点约束LLM行为引导诊断走向正确方向。2. 论文提出的方法Flow-of-Action 是如何工作的这篇论文的核心方法叫Flow-of-Action。它可以理解为一种“带有标准排障流程约束的 LLM 多智能体根因分析系统”。普通 ReAct Agent 做 RCA 时基本流程是思考 → 选择一个工具动作 → 得到观测结果 → 继续思考这种方式看起来很自然但在根因分析场景中有一个明显问题RCA 不是简单问答而是一个复杂的排障过程。一次故障可能同时涉及日志、指标、调用链、服务状态、网络状态等多种信息。每得到一个观测结果后下一步该查什么并不总是唯一确定的。如果完全依赖 LLM 自己判断它很容易因为幻觉、经验不足或者上下文过长而选错工具导致后续分析方向逐渐跑偏。Flow-of-Action 的基本思想就是不要让 LLM 在复杂工具空间里自由发挥而是把 SRE 的标准排障经验整理成 SOP并让 Agent 在 SOP 的指导下进行 RCA。换句话说LLM 仍然负责理解、推理和决策但它不是“裸奔”的而是在 SOP、工具、历史案例和多个辅助智能体的共同约束下工作。2.1 Flow-of-Action 的整体流程Flow-of-Action 可以粗略理解为下面这条诊断链路告警输入 → 提取故障信息 → 匹配或生成 SOP → 将 SOP 转成可执行代码 → 执行代码收集观测结果 → 根据观测结果匹配历史故障 → 判断是否已经找到根因 → 如果没有找到则继续下一轮分析。这个流程看起来比较长但本质上是在模拟真实 SRE 的排障方式。真实工程师遇到故障时通常不会只凭一句报错直接下结论而是会先判断故障大类再找对应排查流程然后一步步检查指标、日志、调用链和系统状态。如果当前证据还不够就继续深入如果证据已经足够就输出根因。Flow-of-Action 把这个过程拆成了几个关键模块第一知识库负责提供 SOP 和历史故障案例。第二工具系统负责收集和分析指标、日志、调用链等运行数据。第三SOP Flow负责规定 Agent 应该如何使用 SOP。第四Action Set负责在多个可能动作中生成候选动作集合避免模型过早选错。第五多智能体系统负责分工协作让不同 Agent 分别承担动作规划、观测提取、代码生成和终止判断等任务。这几个模块不是彼此孤立的而是围绕同一个目标服务让 LLM Agent 的排障过程更稳定、更符合专家经验。2.2 知识库让 Agent 有经验可依赖Flow-of-Action 的知识库主要包含两类内容SOP 知识和历史故障知识。SOP 知识可以理解为“标准排障手册”。例如遇到网络延迟问题时应该先检查哪些指标再查看哪些调用链再确认哪些服务状态。每个 SOP 都包含名称和具体步骤。系统会把 SOP 名称向量化用于和当前故障信息进行相似度匹配。历史故障知识则相当于“过去发生过的故障案例”。很多线上故障并不是第一次出现而是过去问题的变种。因此如果当前观测结果和历史故障很相似系统就可以借助历史案例推断可能的故障类型。这部分设计的意义在于RCA 是一个强经验任务不能只靠 LLM 的通用知识。LLM 可能知道一些通用排障常识但它不一定了解当前系统的服务结构、工具接口、历史故障模式和企业内部排障规范。因此论文把 SOP 和历史案例显式放进知识库让 Agent 在推理时可以依赖外部经验而不是完全依赖模型参数中的泛化知识。2.3 工具系统把复杂监控数据转成可理解的观测结果在微服务系统中故障信息可能来自多种数据源例如指标、日志和调用链。问题是LLM 并不擅长直接处理复杂的时序曲线、调用链图或者 Kubernetes 原始状态。因此Flow-of-Action 并不是把所有原始数据直接丢给 LLM而是先通过工具进行处理。例如对指标数据系统会调用异常检测工具判断某个服务的 CPU、内存、流量或延迟是否异常对日志数据系统会调用日志查询工具从 Pod 中提取异常日志对调用链数据系统会分析异常 span 和服务调用关系对 Kubernetes 状态系统会调用专门的分析工具查询 Pod、Service 等对象的状态。这些工具会把原始数据处理成文本化的 Alert Report也就是 LLM 更容易理解的观测结果。这点很重要。Flow-of-Action 并不是用 LLM 替代所有传统运维算法而是让 LLM 负责“组织排障过程”和“解释诊断结果”至于底层数据分析仍然交给专业工具完成。2.4 SOP Flow让 SOP 从“文档”变成“可执行排障流程”SOP 是 Flow-of-Action 的核心。普通 SOP 只是文本比如“先检查服务状态再查看日志再分析调用链”。但如果只是把这段文本交给 LLM模型仍然可能漏掉步骤、误解步骤或者在中途被某个观测结果带偏。所以论文进一步提出了SOP Flow。它不是简单地把 SOP 存进知识库而是规定了 Agent 应该如何使用 SOP。SOP Flow 中有几个关键工具match_sop根据当前故障信息匹配最相关的 SOPgenerate_sop如果没有匹配到合适 SOP就让 LLM 生成新的 SOPgenerate_sop_code把 SOP 转换成可执行代码run_sop执行 SOP 代码得到新的观测结果match_observation根据观测结果匹配历史故障案例。整个过程可以这样理解系统首先根据当前告警信息判断应该使用哪个 SOP。如果已有 SOP 能匹配上就直接使用如果没有就让 LLM 根据已有 SOP 示例生成一个新的 SOP。接着系统不会让 LLM 一步步口头执行 SOP而是把 SOP 转换成代码再通过run_sop执行代码自动调用相关工具并收集结果。这一步是论文的一个重要亮点。因为自然语言 SOP 容易被 LLM 执行得不稳定而代码执行相对更确定。把 SOP 转成代码后多个诊断步骤可以被组织成一个整体执行减少 LLM 在每一步重新选择工具时产生的随机性。不过这个设计也有潜在风险。LLM 生成的 SOP 可能不够准确生成的代码也可能出错。因此论文中还设计了错误恢复机制如果 SOP Code 执行失败系统会重新匹配参数或重新生成代码。2.5 Action Set先列候选动作再选择下一步Flow-of-Action 相比 ReAct 的另一个重要改动是加入了Action Set。普通 ReAct 的流程是Thought → Action → Observation也就是说模型每次思考后都要立刻选一个动作。但 RCA 场景中同一个观测结果往往对应多个可能的下一步动作。例如系统返回 “Service name not found”。这句话表面上只是说明“服务名没有找到”但原因可能有很多可能是 SOP 文档里写错了服务名可能是 LLM 在生成 SOP Code 时写错了参数也可能是当前系统中确实不存在这个服务。此时下一步可以选择重新生成代码也可以重新检查 SOP也可以查询系统服务列表。多个动作都有一定合理性。如果让 ReAct 直接选择一个动作它可能因为单步误判走错方向。Flow-of-Action 的做法是先不要急着执行而是先生成一个候选动作集合。这个候选动作集合主要来自两个来源第一ActionAgent 根据当前状态、SOP Flow 和上下文生成若干可能动作并说明每个动作为什么合理。第二系统根据 SOP Flow 的规则补充一些必须考虑的动作。例如如果上一步刚刚生成了 SOP那么下一步通常应该考虑生成 SOP Code。此外JudgeAgent 还会判断当前是否已经找到根因。如果它认为证据已经足够就会把Speak这个动作加入 Action Set表示可以输出最终诊断结果。最后MainAgent 再从这些候选动作中选择一个最合适的动作执行。这样做的好处是模型不是“想到一个动作就立刻做”而是先把可能选项列出来再进行比较。它既保留了 LLM 的灵活性又通过 SOP Flow 限制了过度随机的工具调用。2.6 多智能体系统把复杂 RCA 任务拆给不同 AgentFlow-of-Action 并不是只使用一个大而全的 Agent而是设计了一个多智能体系统。它包括一个主智能体和多个辅助智能体。其中MainAgent是主智能体负责整体排障决策。它会综合当前上下文、工具返回结果、候选动作和其他 Agent 的建议决定下一步做什么。ActionAgent负责生成候选动作集合。它的任务不是直接决定最终动作而是帮助 MainAgent 列出当前比较合理的下一步选项。ObAgent负责从观测结果中提取关键信息。比如执行某个 SOP Code 后返回了大量日志、指标和调用链信息ObAgent 会帮助 MainAgent 判断其中可能暗示了什么故障类型或异常现象。JudgeAgent负责判断当前是否已经找到根因。RCA 过程不能无限进行下去所以需要一个 Agent 专门判断证据是否已经足够是否可以结束诊断。CodeAgent负责把 SOP 转换成可执行代码。它需要了解系统中有哪些工具以及如何把 SOP 步骤转换成工具调用逻辑。这个多智能体设计的意义不是“让多个 Agent 聊天”而是分工减负。RCA 任务太复杂如果所有事情都交给一个 MainAgent它既要理解观测结果又要规划动作又要判断是否结束还要生成代码容易出现遗漏和幻觉。拆成多个 Agent 后每个 Agent 只负责一个相对明确的任务整体过程会更稳定。从工程角度看这种多智能体设计比较务实。它不像一些 Multi-Agent 方法只是让不同角色互相讨论而是把 RCA 过程中的关键能力拆成了几个功能模块动作规划、观测理解、终止判断、代码生成和主决策。2.7 小结Flow-of-Action 的本质是什么综合来看Flow-of-Action 的本质不是简单地“用了多个 Agent”也不是简单地“用了 SOP”。它真正想解决的是如何让 LLM Agent 在复杂 RCA 场景中既能灵活推理又不至于乱调用工具、偏离排障流程。为了解决这个问题论文做了三层约束第一层是SOP 约束用专家排障经验指导 Agent 的整体方向。第二层是Action Set 约束每一步先生成候选动作再选择最终动作减少单步误判。第三层是多智能体分工约束让不同 Agent 负责不同子任务降低主 Agent 的认知负担。因此Flow-of-Action 可以看作是一个“半结构化”的 RCA Agent 框架。它不像传统工作流那样完全固定也不像普通 ReAct 那样完全自由而是在 SOP Flow 的引导下让 LLM 进行有边界的推理和工具调用。这也是这篇论文最值得借鉴的地方在运维根因分析这种高风险、强流程、强经验的任务中LLM 不应该被当成一个自由发挥的万能模型而应该被放进一个由 SOP、工具、历史案例和角色分工共同组成的诊断框架中。3. 实验设计与结果分析论文的实验部分主要回答三个问题Flow-of-Action 的整体效果是否优于已有方法Action Set 的大小会不会影响诊断效果Flow-of-Action 中各个模块是否真的有用这三个问题分别对应论文中的 RQ1、RQ2 和 RQ3。3.1 实验环境和数据集论文使用 GoogleOnlineBoutique 作为实验系统。这是一个典型的电商微服务系统包含多个服务常被用于微服务系统研究。作者将它部署在 Kubernetes 平台上并使用 Prometheus、Elastic、DeepFlow 和 Jaeger 分别收集指标、日志和调用链数据。为了构造故障数据作者使用 ChaosMesh 向微服务 Pod 中注入异常。故障类型一共有 9 类包括 CPU 压力、内存压力、Pod 失效、网络延迟、网络丢包、网络分区、网络重复包、网络包损坏和网络带宽限制。最终论文构造了 90 个故障事件。评价指标主要包括三个第一Root Cause Location Accuracy简称 LA表示根因位置定位是否准确。例如是否定位到了正确的 Pod、Service 或相关组件。第二Root Cause Type Accuracy简称 TA表示故障类型判断是否准确。例如是否判断出是 CPU 问题、内存问题、网络延迟还是网络丢包。第三Average Path Length简称 APL表示 Agent 完成一次诊断平均需要多少步。这个指标用来衡量诊断效率。APL 太大说明排障过程拖沓、工具调用成本高APL 太小也可能说明 Agent 过早下结论诊断证据不足。3.2 RQ1整体性能对比RQ1 主要回答Flow-of-Action 是否比已有方法更准确论文将 Flow-of-Action 与 K8SGPT、HolmesGPT、CoT、ReAct 和 Reflexion 进行了对比。结果显示Flow-of-Action 的整体效果最好。在 GPT-4-Turbo 作为基础模型时ReAct 的平均准确率为 35.50Reflexion 的平均准确率为 29.06Flow-of-Action 的平均准确率达到 64.01。这说明单纯使用 ReAct 这类“思考—行动—观察”框架并不能很好地解决 RCA 问题。原因在于 RCA 场景中工具多、观测复杂、诊断链路长Agent 很容易在中间步骤选错工具或产生幻觉。Flow-of-Action 的优势来自它对 ReAct 的改造。它不是让 LLM 自由选择工具而是引入 SOP Flow 约束诊断方向再用 Action Set 帮助模型从候选动作中选择下一步还通过多个辅助 Agent 分担观测提取、动作生成、代码生成和终止判断等任务。因此它的诊断过程比普通 ReAct 更稳定。K8SGPT 和 HolmesGPT 的效果较差主要是因为它们能访问的信息有限更多依赖 Kubernetes 元数据而 RCA 往往需要结合指标、日志、调用链和历史故障信息。CoT 虽然具备一定推理能力但缺少工具交互能力和流程约束所以在复杂 RCA 任务中表现也有限。Reflexion 在 ReAct 基础上增加了反思机制但如果前面的路径本来就是错的反思大量错误路径反而可能让模型更难得到正确结论。3.3 RQ2Action Set 大小的影响RQ2 主要回答Action Set 中候选动作的数量会不会影响 Flow-of-Action 的效果论文的实验结果显示当 Action Set 的大小发生变化时LA 和 TA 整体波动并不明显。这是因为 SOP Flow 中存在规则约束会保证一些关键流程动作被加入候选动作集合。不过准确率并不是随着 Action Set 变大而持续提升而是呈现“先上升、后下降”的趋势。也就是说适当增加候选动作有助于模型处理复杂场景但候选动作过多又会引入更多干扰选项使模型的决策变得不稳定。因此论文最终选择将 Action Set 的默认大小设置为 5。这个值可以理解为一种折中既为模型保留了足够的灵活性又避免候选动作过多导致决策混乱。3.4 RQ3消融实验RQ3 主要回答Flow-of-Action 中的各个模块是否真的有贡献论文通过移除不同模块来做消融实验包括去掉 SOP Knowledge、去掉 SOP Flow、去掉 Action Set、去掉 ActionAgent、去掉 ObAgent 和去掉 JudgeAgent。实验结果显示去掉 SOP Knowledge 后性能下降最严重平均准确率从 54.06 降到 15.39。这说明 SOP 知识是整个系统的核心。如果没有 SOPAgent 就失去了专家排障经验只能依靠 LLM 自己规划工具调用过程很容易退化成普通 ReAct。去掉 SOP Flow 后平均准确率降到 27.50尤其是根因位置准确率下降明显。这说明仅仅拥有 SOP 知识还不够关键是要让 Agent 知道如何按照 SOP 执行排障。SOP Flow 的作用就是把 SOP 从“静态文档”变成“可执行的诊断流程”。去掉 Action Set 后平均准确率降到 42.34。这个结果说明Action Set 能够帮助模型在复杂观测下更合理地选择下一步动作。不过去掉 Action Set 后 APL 也明显降低说明模型调用工具的步数减少了。这不一定是好事因为它可能意味着模型过早下结论诊断过程不够充分。去掉 ActionAgent、ObAgent 或 JudgeAgent 后性能也都会下降。这说明多智能体分工是有帮助的。ActionAgent 负责生成候选动作ObAgent 负责理解复杂观测结果JudgeAgent 负责判断是否已经找到根因。它们共同降低了 MainAgent 的负担使系统整体更稳定。3.5 实验部分小结总体来看论文的实验结果支持了三个结论。第一Flow-of-Action 的整体效果明显优于普通 ReAct、CoT 和 Reflexion说明在 RCA 这种复杂任务中仅靠通用 LLM 推理框架是不够的。第二Action Set 的大小需要适中。太小会限制模型处理复杂情况的能力太大又会引入过多随机性。论文选择默认大小 5本质上是在灵活性和可控性之间做折中。第三SOP 是 Flow-of-Action 中最关键的组成部分。消融实验表明去掉 SOP Knowledge 或 SOP Flow 后性能都会显著下降。这说明这篇论文真正有效的地方不是简单地堆叠多个 Agent而是用 SOP 把专家经验、工具调用和 LLM 推理组织成一个相对稳定的诊断流程。4. 总结这篇论文的核心贡献不是提出一个新的深度学习模型而是提出了一套更适合 RCA 的 LLM Agent 工程框架。它证明了在复杂运维任务中单纯依赖 LLM 自由推理是不够的必须引入专家 SOP、工具约束、候选动作集合、历史故障知识和多智能体分工。