BLACKBOX：用知识图谱为故障响应注入记忆

生产环境的故障很少孤立出现。一条告警背后，可能牵连着最近的部署、下游依赖、过载的数据库、陌生的服务负责人，以及几个月前似曾相识的同类事件。对于on-call工程师来说，真正的挑战不只是找到答案，而是在短时间内把所有上下文串联起来，并解释清楚这个答案为什么可信。

BLACKBOX正是为解决这个问题而构建的AI故障调查代理。它以FalkorDB作为持久化运维知识图谱，将服务、依赖、告警、部署、Runbook、人员和历史复盘连接在同一张网中。

从告警到解释：图遍历如何定位根因

传统的告警排查往往依赖工程师在多个系统之间切换搜索。BLACKBOX的做法不同：当故障发生时，它不满足于检索孤立记录，而是沿着图结构遍历，理解告警与系统其余部分的关联方式。

假设notifications-api出现高延迟告警。BLACKBOX会同时考察几类可能相关的线索：连接池是否耗尽、最近的PR是否改动了数据库池配置、哪次部署引入了问题、哪些服务依赖notifications、相关代码的负责人是谁、以及历史上是否出现过相似故障模式。

代理沿着这些关系路径寻找可能的根因，确定影响范围，定位相关专家，并生成可执行的解释。与简单返回搜索结果列表不同，这个答案附带了一条穿过系统的推理路径，工程师能看到结论是怎么一步步得出的。

多跳图遍历（Multi-hop Graph Traversal） 是图数据库中的核心查询模式，指从起始节点出发，沿边关系连续跳转多次以发现间接关联。在BLACKBOX场景中，一次典型的多跳查询可能形如：告警节点 → 关联服务 → 该服务的最近部署 → 部署引入的PR → PR作者。这种遍历能力使代理能够跨越多个系统边界，将原本分散在不同工具中的线索自动串联起来。相比之下，传统关系型数据库需要多次JOIN操作才能表达类似逻辑，且随着关联深度增加性能急剧下降；而图数据库将关系作为一等公民存储，多跳查询的延迟与路径长度近似线性，更适合运维场景中深度不确定的根因追溯。

FalkorDB作为运维记忆层

BLACKBOX最核心的设计在于：调查不会随着故障结束而消失。

每次分析完成后，BLACKBOX会把结构化发现写回FalkorDB，包括根因、受影响服务、解决方案、负责人和复盘知识。后续调查可以直接把这些信息作为上下文使用，形成一个反馈闭环：告警触发调查、代理遍历关联数据、识别发现并推荐方案、调查结果写回图谱、未来故障可以召回这些知识。

第一次调查可能需要探索大量关系；而具有相似特征的后续调查，可以从已存储的上下文出发，更快抵达有效答案。

运维知识图谱（Operational Knowledge Graph） 是将运维领域实体及其关系显式建模为图结构的知识库。与通用知识图谱不同，它聚焦于服务拓扑、部署流水线、告警规则、人员归属和故障复盘等运维语义。其价值在于把原本隐含在工程师头脑或散落文档中的“谁知道什么”“什么依赖什么”“上次怎么修的”等关系变成可查询的结构化资产。BLACKBOX将每次调查的结构化发现写回图谱，本质上是在持续扩充这张知识图谱的节点与边，使系统具备累积性记忆。这种设计区别于仅依赖向量检索的RAG方案：RAG召回的是文本片段，而运维知识图谱召回的是实体间的确定关系路径，后者在根因定位中具有更强的可解释性和精确性。

为什么选择图数据库而非文档或表格

运维系统天然是互联的。服务依赖服务，部署改变服务，PR归属于工程师，故障影响多个面向客户的系统，Runbook描述如何恢复组件，复盘解释过去发生了什么。这些关系在扁平文档或孤立表中很难完整保留。

FalkorDB为BLACKBOX提供了自然的表示方式，使其能够提出多跳问题：哪些服务依赖告警服务？最近哪次部署与这次失败有关？疑似根因涉及的代码归谁负责？影响半径内有哪些客户系统？我们以前见过类似故障吗？上次用了什么方案恢复？

由于结果来自相连的图路径，BLACKBOX不仅能说明它相信什么，还能说明它是如何得出这个判断的。这种可解释性在故障响应场景中尤为关键。

冷调查与热调查的差异

BLACKBOX直观展示了有无先验记忆两种调查模式的差别。

冷调查从告警出发，遍历图谱发现相关上下文，可能需要检查依赖、部署、代码变更、人员和Runbook。热调查则利用此前运行中写入的复盘和发现，能召回已学到的知识，减少不必要的工具调用，把精力集中在确认已知模式上。

界面会实时呈现这一过程：用户可以看到图遍历、代理的工具调用、正在写入的发现以及最终解释。

为实时协作而构建的界面

BLACKBOX包含一个面向故障响应的实时调查界面。代理工作时，前端流式传输进度并更新图可视化。UI展示的内容包括当前活跃告警、穿过受影响服务的因果路径、相关部署与PR、面向客户的影响半径、相关负责人与响应者、代理推理事件、发现与复盘写回，以及冷热调查的对比结果。

这种可见性在故障期间很重要。工程师需要理解系统在做什么，而不是等待一个没有证据支撑的黑箱答案。

语言模型的角色与确定性兜底

语言模型在BLACKBOX中负责选择工具、解读图查询结果、归纳证据并生成清晰的故障解释。但图谱始终是运维事实的来源。

BLACKBOX还内置了确定性规划器作为兜底。当模型不可用或请求超出配置的工具预算时，系统仍可基于图谱运行核心调查流程。这保证了演示和故障工作流的韧性，同时维持发现的可解释性。

确定性规划器（Deterministic Planner） 是指不依赖大语言模型随机性、按预定义规则或状态机执行调查步骤的组件。在BLACKBOX中，它作为LLM的降级方案存在：当模型API不可用、响应超时或工具调用次数超出预算时，系统自动切换至确定性规划器，按固定顺序执行核心图查询（如检查依赖、检索最近部署、查找历史相似事件）。这种“LLM优先、确定性兜底”的架构模式在运维代理中尤为重要，因为故障响应场景对可用性和可预测性要求极高，不能因模型侧故障导致调查完全中断。确定性规划器虽然灵活性不如LLM，但能保证调查流程在受控范围内完成，且输出结果完全可复现，便于事后审计。

构建过程中的关键认知

BLACKBOX的开发强化了一个原则：代理记忆只有在结构化且与它所操作的世界相连时，才最有价值。单纯的对话记录无法告诉我们哪个服务导致了故障、谁负责它、哪些系统依赖它。图结构能显式保留这些关系，并让未来的调查使用它们。FalkorDB使持久记忆、多跳推理和实时运维工作流得以在一个系统中结合。

后续方向

BLACKBOX的下一步是接入实时可观测性、工单、部署和聊天系统，让图谱随服务变更和故障演进而保持最新。生产化方面还需要更强的访问控制、租户隔离、限流和更丰富的查询可观测性。

长期愿景是构建一个每次调查都变得更有用的故障响应系统，帮助工程师从告警走向理解，从理解走向行动。BLACKBOX围绕一个简单理念构建：每一次故障，都应该让下一次故障更容易解决。