# Agent 需要什么样的数据库？ LLMS 索引： [llms.txt](/llms.txt) --- 当我们讨论"AI 时代的数据库"时，很容易陷入一个思维陷阱——认为这场变革需要什么全新的存储引擎、什么革命性的索引结构、什么颠覆性的查询语言。 但如果我们冷静审视这个问题，答案可能恰恰相反：**真正的变革不在数据库内核，而在数据库之上的那一层。** > [微信公众号原文](https://mp.weixin.qq.com/s/zFpFECMOCbllihvuh-2BaQ) ------ ## 一、缸中之脑 当前 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 的平台？ 答案，将在接下来的竞争中揭晓。 而我们，正站在这场变革的起点。