← 返回列表
✓ 可直接安装
DeepSeek Harnessdsh的一个插件：
自动检查通过：npm 包已发布且 engines 声明满足基线（声明 Node >=20）；该结论来自程序自动检查，未经人工实机验证。 · 最近上游提交 2026/9/25 · 已提供中文文档
恢复被 DeepSeek Harness 重启中断的 DSH 轮次
综合分
35.7
GitHub 分
35.7
用户评分
—
★ Stars
1
周下载量
—
安装插件（需先安装 dsh CLI 引擎：npm install -g @deepseek-ai/dsh）
dsh plugin --profile web add dsh-recovery-resumenpm 包 dsh-recovery-resume 已校验归属本仓库，走 npm 安装最省事
信任档位：已验证本站已于 1 天前真实安装成功（L4 · 真实安装）
- 是什么
- dsh 原生插件 · other
- 装得上吗
- 本站已真实安装成功（L4 · 真实安装，非静态推断）
- 安全吗
- 本站尚未对该插件做风险分级（暂未覆盖，不等同于无风险）
- 还在维护吗
- 活跃：最近一次提交在 1 天前
档位由下列信号合成：本站实装验证（真实安装，当前最高到 L4）· 验证所用 dsh 版本 · 静态安装检查 · 风险分级 · 仓库维护状态。下方各区块是它的证据明细。 验证判据与等级说明 →
🟢实装验证通过· 2026/9/24
由本站实装验证器在真实 dsh 环境安装成功，非静态推断。
数据截至 2026/9/25（元数据每日更新 · 实装验证按队列轮转，单条结论的验证时间见上方）
安装兼容性检查✓ 自动检查通过
以下结论由程序自动检查 npm 包、engines 声明与入口文件得出，未做人工实机验证——能装不等于用着没问题。
✓npm 包dsh-recovery-resume @ 0.1.2
✓Node 引擎要求 >=20 · 基线 Node 22.19 满足
✓dsh CLI 依赖未声明 dsh 版本约束
✓入口文件main/exports/bin 已声明
验证方式：npm registry 存在性 + package.json 静态校验 · 最后验证 2026/9/24 11:28:53
用户评分
还没有人投票，来当第一个
订阅周报，不错过优质插件更新
每周一封 · 高评分插件 + 新用户活动
README
由 DeepSeek 最新模型翻译生成dsh-recovery-resume DeepSeek Harness（dsh）的一个插件： DSH 重启之后，自动把被打断的任务接着做完。 它解决什么问题 你让 agent 干活，干到一半 DSH 重启了（崩溃、升级、手动重启都算）。 重启后会话还在，但那个被打断的任务不会自己继续——要等你再发一条消息，它才会动。 装了这个插件，DSH 重启后它会自动发一条消息，让 agent 接着做。 这条消息不是简单一句“继续”。重启可能正好发生在下载或推送的半路上， 所以消息会要求 agent 先检查实际做到了哪一步，再从对的地方接着做： 不许想当然地认为成功了，也不许想当然地认为失败了。 安装 dsh plugin --profile web add github:flandre2233/dsh-recovery-resume 装完重启一次 DSH，插件才会生效。 不需要装任何依赖，也不需要编译。 什么时候会自动续跑 下面几条全部满足才会动手，否则什么都不做： - 上一个任务是被意外打断的（中断、出错、或输出太长被截断），而不是正常结束 - 打断之后你还没发过新消息，也没有开始新任务 - 打断发生在 15 分钟以内（太久以前的就不翻旧账了） - 这个会话已经重新打开了 如果失败的原因重试也没用，就不续跑，比如 API key 无效、余额用完、对话太长超出上限。 这些情况重试只会白白花钱。哪些错误算“值得重试”，用的是 DSH 官方自己的判断标准。 如果会话里有一个进行中的目标（goal），插件还会让它继续推进， 效果和你在界面上点“继续”一样。你手动暂停的目标，插件绝不会动。 防止失控 最怕的情况是：“重启 → 续跑 → 又崩 → 又重启 → 又续跑……”，无限循环地花钱。 所以有三道保险： | 保险 | 规则 | |---|---| | 1 | 同一个会话，DSH 每启动一次最多续跑 1 次 | | 2 | 连续续跑 3 次都没有进展，就停下来不再自动续跑，等你处理（记录保存在 $DSH_HOME/recovery-attempts.json，重启也不会清零） | | 3 | 两次续跑之间要等一段时间：第 1 次之后等 10 分钟，第 2 次之后等 20 分钟 | 只要续跑之后任务确实往前推进了，这些计数就会清零——保险只针对“反复失败”，不影响正常使用。 触发上限时插件只写日志，不做任何别的事。 怎么确认它在工作 先看插件有没有被加载： dsh --profile web --dump-config | grep -A2 recovery-resume 插件的日志会打印在运行 dsh web 的那个终端窗口里。 如果你是用某个启动器（比如桌面版 app）打开 DSH 的，日志会在启动器保存的地方， 常见的是 ~/.dsh/host.log——这个文件是启动器生成的，手动运行 DSH 时不存在。 grep dsh-recovery-resume ~/.dsh/host.log # 如果你的启动器会写这个文件 触发续跑时，日志长这样： dsh-recovery-resume: agent 创建 id=session-… status=idle dsh-recovery-resume: ★ 发现未处理的中断（reason=interrupted turnSeq=8451 lastTool=bash） dsh-recovery-resume: 续跑消息已入队 session-… dsh-recovery-resume: 已重新武装 goal … 大多数时候什么都不会发生，这是正常的。 下面这些日志也都是正常情况，不是出故障了： | 日志 | 意思 | |---|---| | 无需续跑（尾部没有未处理的非人为中断） | 上次是正常结束的，或者你已经接着聊过了 | | 跳过 …（上次失败是永久性的…） | 失败原因是 key 无效、余额不足之类，重试没用 | | 跳过 …（本次进程已续跑 1 次） | 第 1 道保险在起作用 | | 冷却中（…还需 N 秒） | 第 3 道保险在起作用 | | 一行日志都没有 | 插件没被加载，先用上面的 --dump-config 查一下 | 测试 npm test # 85 个用例，不需要装依赖，也不需要 DSH 在运行 也可以单独跑某一个：node tests/logic.test.mjs（Windows 上也能跑）。 已知限制 - 只在 DSH 0.1.6-alpha.1 + macOS 13（Intel）上实际验证过。插件用到的是 DSH 的内部接口， 升级 DSH 之后请重新跑一遍测试。 - “15 分钟以内”这个时间是写死的，目前不能改。 - 插件不判断任务其实是不是已经做完了。如果重启前刚好做完，agent 会多检查一轮， 这是预期行为（消息本来就要求它先检查）。 - 子代理（subagent）的会话不处理。 设计思路、参考的 DSH 源码位置和实测记录见 docs/notes.md。 许可 MIT，见 LICENSE。