Background Jobs zh

后台任务

未实现。上游的任务生命周期注册表在 Edge 中没有服务端提供者。

上游参考：后台任务

上游提供了什么

任务子系统通过 ctx.jobs（JobRegistry）管理长时间运行的生产者工作。生产者拥有执行资源，运行时拥有身份、访问控制和生命周期状态。

• JobRegistry（ctx.jobs）— 抽象服务，提供 start()、list()、get()、read()、kill()、wait()。LocalJobRegistry 是进程本地的实现。
• 生产者契约 — 生产者声明种类（bash、subagent），提供 cancel() + done promise + 可选的 readOutput() 用于流式输出。
• 消费者视图 — JobSnapshot 投影，状态生命周期：running → stopping → completed/killed/failed。
• Session 集成 — apiproxy 订阅 onJobsChanged，通过 mux 通道广播 session/jobs 帧。

Edge 当前状态

未实现 依赖中没有 dsh-jobs 包。ctx.jobs 不可用。没有服务端任务管理。

客户端 UI 插件 dsh-client-ui-jobs 已包含在 33 个插件的 bundle 中——可以渲染任务状态面板和控件。但没有服务端的 JobRegistry，它无内容可显示。

Cloudflare 可用能力

Cloudflare 产品	可实现的功能	Plan 要求
DO alarms	定时唤醒用于延迟工作。Edge 已用于 WebSocket downlink 过期。可用于定期任务状态检查或超时强制。	免费
DO 进程内执行	短任务可直接在 DO isolate 内运行——和当前 just-bash 执行方式相同。受 Workers CPU 时间限制（免费 30s，付费 30min）。	免费 (30s) / 付费 (30min)
Cloudflare Containers	需要真实进程的长任务（原生构建、测试套件、大文件操作）。Container 可以和 DO 并行运行，通过 fetch 协调。完整 Linux 环境。	Enterprise / Workers Paid（beta）

架构缺口

缺口是 JobRegistry 提供者，不是概念本身。上游的 LocalJobRegistry 管理进程内存中的状态并做进程级清理。Edge 需要一个 DurableObjectJobRegistry：

• 在 DO 内存中追踪任务状态（与 DO 激活生命周期一致）
• 将任务元数据持久化到 DO KV 用于冷 session 恢复
• 简单任务委托给当前的 shell 后端（just-bash），重任务委托给 Container
• 通过现有的 WebSocket downlink 广播 session/jobs 帧

just-bash shell 已经在 DO 内同步运行命令。任务本质上是"一个带生命周期跟踪的异步运行命令"——执行引擎已有，生命周期包装还没有。

TODO

**评估基于 DO 状态的 JobRegistry。**上游 JobRegistry 是抽象的——一个 DO 专属的子类可以在 DO 内存中跟踪任务并用 KV 持久化恢复。短任务用现有的 just-bash 引擎；长任务可在 Container（付费 plan）可用时使用。先做仅 DO 的任务（兼容免费 plan），Container 委托作为升级路径。