Temporal 重放太重？Waymark 把工作流编译成字节码

durable execution（持久化执行）的通行做法是"重放"：把工作流代码存下来，崩溃后重新执行一遍历史来恢复状态。Show HN 上的新项目 Waymark（piercefreeman/waymark，MIT，HN 46 分、15 条评论，2026-11-07 快照，发帖约 7 小时）选了另一条路：不重放，编译——遍历你的 AST，把 Python 工作流逻辑映射成自家无栈 VM 的字节码。

piercefreeman/waymark 仓库

它怎么做（仓库口径）

编译式持久化：走 AST、生成 stackless VM 字节码，工作流状态恢复不依赖重放执行历史；
只用 Postgres 当任务队列：不引入额外的 broker；作者自测基准约 1,500 工作流/秒（作者口径，未经独立复现）；
Python 优先（JS 计划中），带 FastAPI 依赖注入集成；
Rust 核心：中心化的 Rust 内核负责集群并行化；
定位场景：后台任务与 agent runner 循环——长跑、可中断、要恢复的那种。

对照着看

Temporal、DBOS 这类 durable execution 方案验证了"工作流要能恢复"这个需求，但重放模型的成本——历史越来越长、副作用要幂等、调试要看回放轨迹——一直是被诟病的地方。Waymark 把"恢复"从解释执行变成字节码跳转，理论上状态恢复是确定性的字节码位置，而不是把历史再跑一遍。代价是：AST 到字节码的编译层要跟上 Python 语言的全部动态性，支持面（JS 还在计划中）与边界情况的处理是这种方案的长期考验。

判断

对在用 Temporal/DBOS 或在给 agent runner 找持久化底座的团队，Waymark 值得放进观察清单：编译而非重放是一条少数人走的路线，Postgres-only 的依赖栈对中小团队友好。三点校准：① Show HN 7 小时、单人作者，生产采用前等它多飞一会；② 1,500 工作流/秒是作者自测口径；③ 与 Temporal 的对比要看工作流复杂度——重放模型的生态成熟度（可视化、版本迁移、多语言 SDK）是编译路线暂时给不了的。