第一次学 Neo4j，我终于明白 Agent 为什么不只用 MySQL

大家好，我是大煊。

我以前对数据库的理解很朴素：业务数据放 MySQL，热点数据放 Redis，搜索复杂一点再上 Elasticsearch。

所以我第一次在一个 AI 客服项目里看到 Neo4j 时，第一反应不是兴奋，而是疑惑：

一个电商客服系统，为什么还要搞图数据库？

我的数据库世界，只有“表”

做 Java 后端时，我最熟的就是表。

用户表、订单表、商品表、权限表、日志表。

这些数据最大的特点是：结构固定。

比如订单表关心的是：

这种数据 MySQL 非常擅长。

事务、一致性、索引、SQL 查询，都很稳。

所以过去很多年，我几乎没想过一个问题：

已经有 MySQL 了，为什么还需要别的数据库？

AI Agent 遇到的问题开始变了

学习 AI Agent 以后，我发现它要回答的问题，和传统 CRUD 不太一样。

传统系统更常见的问题是：

订单 1001 发货了吗？

用户 41 有没有售后单？

这类问题，本质是在查一条记录。

但 AI 客服还会遇到另一类问题：

有没有 256G 的手机？

70 多寸的电视有哪些？

非有机的大米有哪些品牌？

这些问题表面是在聊天，底层其实是在问：

数据之间是怎么连起来的。

手机是分类。

小米 12S Ultra 是 SPU。

8GB+256GB 某个颜色是 SKU。

256G、颜色、屏幕尺寸是属性。

品牌、分类、属性、商品之间，全是关系。

MySQL 能存关系，为什么还要 Neo4j？

这是我一开始最疑惑的地方。

MySQL 当然能存关系。

商品表、品牌表、分类表、中间表，一样可以建。

甚至你愿意写 SQL，也能一路 Join 出结果。

但问题是，关系一多，查询会越来越绕。

在这个项目的 Neo4j 里，我看到的电商图谱大概是这样的：

关系主要有三种：

一条商品链路大概是：

SKU -> SPU -> 三级分类 -> 二级分类 -> 一级分类

再补两条：

SPU -> 品牌 SKU -> 属性 User -> 浏览过的 SKU

这就不是单纯“查表”了。

它更像把一张商品 ER 图，变成了可以直接查询的数据库。

AI 为什么越来越喜欢图数据库？

因为 AI 问题里，经常不只需要“相似文本”，还需要“关系路径”。

普通 RAG 更像：

文档切片 -> 找相似内容 -> 交给大模型回答

它适合问：

退货政策是什么？

因为退货政策通常就是一段文档。

但如果用户问：

有没有 256G 的手机？

这时更像是在走一条路径：

手机分类 -> 某款手机 -> 具体 SKU -> 256G 属性

如果用户问：

我之前看过的商品里，有哪些是小米品牌？

那又要走：

用户 -> 浏览过的 SKU -> SPU -> 品牌

这就是 Neo4j 的价值。

它让 AI 客服不只是“找相似文档”，还可以“沿着关系找答案”。

所以 MySQL 过时了吗？

当然不是。

我现在的理解是：它们解决的问题不一样。

如果用户问“订单有没有发货”，交给 MySQL。

如果用户问“退货政策是什么”，交给文档 RAG。

如果用户问“有没有某个属性的商品”，Neo4j 就更自然。

所以不是 AI 项目非要堆数据库。

而是 AI Agent 遇到的问题，已经从“查一条记录”，变成了“理解一句话，然后在一堆关系里找答案”。

我最大的收获

以前做 Java 后端，我更多思考的是：

数据应该放哪张表？

现在看 AI Agent 项目，我开始多问一个问题：

这些数据之间有什么关系？

这是我第一次真正理解 Neo4j 的地方。

它不是为了显得架构复杂。

它是在 MySQL 之外，多了一层“关系记忆”。

可以把它想成一张可以被程序查询的业务关系图。

MySQL 解决“记录是什么”。

Neo4j 解决“它和谁有关”。

这个边界一清楚，AI 客服为什么不只用 MySQL，就好理解多了。