95.2%对81.6%：给AI智能体一张图，排障准了多少

500个留出的合成故障案例，带干扰项、带红鲱鱼部署、带缺失遥测。图智能体把真正的根因排在第一位的比例是95.2%。同样信号、同样调参、只把关系去掉的最强行级基线，做到81.6%。而这个项目的第一版——简单挑“最深的失败服务”——只有25%。

这是 Mohit Sachin Shirke（团队 Night Hunter）为 Graph Hacks: Context for AI Agents（WeMakeDevs × FalkorDB）Track 01 做的项目 SynapseGuard。他想搞清楚一件事：图数据库到底能帮智能体多少。所以他没停在“感觉有用”，而是把它量了出来，还跑在了不是自己造的数据上。

烟雾报警器会告诉你起火了，但永远不会告诉你火是从哪个房间烧起来的。微服务告警是同一个逻辑。结算挂了，告警响在“大门口”：代理返回错误，前端延迟飙升。真正的原因通常在那些服务往下两跳、四跳的地方。值班工程师最贵的那几分钟，全花在搞清楚谁调谁、什么变了、坏掉的东西归谁管。

SynapseGuard 要做的事，就是从报警器走到起火的房间，并且把每一步都摆出来。智能体的全部上下文就活在一张图里：服务调用图（用的是 OpenTelemetry Demo 的真实拓扑），每个服务上挂着实时遥测；每个服务跑在哪台主机上；变更日志，包括部署、配置改动和功能开关；还有人——团队、负责人、值班轮换、每次变更的作者、谁做过什么；以及智能体自己对过往故障的记忆和它提议过的动作。

故障来了，智能体做五件行表做不到的事。它按可达性剪枝：从告警服务出发沿同步 CALLS 边往下走，但只走进不健康的服务，一跳一跳来，每跳一条走索引的 Cypher 查询。一个坏了但从症状出发根本走不到的服务，不是这个症状的原因。它在子图里按证据给候选打分：候选下面还有没有东西能解释它？它解释了多少降级？它是不是先坏、调用方是不是在一分钟内跟上？之前是不是刚落了变更？几个坏掉的服务是不是共享一台打满的主机？

它给出该叫谁，并且带证据。每个人名都附一条图路径，比如 p-alice → ON_CALL → team-checkout → OWNS → payment，再加上变更的作者。它按结构行动：算出爆炸半径，跑 FalkorDB 的 algo.maxFlow，放置最便宜的熔断器，把用户和故障隔开。最后，它等人。每个动作都要有人批准再执行。智能体不确定的时候会直说，并把答案标记为待核实。

演示里，一个功能开关弄坏了支付服务，同时一个无关的前端部署落下来当红鲱鱼。一次点击给出：根因是 payment，相对置信度 94%。开关在支付降级前 79 秒落地。该叫 Alice，值班负责人。

同样的能力也以 MCP 服务器的形式暴露，但形式是一份固定目录：人写的、参数化的 Cypher 工具，blast_radius、who_to_page、path_between、recent_changes 等等。任何查询跑之前，名字先在图里解析。你问 payments-gateway，这个名字不存在，那就一条查询都不跑：智能体回你，图里没有这个名字，你是不是想说 payment。自由形式的 Cypher 默认关闭，任何工具都不能批准动作。一个跑在 CPU 上的小本地模型（llama3.1:8b）在 12 道测试题里选对了 12 次工具。它最后那句话，只要提到了工具没返回的东西，就会被拒掉。

然后他跑了 RCAEval，一个真实故障注入的公开基准：Online Boutique、Sock Shop 和 Train Ticket 三个系统共 645 个案例，指标来自真实集群，但没有变更日志，也没有主机放置信息。Train Ticket 的调用图是从 574,479 条真实 Jaeger span 里学出来的；Online Boutique 上，同样的方法确认了他手写图的每一条边。

诚实的结果是：用他的默认设置，图的排序和一个强的无图打分器打平。有的系统上更好，有的更差，包括在留出的 Train Ticket 上差了 4 个百分点。用其他真实系统上学到的权重，图打分器在 6 个留出系统套件里赢了 4 个——但看到这些结果之后，他没有改产品的默认设置。图在排序上的优势来自把遥测和变更、放置信息连起来，而 RCAEval 没有这些连接，图没有东西可以利用。

真实数据还抓到了一个合成数据永远抓不到的 bug：一个严重度分数饱和在 1.0，不再能把服务区分开。

把 FalkorDB 6.0.2 往死里压，压出了两个问题，都在仓库里复现了。一是带两个 MATCH … WHERE … IN $list 子句的查询形状会静默返回零行，除非你在两个子句之间放一个 WITH。二是带两个 OPTIONAL MATCH、一个聚合和 ORDER BY 的查询把服务器搞崩了。另外两条教训：WHERE n.id IN $list 会走索引，而 UNWIND … MATCH (n {id: x}) 不走，换过来之后，1000 个服务规模下排查快了约 3.6 倍；结果会被 RESULTSET_SIZE（10000 行）截断且不给警告，所以任何“返回全部”的查询都必须有界。

他自己总结了几条。图在答案依赖“结构 + 运营上下文”的连接时才配得上它的位置：调用连上变更、放置和时间。把关系拿掉，同样的信号就会怪错服务。要在别人的数据上量。他自己的合成基准在讨好他，真实数据才告诉他图在哪有用、在哪没用。给 LLM 智能体图工具，别给它图的写权限——只读权限属于数据库和工具设计，不属于提示词。让每个答案都亮出它的路径，这把“信我”变成“查我”，而这正是凌晨三点值班工程师真正需要的东西。