AI Agent 的持久工作流，不必一上来就搬出 Postgres

DBOS 的观点是：Postgres 足够支撑 durable execution。Obelisk 作者把这句话往更轻的方向推了一步：对大量 AI agent 和实验型工作流来说，SQLite 也许就够了。

这个判断反常，也有用。因为一聊“持久工作流”，很多团队马上想到共享数据库、调度集群、控制平面、高可用部署。可 durable execution 的核心，不是让计算永远活着。真正要守住的，是状态。

SQLite + Litestream 解决的是状态持久，不是平台永生

Obelisk 这套思路的事实锚点很简单：workflow progress 存在 execution log 里；工作流可以从持久历史 replay；activity 可以 retry。

也就是说，计算可以挂。机器可以换。任务可以重跑。只要执行历史还在，系统就有机会把进度接回来。

SQLite 在这里负责本地事务状态。它离运行时很近，没有额外数据库服务，也少一个网络依赖。Litestream 再把 SQLite 的变更异步流到 S3 兼容对象存储，用来备份、迁移和恢复。

这套组合最适合的对象，不是大一统平台。它更像给突发、实验性、按 agent 或 tenant 拆分的小工作流准备的默认值。

对 AI agent 开发者来说，这会改变一个动作：别急着先搭共享工作流中台。先把每个 agent 的状态单元做小，日志做清楚，恢复路径跑通。平台团队也可以晚一点采购或迁移重型数据库方案，先验证 agent 是否真的有稳定流量和共享扩展需求。

边界要钉死：Litestream 不是高可用数据库

异步复制不是小字注释。它是架构边界。

如果本地卷在最新写入同步到对象存储前消失，那部分写入可能丢。这个风险不能被包装成“云上容灾”。SQLite + Litestream 可以让小工作流更耐摔，但不能等同 Postgres 式共享高可用数据库。

选择其实不复杂：

这里还有几个工程变量，不能省。

并发写入压力有多大？恢复时的 RPO、RTO 能不能接受？对象存储延迟会不会拖慢恢复？本地卷的生命周期是不是可靠？这些问题答不出来，就别把“小架构”当万能药。

我不太买账的是另一种叙事：凡是 durable workflow，就默认需要一个中心化、常驻、强运维的平台。这听起来安全，实际可能只是提前缴税。

Postgres 当然有它的位置。高可用、共享扩展、强一点的运维边界，这些都是真需求。问题在于，很多 AI agent 系统还没证明自己有这种需求，就先把架构搭成了未来十倍规模。

AI agent 的默认架构该小一点，观察点也更具体

AI agent 现在的现实是：不稳定，突发，试错频繁，还特别需要事后看清“它到底干了什么”。

这类系统最怕的不是单个 agent 挂掉。更麻烦的是所有 agent 的混乱都被塞进一个共享平台，最后谁的问题都像平台问题。

更好的默认值，是先小、先隔离、先可观察。一个 agent 或一个 tenant 有自己的状态边界。出问题时能拉回日志，能 replay，能审计。坏也坏一小块。

这有点像早期铁路。不完全一样，但有相似的治理逻辑：先有局部线路跑通，流量、标准和调度压力上来后，再谈更大的网络。技术扩张常败在一个毛病：业务还没证明，帝国已经开工。

放到 AI agent 上，真正该观察的不是“SQLite 能不能打败 Postgres”。这个问题太粗。

更该看三件事：

• agent 的状态是否天然可按 tenant 或任务隔离；
• 最新几秒或几次写入丢失，业务能不能接受；
• replay、retry、审计是否比共享扩展更早成为刚需。

如果答案偏向隔离、可接受小窗口丢失、重视调试，那么 SQLite + Litestream 是一个值得先试的默认选项。不是因为它高级，而是因为它诚实。

如果答案偏向共享写入、高可用、不能丢最新状态，那就别省这个复杂度。该上 Postgres 就上 Postgres。省错地方，后面会用事故补账。

这篇文章真正提醒我的，不是 SQLite 又赢了一局。它提醒的是：AI agent 的持久化，不该被平台野心绑架。模型看着更强，产品未必更稳。先把状态守住，比先把城墙修高更重要。