把 Agent 的狀態放進數據庫

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

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

但最近我發現，這個方案吸引了不少意想不到的用戶。他們不是來做 ERP 的，而是來存 AI Agent 狀態的。

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

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

Agent 到底需不需要數據庫？

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

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

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

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

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

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

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

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

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

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

我認為有兩個殺手锏。

殺手锏一：時光機

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

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

Claude 誤刪代碼庫的案例已經出現了，更不用說那些沒有被版本管理的數據。

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

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

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

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

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

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

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

殺手锏二：共享大腦

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

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

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

而 PGFS 的共享方式非常優雅。設想這樣一個架構：

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

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

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

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

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

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

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

怎么做：Pigsty 的 JUICE 模塊

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

什么是 JuiceFS？

JuiceFS 是一款高性能的 POSIX 兼容分布式文件系統。架構很簡潔：一個元數據引擎 + 一個數據存儲后端。元數據引擎管理文件目錄樹和屬性，數據存儲后端存放文件內容。

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

聲明式一鍵部署

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

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

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

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 監控指標端口

就這么簡單。系統會自動完成 JuiceFS 的格式化、掛載、開機自啟配置和監控集成。

你也可以輕松依葫蘆畫瓢定義多個 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 狀態就存儲到數據庫中了！

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

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

總結

回到最初的問題：AI Agent 到底需不需要數據庫？

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

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

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

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

這才是數據庫在 AI 時代的正確打開方式。

數據庫老司機

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

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

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