一年前，我寫(xiě)過(guò)一篇文章叫《》。當(dāng)時(shí)是為了解決 Odoo 社區(qū)的一個(gè)需求：將文件與 PostgreSQL 數(shù)據(jù)庫(kù)一起做 PITR，回滾到指定時(shí)間點(diǎn)。

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

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

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

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

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

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

對(duì)于 To C 的本地單機(jī)單 Agent 場(chǎng)景，他說(shuō)得也許沒(méi)錯(cuò)。一個(gè)人用一個(gè) Claude Code，狀態(tài)就放在 .claude/ 目錄下，Git 管好代碼，沒(méi)什么問(wèn)題。在這種場(chǎng)景下拿 PG 來(lái)存儲(chǔ)狀態(tài)，有點(diǎn)拿著錘子找釘子的感覺(jué)。

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

什么叫"稍微復(fù)雜一點(diǎn)"？

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

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

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

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

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

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

我認(rèn)為有兩個(gè)殺手锏。

殺手锏一：時(shí)光機(jī)

第一個(gè)，是時(shí)間點(diǎn)恢復(fù)（Point-in-Time Recovery, PITR）。

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

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

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

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

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

具體來(lái)說(shuō)：當(dāng)你往 PGFS 掛載的目錄寫(xiě)文件時(shí)，數(shù)據(jù)實(shí)際上寫(xiě)進(jìn)了 PG 的 jfs_blob 表里。文件操作和數(shù)據(jù)庫(kù)操作共用同一套 WAL 日志。當(dāng)你做 PITR 回滾時(shí)，數(shù)據(jù)庫(kù)和文件系統(tǒng)會(huì)同時(shí)回到指定的時(shí)間點(diǎn) —— 精確到每個(gè)操作的微秒時(shí)間戳。

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

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

對(duì)于 AI Agent 來(lái)說(shuō)，這個(gè)能力的價(jià)值怎么強(qiáng)調(diào)都不過(guò)分。它讓你有了一個(gè)"無(wú)限撤銷(xiāo)"的安全網(wǎng) —— 或者說(shuō)，一個(gè)可以隨時(shí)存檔/讀檔的游戲存檔系統(tǒng)。

殺手锏二：共享大腦

如果你只有一個(gè)人、一個(gè) Agent，那確實(shí)不需要共享。但是當(dāng)你開(kāi)始用并行的 Agents、Sub-Agents 時(shí)，就需要一個(gè)高效溝通的地方。

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

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

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

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

一行連接串，一行掛載命令 —— 就可以讓多個(gè)人、多臺(tái)機(jī)器、多個(gè) Agent 共享同一個(gè)工作空間。

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

可以每個(gè)人負(fù)責(zé)一個(gè)子項(xiàng)目，在一個(gè)整體 Repo 里面協(xié)作。

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

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

當(dāng)然除了上面兩點(diǎn)之外，還有很多其他的好處，ACID，高可用，可觀測(cè)性，備份恢復(fù)，復(fù)制 / CDC 工具，這里就不一一展開(kāi)了。

怎么做：Pigsty 的 JUICE 模塊

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

什么是 JuiceFS？

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

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

聲明式一鍵部署

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

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

你對(duì)這個(gè)默認(rèn)定義的 /fs 目錄下的所有文件讀寫(xiě)都會(huì)落在數(shù)據(jù)庫(kù)里，而你也可以將這個(gè)數(shù)據(jù)庫(kù)同時(shí)掛載到其他目錄，甚至是多個(gè)不同電腦上的本地目錄，實(shí)現(xiàn)目錄共享。而這一切都是通過(guò)一段簡(jiǎ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)控指標(biāo)端口

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

你也可以輕松依葫蘆畫(huà)瓢定義多個(gè) JuiceFS 實(shí)例，或者把同一個(gè)實(shí)例共享掛載到多臺(tái)不同的機(jī)器上面去

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

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

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

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

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

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

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

總結(jié)

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

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

PGFS 通過(guò) Pigsty 的 JUICE 模塊，給 AI Agent 提供了兩個(gè)殺手锏能力：

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

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

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

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

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

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

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