Agent的数字躯体：一场不在内核的数据库革命

当我们讨论"AI 时代的数据库"时，很容易陷入一个思维陷阱——认为这场变革需要什么全新的存储引擎、什么革命性的索引结构、什么颠覆性的查询语言。但如果我们冷静审视这个问题，答案可能恰恰相反：真正的变革不在数据库内核，而在数据库之上的那一层。

一、从"缸中之脑"说起

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

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

问题的根源在哪里？不是数据库不够快，不是索引不够好，而是 Agent 缺少一个统一的"数字躯体"——一个能够整合技能、记忆和推理能力的一体化容器。

二、三大器官的缺失

如果我们借用人类高阶智能的运作机制来审视这个问题，当前 Agent 架构缺失的恰恰是三个关键"器官"：

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

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

前额叶皮层（Prefrontal Cortex）——人类在行动前能够在脑海中预演多种可能，评估风险，选择最佳路径。但 Agent 面对的数据库是"单一时间线"的，所有操作直接作用于生产环境，没有安全的"想象空间"供它试错。一旦决策失误，后果往往不可逆。

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

三、范式革命的三个维度

理解了问题所在，解决方案的轮廓也就清晰了。Agent-Native Database 需要在三个维度上完成进化：

第一维度：从数据存储到技能内化。 数据库不应只是被动的数据仓库，而应成为 Agent 的"数字肌肉"。通过库内计算（In-Database Computing），将频繁使用的推理逻辑下沉到数据层，让 Agent 像调用本能动作一样调用内部技能库。PostgreSQL 的多语言运行时（PL/Python、PL/Rust、PL/V8）已经提供了这种可能——函数与数据共址，执行路径缩短为零。PostgresML 更进一步，允许在 SQL 查询中直接调用机器学习模型，模型向数据移动，而非数据向模型移动。

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

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

四、一个被忽视的真相

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

向量索引（pgvector）本质上是 PostgreSQL 扩展机制的又一次应用。图查询（Apache AGE）同样如此。库内计算是存储过程的自然延伸。分支与时间旅行依赖的 MVCC 和写时复制早已是成熟技术。这些能力所需的底层技术——ACID 事务、B-tree 索引、WAL 日志、查询优化器——都是"boring technology"，经过数十年验证，稳定可靠。

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

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

五、PostgreSQL 的压倒性优势

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

答案几乎只有一个：PostgreSQL。

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

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

更关键的是，这些扩展可以组合使用。TimescaleDB + PostGIS 实现时空分析。pgvector + BM25 实现混合检索。Apache AGE + pgvector 实现 GraphRAG。这种组合的可能性是专用数据库无法企及的。Pinecone 只能做向量，Neo4j 只能做图，而 PostgreSQL 可以同时做向量、做图、做关系、做时序、做全文，且所有这些都在同一个 ACID 事务边界内。

对于 Agent 而言，这意味着什么？意味着它的"数字躯体"可以是统一且一致的。不需要维护多套系统，不需要担心跨库数据同步，不需要在应用层重新发明事务一致性。一个 PostgreSQL 实例，就是一个完整的认知基础设施。

当然，有人会问：DuckDB 呢？SQLite 呢？

DuckDB 在分析场景有极大优势，嵌入式、列存、向量化执行，聚合查询比 SQLite 快 20-50 倍。但它的定位是"分析数据库"，缺少 PostgreSQL 那样的扩展生态和 OLTP 能力。SQLite 在边缘场景无可匹敌——零配置、单文件、700KB 体积——Turso 甚至将其定位为"万亿 Agent 时代的数据库"。但 SQLite 的扩展能力有限，无法承载复杂的 Agent 工作负载。

它们可能成为特定场景的补充——DuckDB 用于分析型 Agent，SQLite 用于边缘设备上的本地优先操作——但作为 Agent 认知基础设施的核心，它们的机会不大。PostgreSQL 在这个赛道上的优势是压倒性的。

六、真正的竞争在哪里

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

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

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

在扩展层面，三大赛道正在激烈角逐。OLAP 赛道有 pg_duckdb、pg_clickhouse、pg_parquet、pg_lake；全文检索赛道有 pg_textsearch、ParadeDB、vchord_bm25；向量检索赛道有 pgvector、pgvectorscale、vchord 以及各种专门优化。每个赛道都有多个玩家在卷，试图成为该能力维度的标准选择。

在平台层面，Supabase 将 PostgreSQL 包装为"Firebase 替代品"，提供实时订阅、认证、边缘函数的一体化体验。Neon 专注于 Serverless 和分支能力，让数据库配置在 500 毫秒内完成，支持自动缩放到零。Pigsty 提供生产就绪的 PostgreSQL 发行版，集成监控、高可用、备份恢复的完整解决方案。DBLab 和 Xata 则探索"Git for Data"的不同实现路径。

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

七、未来两年的关键窗口

接下来的两年（2025-2027）将是关键的时间窗口。

我们有理由相信，会在 PostgreSQL 生态中出现一个新物种——某种"AgentFS"或"Agent-Native Platform"。它可能具备以下特征：

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

其次，它会实现 MCP（Model Context Protocol）或类似协议的原生支持，让 Agent 框架能够无缝连接数据库，而不是通过繁琐的中间层。数据库本身成为 Agent 的一个"工具"，可以被发现、被调用、被协调。

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

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

八、结语：躯体与灵魂

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

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

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

PostgreSQL 已经准备好了。它的扩展生态证明了这种"上层建筑"是可能的。剩下的问题是：谁能最先将这些分散的能力整合为一个统一的、面向 Agent 的平台？

答案，将在未来两年揭晓。

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

提示：本文由 Claude Opus 4.5 撰写，老冯提问，追问，审校。

数据库老司机

点一个关注 ⭐️，精彩不迷路

对 PostgreSQL， Pigsty，下云 感兴趣的朋友

欢迎加入 PGSQL x Pigsty 交流群（搜pigsty-cc）