FalkorDB实战：用图数据库构建能自证修复的安全事件Agent

大多数AI Agent的演示停留在给出答案这一步，但AegisGraph项目要做的，是在生产环境中执行动作——一旦出错，凌晨三点就会有人被叫醒。在Graph Hacks黑客松（WeMakeDevs与FalkorDB联合举办，Track 01：作用于关联数据的Agent）中，团队构建了AegisGraph，并从中得出一个核心结论：Agent能否安全行动，几乎完全取决于其上下文的结构。扁平的向量片段不够用，知识图谱才是答案。

安全事件真正在问什么

一个WAF告警指出，伪造的Bearer令牌正被auth-token-service接受，并指向jwt-crypto-core。值班工程师需要同时回答三个问题：攻击者从这里能触达哪些客户数据？在不拖垮结账流程的前提下，能切断什么来阻止攻击？谁应该修复这段代码？

每个答案都住在不同的系统里。包导入关系藏在代码仓库，服务间流量记录在服务网格，数据访问权限由云IAM管理。真正的答案是一条跨这三层的多跳路径：CVE → Package → Function → Service → Service Mesh → IAM Role → Database。在演示拓扑中，这条路径有5到8跳，且有六条这样的路径通向3个关键PII数据库。

向量存储能找到“听起来像JWT漏洞”的文本，但它无法告诉你legacy-billing-bridge同时位于全部六条路径上。

CVE（Common Vulnerabilities and Exposures）是公开披露的软件漏洞唯一编号，例如 CVE-2021-44228 对应 Log4Shell。WAF（Web Application Firewall）是部署在应用前端的防火墙，用于检测并拦截恶意 HTTP 流量；当它告警“伪造的 Bearer 令牌被接受”时，说明认证环节可能已被绕过。Bearer 令牌是 OAuth 2.0 中常见的一种访问凭证，持有者无需证明身份即可使用，因此一旦被伪造，攻击者就能冒充合法用户调用服务。IAM Role（Identity and Access Management Role）是云平台中授予服务或用户临时权限的身份实体，ASSUMES_ROLE 关系表示某个服务通过扮演该角色获得对数据库等资源的访问权。这些概念共同构成了安全事件中“谁在什么位置、能碰到什么”的分析基础。

一张图统摄代码、运行时与身份

团队将三个层面建模为单个FalkorDB属性图：

代码层： (:Vulnerability)-[:AFFECTS]->(:Package)<-[:IMPORTS]-(:Function)<-[:MAINTAINED]-(:Developer)，外加(:Function)-[:CALLS]->(:Function)
运行时层： (:Service)-[:DEPLOYS_CODE]->(:Function) 和 (:Service)-[:ROUTES_TO]->(:Service)
身份与数据层： (:Service)-[:ASSUMES_ROLE]->(:IAMRole)-[:CAN_ACCESS]->(:Database)

整个爆炸半径浓缩为一条OpenCypher查询：

MATCH (v:Vulnerability {id: $cve_id})-[:AFFECTS]->(:Package)<-[:IMPORTS]-(f:Function)<-[:DEPLOYS_CODE]-(origin:Service)
WITH DISTINCT origin
MATCH attack = (origin)-[:ROUTES_TO*0..3]->(pivot:Service)-[:ASSUMES_ROLE]->(role:IAMRole)
               -[:CAN_ACCESS]->(db:Database {contains_pii: true})
WHERE ALL(r IN relationships(attack) WHERE coalesce(r.status, 'ACTIVE') = 'ACTIVE')
RETURN pivot.name, role.name, db.name, [n IN nodes(attack) | n.name] AS path

这条查询同时回答了“攻击者能碰到什么数据”和“哪条服务路径是枢纽”两个问题。legacy-billing-bridge之所以关键，不是因为它的代码有漏洞，而是因为它在图上的位置——这是向量检索无法提供的洞察。

属性图（Property Graph）是一种图数据模型，节点和边都可以携带键值对属性（如 status: 'ACTIVE'），非常适合表达带语义的复杂关系。OpenCypher 是图查询语言的开放标准，用模式匹配语法描述路径，例如 (a)-[:REL*0..3]->(b) 表示从 a 到 b 长度 0 到 3 跳的可变长路径。多跳查询指在图上沿关系遍历多步，而不是只做单表连接，这正是跨代码、运行时、身份三层追踪攻击路径所需要的。FalkorDB 是一个支持 OpenCypher 的属性图数据库，以低延迟和稀疏矩阵计算见长，适合在 Agent 场景中快速执行爆炸半径这类路径查询。

沙箱图：让Agent先证明再行动

标题中的“Look Before You Leap”点出了这个项目的灵魂：Agent不能直接在生产环境执行修复，而是先在FalkorDB沙箱图中模拟。沙箱图是生产图的克隆，Agent在沙箱中执行建议的切割动作（例如移除某个IAM角色、隔离某个服务），然后重新运行爆炸半径查询，验证攻击路径是否被切断、关键业务路径是否仍然连通。

AegisGraph项目截图

这种“先证明、后执行”的模式，把Agent从概率性的文本生成器变成了可验证的决策系统。每一个动作在执行前都有图上的证据支撑，而不是依赖语言模型的置信度。

为什么图结构是Agent安全行动的前提

从AegisGraph的实践中可以提炼出几个对构建生产级Agent的启示。

上下文结构决定行动质量

Agent的行动安全性不取决于模型多大，而取决于喂给它的上下文是否保留了实体间的真实关系。扁平化文本丢失了“谁依赖谁”的拓扑信息，而多跳安全分析恰恰依赖这些拓扑。图数据库原生支持路径查询和关系遍历，这是关系型数据库和向量库难以高效替代的。

向量检索通过将文本编码为高维向量并计算相似度来召回内容，擅长语义匹配，但无法保证实体间的拓扑关系。例如，它能找到“与 JWT 漏洞相关”的文档，却无法回答“哪个服务同时位于全部六条攻击路径上”。关系型数据库虽然支持 JOIN，但在深度可变的多跳路径查询上需要递归 CTE，性能和表达力都不如图数据库。图数据库原生将关系作为一等公民存储，路径遍历是核心操作，因此在安全分析、依赖分析等场景中具有结构性优势。理解这一区别，才能明白为什么 AegisGraph 选择属性图而非向量库或关系库作为 Agent 的上下文底座。

验证闭环比单次推理更重要

沙箱模拟本质上是在图上做“如果……会怎样”的反事实推理。Agent提出的修复方案在沙箱中执行后，用同样的图查询验证效果，形成闭环。这种模式可以推广到任何高风险操作场景：先影子执行，再对照预期验证，最后才落到生产。

多系统关联需要统一图谱

代码、运行时、身份三个层面的数据天然分散在不同系统中。把它们建模进同一张属性图，使得跨系统的多跳查询成为可能。FalkorDB的属性图模型和OpenCypher支持，让这种统一建模在工程上可行。

值得关注的落地边界

提一嘴，这个方案依赖图数据的完整性和新鲜度。如果代码依赖、服务路由或IAM策略的同步存在延迟，图上的路径分析就会失真。此外，沙箱图与生产图的一致性维护本身是一个工程挑战，尤其是在高频变更的生产环境中。AegisGraph作为黑客松项目展示了方向，但生产落地还需要解决数据管道的实时性和图版本管理问题。

对于正在构建安全Agent或任何需要在高风险环境中行动的Agent的团队，AegisGraph的核心教训值得记住：让Agent在图上先证明它的修复，再让它动手。