为什么我认为AI数据库的必备功能是图？

胖头鱼的技术专栏-443 为什么我认为AI数据库的必备功能是图？（20260710）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Pro: Database
PostgreSQL ACE

10年+数据库行业经验
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP，ITPUB认证专家
圈内拥有“总监”称号，非著名社恐（社交恐怖分子）

全网同名：胖头鱼的鱼缸
ITPUB：yhw1809
除授权转载并标明出处外，均为“非法”抄袭

914fcc7ad57defa7868c3be1ca7fb4f5.jpg

最近好像AI数据库，AI Database的概念，重新被炒了起来，多家国产数据库也在向着AI Agent基础设施方向发力。

众所周知，没错，我又要打广告了，https://db4agent.top/，知道的人我从3月离职旅游回来之后就一直在做这件事，简单来说就是基于数据库的AI Agent基础设施架构。我需要数据库的能力在页面中也有展示：

image.png

简单来说是就是数据的多模态融合，其实为了数据库从设计开始就有良好的性能，除了“基于关系数据的JSON文档API”确实是可以不需要的以外，可以通过Agent使用的API定义关系型数据和JSON映射关系来解决相关问题，其余即便标记为“可选”数据库功能在我看来也是必需的。

稍微扯远了点，在之前文章中，我也提到过，无论是Agent的记忆存储，还是RAG能力急需的知识库，里面的内容条目都是存在关系的，因此我认为按照图来组织记忆与知识库数据是AI数据库发展的必然方向。如果按照传统方式独立存放于使用，对于相关功能的使用都会因为无法快速定位关联条目而消耗大量的Token。

具体点来说就是：

• 记忆存在链条，记忆不仅仅是文本独立存在的，还存在上下文与派生关系的，同时即便是内容相近（或向量化后接近）的条目也可能完全没有关系。如果可以以图的方式快速获准确取相关记忆，不仅可以帮助Agent全面的获取需要的内容，还可以更好的整合、优化记忆
• 知识库，我们一般也称谓知识图谱，从图谱二字我们就能看出，知识的关联性与上下层关系，如果单纯依靠记录上级的方式来存放知识，那么读取多层上级或临近关系知识一样会消耗大量操作

但如果记忆和知识都有数据库的图功能支持了，那么我们可以非常快捷的通过多模态数据库混合检索在一条语句中快速获取精确的所需内容，这样即节约了时间也节省了算力。

其实在我实际工作中使用多模态融合数据库中使用图功能解决实际问题的场景反而不是记忆与知识，是工作流。这个场景，开发人员采用了两种方式来处理工作流：

1. 将所有已经确定的工作流写入一个Skill里面，实际使用中发现的问题：每次使用都要将输入内容和整个Skill匹配，消耗大且不精确，Agent实际运行过程的Tools调用中还经常因为匹配问题出现error（懂得都懂）
2. 尝试解决工作流匹配的问题，将所有工作流都向量化存入了向量数据库中，消耗操作确实少了不少，但是接下来的问题就是存在多条内容非常类似的工作流，向量匹配评分非常接近，精确度一样会出现问题

交流之后，我建议使用了关系型数据存储+属性图，具体就是将所有工作步骤/节点（包括入口、出口）记录为Node，Node之间可传递工作流关系记录为Edge，通过属性图定义，整个工作流就变成了一个可以被有效查询的图，定义好入口、出口，特殊情况定义好中间步骤/节点，即可精确查询出匹配的工作流了。

说到这里，大家可能也能够理解我为什么会选择属性图（Property Graph）来实现图功能，一方面是关系型数据存储高效的存取效率；另一方面就是关系型数据的变更会实时展现在图中，不会出现异构数据库同步的问题，也不需要因此出现的额外维护与高可用需求；最后一点则是当需要调整图映射模型时，修改或新增属性图定义即可，尽可能减少了对原有依赖的影响。

当然在我的系统中，属性图不仅是解决了记忆、知识和工作流的问题，Workspace中的上下文、任务计划、SDD、循环工程等工程都大量使用了属性图，这增加的不仅是数据关联性，也增加了Agent运行相关数据记录的规范与准确性，同时配合数据库逻辑的实体化设计，可以无缝的扩展系统能力。

本期通过阐释在使用数据库解决AI Agent运行过程中在记忆、知识、工作流等问题的理念与方法，阐释图是AI数据库必备功能的原因。

老规矩，知道写了些啥。