Change Guardian：用AI图谱找出IT依赖地图遗漏的隐藏风险

一张过时的IT依赖地图，可能让51家医院的急诊科在凌晨2点同时断掉关键化验结果。Change Guardian用AI代理和图数据库，找出了这张地图上没人写下的51条隐藏连线。

每个IT团队都会问的问题

假设你负责一家医院的核心IT系统。今晚，你需要为一台服务器安装安全补丁并重启。动手之前，你打开CMDB（配置管理数据库），查看"哪些系统依赖这台服务器"，也就是所谓的爆炸半径（blast radius）。

地图显示：只有化验报告系统受影响，风险很低。你批准了变更。

凌晨2点，全区域急诊科停止接收关键化验结果。

问题出在哪里？地图不是画错了，而是过期了。每周都有新连接被加入——项目临时接入、快速修复、新院区上线。有人打算更新CMDB，但没做。地图记录的内容和系统实际的行为之间，这道缓慢扩大的裂缝被称为CMDB漂移（CMDB drift）。

Gartner曾警告，不处理CMDB数据质量问题的组织，最终会遭遇可见的业务中断。而批准变更的人根本无从知道哪条线缺失——因为缺失的线，和本来就不存在的线，看起来一模一样。

CMDB（配置管理数据库） 是ITIL框架中的核心实践，用于记录IT环境中的配置项（服务器、应用、数据库、网络设备等）及其相互关系。它本应是变更影响分析的权威依据，但现实中CMDB的维护往往滞后于实际变更——临时接入、紧急修复、项目上线等操作很少同步更新。这种数据与实际状态之间的偏差即CMDB漂移。漂移的危险在于它是无声的：缺失的依赖连线与本来就不存在的依赖看起来完全相同，任何基于CMDB的影响分析都会系统性低估爆炸半径。Gartner的研究指出，CMDB数据质量问题已成为变更管理失败的主要诱因之一，而修复漂移的关键在于引入独立于人工维护的证据源进行交叉验证。

Change Guardian解决了什么

Change Guardian是一个AI代理，它的核心思路是：不只看地图上写了什么，更看系统实际做了什么。它会从多个真实工具的数据中交叉验证，找出没人记录的依赖关系，展示真实的爆炸半径，并用确切的图路径解释原因，然后采取行动——通知正确的人，并向地图提出修复建议，等待人工批准。

为了让系统可验证，作者构建了虚构的Northwind Health医疗系统：51家医院、约1000家诊所、两个数据中心和两个云区域，覆盖从面向患者的服务到服务器、存储、网络设备和医疗设备的每一层。选择医疗场景的理由很直接："什么真正依赖什么"这个问题，在错误会伤人的地方最重要。

据作者在Dev.to发布的项目说明，该工具在Graph Hacks 2026黑客松中由WeMakeDevs和FalkorDB支持完成。

真相来自证据，而非单一工具

Change Guardian的"实际发生了什么"视图来自证据——来自真实医院已经在运行的工具所产生的记录。作者模拟了十种工具的数据源，每种都按其真实格式生成数据：

• 发现扫描列出网络上的每台设备
• 应用监控显示哪些应用调用了哪些数据库
• 网络流量记录显示谁在和谁通信，即使设备上没有安装软件
• 接口引擎（路由医疗消息的中枢）显示消息实际流向哪里
• 备份和存储报告显示数据是否真的有安全副本
• 登录和数据库审计日志、HR数据源、IT服务台历史显示谁使用什么，以及哪个团队真正在修复每个系统

没有任何单一工具能看到全部。网络能看到流量但看不到意图；接口引擎能看到消息路由但看不到服务器；服务台知道谁在修复问题，而这往往和地图上写的所有者不一致。真相藏在组合之中。

核心案例：一个补丁，51家医院

一个变更请求写道：为dc1-host-07应用ESXi安全补丁并重启。依赖链从下往上依次是：物理服务器→虚拟机→数据库lrc-db-01。

CMDB说这个补丁影响4个组件，0家医院。

证据说：107个组件，51家医院。

差异来自哪里？CMDB记录了医院的危急化验结果接口（将紧急结果传送到急诊科的馈送），也记录了数据库。它缺少的是两者之间的51条连线。接口引擎的配置显示，全部51条馈送每天都写入lrc-db-01，已经持续14天。但没有人把这些连线加入地图。

所以，那个看似只影响化验报告的补丁，实际上会切断全部51家医院急诊科的危急化验结果。

为什么选择图数据库

依赖地图天然是图：服务器、数据库、服务是节点，"依赖于"是节点之间的边。"如果这个挂了会怎样"意味着沿着边走——从服务器走到它上面的一切，再到那之上的一切，有时深入很多步。

Change Guardian将两个版本的真相存储在同一个FalkorDB图中，使用相同的节点和两种边：CMDB声明的边，以及证据观察到的边。于是问题变成从同一起点出发的两次遍历：只走声明边 → CMDB认为会坏什么；走声明边加观察边 → 实际会坏什么。

两次遍历之间的差异就是发现本身，而它们之间的路径自动成为解释。

作者也诚实测试了普通关系数据库的替代方案，结果混合：在大规模依赖遍历上图数据库明显更快（在347万节点上，追踪105,713个依赖组件，FalkorDB耗时38毫秒，PostgreSQL耗时357毫秒，约9倍差距），并发100用户时FalkorDB最慢响应1.7秒，PostgreSQL达到4.4秒；但构建包含所有者、部门、医院信息的完整报告时，PostgreSQL反而更快（908毫秒对1324毫秒），因为那本质上是表连接的强项。作者还指出，对于最大的变更，FalkorDB负责遍历、SQL负责填充细节的混合方案最快。

图数据库以节点和边为原生存储模型，特别适合多跳依赖遍历。与关系数据库通过JOIN模拟图结构不同，图数据库在遍历时采用无索引邻接（index-free adjacency），即每个节点直接持有其邻居的指针，遍历成本与路径深度成正比而非与全表规模成正比。在爆炸半径分析这类需要从单一起点深入多层的查询中，这一特性带来数量级的性能优势。FalkorDB是基于Redis的图数据库，支持Cypher查询语言和向量索引，其内存优先架构使其在低延迟遍历场景中表现突出。文章中的基准测试（347万节点、105,713个依赖组件、38毫秒对357毫秒）正是这一特性的直接体现——但需注意，图数据库的优势集中在遍历类负载，聚合报表类查询仍可能是关系数据库的强项。

为什么需要AI代理，而不只是代码

发现漂移本身由精确的图检查完成，这是刻意的设计：检测必须精确且可测试。根据作者公布的基准答案对比，这些检查找出了全部109个植入的问题，没有误报，包括正确没有标记四条看起来损坏、实际正常的备份链路。

但审查变更不是一个固定流程。下一个问题取决于上一个答案：实际影响与声明影响不同吗？如果不同，哪些连线是隐藏的，什么证据能显示它们？新受影响的系统真正归谁所有（往往不是地图上说的）？附近最近还有其他变更吗？风险有多高，该警告谁，下一步该做什么？

这正是AI代理的用武之地：一个能够自主决定下一步、调用工具查询、持续推理直到能够回答的AI模型。Change Guardian的代理从18个图工具中选择步骤并解释原因，通过MCP（模型上下文协议） 提供工具调用，意味着任何兼容MCP的AI应用都能使用同一套图工具。它还会写变更备注、请求变更委员会审查；对CMDB本身的修改永远等待人工批准。

每一个数字和系统名称都会对照图进行校验。如果不匹配，它的答案会被搁置，改为展示基于规则的审查结果。每次调查成本不到半美分。

MCP（Model Context Protocol，模型上下文协议） 是由Anthropic提出并开源的标准化协议，用于让AI模型以统一方式调用外部工具和数据源。在MCP之前，每个AI应用都需要为每个工具编写定制化的调用集成，工具与模型之间形成N×M的适配矩阵。MCP将这一矩阵降为N+M：工具只需实现一次MCP服务器，任何兼容MCP的AI客户端即可直接使用。在Change Guardian的案例中，18个图查询工具被封装为MCP工具，代理通过协议发现并调用它们，这意味着同一套图工具可以被Claude Desktop、IDE插件或其他MCP客户端复用，而无需修改代理逻辑。MCP的核心价值在于将工具能力与代理实现解耦，使图数据库的查询能力成为可移植的基础设施。

记忆让判断积累而非流失

当人员批准建议后，51条缺失连线被加入CMDB。这次批准也存储在代理自己的记忆图中（FalkorDB中的另一个独立图）。下次任何人审查这台服务器的变更时，代理已经知道：有人确认过这51条连线。如果有人将某个发现标记为误报而拒绝，代理不会再提出它。

没有记忆，每次审查都从零开始，人们永远在回答同样的问题。有了记忆，人类判断得以积累，而不是被丢弃。

诚实的测试结果

作者写了九个已知答案的测试场景。前五个场景塑造了代理：首次运行只解决了5个中的2个，因为缺少两个工具；加入后解决了5个中的4个。作者坦言："你调优过的分数证明不了什么。"

于是又写了四个从未见过的场景，在运行之前保存预期答案，只运行一次，事后不做任何修改。最终数据上，代理9个中答对7个。

两次失败最有教学意义：都涉及警告了错误的团队（其中一个还命名了错误的原因）。所有权是代理最难做对的事情——这很合理，因为所有权恰恰是真实CMDB中过期最快的信息。

意外收获

作者分享了几条工程经验：

先检查工具，再怪数据库。 第一次基准测试对FalkorDB不公平：缺少一个库导致Python客户端读取结果缓慢。安装后解码速度提升约三倍。作者修正并公布了更正。

在完全相同的条件下测量。 一次重跑看起来慢了2.7倍，原因不是数据库，而是笔记本电脑在忙别的事情。之后只发布背靠背、同条件测量的结果。

图算法可以审计你自己的模型。 作者运行了一个连通分量检查（寻找未连接任何其他节点的节点组）来找孤立系统，结果没找到孤儿节点，却揭示了整族服务谁都没有连接到任何东西——这让一些危险的变更看起来无害。模型因此被修复。

为代理预留测试集。 事先承诺的分数，远比调优出来的分数有价值。

下一步

目前Change Guardian运行在虚构数据上。下一步是只读连接真实CMDB，让它在每个变更请求提交的瞬间就进行审查，使警告在任何人批准变更之前到达，而不是在故障之后。

因为最危险的依赖，就是没有人写下来的那一个。

演示视频：https://youtu.be/FjRZv8ZxBCE · 在线体验：https://change-guardian.vercel.app · 代码：https://github.com/sudarshan032/northwind-drift-agent