把 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