事件总线挂了，AI凭什么知道该找谁？他们用图数据库答了

“事件总线宕机了。”就这一句话，普通聊天机器人从几份检索到的文档里，答不出一串要命的问题：哪些系统依赖它？哪些项目和团队被波及？谁该负责响应？是不是已经有工单在跟？上一次排查查到了什么，换个智能体重启之后还能不能接着干？

Team Terminator 为 Graph Hacks 黑客松做了一个叫 Company Brain 的东西，底层是 FalkorDB 图数据库，服务对象是一家虚构公司 Nimbus Labs。它的思路很直接：答案不该从假设里来，得从连起来的证据里来。

一个产品同时打了三条赛道：面向人、团队、系统、项目、文档、消息、工单和决策的接地问答；在连通数据上执行动作的智能体；以及让调查员存下图谱支撑的事故记忆、再交接给协调员接着干的智能体记忆与协作。

图谱不是可视化皮肤，是工作上下文

公司知识很少待在一个地方。一个系统有负责人、有依赖、有文档、有历史决策、有相关消息、有使用它的项目、有影响它的工单。“事件总线挂了会坏什么”这种问题，答案取决于顺着这些关系往下走。

FalkorDB 在这里不是套在别的数据库外面的展示层。Company Brain 从它里面找事实、存更新、记事故记忆、写会影响后续回答的工单。把 FalkorDB 拿掉，核心流程直接消失：智能体没法遍历依赖和归属，没法证明自己为什么选了某个负责人或优先级，没法持久化后续工单，下一个智能体也接不上前一次调查。

答案不只是一条记录，而是记录之间的路径。

一次故障，三种图谱驱动的行为

演示从 event-bus 出故障开始。用户问“事件总线挂了会坏什么”，系统沿依赖路径返回受影响的系统、使用它们的项目、所属团队、在职人员和已有的开放工单，聊天回复里同时亮出图谱证据和用到的 Cypher 查询。

核心遍历刻意写得小而可读：从系统节点出发，沿 DEPENDS_ON 关系走 1 到 4 跳，找到目标系统。这条路径本身就是解释。大模型负责写回复，FalkorDB 提供回复背后的连通事实。

同一份影响分析接着驱动“响应系统事故”流程：遍历依赖和使用关系，找出风险中的系统和项目，查所属团队和在职人员，据此推荐负责人和优先级，用户创建后续工单。FalkorDB 收到一个新的 Ticket 节点，带上 AFFECTS 和 ASSIGNED_TO 关系。影响分析再跑一遍，新工单就出现在后续证据里了。

最后这一步最关键。应用不只是描述事故，它改动了图谱，改动后的图谱又改变了智能体接下来能说什么。

图谱模型长这样：人属于团队，团队拥有系统，系统依赖系统；人领导项目，项目使用系统；人撰写文档，文档关于系统或项目；工单指派给人、影响系统；人发消息，消息提及系统或项目；决策由人做出、关于系统或项目、来源于文档工单或消息。

应用还能处理示例之外的问题。合适的时候，智能体会构造一条经过校验的只读 MATCH 查询，用来做计数、过滤、分组或列表。改数据的、不安全的子句会被拒绝，生成的 Cypher 作为证据展示出来。

记忆要能活过第一个智能体

事故经常在人、班次、工具之间流转。聊天记录是种很弱的共享记忆，因为它只活在一次对话里。Company Brain 把事故状态本身存进 FalkorDB。

事故调查员只干一件事：检查图谱推导出的影响证据，写一份简短报告，把它存成连到事故上的 Memory 节点。响应协调员干另一件事：读存下来的事故记忆和交接内容，核对当前归属上下文，决定恢复跟进方案，创建关联工单。

演示里能看到那条边界：协调员不依赖调查员浏览器里的聊天历史，它从 FalkorDB 读存储的事故上下文。刷新页面、重新开始、换一个兼容客户端，记忆和交接都还在。

事故能力还通过 MCP 服务器暴露出来。MCP 即模型上下文协议，给另一个 AI 客户端一个标准方式去用同一批图谱支撑的操作。服务器暴露的工具包括分析系统影响、启动调查、读取事故记忆、交接给协调员、协调跟进。这意味着图谱流程不绑死在一个界面上。

真正难的不是把图画出来，是让每个流程都证明图谱确实干了活。答案要接地，图谱证据要在聊天里看得懂，动作要能持久化进后续推理。事故演示成了测试标准：如果新工单写入后没出现，或者协调员不读存储上下文也能继续，那 FalkorDB 就没扛起足够多的产品逻辑。

由此得出一条设计规则：大模型可以解释和选工具，FalkorDB 持有连通事实、证据路径、记忆和动作结果。