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 的动作选择。
SOP（Standard 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：根据当前故障信息匹配最相关的 SOP；generate_sop：如果没有匹配到合适 SOP，就让 LLM 生成新的 SOP；generate_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 任务拆给不同 Agent
Flow-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.50；
- Reflexion 的平均准确率为 29.06；
- Flow-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 RQ2：Action 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 知识是整个系统的核心。如果没有 SOP，Agent 就失去了专家排障经验，只能依靠 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、工具约束、候选动作集合、历史故障知识和多智能体分工。