dsh-auto-retry

dsh-auto-retry —— 让 dsh 在烂网络里也能自己爬起来，而且让你亲眼看着它爬

> DeepSeek Harness（dsh）自动重试插件：报错自动重试、中断自动继续、挂起自动唤醒——

> 屏幕下方实时倒计时横幅直播每一次抢救，右上角弹窗同步战报，数据看板还原每一次重试的真相。

>

> 兼容：dsh 0.1.7-alpha.1 / 0.1.7-alpha.2 / 0.2.0-rc.1 / 0.2.0-rc.2 / 0.2.1-alpha.3（最新已核对兼容）

> 作者：zxmqq1234 · [GitHub](https://github.com/zxmqq1234/dsh-auto-retry) · License: MIT

---

v0.3.1 修复：会话历史加载失败（重要，建议所有用户升级）

v0.3.0 写入的 llm/retry 事件把"预算计数"误用作"链内序号"，违反 dsh 会话加载器对重试事件流的不变量

（同一条重试链内 retryId 必须恒定、链内序号必须从 1 连续递增且不超过 maxRetries）。

运行时一切正常，但重启 dsh 或重新加载会话历史时整个会话会报 SessionFormatError 打不开，

且坏数据在暴露前会持续积累。v0.3.1 起重试事件改为：retryId 链内恒定（含会话/回合/步骤/提供方）、

序号按链从 1 连续计数、并新增链容量闸门保证序号不越过 maxRetries。

> 若你已被 v0.3.0 损坏会话：会话文件中仅需把 llm/retry / llm/retry-started 事件的

> retryId 与 retry 两个字段按上述不变量改写即可恢复加载（不必丢弃会话）。

---

v0.3.0 最新亮点：重试从"黑盒"变"直播"

以前你最憋屈的是：它到底在重试吗？还是已经死了？ 界面毫无动静，你只能干等。

v0.3.0 把整个抢救过程搬到台面上——实测效果（内置重试第 4/5 次，2.2 秒倒计时实时跳动）：

• 底部状态横幅：一旦重试，屏幕下方立刻出现醒目横幅，大字号实时倒计时走着：

↻ 自动重试插件 · 正在重试 · 补充重试 第 2/5 次 · 限流(429) · zai/glm-5.3-flash

3.2 秒后自动重试（数字每 0.2 秒跳动，归零后显示"正在重试…"）

• 连 dsh 自己藏起来的重试都帮你显形：内置重试快到几秒跑完且 UI 不可见——本插件监测到后同样显示"内置重试（本插件代为显示）第 1/5 次 + 倒计时"。"假没重试"之谜从此当场破案。
• 自动继续前也有倒计时：回合阵亡后横幅显示 ⏱ 5.0 秒后自动发送继续消息——这 5 秒正是你的介入窗口，看得见才抢得回。
• 熔断也会喊你：连续失败触顶停止自动继续时，橙色警示横幅明确告诉你"已暂停，回合成功后自动恢复"，绝不无声罢工。
• 每一条横幅、弹窗标题都带 "自动重试插件" 字样——它是谁在干活，从来不含糊。
• 输入框全面升级：所有数字框不再"边输边改"，范围说明写明（如"可填 0~20 的整数"），失焦时自动校验修正并提醒。

---

你是不是也遇到过

深夜挂着一个长任务，你切去干别的，回来一看——界面停在半截，模型没下文了。

你以为它还在跑，其实现已中断 20 分钟；你不知道它断在哪、重试过没有、还救不救得回来。

网络差的傍晚更灾难：限流、超时、连接重置轮番上阵，你只能机械地盯着屏幕，一断就手敲"继续"。

更气人的是"假没重试"：dsh 内置重试其实重试过 5 次——但它快到几秒内跑完、界面上毫无显示，

你看到的只是"没重试就直接停了"。到底重试过没有？为什么停？还能继续吗？没人告诉你。

最难受的是"黑盒等待"：就算它真的在重试，你也不知道还要等几秒、是第几次、值不值得等下去。

这个插件把这些全接管了。 装上它，你从"AI 的保姆"变回"发号施令的人"——

它摔倒了自己爬，爬的时候还让你盯着秒表看。

---

三分钟理解它

dsh 的失败分三种，插件给每一种配了对应的自动恢复手段：

| 故障现场 | 你过去的体验 | 插件的自动动作 |

|---|---|---|

| 请求被拒：限流 429、服务端 5xx、超时、网络断开 | 等一会儿，手动重发 | 再追加几轮重试，间隔越拉越长，直到成功或放弃 |

| 回合阵亡：重试全耗尽、无可用模型、配置错误 | 会话停摆，等你救 | 延迟几秒自动发"继续"，接着原来的上下文往下走 |

| 悄无声息：流挂起、长时间一个字都不吐 | 以为还在跑，其实早死了 | 看门狗掐表：超时无动静就主动掐掉，再自动继续 |

| 输出戛然而止：写到一半因长度被截断 | 后半段没了，手动"接着写" | 自动发"继续"，让它从中断处续写 |

全程你不掉东西：上下文、工具结果、会话日志全部保留——恢复是"接着跑"，不是"重头再来"。

---

四大能力组

🛡️ 一、自动恢复（核心：三层防线，逐级兜底）

第 1 层 · 请求级补充重试（默认开）

内置重试（默认 5 次、间隔 0.5到10 秒）耗尽后，按你勾选的"触发情况"继续追：

限流(429)、服务端错误(5xx)、响应超时、空响应、网络传输错误、未知错误、其他 HTTP 4xx、请求中断——

8 种情况逐项勾选、逐项定次数（0~20 次），主智能体和子智能体分别开关。

间隔策略二选一：指数退避（如填 2 秒 → 2s、4s、8s…封顶 60s）或固定间隔（如填 30 秒 → 每次都等 30 秒）；

上游返回 429 Retry-After 时优先照办，另加 ±10% 抖动防止瞬时拥塞。

第 2 层 · 回合级自动继续（默认开）

重试救不回来的回合，延迟 N 秒（默认 5 秒）后自动以用户身份发送"继续"，开启新回合。

延迟期就是你的介入窗口：期间你手动发消息，本次自动继续自动让位。

连续失败有熔断（默认 5 次封顶，防网络彻底断开时无限空转），回合成功即清零。

"继续"文案可自定义（默认就是"继续"两个字）。

第 3 层 · 无响应看门狗（默认关，强烈建议开）

dsh 的回合内请求没有超时保护——流一旦挂起就永远挂着，无报错、无重试、无终局。

看门狗是唯一解药：运行中超过判定时长（默认 180 秒，可调 30~600 秒）没有任何流输出和事件，