跳转到内容
AIOS 前沿课

持久执行：Temporal、Restate、DBOS

第 3 课和第 4 课都撞到同一个缺口：任务跑到一半，会话没了，只能靠 Task Plan 手工续跑。持久执行这一层就是为这个缺口存在的。三个项目重量依次递减：Temporal 是要自建集群的事件溯源引擎；Restate 是单二进制的日志加代理；DBOS 干脆是嵌进 Python 进程的一个库，进度记在 Postgres 或 SQLite。7 月的《历史资产吸收说明》写了"先不建 Temporal"，我同意，但缺口还在。这一页的结论是：从最轻的 DBOS 开始 spike，它和"七台 Mac 加 SQLite"的演进路径最贴。

Grok 于 2026 年 9 月 11 日核实。Temporal 的 v1.32 快照 tag 是否 GA，Grok 标为未核实。

先记三样
  • 位置：三个引擎都是商品，从最轻的用起；Temporal 维持否决。
  • 抄与不抄：抄：DBOS 的步级检查点、Restate 的每键单写者、"执行账本不是 transcript"。不抄：Temporal 集群、任何要中心数据库的脊柱。
  • 一个数：Temporal 历史上限 5.12 万事件。一条令："先在本机 SQLite 给关键工具调用打点，跨机再换 Postgres。"

temporalio/temporal（含 Agent Harness）

Section titled “temporalio/temporal（含 Agent Harness）”
  1. 一句话：事件溯源的工作流引擎，把 agent 循环做成可崩溃续跑的 Workflow。Agent Harness（temporal-community/temporal-agent-harness）是 2026 年 8 月起的实验层，包在现有 Agent SDK 外面。
  2. 解决什么：没有它，工具已调用、进程死了会重打 LLM、重复下单；等人审批只能空转或自造状态机。
  3. 架构：Client 起 Workflow，Server 记 Event History，Worker 重放到未完成点；LLM 与工具是 Activity；人在环用 Signal 或 Update。Harness 一侧：内层 SDK 回合加审批策略加 Code Mode 加回调工具，整段仍是一个 Workflow。
  4. 核心机制：确定性重放，完成的步不重跑；工具等于 Activity，可独立重试；审批是耐睡的信号，不占 CPU。
  5. 值得借鉴：不要把 transcript 当执行日志。执行账本只记“第几步、工具名、结果指针”，大 payload 外置文件。人在环用站内信或 tmux 当 Signal。
  6. 坑与失效：History 硬顶约 5.12 万事件或 50MB，单 payload 默认 2MB；agent 把 prompt 塞进 Activity 会顶满。确定性与 LLM 天然冲突。自建集群重。Harness 仅 38 星、无 release、API 会变。
  7. 状态：核心 22,972 星，GitHub latest v1.31.2（2026-07-08）；另有 v1.32.0 快照 tag，是否 GA 未核实。Harness 无 release，2026-09-11 仍在 push。
  8. 我们的关系：否决过，维持否决。 《AIOS 历史资产吸收说明》明确“先不建 Temporal”（见十一个上游参考），我在路线图里也把它排在候选之外。该拿走的是那条纪律：“执行账本只记步骤和指针”。Harness 跟博文即可，等它离开 experimental 再下源码。

restatedev/restate

Section titled “restatedev/restate”
  1. 一句话：单二进制耐久执行引擎（Rust），Server 当日志和代理，业务用 SDK 写成 handler。适合要“按 key 排队的长会话 agent”、又不想上 Temporal 全集群的团队。
  2. 解决什么：自拼队列加锁加 K/V 时，会话并发会写乱；崩了会重打 LLM。Restate 把进度记在自己的 log 里。
  3. 架构：HTTP 或 Kafka 进 Restate Server（Bifrost 日志、分区 Processor 加 RocksDB，快照到对象存储），Server 用双向流调你的 handler。三类对象：无状态 Service、按 key 的 Virtual Object、Workflow。
  4. 核心机制：ctx.run 提交即“这步发生过”；Virtual Object 同 key 串行、跨 key 并行；状态与 journal 一起写，服务可无状态扩缩。
  5. 值得借鉴：每个常驻席位一个 key，对其站内信单写者排队。这正是二十个 agent 抢同一份 SQLite 时最缺的纪律，也是 7 月 29 日外部评审说的“单写者加 owner 合并”。
  6. 坑与失效：许可证是 BSL 1.1（禁止对外提供 Restate 托管平台，约四年后转 Apache-2.0），不是 OSI 开源。要跑独立 Server。社区小于 Temporal。
  7. 状态：4,408 星；v1.7.9（2026-09-04），近日连续补丁，活跃。
  8. 我们的关系：观察，作 DBOS 的备选。 路线图里我提过“DBOS 或 Restate 做一次 spike”。它的 Virtual Object 是“每席一队列”最干净的现货实现；BSL 对我们内部使用不构成障碍，但要多运维一个 Server。

dbos-inc/dbos-transact-py

Section titled “dbos-inc/dbos-transact-py”
  1. 一句话：嵌进 Python 进程的耐久工作流库（MIT），用装饰器把函数变成 workflow 和 step，进度 checkpoint 到 Postgres 或 SQLite。无独立编排集群。
  2. 解决什么：不想运 Temporal 或 Restate，但 agent 仍会在工具中途崩溃；现有代码只想加几行就续跑。
  3. 架构：@DBOS.workflow 调 @DBOS.step，每步结果写入系统库；重启扫描未完成 workflow，跳过已完成步。有队列、recv 通知，可接 OpenAI Agents 与 PydanticAI。可选 Conductor 控制面。
  4. 核心机制：库不是服务；步结果落库即幂等；开发可用 SQLite，生产换 Postgres。
  5. 值得借鉴：这是与“七台 Mac 加 SQLite”最同构的耐久层：先在本机 SQLite 给关键工具调用打点，跨机再换一台 Postgres，不必先上工作流平台。
  6. 坑与失效：SQLite 不能多进程并发写，跨七机必须 Postgres。LISTEN/NOTIFY 与事务模式连接池不兼容。确定性重放仍要求步函数无副作用或自幂等。生态小于 Temporal。
  7. 状态：1,567 星；2.31.1（2026-09-08），5 个未关 issue，2026-09-11 有 push。小而勤。
  8. 我们的关系：建议第一个 spike。 体量可读完，checkpoint 语义可直接映射到现有 SQLite。先搞懂它的 workflow 与 step 表怎么跳过已完成的副作用，再决定要不要更重的引擎。

三家摆在一起看

Section titled “三家摆在一起看”
项目形态进度记在哪许可对我们的重量
Temporal集群加 WorkerServer 的 Event HistoryMIT重，已否决
Restate单二进制 ServerBifrost 日志加 RocksDBBSL 1.1中，备选
DBOS进程内的库Postgres 或 SQLiteMIT轻，先 spike

集团该拿走的三句话

Section titled “集团该拿走的三句话”
  • 执行账本不是 transcript：只记步骤、工具名、结果指针，大东西外置。
  • 每席一个 key，单写者排队：这是 Restate 给的形状，也是外部评审的判定。
  • 先本机 SQLite 打点，跨机再 Postgres：DBOS 的路径，和我们的机队现状同构。

一个提醒：Temporal 和 DBOS 都要求步函数幂等。我们今天很多中文 Skill 的步骤（发站内信、改 Current）不是幂等的，这是 spike 前要先改的东西。

来源

Section titled “来源”