用图记忆串起生产故障排查线索

生产环境发生故障时，最初的十分钟往往不是在修复，而是在追问：还有哪些系统会受影响？谁熟悉这套系统？以前发生过类似的问题吗？

答案其实都有，只是散落在服务拓扑图、团队组织架构和历史故障复盘中。总得有人顶着压力，手动把这些信息拼起来。这就是我参加 WeMakeDevs 和 FalkorDB 举办的 Graph Hacks 时想解决的问题。

Incident Brain 是一个将上下文保存在 FalkorDB 图中的 Agent。你输入一句类似「payments-api 正在返回 500 错误」的话，它就会给出：

影响范围：所有受影响的下游服务，按跳数距离列出。

找谁求助：根据服务归属和实际操作经验，对相关人员进行排序。

相似的历史故障：故障根因、修复方法，以及当时由谁修复。

证据：支撑每项结论的具体节点、边和 Cypher 查询，并在实时图视图中高亮显示。

接着，你可以记录这次故障。记录会写回图中，下次发生类似故障时，就能检索到它。

这些问题的核心都是连接关系。「这个服务出故障后，哪些服务会跟着出问题？」是一个多跳查询问题。在 SQL 中，这意味着递归连接；在 FalkorDB 中，一条易读的查询就够了：

MATCH (f:Service {name: $name})<-[:DEPENDS_ON*1..4]-(s:Service)
RETURN DISTINCT s.name

这条查询随后被封装成了 Agent 可以调用的一个工具。Agent 从不猜测。它回答中的每项事实，都来自工具执行 Cypher 查询后返回的真实节点和边。

通过多跳遍历确定影响范围。

使用 shortestPath 解释为什么一个服务会影响另一个服务。

使用图算法 PageRank，按重要程度对受影响的服务排序。

持久化记忆：每条记录下来的故障都会成为一个节点，并带有 AFFECTED、FIXED_BY 和 SIMILAR_TO 边，因此重启后记忆依然存在。

多图支持：一张共享的公司图，加上每个团队各自独立的记忆图。

移除 FalkorDB，整个产品就无法工作。图不是装饰，而是它的大脑。

技术栈包括 Python、FastAPI、官方 FalkorDB Python client、LLM tool calling、浏览器中的力导向图视图，以及 Docker。整个系统只需一条命令即可启动：docker compose up。

[请将这里替换为你实际遇到的挑战。例如：「我的第一个版本允许模型根据自身知识回答，结果它编造了一个根本不存在的服务。我通过强制所有回答都来自工具结果，并返回节点 ID 作为来源，解决了这个问题。」请使用真实发生过的经历。]

[根据你的亲身经历，写上两三句真实感受。例如：「先设计图的 schema，让后续工作都容易了起来。关系一旦明确，工具就可以做得小而简单。」]

在线演示：https://incident-brain-ashen.vercel.app/

GitHub：https://github.com/vidishagupta/incident-brain

演示视频：https://youtu.be/tgIFDHjhuek?si=hZQJeaH4cgNR8uqV

这个项目为 FalkorDB 和 WeMakeDevs 举办的 #GraphHacks 而构建。如果你也在开发 Agent，不妨试着给它一张图。凭空猜测和沿着关系寻找答案，差别很大。

如需进一步采取行动，你可以考虑屏蔽此人和／或举报滥用行为。