凌晨三点系统崩了，AI凭什么找到真凶？

凌晨三点，生产系统挂了。最难的部分从来不是找到报错，而是搞清楚到底是谁把它弄挂的。

哪个服务该背锅？最近改了什么？有没有别的服务被牵连？以前是不是踩过同一个坑，当时怎么修的？这几个问题彼此咬合，可一个只握着孤立文档、或者只记得单次会话信息的AI代理，很容易把这些线索漏掉。它上下文里也许躺着正确答案，但那不等于它看懂了这些东西是怎么串起来的。

GraphOps Brain 就是冲着这个问题做的，一个围绕 FalkorDB 搭起来的AI可靠性平台。思路不复杂：把服务关系、事故历史、公司知识、代理记忆全部塞进一张互相连通的图里。代理不再只靠大模型硬猜，而是去查这张图、顺着关系走，拿查到的结果做事故调查。

第一件事：让代理在连通的数据上动手

事故响应很少是孤立的。一个服务出问题，可能拖垮好几个；而病根，也许是系统另一头的一次部署。为了表达这些关系，项目把服务、依赖、部署、事故都建模成 FalkorDB 里的节点，用 DEPENDS_ON、CHANGED、AFFECTED 这类关系把相关部分连起来。

这给代理的东西，比一堆日志或文档有用得多：一条可以探索事件与服务如何相互关联的路径。比如 checkout-api 挂了，代理可以查图找最近的部署，顺藤摸瓜把涉及的服务串出来。项目用 Cypher 查询取这些信息，拼出一条连接相关实体的证据链，形如：Deploy-42 → Payment-Gateway → Checkout-API → Incident-2481。

关键在于，代理不需要凭一段文字描述去编一个根因。它从图里取到连通的证据，再拿这些证据推进调查。上下文够了，它去找一个相关的历史修复方案，提议回滚，交给工程师审。最终决定权在人手里，而不是把生产环境无条件交给代理。

第二件事：会话结束之后，记忆去哪了

做代理的人迟早会撞上这个问题：一次会话结束后，代理学到的东西还剩什么？对话历史能留下说过的话，但未必能给代理一个有用的方式，把过去的事故和涉及的服务、修复方案连起来。

GraphOps Brain 用 FalkorDB 存两种记忆。情景记忆记录一次事故期间发生了什么；程序记忆记录一个问题是怎么被解决的、某类问题可以怎么处理。这些记忆通过 ABOUT 关系挂到相关服务上，不是孤零零的文本条目，图还能显示一条记忆关联了哪些实体。

下一次事故来了，代理可以去图里查相关记忆，用查到的结果决定接下来查什么、建议什么。项目还给“验证成功的修复”做了一个简单的置信度调整：confidence += (1 - confidence) * 0.2。意思是修复被验证成功后置信度上调，但分数越高，每次涨得越少。作者自己说得很清楚，这只是个简单启发式，不保证代理一定对，只是给记录成功结果、改善后续推荐一个起点。

第三件事：公司大脑与带权限的检索

第三块聚焦公司知识。设想一个工程师问：“支付SDK迁移政策是什么？”常规检索管线可能找到一份相关文档丢给大模型。但找到文档只是工作的一半，系统还得理解它周围的上下文，以及提问的人有没有资格看。

为此项目用 FalkorDB 搭了一条 GraphRAG 管线，检索分两步：先全文搜索找到相关的 Document 节点，再顺着图扩展，取回关联上下文，比如文档所描述服务的负责人。多出来的上下文让答案更有用，因为代理不是只对着一份文档干活。

同样重要的还有访问控制。文档带可见性属性，比如 workspace 或 team:payments。检索查询会把用户权限算进去，在上下文送进大模型之前，先过滤掉用户无权访问的文档。举例来说，Core Platform 团队的 Krish 问支付SDK迁移政策，界面给出答案的同时会提示“1 matching item hidden by permission”；换成 Payments 团队的 Ananya 问同一个问题，系统就能取到她权限内可访问的那份相关 RFC。

这里的区别在于，检索不只看哪份文档和问题匹配，还要看用户能不能看。这有助于防止受限信息被塞进发给模型的上下文里。

护栏：不让大模型自己写 Cypher

把数据库交给AI代理，还有一道坎：怎么阻止它生成一个意料之外甚至破坏性的查询？比如 MATCH (n) DETACH DELETE n，能把选定图里所有节点和关系删干净。没人想让大模型在没有约束的情况下即兴发挥数据库命令。

GraphOps Brain 的做法是，大模型不直接写 Cypher。它解读用户请求，然后从预定义、参数化的查询模板里挑一个。项目里有 40 多个查询文件，包括 Q01_blast_radius.cypher 这样的模板。查询执行因此被限制在一组受控操作内，数据库交互也更容易审查和维护，因为查询逻辑活在代码库里，而不是每次请求现编。

作者也承认，这本身不能消除所有安全风险，但它在“模型如何理解请求”和“应用允许哪些数据库操作”之间划出了一条清楚的边界。

把这几块拼起来看，同一张图可以表示服务依赖、把事故连到历史修复、跨会话保留记忆、并在访问控制下检索公司知识。图不只是存关系的地方，那些关系本身可以成为代理调查问题、解释发现、给出建议时所依据的信息的一部分。作者说，置信度怎么评估、修复方案怎么验证、失败怎么处理，都还有很大改进空间，但这个项目至少朝着“靠连通的、可检索的证据干活”而不是“全靠大模型生成”的方向，迈了一步。