TigerFS 连载 1 | Agent 的状态该放在哪里：一场正在发生的路线之争
digoal约 8 分钟系列第 1 篇 / 共 6 篇
本文是整个 TigerFS 系列的地基。不理解这一篇，后面 5 篇就只是在记 API。
一个 2026 年才出现的问题
1971 年，Unix 创造者用一句话定义了文件系统的社会契约："Everything is a file." 这句话在接下来的五十年里塑造了整个计算工业——编译器、终端、编辑器、Shell 管道，全都建立在这条契约上。
但这句话有一个前提：文件是本地磁盘上的字节。一旦文件背后不是字节，而是一套需要并发控制、需要事务、需要审计的共享状态，它就裂开了。
2025 年之后，裂痕被 AI 放大到无法回避。因为 LLM 是通过文件系统认识世界的：它的训练语料是代码仓库和文档，它的工具集是 ls/cat/grep/edit，它的"记忆"是文件。而今天，一个 Agent 干的事是：
三个 Agent 同时改同一批文件 一个 Agent 探索了 40 步，最后发现方向错了 人类在 Agent 执行到第 17 步时喊停："回到第 10 步" 事后要回答："上周三下午，是哪个 Agent 把这张表删了？"
这些问题，文件系统用 mv 和 .bak 文件能回答吗？能，但代价是：单写者假设、无事务、跨机器不可用、回滚要靠人肉 git 操作。
于是问题来了：当 LLM 成为数据的主要消费者，文件系统的角色是不是要重上一次？
赛道全景：三层栈，不是三个选项
过去一年，这个方向上出现了至少 30 个项目。如果不做分层，会看成一团乱麻。我把它拆成三层：
A 层：Agent 在哪跑
这一层解决的是隔离与生命周期。Agent 要执行代码就要有执行环境，而传统容器启动太慢、状态易丢，所以催生了一大批"Agent 专用沙箱"。
snapshot_filesystem() 可 fork 出并行分支 |
值得注意的是 Cloudflare Computer 官方文档里的一段自陈，很有引用价值：
"Container access goes through FUSE, so heavy IO workloads (large
node_modulesinstalls, big tarball extractions) take a measurable performance hit compared to a native filesystem."
FUSE 在这个赛道不是小众玩法，是已经有人押上生产的架构选择。 这为 TigerFS 的技术选型提供了外部佐证——但也同时说明了 FUSE 的性能代价是真实存在的。
B 层：状态存在哪、怎么回滚
这一层解决的是断点续跑与时间旅行。
LangGraph 的 checkpointer 是这个赛道最成熟的方案：图状态在每个 super-step 边界存快照，三档 durability（exit/async/sync），配套 time travel 支持从任意历史检查点 replay 或 fork。
这里有一个值得停下来想的事实：LangGraph 为什么要单独发明 checkpointer，而不是用文件系统？
因为它需要三件文件系统给不了的东西：(1) 状态与执行位置的绑定——不是"文件回到某版本"，而是"我从第 N 步重跑"；(2) pending writes 容错——进程崩溃时正在写的状态不丢；(3) 人在回路——在特定节点挂起，等人批准再继续。
这三件事，本质上是工作流引擎的语义，不是文件系统的语义。TigerFS 并没有解决 LangGraph 的问题，它解决的是相邻但不同的另一个问题。这个区分很重要，后面第 4 篇会展开。
Temporal 是传统分布式 durable execution 领域的答案，正在切入 Agent 场景。窗口协议层则有 MCP Roots——让客户端向 server 声明文件系统边界。
而代码 Agent 那一支，出人意料地一致：
/rewind | ||
/undo | Git 本身 | |
.cursor/rulesAGENTS.md |
四个工具，四种实现，一个共同点：全部用 Git 或影子 Git。 没有人把它们的状态放进数据库事务。
这构成了 TigerFS 论点的核心语境：主流答案认为"文件系统适合人和 Agent 读写，版本控制交给 Git"。TigerFS 主张的是另一件事——
文件系统不应该是磁盘的视图，而应该是数据库事务的另一个视图。
C 层：数据即工作区
这是 TigerFS 所在的一层，也是争议最大的一层。
我按 GitHub API 在 2026-10-07 实测了三个关键项目：
AgentFS 是这个赛道里最重要的对照组，它比 TigerFS 早三个月发布，star 数是后者的近 5 倍。Turso 官方博客对其定位的表述是"the filesystem for agents"，技术路径更激进：整个 Agent runtime 就是一个 SQLite 文件，cp agent.db snapshot.db 就是一次快照。
它和 TigerFS 站在同一个立场上——Pekka Enberg 明确论证了文件系统抽象对 Agent 是有效接口——但选了完全不同的底座。
一个耐人寻味的产业事实
TigerData（TimescaleDB 母公司）在做 TigerFS 的同时，也在推 Agentic Postgres 这个商业产品，内置 MCP server、master prompts、pgvectorscale、BM25 全文检索，以及 copy-on-write 即时 fork。
这是同一家公司押注同一命题的两种不同技术路线：
TigerFS 走"文件系统是 API"——开源、FUSE、为 Unix 工具链优化 Agentic Postgres 走"MCP / 工具是 API"——闭源商业、copy-on-write、为 SaaS 场景优化
一家最懂 PostgreSQL 生态的公司，同时押了两条互相竞争的路线。这说明的不是路线对错，而是这个命题本身还没收敛。谁先跑出来，现在下结论还太早。
反对意见：必须摆在桌面上
这个题目最有价值的地方在于，支持方和质疑方都有一手来源。
质疑一：性能，至今没有答案
InfoQ 在 2026 年 4 月 4 日的专文报道里引用了 Hacker News 的讨论。用户 iamcalledrob 的提问直指要害：
"I wonder what the performance characteristics are? I'm assuming this is going to work well for small datasets that fit in memory, and probably less well beyond that. Also curious how the tables and index are maintained, for example if there's a write heavy workload. Does TigerFS handle rebuilding/repacking and the associated drudgery?"
InfoQ 自己的结论也带着保留：
"TigerFS translates filesystem operations into SQL queries, so complex operations like recursive directory traversals may result in multiple database queries that could impact performance."
这条质疑的可信度很高，因为它直指架构本质。 文件系统的心智模型允许你随手 find . -name '*.md'，而在 SQL 里这可能是递归 CTE + 多次往返。更关键的是：截至 2026-10-07，TigerFS 没有任何公开的性能 benchmark。这个问题提问至今，我在公开渠道没有找到回应。
质疑二：有人已经用脚投票选了另一条路
arc0.me 的一篇文章（2026-03-13）标题就叫《Agents Need a Database, Not a Filesystem》。作者运行着一个 7×24 的自主 Agent（74 个传感器、约 108 个 skills），从文件迁移到了 SQLite。他给出的实证是：并行传感器读写同一 JSON 文件造成 read-modify-write 竞态，导致 62% 的任务量是连锁重复。核心论断：
"Lock files are just bad databases."
这个案例和 TigerFS 的主张其实是互补的——他证明了并发文件确实会坏，TigerFS 正是来解决这个的。但他的结论（用 SQLite，而不是用 Postgres + FUSE）说明：问题是真的，但解法未必是 TigerFS 给的那个。
两篇 arXiv 预印本给出了更严谨的边界划分，其中一条直接反驳"把 Agent 状态放数据库再挂出去"的做法：
SQLite 的 WAL 模式是单写者的，且不适合放在网络文件系统上。
Interchange Is Not Storage Beyond Session JSON
Health Samurai 会议记录里的一句话，是对这个命题最精准的反驳：
"You can simulate files on a database, but not the reverse."
（你可以在数据库上模拟文件，反过来不行。）
质疑三：作者自己承认的限制
Michael Freedman 在 HN 上亲口说过：
"TigerFS works well with local PG — in fact, all of my testing framework uses this setup. Big upside of this is latency; main downside is that such a deployment is primarily 'single user mode.'"
而官方文档 tigerfs.io/agents.txt 里明确写着：history 和 undo 需要 TimescaleDB。也就是说，这个项目最核心的"可回滚 Agent 状态层"卖点，对社区版 PostgreSQL 用户并不成立。这是一条商业模式上的硬约束——也是判断它能走多远的关键。
我的判断：三条路线，三种赌注
把上面这些材料放在一起，我觉得可以给出一个有依据的判断：
第一，"文件是 Agent 的自然接口"这个命题已经被验证了。 这不需要 TigerFS 来证明——AgentFS 用 SQLite 拿到了 5 倍 star，Cloudflare 用 FUSE 上了生产，而所有主流编码 Agent 都在用文件工具。接口之争已经结束了，赢的是文件。
第二，争议不在接口，在底座。 TigerFS 选 PostgreSQL，AgentFS 选 SQLite。这个选择决定了三件事：能不能多写者并发（TigerFS 能，SQLite WAL 不能）、能不能跨机器共享（都能）、能不能接上企业既有的数据资产（只有 TigerFS）。TigerFS 的赌注是"Agent 的工作区会和业务数据长在一起"，AgentFS 的赌注是"Agent 的状态是自包含的"。
我的倾向是：长期看 TigerFS 的赌注更接近真相。 理由是 Agent 正在从"写代码"扩展到"操作业务数据"，一旦跨过这条线，状态就必须落在有事务保证的多用户系统上。但这个判断有明确的前提假设——前提是 PostgreSQL 的性能问题能被解决。而目前没有任何公开数据能证明这一点。
第三，这个赛道还远未定型。 TigerFS 710 star、两个主要贡献者（572 commits 来自 mfreed 一人）、2026 年 1 月才创建、没有任何第三方生产案例。AgentFS 标注 BETA。我不认为现在有资格说谁赢。
接下来
这个系列接下来会做什么：
第 2 篇：TigerFS 到底怎么把 PostgreSQL 挂成文件系统， ls背后发生了什么第 3 篇：一条路径如何变成一条 SQL——查询下推的设计与代价 第 4 篇：让 Agent 可以反悔——savepoint、原子 undo 与 per-user undo 的实现 第 5 篇：实战，给多个 Agent 建一块真的能用的共享工作区 第 6 篇：边界、代价与反对意见——什么场景该用，什么场景绝对别用
第 6 篇会回到本文提出的性能质疑，用我自己的实测数据给出回答。
本文事实核查说明
所有 star/fork/创建日期为 2026-10-07 通过 GitHub API 实测 TigerFS 内部机制类论断在后续文章中标注了源码位置，并在本机 PostgreSQL 18.6 + TimescaleDB 2.30.1 上实测验证 融资数字、benchmark 分数、第三方生产案例：本文一律不引用（该领域数字互相矛盾严重，无法交叉验证） 各代码 Agent 的 checkpoint 机制均引自各自官方文档