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

一、從"缸中之腦"說起

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

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

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

二、三大器官的缺失

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

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

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

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

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

三、范式革命的三個(gè)維度

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

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

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

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

四、一個(gè)被忽視的真相

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

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

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

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

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

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

答案幾乎只有一個(gè)：PostgreSQL。

不是因?yàn)樗牟樵兯俣茸羁欤ㄕ摲治鲂阅?，ClickHouse、DuckDB 都能超越它），不是因?yàn)樗南蛄繖z索最強(qiáng)（專用向量庫在十億規(guī)模下仍有優(yōu)勢(shì)），而是因?yàn)樗鼡碛?strong>獨(dú)一無二的擴(kuò)展架構(gòu)。

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

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

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

當(dāng)然，有人會(huì)問：DuckDB 呢？SQLite 呢？

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

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

六、真正的競(jìng)爭在哪里

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

而我們，正站在這場(chǎng)變革的起點(diǎn)。

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

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

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

對(duì) PostgreSQL， Pigsty，下云 感興趣的朋友

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