Agent的數(shù)字軀體：一場不在內(nèi)核的數(shù)據(jù)庫革命

當我們討論"AI 時代的數(shù)據(jù)庫"時，很容易陷入一個思維陷阱——認為這場變革需要什么全新的存儲引擎、什么革命性的索引結(jié)構(gòu)、什么顛覆性的查詢語言。但如果我們冷靜審視這個問題，答案可能恰恰相反：真正的變革不在數(shù)據(jù)庫內(nèi)核，而在數(shù)據(jù)庫之上的那一層。

一、從"缸中之腦"說起

當前 AI Agent 的處境頗為尷尬。它們擁有令人驚嘆的推理能力——能寫代碼、能做分析、能進行復雜的多步規(guī)劃——卻被迫棲身于"文件系統(tǒng) + 外部腳本"的簡陋環(huán)境中。LangChain 默認用 InMemoryStore，進程一重啟就失憶；AutoGPT 把狀態(tài)寫進 JSON 文件，多個 Agent 協(xié)作時競態(tài)條件頻發(fā)；即便是最先進的 Agent 框架，也需要同時維護向量庫、關(guān)系庫、緩存層三套獨立系統(tǒng)。

這種架構(gòu)就像"缸中之腦"——一個強大的大腦被放在營養(yǎng)液里，通過細細的管子與外部世界交互。每一次感知都要經(jīng)歷數(shù)據(jù)提取、序列化、網(wǎng)絡傳輸、外部處理、反向?qū)懭氲穆L鏈路。Agent 的"神經(jīng)傳導速度"被拖慢了幾個數(shù)量級。

問題的根源在哪里？不是數(shù)據(jù)庫不夠快，不是索引不夠好，而是 Agent 缺少一個統(tǒng)一的"數(shù)字軀體"——一個能夠整合技能、記憶和推理能力的一體化容器。

二、三大器官的缺失

如果我們借用人類高階智能的運作機制來審視這個問題，當前 Agent 架構(gòu)缺失的恰恰是三個關(guān)鍵"器官"：

小腦與反射弧（Muscle Memory）——人類學會騎自行車后，不需要每次都"想"如何保持平衡，這種技能已經(jīng)內(nèi)化為無意識的肌肉記憶。但 Agent 每次執(zhí)行任務，都要重新生成代碼、調(diào)用外部運行時、等待返回結(jié)果。它沒有"本能反應"，只有"深思熟慮"。

海馬體（Hippocampus）——人類的記憶不是關(guān)鍵詞索引，而是聯(lián)想網(wǎng)絡。我們能從一首歌想到初戀，從一種味道想到故鄉(xiāng)。但 Agent 的記憶系統(tǒng)被割裂為向量庫（只懂語義相似）和知識圖譜（只懂顯式關(guān)系），兩者各自為政，無法"觸類旁通"。

前額葉皮層（Prefrontal Cortex）——人類在行動前能夠在腦海中預演多種可能，評估風險，選擇最佳路徑。但 Agent 面對的數(shù)據(jù)庫是"單一時間線"的，所有操作直接作用于生產(chǎn)環(huán)境，沒有安全的"想象空間"供它試錯。一旦決策失誤，后果往往不可逆。

這三個缺失共同構(gòu)成了 Agent 自主性的天花板。沒有肌肉記憶，它反應遲鈍；沒有聯(lián)想記憶，它語境失明；沒有反事實推演，它不敢冒險。

三、范式革命的三個維度

理解了問題所在，解決方案的輪廓也就清晰了。Agent-Native Database 需要在三個維度上完成進化：

第一維度：從數(shù)據(jù)存儲到技能內(nèi)化。 數(shù)據(jù)庫不應只是被動的數(shù)據(jù)倉庫，而應成為 Agent 的"數(shù)字肌肉"。通過庫內(nèi)計算（In-Database Computing），將頻繁使用的推理邏輯下沉到數(shù)據(jù)層，讓 Agent 像調(diào)用本能動作一樣調(diào)用內(nèi)部技能庫。PostgreSQL 的多語言運行時（PL/Python、PL/Rust、PL/V8）已經(jīng)提供了這種可能——函數(shù)與數(shù)據(jù)共址，執(zhí)行路徑縮短為零。PostgresML 更進一步，允許在 SQL 查詢中直接調(diào)用機器學習模型，模型向數(shù)據(jù)移動，而非數(shù)據(jù)向模型移動。

第二維度：從關(guān)鍵詞檢索到聯(lián)想記憶。 單純的向量相似度搜索無法回答"誰是發(fā)布了 GPT-4 的公司的 CEO"這類需要多跳推理的問題。必須打破向量與圖譜的界限，構(gòu)建動態(tài)語義圖譜——既能模糊匹配語義，又能遍歷結(jié)構(gòu)關(guān)系。GraphRAG 的實驗表明，這種融合架構(gòu)在多跳推理任務上的準確率可達 87%，而純向量方案僅為 23%。pgvector 與 Apache AGE 的組合正在讓 PostgreSQL 具備這種"海馬體"能力。

第三維度：從 CRUD 到反事實推演。 Agent 需要"Git for Data"——能夠瞬時創(chuàng)建數(shù)據(jù)庫分支、在隔離環(huán)境中模擬不同決策的后果、然后選擇性地合并或放棄。Neon 的寫時復制架構(gòu)使分支創(chuàng)建在毫秒級完成，無論數(shù)據(jù)庫多大。這賦予了 Agent 真正的"想象力"：它可以在平行宇宙中大膽試錯，而不必承擔破壞生產(chǎn)環(huán)境的風險。

四、一個被忽視的真相

但這里有一個容易被忽視的真相：這三大能力沒有一項需要重新發(fā)明數(shù)據(jù)庫內(nèi)核。

向量索引（pgvector）本質(zhì)上是 PostgreSQL 擴展機制的又一次應用。圖查詢（Apache AGE）同樣如此。庫內(nèi)計算是存儲過程的自然延伸。分支與時間旅行依賴的 MVCC 和寫時復制早已是成熟技術(shù)。這些能力所需的底層技術(shù)——ACID 事務、B-tree 索引、WAL 日志、查詢優(yōu)化器——都是"boring technology"，經(jīng)過數(shù)十年驗證，穩(wěn)定可靠。

換言之，Agent-Native Database 的革命不是關(guān)于什么新內(nèi)核、新存儲、新索引。那些作為"精確工具"的數(shù)據(jù)庫核心技術(shù)，Agent 仍然需要使用，而且不會被替代。真正產(chǎn)生變革的是數(shù)據(jù)庫之上的那一層——如何用好數(shù)據(jù)庫，如何將 Agent 需要的功能組織起來，如何用現(xiàn)有的"無聊"技術(shù)支撐這些看似炫酷的能力。

這個認知至關(guān)重要。它決定了我們應該把注意力放在哪里。

五、PostgreSQL 的壓倒性優(yōu)勢

如果戰(zhàn)場在"數(shù)據(jù)庫之上的那一層"，那么誰最有資格成為這場革命的基座？

答案幾乎只有一個：PostgreSQL。

不是因為它的查詢速度最快（論分析性能，ClickHouse、DuckDB 都能超越它），不是因為它的向量檢索最強（專用向量庫在十億規(guī)模下仍有優(yōu)勢），而是因為它擁有獨一無二的擴展架構(gòu)。

PostgreSQL 的擴展機制不是淺層的插件系統(tǒng)，而是允許第三方代碼深度集成到查詢規(guī)劃器、執(zhí)行器、存儲引擎和事務系統(tǒng)的"內(nèi)核開放"。這意味著社區(qū)可以在不 Fork 核心代碼的情況下，將任何新能力——向量搜索、圖查詢、時序分析、地理空間、機器學習——變成 PostgreSQL 的"原生能力"。

更關(guān)鍵的是，這些擴展可以組合使用。TimescaleDB + PostGIS 實現(xiàn)時空分析。pgvector + BM25 實現(xiàn)混合檢索。Apache AGE + pgvector 實現(xiàn) GraphRAG。這種組合的可能性是專用數(shù)據(jù)庫無法企及的。Pinecone 只能做向量，Neo4j 只能做圖，而 PostgreSQL 可以同時做向量、做圖、做關(guān)系、做時序、做全文，且所有這些都在同一個 ACID 事務邊界內(nèi)。

對于 Agent 而言，這意味著什么？意味著它的"數(shù)字軀體"可以是統(tǒng)一且一致的。不需要維護多套系統(tǒng)，不需要擔心跨庫數(shù)據(jù)同步，不需要在應用層重新發(fā)明事務一致性。一個 PostgreSQL 實例，就是一個完整的認知基礎(chǔ)設施。

當然，有人會問：DuckDB 呢？SQLite 呢？

DuckDB 在分析場景有極大優(yōu)勢，嵌入式、列存、向量化執(zhí)行，聚合查詢比 SQLite 快 20-50 倍。但它的定位是"分析數(shù)據(jù)庫"，缺少 PostgreSQL 那樣的擴展生態(tài)和 OLTP 能力。SQLite 在邊緣場景無可匹敵——零配置、單文件、700KB 體積——Turso 甚至將其定位為"萬億 Agent 時代的數(shù)據(jù)庫"。但 SQLite 的擴展能力有限，無法承載復雜的 Agent 工作負載。

它們可能成為特定場景的補充——DuckDB 用于分析型 Agent，SQLite 用于邊緣設備上的本地優(yōu)先操作——但作為 Agent 認知基礎(chǔ)設施的核心，它們的機會不大。PostgreSQL 在這個賽道上的優(yōu)勢是壓倒性的。

六、真正的競爭在哪里

如果 PostgreSQL 是確定的基座，那么真正的競爭會發(fā)生在哪里？

答案是 PostgreSQL 生態(tài)的上層——那些將擴展能力包裝為產(chǎn)品、將"boring technology"轉(zhuǎn)化為 Agent 可用能力的發(fā)行版和平臺。

我們已經(jīng)看到這場競爭的雛形：

在擴展層面，三大賽道正在激烈角逐。OLAP 賽道有 pg_duckdb、pg_clickhouse、pg_parquet、pg_lake；全文檢索賽道有 pg_textsearch、ParadeDB、vchord_bm25；向量檢索賽道有 pgvector、pgvectorscale、vchord 以及各種專門優(yōu)化。每個賽道都有多個玩家在卷，試圖成為該能力維度的標準選擇。

在平臺層面，Supabase 將 PostgreSQL 包裝為"Firebase 替代品"，提供實時訂閱、認證、邊緣函數(shù)的一體化體驗。Neon 專注于 Serverless 和分支能力，讓數(shù)據(jù)庫配置在 500 毫秒內(nèi)完成，支持自動縮放到零。Pigsty 提供生產(chǎn)就緒的 PostgreSQL 發(fā)行版，集成監(jiān)控、高可用、備份恢復的完整解決方案。DBLab 和 Xata 則探索"Git for Data"的不同實現(xiàn)路徑。

Databricks 以約 10 億美元收購 Neon，正是這場競爭的標志性事件。它印證了一個判斷：Agent 時代的數(shù)據(jù)庫基礎(chǔ)設施具有戰(zhàn)略價值，而這個價值不在底層內(nèi)核，在生態(tài)整合層。

七、未來兩年的關(guān)鍵窗口

接下來的兩年（2025-2027）將是關(guān)鍵的時間窗口。

我們有理由相信，會在 PostgreSQL 生態(tài)中出現(xiàn)一個新物種——某種"AgentFS"或"Agent-Native Platform"。它可能具備以下特征：

首先，它會將 pgvector、Apache AGE、PL 運行時、時間旅行能力統(tǒng)一整合，提供面向 Agent 的一等公民 API。開發(fā)者不需要分別了解每個擴展的用法，而是直接調(diào)用"記憶存儲"、"技能注冊"、"分支模擬"這樣的高層抽象。

其次，它會實現(xiàn) MCP（Model Context Protocol）或類似協(xié)議的原生支持，讓 Agent 框架能夠無縫連接數(shù)據(jù)庫，而不是通過繁瑣的中間層。數(shù)據(jù)庫本身成為 Agent 的一個"工具"，可以被發(fā)現(xiàn)、被調(diào)用、被協(xié)調(diào)。

第三，它可能內(nèi)置"記憶層次"抽象——工作記憶、情景記憶、語義記憶的區(qū)分不再由應用層實現(xiàn)，而是由數(shù)據(jù)庫平臺提供原生支持，包括自動的記憶鞏固與遺忘策略。

這個新物種的出現(xiàn)，可能來自現(xiàn)有玩家的進化（Supabase 向 Agent 場景延伸，Neon 深化分支能力），也可能來自新入場者的顛覆。但無論如何，它的根基必然是 PostgreSQL——因為只有 PostgreSQL 具備承載這種統(tǒng)一平臺的擴展深度和生態(tài)廣度。

八、結(jié)語：軀體與靈魂

數(shù)據(jù)庫作為 Agent 的"數(shù)字軀體"，這個隱喻蘊含著深刻的洞察。

軀體不是靈魂，但靈魂需要軀體才能行動。LLM 是 Agent 的推理核心，但如果它沒有可靠的記憶系統(tǒng)、沒有內(nèi)化的技能庫、沒有安全的試錯空間，它就只能是"缸中之腦"——聰明但無力。

真正的 Agent-Native Database 不需要重新發(fā)明輪子。B-tree 仍然是 B-tree，WAL 仍然是 WAL，MVCC 仍然是 MVCC。這些"無聊"的技術(shù)已經(jīng)足夠好，足夠可靠。需要做的是在這些堅實的地基之上，構(gòu)建一層新的抽象——讓 Agent 能夠像使用自己的身體一樣使用數(shù)據(jù)庫，自然、流暢、無需刻意思考底層細節(jié)。

PostgreSQL 已經(jīng)準備好了。它的擴展生態(tài)證明了這種"上層建筑"是可能的。剩下的問題是：誰能最先將這些分散的能力整合為一個統(tǒng)一的、面向 Agent 的平臺？

答案，將在未來兩年揭曉。

而我們，正站在這場變革的起點。

提示：本文由 Claude Opus 4.5 撰寫，老馮提問，追問，審校。

數(shù)據(jù)庫老司機

點一個關(guān)注 ??，精彩不迷路

對 PostgreSQL， Pigsty，下云 感興趣的朋友

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