把 Agent 的狀態(tài)放進數(shù)據(jù)庫

一年前，我寫過一篇文章叫《》。當時是為了解決 Odoo 社區(qū)的一個需求：將文件與 PostgreSQL 數(shù)據(jù)庫一起做 PITR，回滾到指定時間點。

方案運行得還不錯。它用純軟件的方式，實現(xiàn)了原本需要昂貴 CDP 專用硬件才能實現(xiàn)的功能 —— 文件系統(tǒng)與數(shù)據(jù)庫一起回滾到任意時間點。性能也行，對于 Odoo、Dify 這類應用綽綽有余。

但最近我發(fā)現(xiàn)，這個方案吸引了不少意想不到的用戶。他們不是來做 ERP 的，而是來存 AI Agent 狀態(tài)的。

做法其實很簡單：通過 PGFS，把 PG 數(shù)據(jù)庫掛載成一個本地目錄。讀寫這個目錄，實際上就是在讀寫遠程的數(shù)據(jù)庫。然后把 AI Agent 的工作目錄、配置文件、記憶數(shù)據(jù)全都放進去。

這讓我意識到，PGFS 這個東西，可能比我最初想象的要有用得多。至少我知道，一家做 OpenClaw 商業(yè)發(fā)行版的公司，已經(jīng)在用 PGFS 方案作為底層記憶共享機制了。

Agent 到底需不需要數(shù)據(jù)庫？

在聊怎么做之前，先說說 “Why”。這是個被反復爭論的問題。我的朋友蔣老板就經(jīng)常跟我 Argue：AI Agent 不需要數(shù)據(jù)庫，用個 SQLite 就行。

對于 To C 的本地單機單 Agent 場景，他說得也許沒錯。一個人用一個 Claude Code，狀態(tài)就放在 .claude/ 目錄下，Git 管好代碼，沒什么問題。在這種場景下拿 PG 來存儲狀態(tài)，有點拿著錘子找釘子的感覺。

但是，一旦場景稍微復雜一點，數(shù)據(jù)庫就是不可避免的。 正如圖靈獎得主、PG

什么叫"稍微復雜一點"？

多 Agent 協(xié)作。 你開始用并行的 Sub-Agents 來分工：一個負責寫代碼、一個負責寫測試、一個負責審查。它們之間需要溝通任務狀態(tài)、共享上下文。用 Markdown 文件做任務隊列？能跑，但很脆弱。

從單人到團隊。 你一個人 Vibe Coding 的時候無所謂，但當團隊里有三五個人，每個人都有自己的 Agent 在干活，就需要一個地方來協(xié)調(diào)。當出現(xiàn)跨設備、跨個體、跨組織協(xié)作的時候，數(shù)據(jù)庫就要比筆記本上的目錄方便多了。

To B 場景。 企業(yè)級應用天然需要集中存儲、審計、權(quán)限控制。你需要 CDP 能力，隨時回滾到任意時間點，需要靈活地快照、分叉、共享，處理好并發(fā)爭用與數(shù)據(jù)一致性。

To C 的終極形態(tài)。 現(xiàn)在你的 Agent 是跑在一臺機器上，獨占這個機器的環(huán)境。但如果你真的想實現(xiàn)類似 Jarvis 那樣的愿景 —— Agent 應該運行在你所有的設備上，提供統(tǒng)一的使用體驗 —— 那么這些 Agent 必然需要一個共享的記憶。

當復雜度開始升高，你早晚會開始使用數(shù)據(jù)庫來解決這些問題。除非你準備在文件系統(tǒng)上重新發(fā)明一個蹩腳的數(shù)據(jù)庫。

那么，數(shù)據(jù)庫到底能給 AI Agent 提供什么獨特的價值？

我認為有兩個殺手锏。

殺手锏一：時光機

第一個，是時間點恢復（Point-in-Time Recovery, PITR）。

在現(xiàn)有的 AI Agent 工作流里，如果 Agent 把事情搞砸了，是很難辦的。特別是當 Agent 完全依賴文件系統(tǒng)和 Git 來管理狀態(tài)時 —— 你是個純代碼開發(fā)者，又構(gòu)建了良好的 Git 工作流，能及時 commit 和 push，那還好說。但現(xiàn)實是，很多狀態(tài)并不在 Git 里：Agent 的配置文件、中間產(chǎn)出、臨時數(shù)據(jù)、工作記憶……這些東西一旦被誤操作，就回不來了。

Claude 誤刪代碼庫的案例已經(jīng)出現(xiàn)了，更不用說那些沒有被版本管理的數(shù)據(jù)。

你可能會說：我可以用 Git 或者 ZFS 做快照。可以，但有兩個問題：第一，快照是離散的時間點，你只能回到"上一個快照"，而不能回到"3 分 27 秒之前"那個精確的時刻 —— 比如誤刪除發(fā)生的前一秒。第二，你得顯式地管理這些快照：什么時候做、保留多久、怎么清理。這本身就是運維負擔。

以前，想實現(xiàn)"回到任意時間點"這種能力，只有兩條路：要么買昂貴的 CDP 硬件，要么自己實現(xiàn)一套復雜的日志系統(tǒng)。

PGFS 給了第三條路：把文件系統(tǒng)的所有寫入都變成數(shù)據(jù)庫的寫入，借助 PostgreSQL 的 WAL 日志，天然獲得 PITR 能力。

具體來說：當你往 PGFS 掛載的目錄寫文件時，數(shù)據(jù)實際上寫進了 PG 的 jfs_blob 表里。文件操作和數(shù)據(jù)庫操作共用同一套 WAL 日志。當你做 PITR 回滾時，數(shù)據(jù)庫和文件系統(tǒng)會同時回到指定的時間點 —— 精確到每個操作的微秒時間戳。

這意味著你的 Agent 擁有了一臺時光機：不管它做了什么，你都可以把一切恢復到任意一個時間點。 代碼、數(shù)據(jù)、配置、記憶，全部一起回滾，沒有任何不一致。

這還帶來了一個額外的能力：瞬間克隆與分支。因為代碼狀態(tài)本質(zhì)上也是數(shù)據(jù)庫里的數(shù)據(jù)，你可以基于某個時間點創(chuàng)建一個新的數(shù)據(jù)庫實例，里面的文件狀態(tài)和數(shù)據(jù)庫狀態(tài)完全一致。就像 Git 的 branch，但連數(shù)據(jù)庫里的業(yè)務數(shù)據(jù)也一起分支了。讓不同的 Agent 在不同的"分支"上工作，互不干擾。搞砸了？回滾。想試試另一條路？Fork 一個新環(huán)境。這是純文件系統(tǒng)方案做不到的。

對于 AI Agent 來說，這個能力的價值怎么強調(diào)都不過分。它讓你有了一個"無限撤銷"的安全網(wǎng) —— 或者說，一個可以隨時存檔/讀檔的游戲存檔系統(tǒng)。

殺手锏二：共享大腦

如果你只有一個人、一個 Agent，那確實不需要共享。但是當你開始用并行的 Agents、Sub-Agents 時，就需要一個高效溝通的地方。

目前的單機模式是怎么做的？在項目目錄里寫一個 Markdown 文件當 To-Do List，手動派發(fā)任務，讓 Sub-Agent 去執(zhí)行。一個人的時候勉強能跑。但如果用一張數(shù)據(jù)庫表來記錄任務，所有 Agent 都從里面取活、更新狀態(tài)、上報結(jié)果 —— 這就是一個天然的任務調(diào)度中心。不需要文件鎖，不需要輪詢，數(shù)據(jù)庫的 MVCC 和 NOTIFY/LISTEN 天然解決并發(fā)問題。

更重要的是：文件目錄很難簡單地共享給其他人。 你可以用 FTP、NFS，但配置麻煩，安全性也是問題。

而 PGFS 的共享方式非常優(yōu)雅。設想這樣一個架構(gòu)：

1.你有一臺云服務器，上面運行著一套 Pigsty（包含 PostgreSQL）。2.在上面創(chuàng)建一個 PGFS 掛載點，比如 /fs。3.所有項目代碼、Agent 配置、共享記憶，都放在這個目錄下。4.團隊里的任何一個人，只要知道數(shù)據(jù)庫連接串，就可以用一行命令把這個目錄掛載到自己的本地機器。

一行連接串，一行掛載命令 —— 就可以讓多個人、多臺機器、多個 Agent 共享同一個工作空間。

我現(xiàn)在自己的工作方式就是這樣：一個基于 Pigsty 的 Monorepo，所有項目都在里面。云服務器上可以直接用 Claude Code 干活，同時把云端的 PGFS 掛載到本地，實現(xiàn)本地讀寫。多平臺、多實例、無縫同步。

可以每個人負責一個子項目，在一個整體 Repo 里面協(xié)作。

再往遠了想：如果你真的想要一個 Jarvis 風格的數(shù)字管家，它肯定需要一個集中的地方來存儲狀態(tài)。你不能讓每個 Agent 都有自己獨立的記憶 —— 否則你得到的不是一個助理，而是一群互不知情的蝦兵蟹將。

多個 Agent 共享記憶，最自然的方式就是建一個中樞：云端一臺虛擬機，跑一套 Pigsty，通過一個 URL 把數(shù)據(jù)庫掛載到本地。每一個 Agent 都可以讀寫共享狀態(tài)，同時保留各自的私有記憶。

當然除了上面兩點之外，還有很多其他的好處，ACID，高可用，可觀測性，備份恢復，復制 / CDC 工具，這里就不一一展開了。

怎么做：Pigsty 的 JUICE 模塊

說了這么多"為什么"，來說說"怎么做"。底層能力一年前就有了。當時我已經(jīng)把 JuiceFS 打包到了 Pigsty 里。在 Pigsty 4.0 版本中，正式發(fā)布了 JUICE 模塊，把整個流程做成了聲明式配置，一鍵部署。

什么是 JuiceFS？

JuiceFS 是一款高性能的 POSIX 兼容分布式文件系統(tǒng)。架構(gòu)很簡潔：一個元數(shù)據(jù)引擎 + 一個數(shù)據(jù)存儲后端。元數(shù)據(jù)引擎管理文件目錄樹和屬性，數(shù)據(jù)存儲后端存放文件內(nèi)容。

PGFS 的核心設計就是：JuiceFS 支持用 PostgreSQL 同時作為元數(shù)據(jù)引擎和數(shù)據(jù)存儲后端。 所有的文件元數(shù)據(jù)和文件內(nèi)容都存在 PG 里，共享同一套 WAL 日志。（TimescaleDB 最近出了一個 TigerFS，提供類似功能，但成熟度偏低。我也已經(jīng)打包整合了。）

聲明式一鍵部署

在 Pigsty 的 vibe 配置模板中，就已經(jīng)提供了一個配置好的例子。只要你在一臺全新的 Linux 服務器上執(zhí)行這幾行命令，那么你在 /fs 這個目錄上就已經(jīng)擁有一個預先定義并掛載好的 PGFS 了。

curl -fsSL https://repo.pigsty.io/get | bash; cd ~/pigsty
./configure -c vibe -g # 使用 vibe 模式，生成隨機密碼！
./deploy.yml # 部署基礎設施和 PostgreSQL
./juice.yml # 部署 JuiceFS 文件系統(tǒng)

你對這個默認定義的 /fs 目錄下的所有文件讀寫都會落在數(shù)據(jù)庫里，而你也可以將這個數(shù)據(jù)庫同時掛載到其他目錄，甚至是多個不同電腦上的本地目錄，實現(xiàn)目錄共享。而這一切都是通過一段簡短配置定義的：

juice_instances:
jfs:
path: /fs # 掛載到本地的 /fs 目錄
meta: postgres://dbuser_meta:DBUser.Meta@10.10.10.10:5432/meta
data: --storage postgres --bucket 10.10.10.10:5432/meta \
--access-key dbuser_meta --secret-key DBUser.Meta
port: 9567 # Prometheus 監(jiān)控指標端口

就這么簡單。系統(tǒng)會自動完成 JuiceFS 的格式化、掛載、開機自啟配置和監(jiān)控集成。

你也可以輕松依葫蘆畫瓢定義多個 JuiceFS 實例，或者把同一個實例共享掛載到多臺不同的機器上面去

app:
hosts:
10.10.10.11: {}
10.10.10.12: {}
vars:
juice_instances: {....}

最妙的是，不僅僅是這些 Linux 服務器可以共享掛載，對于 macOS 和 Windows 用戶，你也可以把云端的 PGFS 掛載到本地：

juicefs mount "postgres://dbuser_meta:DBUser.Meta@10.10.10.10:5432/meta" ~/work -d

一行連接串就是你的"共享云盤"入口。 比 NFS、FTP 簡單太多。我最近準備弄一個一鍵配置腳本，在 macOS 和 Windows 上一次新配置好 Juicefs，只需要一鍵填一個 URL，就可以立即把所有的事情配置好。

當然，對于老司機來說，一看就知道怎么回事了，你只需要把 Claude Code，Codex，OpenClaw 在家目錄下的 dot 目錄移動到這個掛載上來的共享工作目錄然后軟鏈接回原位，你的 Agent 狀態(tài)就存儲到數(shù)據(jù)庫中了！

而且最棒的是，性能也還不錯。和原生文件系統(tǒng)比，PGFS 的吞吐量肯定差一些。但實測數(shù)據(jù)還不錯，文件讀寫大概在百MB/s 上下的吞吐量，而且 JuiceFS 也有本地緩存機制，對于 Odoo，Coding Agent 之類的場景肯定是綽綽有余了。

當然，最棒的特性莫過于當 Agent 把你的環(huán)境搞砸了，你可以使用 pitr 一鍵回滾到任意時間點的黑魔法：

總結(jié)

回到最初的問題：AI Agent 到底需不需要數(shù)據(jù)庫？

對于單人單機的簡單場景，確實不一定需要，SQLite 也可能夠了。但 Agent 的世界正在變得越來越復雜 —— 多 Agent 協(xié)作、團隊共享、狀態(tài)持久化、容錯回滾。這些需求一旦出現(xiàn)，數(shù)據(jù)庫就不是可選項，而是基礎設施。

PGFS 通過 Pigsty 的 JUICE 模塊，給 AI Agent 提供了兩個殺手锏能力：

1.時光機：基于 PITR 的任意時間點回滾，代碼、數(shù)據(jù)、配置、記憶一起恢復。還能瞬間克隆和分支，讓 Agent 在不同的"存檔"上并行實驗。2.共享大腦：多 Agent、多人、多機器共享同一個工作空間和記憶。一行連接串，一行掛載命令。

這兩個能力，是純文件系統(tǒng)方案做不到的。以前實現(xiàn)這些需要幾十萬的 CDP 硬件。現(xiàn)在？一臺云服務器，一套開源軟件，四行命令。一分錢都不要。

這才是數(shù)據(jù)庫在 AI 時代的正確打開方式。

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

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

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

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