幾個月前，老馮寫過一篇 。那篇文章里我做了個判斷：Agent 基礎設施的下一場熱鬧會發生在“記憶”這個方向，圍繞著“Agent 該怎么記住東西”會冒出一大批創業公司和開源項目，資本會涌進來，架構圖會畫得越來越花。

果不其然，Mem0 又融了一輪，MemGPT 改名 Letta 繼續融，Zep、Cognee、Hindsight、MemoryScope、Memobase、SuperMemory、Graphiti、LangMem、EverMemOS——一抓一大把。

每家的技術博客上都掛著差不多的架構圖：底下一個 episodic 層，中間一個 semantic 層，頂上一個 reflection 或 procedural 層，層與層之間箭頭來回穿梭，寫著 consolidation、retrieval、forgetting。GitHub star 在漲，arXiv 論文在刷榜，技術大會每場都有一個 Agent Memory 的 track。熱鬧是真的熱鬧。

但這次我想潑個冷水： 這條賽道火歸火，但也許兩年后就不存在了 。

這不是論證，而是直覺。但這句話得先說清楚，我不是說 Agent 不需要記憶——恰恰相反，記憶是整場 Agent 革命里最重的籌碼，是終局壁壘所在。我說的是： Agent 需要記憶，但不需要今天這種被稱作“Memory 框架”的東西 。

這兩句話聽起來像同一件事，其實差兩個字，差一條賽道的生死。

下面講講為什么 —— 當然，這只是老馮的個人觀點。

一、終局是三分天下

要看清今天的賽道，得先把終局畫出來。

這里先交代一句：下面說的“終局”指的是 嚴肅的企業級 Agent，以及任何把數據當成核心資產的組織與個人 。消費端也許另一幅圖景——普通用戶用一個 ChatGPT、一個 Gemini，廠商順手把記憶也做了。

老馮對 AI Agent 的終局判斷很簡單 —— 三分天下 。一個成熟的 Agent，在終局狀態下，大體就是這樣一副架子：

DB_URL=postgres://user:pass@host:5432/memory

一個 URL 提供智力，一個 URL 提供記憶，中間由 Harness 負責把模型套起來、駕馭它去完成具體任務——加載 Skills、組織 context、調用工具、處理循環。想換模型廠商？換 MODEL_URL。想把數據遷到別家？換 DB_URL。想本地自建？兩個都換成 localhost。三層徹底解耦：智力層由模型廠商提供，記憶層由數據庫廠商提供， 駕馭執行的那一層由 Harness 承擔 ——Claude Code、Cursor、Devin 這些今天還在爆發式演化的產品，本質上都是 Harness。

這套格局不是架構師一廂情愿的設計品味，它背后有一套很樸素的動力學。

終局里真正的壁壘，不在算力，也不在模型。算力短期關鍵長期攤平，和“永恒的電力壟斷不存在”是一回事。模型中期關鍵長期平權，開源模型一年一個臺階往上追，GPT-5 和 DeepSeek V4 的差距比 GPT-4 時代已經小了一大截。再過兩年，Agent 能用的模型大概率是個豐儉由人的菜市場。真正拿得住的壁壘只有一樣—— 私有數據 。

而嚴肅的企業用戶不會允許自己的核心數據被“一鍋端”，也不會允許它和別家的數據無序混在同一個服務商的黑箱里。一旦被鎖住，這家服務商對你就有永恒的議價權——過去三十年從數據庫到云的采購史，都是這條邏輯寫的。于是博弈的終點就是上面那副架子—— 模型廠商管智能，Harness 管駕馭執行，數據庫廠商管記憶 ，三方互不吞并、互相制衡。

三分天下的圖畫完了—— 模型、Harness、數據庫，各自獨立，各自為王 。

現在可以回頭問那個關鍵問題：今天市面上這些 Memory 框架，坐在哪一塊上？

二、Memory 框架是什么？

先對 Memory 框架做一次顆粒度區分，免得一竿子打翻一船人。

今天被塞進“Memory 框架”這個筐里的項目，其實不是同一種東西，大致可以分成四類，每一類的命運不一樣。

第一類，數據庫套殼 SDK 。代表是早期的 Mem0、LangMem、MemoryScope、SuperMemory 這一批。它們的核心能力就是在一個數據庫（通常是 PG+pgvector 或 SQLite）上封裝一套“extract / store / retrieve / update”的 API，把 episodic 和 semantic 分兩張表，加幾條重要性打分和時間衰減規則。這一類離“數據庫薄薄一層皮”這個描述最貼切， 技術上沒有壁壘，產品上有一點用戶心智 。

第二類，知識圖譜 / 時序圖譜構建器 。代表是 Graphiti、Cognee、Hindsight。它們做的事比第一類要重一些——bi-temporal knowledge graph、增量實體消歧、沖突檢測與失效、hybrid 檢索（語義 + 關鍵詞 + 圖遍歷）。這類項目的策略層確實有工程含量，不是“幾條 SQL”能一筆帶過的。但它們的命運是—— 策略層會被模型吸收（模型自己會做實體消歧、沖突判斷），存儲層會歸回數據庫（圖能力通過 PG 擴展或專用圖數據庫承載），獨立賽道依然不成立 。

第三類，Agent Runtime / Agent OS 。代表是 Letta/MemGPT。它們做的根本不是 Memory 框架該做的事——把 context window 當 RAM、把外部存儲當 Disk、讓模型自己通過 tool call 在兩者之間 swap——這是操作系統意義上的虛擬內存管理。它門檻不低，但它的準確名字是 Agent Runtime ，是 Harness 下位的執行引擎層。其實，它應該歸到 Runtime / Harness 賽道，不是 Memory 賽道。

第一類會被 Skill + 模型自己寫 SQL 直接替代；第二類的策略層會被模型吸收，存儲層會歸回數據庫；

三、它沒有壁壘

回到第一類（數據庫套殼 SDK）——這一類占了市面上的大多數，也是這篇文章主要的打擊對象。

把它們拆到最細，干的事情就兩件： 替 Agent 設計幾張表的 schema，替 Agent 封裝幾條 SQL 。

所謂 episodic 和 semantic 分表，是 schema 設計。所謂重要性打分、時間衰減、反思壓縮，是寫入時跑的幾段規則。所謂向量召回加 BM25 加 cross-encoder 重排加 RRF 融合，是查詢組合。所有 PR 稿的術語、所有類腦箭頭圖剝掉，底下就是 建表和 SQL 。

建表和 SQL 有壁壘嗎？這是程序員第一周就會的東西。那框架憑什么值錢？憑它們“替 Agent 想好了該怎么建表、怎么寫查詢”。

那“替 Agent 想好”這件事，值多少？

老馮前陣子琢磨過這個——用 PG 加幾個擴展加一組存儲過程，把 Mem0 干的事從頭糊一遍，幾天夠了。最后沒做。為什么沒做？ 沒意思，沒壁壘 。任何一個懂點 PG 的工程師，周末抽一下午就能寫出個基礎版 Mem0，功能上九成相似。剩下那一成是 UI、是 SaaS 控制臺、是發布節奏、是開發者關系——那是運營和產品的壁壘，不是技術壁壘。

那“教會 Agent 怎么用這套東西”又要多少？ 一個 Skill，一張 markdown 。

幾百個 token 的一段指令，告訴模型“你有一個 PostgreSQL 數據庫連接在 DATABASE_URL，用戶說話時你自己判斷哪些事實值得存，每次回答前做向量加全文的混合檢索，發現新舊沖突就 UPDATE 舊的”——就這樣。Mem0 那套 ADD / UPDATE / DELETE / NOOP 流水線、Cognee 的圖譜構建、Graphiti 的時序圖——這些“認知架構”能做的事，現在的模型自己寫 SQL 就能做到，而且寫得比你干凈。

Claude 的 Skills 機制已經把這條路走通一半。用戶寫個 memory-skill.md，描述清楚“記憶怎么存、怎么查”，Claude 在需要時自動調用，不需要任何外部 Memory 框架。哪天 Anthropic 或 OpenAI 把一個官方 memory skill 作為最佳實踐發出來，這一整批項目從模型側就被架空了。

你以為的護城河，其實是一張寫著幾百字的 markdown 。生產環境里這張 markdown 背后自然會接上受控工具和固化的數據庫 pipeline——但那些位置該歸 Harness 的歸 Harness，該歸數據庫的歸數據庫，依然沒有獨立 Memory 框架的位置。

四、苦澀的教訓

上一節是從產業結構上說 Memory 框架沒位置。再往深一層，從方法論上也有一把刀—— The Bitter Lesson 。

Sutton 2019 年那篇一千多字的博客，講的事很簡單：過去七十年，AI 領域反復上演同一個劇本——研究者把自己對某個領域的精心理解編碼進系統，短期看效果不錯，長期必輸給“讓模型自己學”的通用方法。國際象棋的評估函數輸給搜索，圍棋的棋譜先驗輸給自我對弈，語音識別的音素建模輸給統計方法，CV 的 SIFT 輸給深度學習。每一次，靠“領域理解”的路線都輸了，贏的是看起來“沒有智慧”、只是能吃算力和數據的方法。

這把刀落到 Memory 框架上要小心——它 不打 所有系統抽象。操作系統、數據庫、編譯器都是人類設計的抽象，它們沒有被端到端學習吃掉，也不會被吃掉，因為它們提供的是可靠的底層積木，不是替 AI 做決策。Sutton 打的是后者。

Memory 框架的問題在于它 站在后者那一邊 。它硬編碼的那些東西——什么信息值得記、記在哪一層、什么時候觸發反思、怎么組合向量和全文——每一項都是“替 Agent 做認知決策”的意見，而不是通用積木（向量存儲、全文檢索、事務、索引這些真正的積木，早就被數據庫提供了）。今天 Agent 需要這些意見，只是因為模型還不夠強；等模型強到能自己判斷——這件事已經在發生——這些手工認知策略會像 SIFT 遇見 AlexNet 那樣，一夜之間變成廢鐵。

產業結構上它沒位置，方法論上它也撐不住。兩條線在這里合攏。

五、真正的壁壘

那什么 有 壁壘？

三分天下那張圖里，嚴格來說只有兩個位置上的壁壘是確定的，另一塊的壁壘還在成形。

模型那塊 會打血戰。閉源和開源拉鋸、價格一年一腰斬、廠商排名每半年洗一次牌。這塊有壁壘，但壁壘屬于少數幾家頭部模型廠商，且局勢仍在劇烈變動。

Harness 那塊 還沒定型。Claude Code / Codex 現在跑在最前面，但其他的也開始露頭：OpenClaw，Hermes；Letta/MemGPT 那支 Agent Runtime 方向如果真能做成也挺有意思。Harness 這塊今天剛長出些壁壘，又被 Claude Code 開源給掀翻拉平到一個水平線。

剩下那塊—— 數據庫 ——是全局里 確定性最高 的位置。

確定性來自一個結構性事實： 數據庫不在 AI 沖擊的范圍內 。

什么東西會被 AI 沖擊？價值來自“信息加工”的東西——文案、設計、初級編程、法律文書、客服、PPT。它們的本質是把信息 A 映射到信息 B，而 LLM 做的就是這件事。LLM 有多強，它們被壓縮得有多狠。

那什么不在這個前線上？ 物理世界的持久化層 。數據庫干的事情是在真實的磁盤上、通過真實的操作系統和文件系統、對抗真實的斷電和崩潰、在多節點間用真實的網絡達成共識，讓字節在二十年后還能被準確讀回來。這件事的本質不是信息加工，是 物理世界的可靠性保證 。LLM 再聰明變不出一塊磁盤，保證不了 fsync 的語義，也不會代替兩階段提交。

Agent 越強大，它越需要一個可靠的物理世界錨點。Agent 革命不會削弱數據庫的價值， 只會放大它 。

所以三分天下的終局里，模型那塊會打到流血，Harness 那塊還在摸索， 只有數據庫這塊地基，三十年前就定了，三十年后還會在 。

六、數據庫的盡頭是 PG

那具體到記憶層，會是哪個數據庫？

這里要分階段看。

現階段 ——對一個跑在本地的個人 Agent、或者單機場景下的輕量 Agent 來說， SQLite 甚至文件系統也完全夠用 。SQLite 零運維、文件形態、本地跑、原生支持 JSON 和向量擴展，單體 Agent 的記憶需求它完全扛得住。相當多的 Agent 應用在本地持久化上就是直接用 SQLite。這個階段講“記憶層需要 PG”是過度工程。

但往前演化一步——一旦 Agent 需要跨 Agent 協作、跨設備持久化、跨組織可遷移、面對多租戶和并發——也就是需要“通用可遷移的記憶層”——局勢就會收斂 。收斂到哪？

PostgreSQL 。

原因有三層。

第一層，事實已經在發生 。相當一部分認真做 Agent 基礎設施的嚴肅項目都在向 PG 或 PG 兼容后端靠攏——Letta 官方支持 PG + pgvector，Hindsight 明確只支持 PG + pgvector，Tiger Data 直接把產品線命名為 Agentic Postgres。這不是 PG 生態自我證明（Supabase、Neon 這種本來就是 PG 家族的不算），是 原本站在其他路線上的項目在往 PG 收斂 。

第二層，線纜協議（Wire Protocol）是事實標準 。PG 協議之于通用記憶層，就像 HTTP 之于應用層——夠老、夠穩、夠通用、夠開放，沒有哪家廠商能擁有它，也沒有哪家廠商能替換它。模型在訓練語料里見過幾百萬次 SQL 和 psql，它天然會說這門語言，不需要額外訓練。私有協議的數據庫在 AI 時代已經輸了一半，因為模型不熟它。

第三層，擴展生態已經把記憶層需要的所有檢索原語覆蓋了 。向量有 pgvector，全文有 tsvector 加 GIN，圖有 AGE 以及新一代基于 PG 的圖擴展，時序有 TimescaleDB，地理有 PostGIS，水平擴展有 Citus。這些都是擴展插進來的，不是重寫整個系統——因為 PG 三十年前就做了個關鍵決定：不替上層預設語義。這是 PG 真正牛逼的地方，三十年后任何新工作負載都能插進來。

所以這條演化路徑是清楚的—— 在“通用可遷移的記憶層”這件事上，除了 PG 協議沒別的選 。圖數據庫、對象存儲、端側 SQLite、專用搜索系統——它們會在各自的專用場景里繼續存在，這不沖突。但在“通用 Agent 記憶”這個場景里，PG 就是那個終局。

SQLite 和 PG 在架構紀律上是一族人——都是通用持久化層、都不預設上層語義、都有幾十年的可靠性積累、都不在 AI 沖擊的前線上、都有靈活的擴展極致。SQLite 是端側和本地場景的 PG，PG 是服務端和協作場景的 SQLite。它們是同一條路上的兩個 size。

真正被三分天下分食掉的，是那種“介于數據庫和應用之間的中間件”——也就是今天的 Memory 框架。

回到三分天下這張圖。模型層在流動，Harness 層在成形，記憶層在沉淀。三塊地盤各自為王，沒有哪一塊是今天“Memory 框架”的位置。它們不是某一方的對手——它們是過渡態下代管了三方工作的中間商，而真空一旦被填滿，中間商就無處可去。

十年后再回望 2026 年這場 Memory 框架喧嘩，會看到一件很平淡的事——那些號稱“給 Agent 設計認知”的框架，最后真正留下來的代碼，是它們最樸素的那一部分： 把數據老老實實塞進 PostgreSQL 的那幾行 SQL 。

其他的，都會被端到端學習吃掉。

數據庫老司機

點一個關注 ??，精彩不迷路

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

歡迎加入 PGSQL x Pigsty 交流群 QQ 619377403