OpsMem：让故障诊断智能体同时记住”当前证据”与”历史经验”

论文：OpsMem: Dual-Memory Reasoning with Cross-Memory Resonance for Failure Diagnosis
作者：Yongqian Sun、Rongchen Gao、Yu Luo、Wenwei Gu、Shenglin Zhang 等
机构：南开大学、清华大学、华为技术有限公司
版本：arXiv v1，2026 年 7 月 13 日

在复杂软件系统中，故障诊断并不是一次检索或一次推理，而是一个持续变化的过程：智能体需要根据当前告警提出假设，调用工具收集指标、日志和系统快照，再依据新证据修正甚至推翻已有判断。

这类任务同时依赖两种信息：

  • 当前事件已经发现了什么、排除了什么；

  • 历史上类似现象通常对应什么故障、应该检查哪些方向。

OpsMem 的核心主张是：现有方法通常只能较好地处理其中一部分。Agent 推理方法关注当前诊断过程，却容易在长链路中发生上下文漂移、证据虚构和回溯失败；RAG 等知识增强方法能够引入历史经验，但通常只在查询时进行一次静态检索，无法随着诊断状态变化持续调整知识。OpsMem 因此将故障诊断建模为短期诊断状态与长期运维经验之间的动态耦合过程。(arXiv)

一、OpsMem 想解决的核心问题

传统 ReAct 式故障诊断可以形成“思考—行动—观察”的工具调用轨迹，但轨迹本身并不等于稳定的诊断状态。当交互轮数增加时，早期证据可能被遗忘，中间假设可能被误当成事实，已经被否定的方向也可能重新进入推理。

GoS 等方法通过显式维护症状、证据和假设，缓解了长程推理中的状态漂移问题。不过，仅有当前状态仍然不够。真实运维诊断通常依赖大量系统特定经验，例如某组指标组合意味着连接池问题，而不是一般意义上的资源过载。

另一类方法通过历史案例、SOP、运维文档或知识图谱增强诊断。但普通 RAG 往往以初始告警或当前查询作为检索入口，返回若干文本片段。随着新证据出现，早期检索结果可能逐渐失去相关性；与此同时，真正需要的经验也可能因为最初查询信息不足而没有被召回。(arXiv)

OpsMem 将上述问题归纳为三个挑战：

  1. 记忆表示：如何分别表示一次事件的动态状态和跨事件积累的运维经验；

  2. 记忆协调：如何根据不断变化的诊断状态激活对应经验；

  3. 记忆巩固：如何把已解决事件沉淀为新经验，同时避免噪声持续进入长期记忆。(arXiv)

二、总体架构：两种图记忆和一个诊断闭环

OpsMem 由四个主要部分构成：

  1. 短期记忆 Short-Term Memory，简称 STM；

  2. 长期记忆 Long-Term Memory，简称 LTM；

  3. 跨记忆共振 Cross-Memory Resonance，简称 CMR；

  4. 由双记忆共同约束的多智能体诊断与长期记忆巩固机制。

收到监控平台告警后，系统首先初始化 STM。当前 STM 随后触发 CMR，从 LTM 中激活与当前状态相关的故障模式、历史案例和诊断流程。

中央智能体根据 STM 与激活后的 LTM 制定检查计划，将任务分配给专家智能体。专家智能体调用指标、日志和 Shell 等诊断工具获取证据，并返回分析结果。中央智能体再把新证据、假设以及支持或反驳关系写回 STM。

如果当前证据还不足以支持某个根因，更新后的 STM 会再次触发 CMR。也就是说，OpsMem 并不是“检索一次知识，然后完成推理”，而是形成如下循环：

更新诊断状态 → 重新激活经验 → 规划检查 → 获取证据 → 修正诊断状态

当某个假设获得足够支持后，系统输出诊断结果；故障解决后，再将这次诊断中的可复用经验写回 LTM。(arXiv)

三、短期记忆：把诊断过程变成显式状态图

OpsMem 的短期记忆沿用了 GoS 的信念状态抽象，将当前故障的诊断状态表示为图：

Ms=(Vs,Es)M_s=(V_s,E_s)

节点主要分为三类：

节点类型 含义
Symptom 初始告警或已经观察到的异常症状
Evidence 通过指标、日志和命令等工具获得的证据
Hypothesis 当前候选根因或中间解释

边表示不同的诊断关系，包括：

  • derive：从症状或证据推导出新的判断；

  • refine：细化原有假设；

  • support：证据支持某个假设；

  • refute：证据反驳某个假设。

STM 的作用并不只是保存聊天历史，而是显式记录“目前知道什么、推断了什么、排除了什么”。随着工具调用持续进行，新的证据和中间分析不断写入图中。因此，即使诊断链路较长，系统仍可以围绕结构化状态而不是完整自然语言轨迹继续推理。(arXiv)

四、长期记忆：不是文档库，而是运维经验图

OpsMem 将长期记忆表示为另一张图：

Ml=(Vl,El)M_l=(V_l,E_l)

LTM 包含三类核心节点。

1. Pattern：故障模式

Pattern 是 LTM 的中心节点，表示一种典型故障模式。一个模式由若干标准化 Signal 组成，例如：

  • 内存使用率持续过高；

  • 数据库连接数接近上限；

  • 大量连接处于 Sleep 状态；

  • 请求量没有明显增长；

  • 应用出现连接超时。

单个 Signal 只是一个诊断线索，Pattern 则表示多个 Signal 之间经常共同出现的结构化关联。

2. Case：历史案例

Case 记录某个 Pattern 对应的具体历史事件。它提供过去发生过什么、最终根因是什么等案例级参考。

3. Procedure：诊断流程

Procedure 记录针对某个 Pattern 的检查步骤，例如应该查看哪些指标、执行哪些命令以及如何区分相近故障。

Pattern 通过带权边关联 Case 和 Procedure。因此，一个模式被激活后，不仅会返回相关历史案例，还会同步提供可执行的诊断方向。相比以文本片段为基本单位的 RAG，这种表示将“故障模式”“案例参考”和“检查流程”区分为不同层次。(arXiv)

五、跨记忆共振：OpsMem 最关键的机制

Cross-Memory Resonance 是 OpsMem 区别于普通知识检索的核心。它负责让当前 STM 中的症状和证据，持续激活 LTM 中对应的运维经验。

从论文给出的实现来看，“共振”并不是一种新的神经网络结构，而是由信号耦合、模式激活和记忆传播组成的状态感知图激活过程。(arXiv)

第一步：Signal Coupling，信号耦合

系统从 STM 中提取症状节点和证据节点，再使用 LLM 将这些内容规范化为 Query Signals。

随后，Query Signals 与 LTM 各个 Pattern 中的 Signals 进行语义匹配。论文实现使用 BGE-M3 生成向量，并以余弦相似度计算耦合程度。

对于某个 LTM Signal，其耦合分数取它与所有 Query Signals 之间的最大相似度。低于阈值的分数被设为零，剩余信号被视为已激活。论文实验将该阈值设置为 0.6。(arXiv)

这种设计意味着，长期记忆的激活依据来自 STM 中已经获得的真实观察，而不是智能体当前自由生成的假设。

第二步：Pattern Activation，模式激活

仅匹配到一个相似信号，并不足以说明整个故障模式成立。因此，OpsMem 将 Signal 级分数提升为 Pattern 级分数。

Pattern 激活同时考虑两个因素：

  • 已激活信号的平均耦合强度；

  • 已激活信号占该 Pattern 全部信号的比例。

第一个因素衡量当前观察与模式线索匹配得有多强，第二个因素衡量当前证据覆盖了多少模式特征。论文实现中，两部分采用相同权重，模式激活阈值同样为 0.6。(arXiv)

因此，OpsMem 不是看到一个“数据库连接高”就直接召回所有数据库故障，而是优先激活与当前多个证据共同匹配的模式。

第三步：Memory Propagation，记忆传播

模式被激活后，系统沿 LTM 中的带权边向关联节点传播激活分数，并据此选择最相关的 Case 和 Procedure。

三类信息承担不同作用：

  • Pattern 给出可能的诊断方向；

  • Case 提供历史事件参考；

  • Procedure 指导下一步应如何检查。

论文实现每次 CMR 保留排名前三的 Pattern、Case 和 Procedure。每当 STM 更新时，整个 CMR 过程都会重新运行，使长期记忆随诊断状态变化而变化。(arXiv)

这也是 OpsMem 与静态 RAG 最实质的区别：知识不是一次性附加到上下文，而是被当前诊断状态反复选择和刷新。

六、双记忆如何驱动多智能体诊断

当前 STM 和激活后的 LTM 子图会被序列化到智能体提示词中。每轮诊断包括四个阶段。

Plan

CentralAgent 根据当前状态和已激活经验制定一个或多个诊断任务，并选择对应的 ExpertAgents。

Acquire Evidence

ExpertAgents 调用指标、日志、Shell 等诊断工具，迭代收集观测结果。

Analyze

专家智能体分析工具返回的信息，形成简洁的诊断报告。

Update STM

CentralAgent 汇总专家报告，将新证据、候选假设及其关系写回 STM。

完成更新后，系统检查是否已经收敛。如果存在获得充分支持的假设，就输出根因；否则进入下一轮 CMR 和诊断。论文实验最多执行三轮，若仍未收敛，则返回支持度最高的候选假设。(arXiv)

从这一流程看，LTM 并不直接替代推理或直接给出答案。它的主要作用是影响“接下来检查什么”以及“如何解释新证据”；STM 则负责约束哪些判断已经被支持或否定。

七、长期记忆巩固：如何从已解决事件中学习

故障解决后，OpsMem 启动独立的多智能体记忆巩固模块。

首先，MetaAgent 总结完整诊断轨迹，并结合最终 STM 与本次激活的 LTM 子图进行反思。随后，它判断本次事件可能需要更新哪些类型的长期记忆，再调用 Pattern Agent、Case Agent 或 Procedure Agent。(arXiv)

每个记忆智能体执行两个主要阶段：

  1. Locate：在现有 LTM 中定位与当前事件相关的节点；

  2. Propose：根据诊断总结、最终 STM 和已有记忆提出节点级变更。

论文将节点操作简化为：

  • CREATE：创建新节点；

  • DELETE：删除过时节点。

当某个已有节点需要修改时，系统不是原地执行 UPDATE，而是删除旧节点并创建修订版本。

所有候选变更还需要经过 MetaAgent 审核，以过滤不合格更新。最后，Relation Synthesis 为通过审核的新节点建立关系边，将其连接到 LTM 中。(arXiv)

因此，OpsMem 的“自进化”不是更新模型参数，而是不断重构外部长期记忆图。模型本身保持不变，变化的是系统可以激活和复用的故障模式、历史案例与诊断流程。

八、实验设计

论文使用华为生产微服务系统中的 120 个真实故障事件进行评估。事件覆盖应用服务、资源管理、数据库和基础设施等类型。

每个事件包括：

  • 初始故障告警；

  • 时序指标；

  • 系统日志；

  • Shell 级系统快照；

  • 值班工程师在事后分析中确认的真实根因。

初始 LTM 来自运维访谈、调查问卷和运维文档，作者使用 GPT-5.4 辅助抽取 Pattern、Case 和 Procedure。用于评估的 120 个事件没有参与初始 LTM 构建。为保持公平，知识增强基线使用相同知识来源，只是以不同 RAG 结构组织。(arXiv)

论文选择三种 Seed LLM：

  • Qwen3.5-27B；

  • Gemma-4-31B；

  • GLM-4-32B。

基线分为两类：

类别 方法
Agent 推理 ReAct、GoS
知识增强 GoS + VectorRAG、GoS + GraphRAG、GoS + LinearRAG

评估采用 Qwen3.5-27B 作为 LLM Judge，将预测根因分成三级：完全匹配记为 2，相关但不完全匹配记为 1，否则为 0。

论文报告两个指标：

  • Match：得分为 2 的比例；

  • Relevant：得分至少为 1 的比例。

每个结果至少进行五次独立判断，再通过多数投票汇总，并使用专家抽样进行验证。(arXiv)

九、总体实验结果

Qwen3.5-27B

方法 Match Relevant
ReAct 20.83 49.17
GoS 30.83 55.83
GoS + VectorRAG 48.33 61.67
GoS + GraphRAG 53.33 71.67
GoS + LinearRAG 53.33 72.50
OpsMem 78.33 85.83

Gemma-4-31B

OpsMem 获得 63.33 的 Match 和 82.50 的 Relevant。对应最强基线分别为 56.67 和 79.17。(arXiv)

GLM-4-32B

OpsMem 获得 53.33 的 Match 和 77.50 的 Relevant。最强基线分别为 40.00 和 69.17。(arXiv)

综合三种模型，OpsMem 相比各自最强基线：

  • Match 提高 6.66 至 25.00 个百分点；

  • Relevant 提高 3.33 至 13.33 个百分点。(arXiv)

论文摘要中提到的最高 46.88% 和 18.39%，是相对增幅，而不是百分点增幅：在 Qwen3.5-27B 上，Match 从 53.33 提高到 78.33，绝对增加 25 个百分点，相对提升约 46.88%；Relevant 从 72.50 提高到 85.83，绝对增加 13.33 个百分点，相对提升约 18.39%。(arXiv)

实验显示，单纯引入知识已经能明显改善 GoS，但 OpsMem 在三种模型上都进一步超过了 RAG 版本。论文据此认为，性能提升不仅来自“系统拥有运维知识”，还来自知识能够随诊断状态变化被动态激活。(arXiv)

十、消融实验：哪部分最重要

论文在 Qwen3.5-27B 上分别移除不同组件：

方法 Match Relevant
完整 OpsMem 78.33 85.83
去掉 STM 45.00 63.33
去掉 LTM 30.83 55.83
去掉 CMR 56.67 68.33
去掉 LTM Consolidation 70.83 80.83

去掉 LTM 后下降最大，Match 从 78.33 降至 30.83，说明系统特定运维经验是 OpsMem 性能的重要来源。

去掉 STM 后，Match 降至 45.00，表明显式维护当前证据和假设对于长链路诊断同样重要。

保留两种记忆但移除 CMR，Match 为 56.67。这一结果说明，仅仅同时拥有状态和知识并不够，两者需要通过状态感知机制进行协调。

去掉长期记忆巩固的下降相对较小，但 Match 和 Relevant 仍分别下降至 70.83 和 80.83，表明持续写入新经验能够带来额外收益。(arXiv)

十一、OpsMem 是否真的能够“越用越好”

为了验证长期记忆巩固带来的持续改进，论文将 120 个事件按顺序分成四个窗口，每个窗口包含 30 个事件。

每次诊断完成后，完整 OpsMem 都会将经过审核的经验写入 LTM；对照版本则始终使用固定的初始 LTM。

相较于不进行长期记忆巩固的版本，OpsMem 在四个窗口中额外正确诊断的事件数量为：

事件范围 Match 增益 Relevant 增益
1—30 +0 +1
31—60 +3 +1
61—90 +1 +3
91—120 +5 +1

最后一个窗口获得了最大的完全匹配增益。论文将其解释为：早期事件中沉淀的经验能够在后续相似事件中被重新激活，使 LTM 随事件处理逐步演化。(arXiv)

不过，从表中也可以看到，收益并没有随窗口严格单调增长。OpsMem 展现的是“新经验可以被后续事件复用”，而不是每处理一个事件都会稳定提升整体性能。

十二、案例分析：从“连接数高”定位到连接池问题

论文展示了一个匿名化的 MySQL 故障案例。

初始 STM 中记录了：

  • MySQL 连接利用率达到 89.4%；

  • 应用日志出现数据库连接超时；

  • 入口流量略有增长；

  • 候选假设包括流量激增和慢查询。

根据这些状态，CMR 激活了两个长期记忆模式：

  1. Workload Saturation，工作负载饱和；

  2. Idle-Slot Occupation，空闲连接占用连接槽位。

CentralAgent 随后派出两个 DBA Agent，分别检查工作负载和连接状态。(arXiv)

工作负载方向得到的观测包括：

  • Threads_running 为 3；

  • QPS 约为每秒 82 次且基本平稳；

  • 慢查询日志没有命中。

这些证据削弱了流量过载和慢查询假设。

连接方向得到的观测包括：

  • Threads_connected 达到 135 和 151；

  • 约有 118 个连接处于 Sleep 状态；

  • 大量休眠连接集中来自同一应用用户。

这些证据支持“连接池问题导致大量空闲连接长期占用槽位”的判断。系统随后将新的支持和反驳关系写回 STM。(arXiv)

这个案例体现了 CMR 的具体作用：长期记忆没有直接宣布根因，而是把一个宽泛的“数据库连接率过高”拆成两个具有区分性的检查方向。智能体随后通过工具证据排除工作负载饱和，并支持空闲连接占用模式。

十三、如何理解 OpsMem 的主要贡献

OpsMem 最有价值的部分，不是简单增加了一个长期记忆模块，而是把故障诊断拆成了三个不同层次。

第一层是当前事件状态。STM 记录症状、证据和假设，使诊断过程不再完全依赖自然语言上下文。

第二层是跨事件经验。LTM 将经验拆分为故障模式、历史案例和诊断流程，而不是把所有信息都作为同质文本片段保存。

第三层是状态与经验之间的动态协调。CMR 根据当前已获得的证据激活模式，并在 STM 更新后重新计算激活结果。知识由此成为诊断循环的一部分，而不是一次性的提示词附件。(arXiv)

从这个角度看，OpsMem 可以被概括为：

以 STM 稳定当前诊断状态，以 LTM 保存跨事件运维经验，再通过 CMR 让经验随证据变化持续参与规划、取证和假设评估。

十四、论文仍未充分回答的问题

OpsMem 的实验结果较为明显，但论文当前版本只有六页，部分问题尚未获得充分展开。

首先，实验数据来自 120 个华为生产事件，数据集没有公开披露完整内容，因此外部读者难以独立验证不同故障类型、难度和重复模式的分布。(arXiv)

其次，主要评价指标由 LLM Judge 给出。论文使用多次判断、多数投票和专家抽样提高可靠性，但没有报告完整人工评估结果、评审一致性或不同 Judge 模型下的敏感性。(arXiv)

第三，论文使用固定的 0.6 信号阈值和模式阈值，每轮保留前三个 Pattern、Case 和 Procedure，诊断最多执行三轮，但没有给出这些超参数的敏感性实验。(arXiv)

第四，长期记忆巩固能够带来额外正确诊断，但论文没有进一步量化 LTM 随时间增长后的规模、重复节点、冲突经验、错误写入率以及检索成本。当前设计主要依靠 MetaAgent 审核候选变更来过滤低质量经验。(arXiv)

最后，论文主要报告诊断准确性，没有比较不同方法的工具调用次数、Token 消耗、诊断时延以及长期记忆维护成本。因此，现有实验能够说明 OpsMem 提高了诊断结果质量，但尚不能完整回答这种提升需要付出多少运行成本。(arXiv)

结语

OpsMem 将故障诊断中的两个关键对象明确区分开来：STM 负责保存当前事件中不断演化的诊断状态，LTM 负责保存跨事件积累的运维经验。CMR 则根据 STM 中已经确认的症状和证据，动态激活 LTM 中的故障模式、案例和诊断流程。

与一次性检索知识相比，OpsMem 的知识选择会随着诊断过程反复刷新；与单纯维护推理状态相比，它又能够利用系统特定的历史经验指导取证方向。诊断结束后，经过审核的新经验还会被重新写入长期记忆，使后续事件可以复用此前的诊断成果。

论文在 120 个真实生产故障事件上的结果表明，这种“诊断状态—运维经验”双记忆协同，在三种不同基础模型上均优于 ReAct、GoS 以及多种 RAG 增强版本。其核心结论并不是“记忆越多越好”，而是：当前状态、长期经验以及二者之间持续更新的对应关系，共同决定了智能体能否稳定地完成复杂故障诊断。 (arXiv)