DeepSeek Harness 的 DSH plugin 后台任务：run_in_background 与 jobId

DSH plugin 让工具跑后台任务的办法是：用 producer 配置控制 run_in_background，在分支里调用 ctx.jobs.start({ kind, label, owner: exec.agent, run }) 注册任务，成功后返回类型化句柄 { kind: 'background', jobId }。 适合长耗时工作；发布 id 之后你必须改用任务自有的取消信号，而不是 exec.signal——这是很多 DSH插件 最容易踩错的一处。这与 工具插件开发 讲的前台契约是同一套工具模型的两个分支。

DSH plugin 的后台任务怎么开：producer 控制 run_in_background

后台能力不是工具自己开线程，而是由 producer 配置控制 run_in_background，把工作交给任务运行时（来源）。 判断依据很直接：

1. 工作是否长耗时 — 需要等待很久、又要让调用方立刻拿到句柄的场景。预期：走后台任务，而不是让前台调用阻塞。
2. 是否需要在执行中查看输出 — 希望过程中能拉取或接收输出追加。预期：后台任务提供 output 源与推送通道。
3. 是否需要独立于调用的生命周期 — 调用被取消后工作仍应继续。预期：后台任务生命周期归 job_kill、owner dispose 与服务 teardown，而不是调用方。

注册表在进入 producer 主体前会把已预先中止的调用判为失败：此时没有任务，其 id 无法满足成功输出 schema（来源）。

DSH plugin 怎么注册后台任务：ctx.jobs.start 与类型化句柄

用 ctx.jobs.start({ kind, label, owner: exec.agent, run }) 注册任务，成功分支返回类型化规范句柄（来源）。 按三步落地：

1. 声明后台分支 — 在 producer 里判断是否需要后台执行。预期：只有长耗时路径进入该分支。
2. 调用 ctx.jobs.start — 传入 { kind, label, owner: exec.agent, run }。预期：运行时校验 owner 与任务控制器可用后开始工作。
3. 返回类型化句柄 — 返回 { kind: 'background', jobId }。预期：调用方拿到 id，而不是等人读文本。

为什么强调类型化句柄：Native 渲染器可以保留 started background job bash-1 这类供人阅读的自然语言，但 PTC mode 绝不能通过解析该文本取得 id——程序只能读 jobId 字段，工具主体也不该迫使调用方从自然语言里解析 id 与字段。

DSH plugin 后台任务的 id、取消与输出怎么管

ctx.jobs.start() 发布 id 后，应使用任务自有的取消信号，而不是 exec.signal（来源）。 关键约定：

• 取消语义一变：之后取消外层调用只会停止等待本次调用，不会终止已经发布的工作。
• 生命周期归属：任务生命周期归 job_kill、owner dispose 与服务 teardown 所有。
• spec 提供的能力：同步 cancel、在资源清理后 settle 且不 reject 的 done，以及拉取式 output 源或经 starter 收到的 JobHandle 推送的追加。
• 输出读取：面向模型的消费式读取由 dsh-tool-jobs 从输出环渲染。
• 前台仍然耦合信号：前台工作仍与 exec.signal 耦合，这点没变。

写完请自检三项：你写出的后台分支是否返回了 jobId 字段而非依赖文本；发布 id 后你是否改用任务自有取消信号；owner 是否设为 exec.agent 以便正确清理。想要现成的任务类工具实现对照，可在 DSH Plugin Hub 找同类插件。