暂停续跑 regrevia/dsh-pause-resume

dsh-pause-resume

DeepSeek Harness 会话标题栏里的一颗按钮。它停掉正在跑的东西——先让正在跑的回合收尾——把一份小计划写到磁盘，重启之后，还是这颗按钮，把那份活儿放回来。

* ⏸ —— 有活儿在跑。按下即停。
* ▶ —— 活儿已停，或上一个进程留下了待恢复的活儿。按下即恢复。
* ↻ —— 回合自己停了。按下即继续没做完的部分。
* ⏸ 变暗 —— 没有可停、可恢复、可继续的东西。

字形就是唯一的状态。没有计数器，没有面板，没有徽标，也没有浮层提示，因为第二个指示器就是同一事实的第二个真相来源。上一次按下若留下了需要人看一眼的东西，那一句话的提示会说明，按钮仍然只给同一个字形。

恢复什么

| 工作 | 暂停 | 恢复 |
| 有未完成回合的会话 | 回合收尾或取消，会话被记录 | 会话挂载，然后发一条可见的续接消息 |
| 已武装的目标 | 连同它当时的修订号一起暂停 | 用那个确切的修订号调 goals.resume；目标驱动器自行继续 |
| 只带着那个目标的会话 | 记录，不停任何东西 | 挂载；恢复的目标接管 |
| 正在跑的后台任务 | 杀掉并记录 | 只记录：任务是活进程，不可重放，所以续接消息会点名它，活儿还需要它时回合会重启它 |
| 正常结束的会话 | 不动 | 不动，而且一开始就不会被记录 |
| 终端 / 已结束的会话 | 不动 | 不动 |
| 定时计划 | 不动 | 不动 |

定时计划不暂停：计划服务没有禁用操作，只有删除，而为了暂停就删掉别人的计划，这买卖本插件不做。暂停期间触发的计划会起一个回合，但只要有暂停计划在等，按钮就一直显示 ▶：待处理的计划占着主操作，所以唯一诚实的下一步就是把恢复做完。那次恢复的摘要里会像其他在按下之后才起的工作一样列出这个计划。

暂停做什么

按下不会立刻取消。它先让正在跑的回合收尾，只取消窗口关闭时还在跑的部分：wrapUpMs（默认 3000；0 表示立即取消，0.9.0 之前的每个版本都是这样）。窗口内结束的回合按已完成停掉；其余的到点取消，所以暂停之后也绝不会留下一个回合在背后跑。无论哪种情况，计划都会写下，会话都会被记录，下一步都一样：按 ▶ 恢复，或者重启让计划被接走。有东西不得不取消时，提示会说待续的活儿已保存；全都自己收尾了，提示就不多说。

窗口关闭时若转向指令还没被读，按下就把它收回：一次没真正发生的暂停不得在恢复后的会话中把它当作新指令重放。只移除那一条消息，只针对已超时的会话，且只在它仍在队列中时移除；队列不可读时，报告写 retractUnavailable，而不是声称队列干净。

没人会再按的计划会自行关闭。手动重启后，你只要自己收尾这些会话就够了：每个已停止的回合都会被判定为仍在运行、已向前推进且不再运行，于是计划像完成恢复那样落定，按钮回到暂停，无需按下。只考虑暂停本身停掉的回合，且只凭正面证据：会话仍在工作、会话列表读不出来，或出现错误，都让计划保持原样。

恢复如何工作

恢复并不声称工作仍在继续。它对每一项做三步诚实的操作：

1. 挂载。 已停止的会话通过 Harness 恢复路径挂载，保留其智能体预设。若已挂载，跳过此步。
2. 继续，只在按下确实取消了回合的地方。 继续是一条普通用户消息，经 sessionController.prompt 发送，请求 id 由计划和会话派生。该 id 让重复恢复幂等，消息在记录中可见，所以人能确切看到恢复了什么。
3. 重新武装目标，用暂停时的修订号。修订号是人的否决权：若目标在暂停期间变了，就不该由我们恢复，该项为 skipped。

每次尝试都记入日志，带上发起它的进程 id，但日志只是报告，不是承诺：下次启动会重新询问运行中的 Harness，而不是信任旧记录。继续请求 id 由计划和会话派生，所以回合开始前的重试会被 Host 去重。失败会把计划留在磁盘上，下次按下会重试每个仍需处理的项。

子代理会话无法由本进程挂载：其父聊天掌管路由。该行作为给父级的注意项报告一次，不当作失败重试，因此它永远不会让计划保持打开。

崩溃，不只是按下

按下会写快照。崩溃什么都不写，所以插件改为保持心跳：running.json 保存当前回合打开的会话，以及写入它的进程 id。上一进程的记录在心跳文件被替换前转成 pending.json 中的崩溃计划，所以第二次或第三次重启仍看到同样的工作，并提供 ▶，无需按下。

崩溃记录比按下弱：它证明会话存在过，不证明重启后回合是打开的。恢复会挂载每个记录的会话并读取实时回合。回合仍在运行的行会被继续；空闲的行由探测保持空闲，探测挂载它来读取，并不是提示词。状态读不出或无法证明的行，一律报为 unknown，而 unknown 不算完成：计划留在磁盘上，按钮继续显示 ▶，下次按下再试。记录下来的目标一律恢复，不管它所在会话的轮次能否证明——丢掉它才是那条老路：一组崩溃的会话，所有目标都在关注列表里，却一个也没恢复。正常结束的会话从不写进这个文件。

同一进程重新加载插件（热重载）时，会看到自己的 id，知道自己没有东西可恢复。磁盘上出现 pausing 状态的计划，说明按下按钮这个动作本身被打断了：这些会话先不动，按钮继续提供恢复，等人来按。

不是按下按钮造成的停止

轮次结束，也可能没人按任何东西：服务商在自己的重试之后返回错误，或者模型撞到输出上限。这类轮次是重启自己修不了的情况，所以插件另记一本小账，continue.json，按钮显示 ↻ 而不是 ▶。这本账独立于暂停计划：它永远不会变成崩溃计划，永远不暂停或取消任何东西，也永远不自己发消息。

什么会成为候选：

* 会话最近一轮以 error 或 max-tokens 结束，之后没有新的轮次开始或结束。
* 会话是根会话，没有父级，也不是子代理。子代理的停止由父级的工具结果来应答；单独续跑子代理，等于对着没人读的对话说话。
* 轮次不是以 completed、aborted、interrupted 或 blocked 结束。手动暂停会中止它的轮次，所以人主动要求的停止永远不会出现在这里；准入之前的阻塞是从未跑过的工作，也不动。

按下按钮会续跑当时可见的行，一次两行，用一条普通用户消息。它不是重试循环：失败的行留在账上等下次按下，只要还有东西在等，按钮就回到 ↻。行会在这些时候消失：更新的轮次开始了、会话已经打开、目标处于活跃状态、会话没了，或者续跑的轮次完成了。标题取自会话自己的标题事件；不会为了给某行起名而加载任何东西。一批最多 40 行，行在多次失败的按下之间保留自己的尝试次数。

每行的标签只用于显示：已经需要人来处理，或者错误码是重试修不了的那种（auth、permission、quota、unknown model、context length），标 blocking；其余标 actionable。pendingContinue 在 count 旁边带上这两个计数，这样一批在跑的时候失败的工作仍然可见；标签从不隐藏行，也从不改变按下的效果——按一次仍然续跑每一行可见的行。

在有待处理行的会话里发新消息就是接管：它清掉那一行，但不对旧工作做任何声明。工作只在按下之后继续，绝不在插件加载时继续，绝不定时触发，绝不会因为上一批失败而触发。

渐进式恢复（默认关闭）

六个长会话同时恢复，就是六个上游模型请求同时发出。网关能扛住一条慢速流，却常常扛不住六条。对 Direct API 用户来说，这通常没问题，多等的这段时间纯属浪费，所以渐进式恢复默认关闭：恢复走普通路径，不加间隔，不设请求池，也不装冷却定时器。

批量恢复撞上限流或超时的时候再打开它：共享账号或网关配额、容量有限的自建代理，或者一恢复多个会话就出故障的环境。单会话超时它帮不上忙，那种情况得去查请求和上游。

分两层，因为只做其中一层，另一层就足以让效果归零：

* 派发间隔。 会话按血缘深度分批恢复，每次启动之间隔 restoreStartGapMs（3 秒），再加最多 0.4 秒抖动。
* 真正的请求池。 插件注册一个 llm/stream 中间件，每个适配器请求占一个许可，直到这条流结束、失败或被取消才释放——不是回合开始时释放，不是第一个分块到达时释放，也不是工具或子代理开始等待时释放（那时请求已经结束了）。压缩以 purpose: 'compaction' 进入同一个池，每次官方重试都重新取一个许可。守卫只在恢复运行时打开，普通聊天永远不会排在它后面。

池的初始容量是 restoreCapacity（1）。连续两条干净的流就加一，上限 restoreMaxCapacity（2）。连续两次失败就降回一，并关闭池 restoreCooldownMs（40 秒），这样一个不健康的上游不会被一串会话轮番捶打。被放弃的流（用户暂停了）既不算成功也不算失败：取消的代价很低。

开关在你按下恢复时读取；正在跑的批次沿用启动时的设置，所以批次中途关掉这个功能不会突然放行队列。要停当前批次，按暂停。

可靠性不依赖这个开关。会话、子代理和后台任务的暂停与恢复，恢复过程中再次暂停，计划持久化，崩溃恢复，续接去重，以及重试入口，在渐进式恢复关闭时全都照常生效。恢复循环无论开关如何都保留自己的小工作批次；可选的只是对真实模型请求的额外限制。

恢复运行中暂停是立即生效的。按下后停止派发，拒绝所有还在等许可的请求，请 Harness 停掉已经开始的工作，把剩下的内容作为未完成的续接写回计划，并返回 paused 和 interrupted: true。再按一次会恢复同一份计划；续接请求 id 按周期生成，所以已经放行的消息会被去重，而不是发两次。
/state 在存在计划时会报告设置和队列：restore 下有 {progressive, active, enabled, capacity, running, queued, dispatched, failed, interrupted, cooldownUntil}。按钮本身仍然只显示图标。

配置（全部可选）：

| 键 | 默认值 | 含义 |
| restoreProgressive | false | 选择启用分阶段恢复；关闭时走普通路径 |
| restoreCapacity | 1 | 恢复开始时允许的模型请求数 |
| restoreMaxCapacity | 2 | 健康检查可以把上限提升到的最高值 |
| restoreCooldownMs | 40000 | 跨会话连续两次失败后的暂停时长 |
| restoreStartGapMs | 3000 | 恢复启动之间的间隔，外加抖动 |

作用范围，如实说明：这里管的是经过本 Host 模型栈的请求。Harness 自身的恢复流程，以及子代理绕过本 Host 直接访问服务商的情况，都不在池内；任何插件也无法为它并不拥有的公司网关承诺并发上限。300 s 的上游空闲超时是上游的决定；分阶段恢复不能假装能修好它，但它让恢复过程产出证据（一个会话，一个确切的请求），而不是一场雪崩。

恢复节奏与堆余量

恢复会话时，要把整份记录反序列化进 Host 堆。单个大会话就有 GB 级，而 Host 的 V8 上限大约 4 GB；超过之后进程不会抛错，而是直接死掉，报 FATAL ERROR: MarkCompactCollector: young object promotion failed。2026-10-29 实测两次：pid 91126 运行 64 分钟后达到 3.65 GB；pid 61989 在恢复 15 个会话后十五分钟达到 3.58 GB。两次都在 ~/Library/Logs/DeepSeek Harness/ 下留下了 crash--host.log。

所以恢复的节奏取决于它能承受多少，而不只是它要做多少：

只恢复这次崩溃打断的。 崩溃计划记录下来的会话才会恢复；历史和正常结束的会话一律不碰。这一点自 0.6.x 起未变。
* 小的先来。 队列按记录大小排序，轻的会话排在前面，重的排在后面。轻会话按 restoreConcurrency（2）并发运行。
* 重会话单独跑。 压缩后记录超过 restoreHeavyMB 的会话独占一步；下一步在它这一轮结束时启动，最迟不超过 restoreSettleMs（90 s）。
* 按一次就排空队列。 某一行只是因为先前恢复的会话还在工作而被压住，引擎会自己重试，间隔一个 restoreSettleMs，直到队列清空。0.8.4 之前，同一次按键只挂载一份大记录，剩下的留给人再按一次——这就是每次重启后都显示 partial 的原因。重试会在用户主动停止、页面重载、以及连续 restoreMaxAttempts 轮都没恢复出任何东西之后停止。
* 堆闸门。 每一步恢复之前都会读取 v8.getHeapStatistics()。如果剩余余量低于 restoreHeapReserveMB，这一轮就不再挂载任何内容。没轮到本次恢复的会话会记进 deferred，保持未启动状态——加载它的对话记录正是这道闸门要避免的开销——下一次按下或下一次启动时再处理它。
* 先预测，再挂载。 准入环节还会估算一份对话记录要占多少堆（压缩后大小的六倍），估算结果放不进剩余余量时就把这一行压住，于是超大会话在被读取之前就被拒绝，而不是等它把堆撑大之后。读不出大小的会话按重量级处理，走串行的重量级路径；/state.scheduling.unknownWeights 报告这一轮有多少个没能测量。

压住了行的轮次不会消耗计划：它以 partial 结束，把每一行连同它的 deferred 备注留在磁盘上，/state.restore.deferred 列出它没能挂载的内容。消耗掉计划会删掉那些从未开始的工作的唯一记录，下一次启动就会给出一次干净的恢复，而某个大会话还欠着没做。

某一轮恢复了重量级会话，或产生了 deferred 时，/state 还会带上 restartRecommended，附上堆用量和原因；一旦有行在等重启，客户端的提示就会切换成「重启后继续没放下的内容」。插件从不自行退出或重启 Host：进程是某个人正在跑的工作，插件为了更干净的堆把它杀掉，等于拿不属于自己的数据来付账。

这条建议的寿命和工作本身一样长：只要 /state.scheduling.deferred 还列着这一轮压住的行（下一次按下也挂载不了它们），它就保留；一次没有任何 deferred 的健康轮次会清掉它；超过六小时的推荐会被丢弃，除非还有行在等。被压住的行保留它原本的意图（挂载或继续），下一次恢复时带着这个意图回来。

三个内存数字来自这个 Host 实际拥有的堆，不是在这里写死的：4 GB 的 V8 上限和 16 GB 的上限没法共用一个预留值，而小的上限希望一次只处理一个会话。/state.scheduling 报告解析后的值，外加 derived，说明其中哪些来自堆而不是来自配置。

| 键 | 默认值 | 含义 |
| restoreConcurrency | V8 上限低于 3 GB 时为 1，否则为 2 | 一轮中同时恢复的轻量会话数 |
| restoreHeavyMB | heapLimitMB / 340，钳制在 8–48 MB | 让会话变成重量级的压缩对话记录大小 |
| restoreHeapReserveMB | V8 上限的 22%，钳制在 320–1536 MB | 低于此堆余量时，一轮不挂载任何内容 |
| restoreSettleMs | 90000 | 等待重量级会话轮到的上限 |
| restoreMaxAgeHours | 72 | 早于此时长的崩溃记录会被归档，而不是挂载 |
四个都是可选项；设置其中一项就会固定该数值，其余项保持推导。

这一层与渐进恢复不同。restoreProgressive、restoreCapacity、restoreMaxCapacity 和 restoreCooldownMs 限制发往上游的真实模型请求；这四个则限制一次恢复保留多少转录内容、以及要跨过多少个会话。两者可以同时开启，互不替代。崩溃证据、调度流程以及 deferred / restartRecommended 字段见 docs/memory-safety.md。

支持的平台

macOS、Windows 和 Linux。状态与日志只通过 node:path 和 node:fs 读写，位于 $DSH_HOME 下（变量未设置时为 ~/.dsh）；不调用 shell，也不 shell out 到 stat、du 或 ps。跨进程互斥使用 session.lock 文件，而非仅 POSIX 可用的调用。Windows 上没有目录 fsync 的等价物，因此跳过——写入仍是临时文件加 rename——这一点连同换行符，是各平台之间唯一的差异。

安装

plugin_manager install_bundle dsh-pause-resume

或用包名从 Harness 插件管理器安装该 bundle。每个配置键都是可选的（见渐进恢复），插件不持有任何凭据。allowRemote 用于从另一台机器访问的 Harness；默认仅限本地。

保证与限制

* 互斥。 阶段状态存放在 Host 上，并在任何工作开始前写入，因此两个窗口、连按两次和一次工具调用不会重叠。第二个调用方会收到 busy——但恢复期间的暂停除外，它会当场中断恢复而不是拒绝：停止绝不能成为那个等待的操作。
* 先持久化，再破坏。 计划落到磁盘之前，不取消任何回合。写入失败意味着什么都没停。
* 有界。 反复失败的恢复会留在磁盘上，并标明其行；它不会像工作已完成那样关闭。读不出的行重试一次，然后要么报告真实进度，要么把计划标记为 partial 并逐行提示，这样按钮不再重复空操作。手动继续的会话会被恢复，绝不重发，一旦运行其提示行立即清除。超出预算的尝试会多观察一会儿再判定失败，而本计划已恢复的会话保持已恢复状态，即使 Harness 在后续启动时将其复活并推进其回合。
* 幂等。 继续请求的 id 由计划和会话推导，因此重试不会重复投递同一条消息；已经推进的回合不再继续，已由人工继续的回合报告为 already running，而不是再次按下。Harness 没有 compare-and-admit，因此从最后一次状态读取到提示词准入之间仍存在亚秒级窗口；这些防护缩小了窗口，结果从不声称原子性。
* 诚实。 读不出来的状态永远不会报成 paused。手动删掉的会话、手动改过的目标、已经在跑的会话：一律跳过，并在结果里点名。
* 不偷偷接管。 没有公开 API 能摘掉智能体，所以暂停的保证是「轮次已取消、目标已暂停、任务已终止」，而不是「进程被冻住」。目标能继续，是因为 Harness 有对应机制；普通会话能继续，靠的是一条可见的用户消息。
* 不碰第三方插件状态。 插件的进程内状态归它自己的挂载点。
* 默认只在本机。 这些路由要求同源请求，并带一个插件请求头。要用远程，必须显式开启，而且照样跳不过请求头。

文件

所有状态都放在 $DSH_HOME/pause-resume/ 下：

| 文件 | 用途 |
| snapshot.json | 一次按下暂停所停下的工作，状态为 pausing 或 paused |
| pending.json | 崩溃恢复计划，保留到一次恢复完成为止 |
| journal/<planId>.jsonl | 恢复尝试记录，标注由哪次启动产生 |
| restores/<planId>.json | 归档的计划，留作上一次恢复的记录 |
| last-restore.json | 上一次恢复的摘要 |
| running.json | 有未结束轮次的会话，用于排查崩溃残留 |
| continue.json | 自行停下、等一次继续按下的轮次 |

每次写入都先写唯一临时文件，再 fsync、rename，最后对目录 fsync。状态从不放在包内。

开发

npm test
npm run audit
npm run smoke:host # boots a throwaway real Host on a free port and asserts the routes
npm run smoke:live # real Host + local mock model stream: pause, SIGKILL, restart, resume once
npm run smoke:maintenance # real Host: pause cancels an in-flight compaction, apart from the session turn
npm run smoke:wrapup # real Host + held model stream: the turn answers the pause as an ordinary completed turn

收尾路径有自己的记录，在 docs/evidence/host-wrapup.json（真实轮次在窗口内自行结束，所以计划欠一次续跑），旁边是 docs/evidence/host-live.json（窗口过期，按下暂停后由它自己收回控制）。

验证记录在 docs/acceptance-0.6.11.md（当前版本：反复失败仍可继续、暂停会截断正在跑的批次、准入归属、交接证明、冷/陈旧目标恢复、渐进门后的继续、阻塞行与可操作行的区分，已证实与未证实两半分开写）、docs/acceptance-0.6.10.md（自行停下的轮次与一次继续按下）、docs/acceptance-0.6.9.md（上一轮评审提出的十个缺陷）、docs/acceptance-0.6.7.md（一次崩溃按下只挪了按钮，没重启任何东西）、docs/acceptance-0.6.6.md（一行 unknown 由人手动继续并完成、子行与根行遵守同样的意图、竞态窗口，以及仍未验证的部分）、docs/acceptance-0.6.5.md（0.6.5）、docs/acceptance-0.6.0.md（0.6.0–0.6.1） docs/evidence/。第二轮评审的八项对照关系，以及对应的代码与证明，见 docs/objective-round2-closure.md。任务生命周期监听的设计评审，包括为什么任务永不重启，见 docs/design/job-lifecycle.md。0.7.0 恢复节流背后的内存安全策略——为什么恢复会杀掉 Host、崩溃证据、调度流程，以及你该关注哪些字段——见 docs/memory-safety.md。

lib/engine.js 不做任何 I/O，lib/snapshot.js 负责持久化，lib/probe.js 承载全部 Harness 服务契约（智能体身份、目标修订、按所有者划分的任务、续接提示词），index.js 只负责把它们接到 Web 路由上。这些模块都能脱离 Harness 测试：test/apply.test.mjs 把插件挂到假注册表上运行。

MIT。

一行说明：会话头一个按钮，⏸ 停掉正在跑的回合、目标与后台任务；重启后同一个按钮变 ▶，把上次的工作接回来。正常结束的会话不记录、不恢复；崩溃会接回记录里的会话与其目标，暂时无法确认状态的会话保持计划未完成，按钮继续给 ▶；日程不会被动（该服务只有删除，没有停用），后台命令只记录不重跑。