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）