SQLite + Litestream + 廉价容器 = 持久化Agent工作流。539位HN读者点赞的核心洞察：AI Agent场景下，一坨本地SQLite文件比一套Postgres集群更靠谱。
事件回顾
5月29日，Obelisk项目团队在博客发表了一篇题为《SQLite is All You Need for Durable Workflows》的文章，迅速在Hacker News引爆讨论，拿下539 points、268条评论，成为当日最热技术话题。
这篇文章的核心论点犀利而直接：对于绝大多数AI Agent工作流场景，SQLite就够了，不需要Postgres。
文章的导火索是DBOS团队此前提出的"Postgres is all you need for durable execution"观点——既然你已经信任你的数据库，为什么还要额外搭一层编排系统？Obelisk团队认可这个方向，但认为可以再往前推一步：连Postgres都不需要，SQLite就能搞定。
文章发表后，HN评论区炸了。有人说"这是今年最清醒的技术文章"，有人反驳"等你到生产环境就知道Postgres为什么存在了"，也有人表示"这正是我一直在做的事，终于有人写出来了"。
核心观点拆解
1. 持久化的关键是状态，不是计算
这是文章最底层的认知翻转：
"Durable execution is often discussed as if it requires durable infrastructure. In many cases it does not. The durable part is the workflow state. The compute can stay cheap and disposable."
翻译成大白话：工作流引擎不需要自己"持久化"，它只需要把状态持久化。 计算节点可以随时挂掉、重启、更换——只要工作流的状态（执行到哪一步了、中间结果是什么、下一步该调哪个函数）安全存在某个地方就行。
这彻底颠覆了传统工作流引擎（Temporal、Airflow、Prefect）的设计范式——它们都需要一套独立的持久化基础设施来保证引擎本身的高可用。而Obelisk的思路是：引擎是临时工，SQLite数据库文件才是老板。
2. SQLite的杀手优势：零运维负债
"SQLite is appealing because it gives you transactional durable state without introducing a separate database service. There is no network hop, no extra control plane, and no new operational surface area just to keep workflow progress safe."
这段话点出了AI Agent开发者最痛的场景：你只是想跑一个Agent工作流，结果要配Postgres、要搞连接池、要处理网络超时、要担心数据库挂了Agent全挂……SQLite的方案是：
- 无网络跳转：数据库文件就在本地，读写是文件系统级别的
- 无额外控制面：不需要管理数据库用户、权限、连接数
- 零运维表面积：不需要维护一个独立的数据库服务
对于大多数AI Agent场景（个人开发、小团队、实验性项目），这简直是降维打击。
▲ Postgres集群 vs SQLite单文件：AI Agent场景下的持久化方案对比
3. Litestream解决"SQLite不能分布式"的千古难题
SQLite最大的槽点是什么？"它只是个文件，怎么备份？怎么迁移？机器挂了怎么办？"
文章给出了一个成熟方案：Litestream——一个开源工具，可以异步地将SQLite的WAL（Write-Ahead Log）变更流式复制到S3兼容的对象存储。
工作流程是：
- Agent在本地跑，工作流状态写入本地SQLite文件
- Litestream在后台持续把变更同步到S3
- 容器挂了？从S3恢复SQLite文件，继续跑
- 想分析Agent行为？从S3拉SQLite文件，本地直接查
文章也诚实地指出了Limitation：Litestream复制是异步的，如果SQLite所在磁盘在最新变更被复制到S3之前就彻底损毁，会丢失少量最新写入。但对于绝大多数AI Agent的"实验性、bursty"工作负载来说，这个trade-off完全可接受。
4. 为什么AI Agent特别适合这个模式
这是文章最精彩的部分——它精准描述了AI Agent工作负载的特征：
"AI agents and AI-generated workflows are often bursty, experimental, and easier to reason about when each agent or tenant has a small self-contained unit of state."
AI Agent工作流的特点：
- 爆发式：不是持续稳定的流量，而是一阵一阵的任务
- 实验性：今天跑这个Agent，明天可能就换方案了
- 隔离友好：每个Agent或租户天然适合拥有独立的状态单元
在这种场景下，"一堆微VM/容器，每个带一个SQLite数据库+S3备份" 的架构，远比"一个always-on的共享Postgres集群"更合理。
▲ 去中心化Agent架构：每个微VM/容器自带SQLite + Litestream S3备份
优点包括：
- 更简单：不用管理数据库连接、连接池、事务隔离
- 更便宜：不需要7×24运行的数据库实例
- 更好的故障隔离：一个Agent的SQLite坏了不影响其他Agent
5. 什么时候还是该用Postgres
文章没有无脑吹SQLite，而是清晰地列出了Postgres更合适的场景：
- 需要高可用：如果你不能接受任何数据丢失，需要同步复制
- 需要共享可扩展性：多个服务需要同时读写同一份工作流状态
- 需要更复杂的查询能力：比如跨Agent的聚合分析
- 异步复制到对象存储不是你要的持久化模型
"Many workflow systems do not need that on day one and should not start with more infrastructure than their state actually demands."
这句话是整篇文章的黄金法则：不要从第一天就为你不存在的需求搭建基础设施。
对AI创业者的启示
启示1：Agent工作流引擎正在"去中心化"
传统的Temporal/Cadence架构要求一个中心化的持久化层，但AI Agent场景正在推动"每个Agent自带状态"的范式。这意味着：
- Agent编排工具可以更轻量
- 部署模型从"平台化"走向"库化"
- Agent的"搬家"成本极低（一个SQLite文件+一个S3备份）
启示2：SQLite正在成为Agent的标配
不只是Obelisk——越来越多的Agent框架正在默认使用SQLite：
- Claude Code 的会话状态用SQLite存储
- OpenClaw 的Agent记忆用SQLite
- Hermes Agent 的对话历史和技能状态也基于SQLite
这反映了一个趋势：Agent的状态存储不需要企业级数据库，需要一个简单、可靠、零配置的本地存储方案。
启示3：Litestream类工具值得关注
如果你在构建Agent工具或平台，Litestream（或类似的WAL流式复制方案）是一个值得集成的能力。它让SQLite从"单体局限"变成了"可备份可迁移的便携状态容器"。
类似的工具还包括：
- LiteFS（Fly.io出品）：分布式SQLite，支持多节点复制
- rqlite：基于Raft共识的SQLite集群
- Turso：基于libSQL的云端SQLite服务
行动建议
- 评估你的Agent工作流：如果你的Agent是爆发式、实验性的工作负载，认真考虑SQLite+Litestream方案，不要默认上Postgres
- 关注Obelisk项目：这是一个专门为AI Agent设计的Go语言工作流引擎，原生支持SQLite和Postgres双后端
- Litestream上手：如果你已经在用SQLite做Agent状态存储，花30分钟配置Litestream+S3备份，你就有了一个接近"生产级"的持久化方案
参考来源
- Obelisk博客原文：obeli.sk/blog/sqlite-is-all-you-need-for-durable-workflows（2026-05-29）
- DBOS "Postgres is all you need for durable execution" 前文
- Litestream项目：litestream.io
- Hacker News讨论：539 points / 268 comments
本文由AI辅助创作，经人工审核编辑发布