Agent 時代，軟件架構(gòu)的底層邏輯變了。

過去十年，我們?yōu)榱诉w就人類團隊的協(xié)作邊界，搞出了微服務(wù)和“多元持久化”（Polyglot Persistence），把系統(tǒng)拆得七零八落。 但在 AI Agent 崛起的新范式下，這種碎片化架構(gòu)正在成為一種昂貴的“技術(shù)負債”。最稀缺的資源不再是存儲或算力，而是 LLM 的注意力帶寬（Context Window）。

微服務(wù)帶來的復(fù)雜度與碎片化，正在向 AI Agent 征收巨額的“認知稅”。 而這劑毒藥的解藥，只有 PostgreSQL。本文就來聊聊，為什么 PG 會成為 AI 時代的“數(shù)據(jù)庫之王”。

—— 老馮在 “第八屆中國 PG 生態(tài)大會” 上的閃電演講

在傳統(tǒng)的“最佳實踐”中，我們習(xí)慣把數(shù)據(jù)拆得支離破碎：MySQL 存交易，Redis 做緩存，Mongo 存文檔，Elasticsearch 搞搜索，Milvus 存向量。

這種設(shè)計理念被稱作“多元持久化”（Polyglot Persistence） —— 在單個系統(tǒng)中使用多種數(shù)據(jù)存儲技術(shù)，以滿足不同的數(shù)據(jù)存儲需求

看上去 “用專業(yè)的工具做專業(yè)的事”很美好，然而這為 AI Agent （以及人類工程師）帶來了一個高度對抗性的環(huán)境。 Agent 主要在上下文窗口的邊界內(nèi)運作，這個有限的緩沖區(qū)——無論是 8k、128k 還是 1M Token——就是 Agent 的全部：短期記憶、工作草稿、接口定義，全部擠在這里。

想象一個典型的跨域查詢?nèi)蝿?wù)：“找出購買了 X 商品并訪問過 Y 頁面，且工單情緒負面的用戶”。在多元持久化架構(gòu)下，Agent 必須經(jīng)歷一場“由于數(shù)據(jù)孤島導(dǎo)致的消耗戰(zhàn)”：

1.加載驅(qū)動與 Schema（燒錢）：Agent 必須把 MongoDB 的語法、ES 的 DSL、Neo4j 的 Cypher，以及各端的 Schema 定義統(tǒng)統(tǒng)塞進上下文。每一個用于解釋 API 的 Token，都是從核心推理能力中竊取的資源。2.編寫膠水代碼（高危）：Agent 被迫充當“分布式調(diào)度器”，編寫 Python 代碼去連接三個不同的系統(tǒng)，處理網(wǎng)絡(luò)超時、認證失敗和版本不匹配。3.應(yīng)用層 Join（低效）：數(shù)據(jù)在不同系統(tǒng)間搬運，Agent 被迫在有限的內(nèi)存里做數(shù)據(jù)清洗和連接。

這種“乒乓（Ping-Pong）”架構(gòu)不僅效率低下，更會導(dǎo)致上下文過載。 將所有工具定義塞進一個巨型 Agent 會迅速耗盡預(yù)算，當無關(guān)的 Schema 和中間數(shù)據(jù)填滿窗口，LLM 的推理能力會被鎖死天花板，直接導(dǎo)致“幻覺”飆升。

上下文經(jīng)濟學(xué)偏愛“小而美”的工具，厭惡龐雜的異構(gòu)系統(tǒng)。

PostgreSQL：零膠水架構(gòu)

解藥是什么？是大一統(tǒng)。

我們需要一個能在一個連接、一種方言里解決所有問題的“數(shù)據(jù)操作系統(tǒng)”。PostgreSQL 憑借其獨步天下的擴展性（Extensibility），早已超越了關(guān)系型數(shù)據(jù)庫的范疇，進化為全能的數(shù)據(jù)平臺。

PG 的哲學(xué)很簡單：把復(fù)雜性下推（Push-down）到數(shù)據(jù)庫內(nèi)核，讓 Agent 保持輕量。

全棧數(shù)據(jù)融合：三位一體

PG 的擴展生態(tài)系統(tǒng)有效吸收了專用系統(tǒng)的能力：

在 PG 生態(tài)中，你不需要為了一個新特性去引入一個新的數(shù)據(jù)庫組件：

對 Agent 而言，這意味著語義宇宙的統(tǒng)一。它不需要在 SQL、DSL 和 API 之間精神分裂。

更重要的是混合檢索（Hybrid Search）的民主化。你可以在一條 SQL 中，同時完成精準過濾、全文關(guān)鍵詞檢索和向量語義檢索。這不是三個系統(tǒng)的拼湊，而是一個引擎內(nèi)部算子的優(yōu)雅流水線。

把數(shù)據(jù)邏輯收斂到單一的、符合 ACID 的 PostgreSQL 引擎中，Agent 不需要關(guān)心分布式事務(wù)的最終一致性，不需要處理跨服務(wù)的數(shù)據(jù)競爭。事務(wù)要么提交，要么回滾。這 種確定性讓 Agent 能將數(shù)據(jù)層視為一個可靠的原子原語（Primitive），而不是一個充滿不確定性的分布式混沌系統(tǒng)。

FDW：零膠水架構(gòu)與位置透明

如果你確實有外部數(shù)據(jù)需要訪問，又怎么辦呢？PG 的 外部數(shù)據(jù)包裝器（FDW） 是 Agent 的“上帝視角”。

通過 FDW，Postgres 可以掛載萬物：DuckDB、MySQL、Redis、Kafka、S3 上的 CSV，甚至是 Stripe 的 API 或系統(tǒng)監(jiān)控指標。

對于 Agent，這實現(xiàn)了完美的位置透明性（Location Transparency）。 Agent 只需要執(zhí)行 SELECT * FROM sales_data。 它不知道，也不需要知道這份數(shù)據(jù)到底是躺在 S3 冷存儲里，還是在 Snowflake 的數(shù)倉里。PG 負責了所有的協(xié)議轉(zhuǎn)換和數(shù)據(jù)搬運。

這就是“零膠水”架構(gòu)的終極形態(tài)：Agent 不再需要寫幾百行 Python 代碼來做 ETL，它只需要發(fā)送一段高密度的 SQL 指令，聲明自己想要的東西。

Supabase 甚至專門做了一個 Rust FDW 框架 wrappers，以及一個專門的網(wǎng)站：fdw.dev ，提供幾十個將外部數(shù)據(jù)接入 PG的包裝。

存儲過程：服務(wù)器端工具箱

PostgreSQL 支持用 Python、JavaScript、Rust 等二十多種語言編寫存儲過程。這不僅是功能，更是架構(gòu)上的降維打擊：

?Token 節(jié)省：復(fù)雜的業(yè)務(wù)邏輯（RAG 流程、數(shù)據(jù)清洗）固化在數(shù)據(jù)庫函數(shù)中，不再占用寶貴的 Prompt 空間。?安全性與沙箱：Agent 調(diào)用的是封裝好的函數(shù)（Tool），而不是裸奔的 SQL，權(quán)限邊界清晰可控。?性能：邏輯貼著數(shù)據(jù)跑，消除了網(wǎng)絡(luò) IO 開銷 —— 通常是最大的性能瓶頸

接口標準化：psql 即 IDE

PG 的 SQL 方言 ，libpq PG線纜協(xié)議幾乎是所有 LLM 訓(xùn)練數(shù)據(jù)中都覆蓋的知識。GPT-4 和 Claude 對寫 PG 風(fēng)格的 SQL 駕輕就熟。

通過在 Postgres 上標準化，我們?yōu)?Agent 提供了一個確定性的環(huán)境。 你甚至不需要 MCP，pymongo、redis-py、neo4j-driver 這些驅(qū)動都可以扔掉了。 命令行里的一個 psql + 連接串就可以開始工作，接口定義簡化為一行： postgresql://user:password@hostname:5432/db

僅憑這一個連接，Agent 就能利用 pg_net / pg_curl 聯(lián)網(wǎng)，利用 FDW 讀寫萬物，利用 SQL 編排邏輯。甚至是執(zhí)行 Shell 命令。

psql 提供 Bash 的功能超集，天然適合成為 AI Agent 的下一個首選執(zhí)行環(huán)境。

結(jié)論

上下文窗口經(jīng)濟學(xué)決定了軟件架構(gòu)的未來。 在智能按 Token 定價、受 Prompt 大小限制的世界里，架構(gòu)簡潔性是終極優(yōu)化目標。

多元持久化曾是技術(shù)能力的象征，現(xiàn)在已成負債——摩擦、延遲、Token 浪費的源頭。它割裂 Agent 的現(xiàn)實，迫使 Agent 將認知資源浪費在膠水代碼上，而非價值創(chuàng)造。

PostgreSQL 配備 pgvector、pg_net、postgres_fdw 等擴展生態(tài)，提供了統(tǒng)一、可編程、"主動"的環(huán)境——一個真正的 Agent 操作系統(tǒng)。它允許 Agent 通過單一標準接口（SQL）進行推理（Vector）、行動（Curl）和觀察（FDW）。

Databricks 和 Snowflake 的巨額收購是最終驗證：AI 的未來是 Agentic 的，而 Agent 的數(shù)據(jù)庫是 PostgreSQL。