第一篇用一支九十秒 AI MV 追问长任务怎样活过进程；第二篇改用《城市如何在夜间醒来》动画解释视频，
因为 OpenMontage 的 animated-explainer manifest 能完整展示 research、proposal、script、scene plan、assets、compose 与 publish。
两个案例不是同一条业务 pipeline，却会遇到相同的等待、失败、返工、外部调用与人工验收压力。这里至少有两个不同的问题。
第一个问题是任务怎样继续存在：浏览器断开、worker 重启或某个外部服务超时后，这次任务是否仍然有同一个 ID， 系统能否知道已经发生了什么。第二个问题是agent 怎样推进制作：它怎样知道当前阶段、已经批准的决定、 何时必须等人、当前环境有哪些工具，以及渲染成功后还要检查什么。
阅读契约。 读完两篇后，应该能说清谁保存长任务身份、谁做创作决定、谁调用外部工具、谁批准产品交付； 也应该能解释，为什么 checkpoint 文件能帮助新会话继续，却仍然不会自动启动新的执行进程。
一、两篇分别解决哪一种中断
Temporal 和 OpenMontage 并不是同一类产品，OpenMontage 也没有在内部使用 Temporal。把它们放在一起，是为了比较两种“继续”： Temporal 保存执行身份与历史，让可用 Worker 继续处理任务；OpenMontage 让新 agent 通过操作说明、manifest、checkpoint 与工具注册表继续制作。
用户请求：制作一支 AI 视频
任务恢复
任务是谁？
已经确认发生了什么？
进程消失后谁能继续？
-> Chapter 01 · Temporal
制作推进
现在在哪个阶段？
哪些创作决定已批准？
可以调用哪些 provider 与 renderer？
成片怎样才算真的可交付？
-> Chapter 02 · OpenMontage二、阅读路线
三、两种“恢复”到底差在哪里
| 责任 | Temporal 这一篇 | OpenMontage 这一篇 |
|---|---|---|
| 持久身份 | Workflow Execution 与稳定的 Workflow ID。 | 项目目录与 project.json 标记。 |
| 历史事实 | 服务端追加式 Event History，可用于 replay。 | 阶段 checkpoint、decision_log.json 与 history/ 文件。 |
| 下一步 | Workflow 根据历史确定性地决定。 | agent 按 manifest 与 stage director 指令继续工作。 |
| 外部动作 | Activity 通过 Worker 执行。 | ToolRegistry 发现并按 capability 路由工具。 |
| 等待人工批准 | Signal / Update 与业务代码共同实现。 | manifest 声明需要批准；写入 completed 时须传入 human_approved=True。 |
| 恢复承诺 | 兼容的 Worker 轮询相应 Task Queue 后，可从历史重建控制流。 | 新的 agent 会话读取项目文件，按 manifest 顺序继续第一个未完成阶段。 |
最后一行是整个系列最重要的差别。OpenMontage 的文件协议把昂贵的创作劳动变成可检查、可接续的项目状态； Temporal 则把控制流本身变成跨进程可恢复的执行身份。一个生产系统可能同时需要二者，但不能因为都出现了 “checkpoint”或“resume”就把它们说成同一层能力。
例如制作停在一半时，Temporal 的 PollWorkflowTaskQueue
由应用 Worker 发起轮询；恢复的前提是有兼容的 Worker 在运行，服务端不会替应用启动进程。
OpenMontage 的 get_next_stage()
则按阶段顺序查找第一个未完成项：即使后面的文件已经存在，较早的 awaiting_human 阶段仍然不能跳过。
checkpoint 的批准检查发生在写入时，
单独读取 checkpoint 或寻找下一阶段不会复核批准，但后续阶段写入 awaiting_human 或 completed 前，
仍会重新检查前置阶段的完成与必需批准字段。
这些布尔字段不验证批准人身份；调用方仍需确认批准来源，并在恢复制作前核对已有外部产物，避免重复生成或付费。