跳过正文
Agent 需要什么样的数据库?
  1. 数据库老司机/

Agent 需要什么样的数据库?

·3482 字·7 分钟· ·
冯若航
作者
冯若航
Pigsty 创始人, @Vonng
目录

当我们讨论"AI 时代的数据库"时,很容易陷入一个思维陷阱——认为这场变革需要什么全新的存储引擎、什么革命性的索引结构、什么颠覆性的查询语言。

但如果我们冷静审视这个问题,答案可能恰恰相反:真正的变革不在数据库内核,而在数据库之上的那一层。

微信公众号原文


一、缸中之脑
#

当前 AI Agent 的处境颇为尴尬。

它们拥有令人惊叹的推理能力——能写代码、能做分析、能进行复杂的多步规划——却被迫栖身于"文件系统 + 外部脚本"的简陋环境中。LangChain 默认用 InMemoryStore,进程一重启就失忆;AutoGPT 把状态写进 JSON 文件,多个 Agent 协作时竞态条件频发;即便是最先进的 Agent 框架,也需要同时维护向量库、关系库、缓存层三套独立系统。

这种架构就像缸中之脑——一个强大的大脑被放在营养液里,通过细细的管子与外部世界交互。每一次感知都要经历数据提取、序列化、网络传输、外部处理、反向写入的漫长链路。Agent 的"神经传导速度"被拖慢了几个数量级。

问题的根源在哪里?

不是数据库不够快,不是索引不够好,而是 Agent 缺少一个统一的"数字躯体"——一个能够整合技能、记忆和推理能力的一体化容器。


二、三个缺失的器官
#

如果借用人类智能的运作机制来审视,当前 Agent 架构缺失的恰恰是三个关键"器官":

肌肉记忆的缺失。 人类学会骑自行车后,不需要每次都"想"如何保持平衡,这种技能已经内化为无意识的本能。但 Agent 每次执行任务,都要重新生成代码、调用外部运行时、等待返回结果。它没有"本能反应",只有"深思熟虑"。

联想记忆的缺失。 人类的记忆不是关键词索引,而是联想网络。我们能从一首歌想到初恋,从一种味道想到故乡。但 Agent 的记忆系统被割裂为向量库(只懂语义相似)和知识图谱(只懂显式关系),两者各自为政,无法触类旁通。

想象力的缺失。 人类在行动前能够在脑海中预演多种可能,评估风险,选择最佳路径。但 Agent 面对的数据库是"单一时间线"的,所有操作直接作用于生产环境,没有安全的想象空间供它试错。

这三个缺失共同构成了 Agent 自主性的天花板。没有肌肉记忆,它反应迟钝;没有联想记忆,它语境失明;没有反事实推演,它不敢冒险。


三、范式革命的三个维度
#

理解了问题所在,解决方案的轮廓也就清晰了。

第一维度:从数据存储到技能内化。 数据库不应只是被动的数据仓库,而应成为 Agent 的"数字肌肉"。通过库内计算,将频繁使用的逻辑下沉到数据层,让 Agent 像调用本能一样调用技能。PostgreSQL 的多语言运行时(PL/Python、PL/Rust、PL/V8)提供了这种可能——函数与数据共址,执行路径缩短为零。

第二维度:从关键词检索到联想记忆。 单纯的向量相似度搜索无法回答"谁是发布了 GPT-4 的公司的 CEO"这类需要多跳推理的问题。必须打破向量与图谱的界限,构建动态语义图谱——既能模糊匹配语义,又能遍历结构关系。GraphRAG 的实验表明,这种融合架构在多跳推理任务上的准确率可达 87%,而纯向量方案仅为 23%。

第三维度:从 CRUD 到反事实推演。 Agent 需要"Git for Data"——能够瞬时创建数据库分支、在隔离环境中模拟不同决策的后果、然后选择性地合并或放弃。这赋予了 Agent 真正的"想象力":它可以在平行宇宙中大胆试错,而不必承担破坏生产环境的风险。


四、一个被忽视的真相
#

但这里有一个容易被忽视的真相:这三大能力没有一项需要重新发明数据库内核。

向量索引(pgvector)本质上是 PostgreSQL 扩展机制的又一次应用。图查询(Apache AGE)同样如此。库内计算是存储过程的自然延伸。分支与时间旅行依赖的 MVCC 和写时复制早已是成熟技术。

这些能力所需的底层技术——ACID 事务、B-tree 索引、WAL 日志、查询优化器——都是 boring technology,经过数十年验证,稳定可靠。

换言之,Agent-Native Database 的革命不是关于什么新内核、新存储、新引擎。那些作为精确工具的数据库核心技术,Agent 仍然需要,而且不会被替代。真正产生变革的,是如何将这些"无聊"技术组合起来,支撑那些看似炫酷的新能力。

这个认知至关重要。它决定了我们应该把注意力放在哪里。


五、PostgreSQL 的压倒性优势
#

如果战场在"数据库之上的那一层",那么谁最有资格成为这场革命的基座?

答案几乎只有一个:PostgreSQL。

不是因为它的查询速度最快(论分析性能,ClickHouse、DuckDB 都能超越它),不是因为它的向量检索最强(专用向量库在十亿规模下仍有优势),而是因为它拥有独一无二的扩展架构

PostgreSQL 的扩展机制不是浅层的插件系统,而是允许第三方代码深度集成到查询规划器、执行器、存储引擎和事务系统的"内核开放"。这意味着社区可以在不 Fork 核心代码的情况下,将任何新能力——向量搜索、图查询、时序分析、地理空间、机器学习——变成 PostgreSQL 的原生能力。

更关键的是组合性。

TimescaleDB + PostGIS 实现时空分析。pgvector + BM25 实现混合检索。Apache AGE + pgvector 实现 GraphRAG。这种组合的可能性是专用数据库无法企及的。

Pinecone 只能做向量,Neo4j 只能做图——这不是贬低,专注正是它们的优势来源。但对于 Agent 而言,它需要的是同时具备向量、图、关系、时序、全文能力,且所有这些都在同一个 ACID 事务边界内。这意味着 Agent 的"数字躯体"可以是统一且一致的,不需要维护多套系统,不需要担心跨库数据同步,不需要在应用层重新发明事务一致性。

一个 PostgreSQL 实例,就是一个完整的认知基础设施。


六、真正的竞争在哪里
#

如果 PostgreSQL 是确定的基座,那么真正的竞争发生在哪里?

答案是 PostgreSQL 生态的上层——那些将扩展能力包装为产品、将 boring technology 转化为 Agent 可用能力的发行版和平台。

我们已经看到这场竞争的雏形。

扩展层面,三大赛道正在激烈角逐:OLAP(pg_duckdb、pg_mooncake)、全文检索(ParadeDB、vchord_bm25)、向量检索(pgvector、pgvectorscale、vchord)。每个赛道都有多个玩家在卷,试图成为该能力维度的标准选择。

平台层面,Supabase 将 PostgreSQL 包装为 Firebase 替代品;Neon 专注于 Serverless 和分支能力,让数据库配置在 500 毫秒内完成;Pigsty 提供生产就绪的发行版,集成监控、高可用、备份恢复的完整方案。

Databricks 以约 10 亿美元收购 Neon,正是这场竞争的标志性事件。它印证了一个判断:Agent 时代的数据库基础设施具有战略价值,而这个价值不在底层内核,在生态整合层。


七、新物种的轮廓
#

接下来几年,我们有理由期待在 PostgreSQL 生态中出现一个新物种——某种 Agent-Native Platform

它会将 pgvector、Apache AGE、PL 运行时、分支能力统一整合,提供面向 Agent 的一等公民 API。开发者不需要分别了解每个扩展的用法,而是直接调用"记忆存储"、“技能注册”、“分支模拟"这样的高层抽象。

它会实现 MCP 或类似协议的原生支持,让 Agent 框架能够无缝连接数据库。数据库本身成为 Agent 的一个工具,可以被发现、被调用、被协调。

它可能内置记忆层次抽象——工作记忆、情景记忆、语义记忆的区分不再由应用层实现,而是由平台提供原生支持,包括自动的记忆巩固与遗忘策略。

这个新物种的出现,可能来自现有玩家的进化,也可能来自新入场者的颠覆。但无论如何,它的根基必然是 PostgreSQL——因为只有 PostgreSQL 具备承载这种统一平台的扩展深度和生态广度。


八、躯体与灵魂
#

数据库作为 Agent 的"数字躯体”,这个隐喻蕴含着深刻的洞察。

躯体不是灵魂,但灵魂需要躯体才能行动。LLM 是 Agent 的推理核心,但如果它没有可靠的记忆系统、没有内化的技能库、没有安全的试错空间,它就只能是缸中之脑——聪明但无力。

真正的 Agent-Native Database 不需要重新发明轮子。B-tree 仍然是 B-tree,WAL 仍然是 WAL,MVCC 仍然是 MVCC。这些无聊的技术已经足够好,足够可靠。需要做的是在这些坚实的地基之上,构建一层新的抽象——让 Agent 能够像使用自己的身体一样使用数据库,自然、流畅、无需刻意思考底层细节。

PostgreSQL 已经准备好了。它的扩展生态证明了这种上层建筑是可能的。

剩下的问题是:谁能最先将这些分散的能力,整合为一个统一的、面向 Agent 的平台?

答案,将在接下来的竞争中揭晓。

而我们,正站在这场变革的起点。

相关文章