自动重试助手 zxmqq1234/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 · 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 秒）没有任何流输出和事件，就主动取消当前请求，交由第 2 层自动继续接管。判定依据是「零活动」（无流帧 + 无事件），长任务里的正常思考、正常工具执行都不会误伤；即使偶发误取消，也会自动恢复，不丢上下文。

附：截断自动继续（默认关）输出因 max-tokens 被截断时自动续写；连续截断同样计入熔断，不会无限续写。

为什么安全：你手动点停止的回合永不自动继续（插件只恢复「看门狗取消」和「真报错」两种情况，你按的停止键永远算数）；每一次重试和继续都写入会话日志，事后可查。

🔔 二、实时状态直击（横幅 + 弹窗，双通道直播，默认开）

通道一 · 底部状态横幅（v0.3.0 新增，重试期间的舞台中央） 重试、自动继续倒计时、看门狗出手、熔断警示——全部在屏幕下方居中横幅实时直播，深色卡片 + 彩色场景条 + 大字号等宽倒计时数字（每 0.2 秒刷新，精确到 0.1 秒）：

┌─────────────────────────────────────────────────┐
│ ↻ 自动重试插件 · 正在重试 │ │ 补充重试 第 2/5 次 · 限流(429) · zai/glm-5.3-flash│ │ 3.2 秒后自动重试 │ └─────────────────────────────────────────────────┘

- 最多 3 条并排轮播；同一会话同类事件自动替换，不刷屏
- 用户介入（横幅显示期间你发了消息）→「准备自动继续」横幅立刻消失，绝不误导
- 不想看？关掉「实时通知」开关即全部静默，看板里照样留痕

通道二 · 右上角弹窗（轻量战报） 每次重试、继续、看门狗出手，右上角实时弹窗，3 条轮播、4 秒自动消失，标题永远带「自动重试插件」。

从此「后台到底发生了什么、还要等多久」一目了然——再也不用盯着屏幕猜。

📊 三、数据看板（不点击不加载，零打扰）

设置页底部的可折叠看板，点开才请求数据。它回答你最关心的问题：

- 到底重试了多少次？ 总重试次数，且内置重试和本插件追加分开设——「假没重试」之谜在这里现出原形
- 平均几次能救活？ 「平均重试次数成功」：含重试的成功回合平均吃了几次重试
- 哪种错在作妖？ 按错误码分布（限流多还是超时多？）
- 哪个 AI 不靠谱？ 按 AI（provider/模型）分布——哪个模型、哪个中转爱出问题一目了然
- 最近趋势如何？ 按日统计（重试/继续/失败回合），今天 / 近 7 天 / 近 30 天 / 全部自由切换
- 逐条明细：时间、类型、AI、错误码、第几次、来源（内置/补充）、延迟，最近 200 条

数据持久化在本地（~/.dsh/auto-retry-stats.json，滚动保留 5000 条），跨重启不丢。

📖 四、透明与掌控（把「为什么」讲给你听）

- 内置策略展示：设置页直接展示每个 provider 当前生效的内置重试策略（模式/次数/可重试错误码/退避参数/流空闲超时），和本插件的关系一目了然
- 「为什么没重试就停了」说明卡：五种「停住」的真相（内置重试太快不可见 / 零重试错误 / 空响应当成功 / 流挂起无超时 / 输出截断）逐条讲透
- 全量悬浮提示：8 种触发情况、每个开关、每个输入框，悬停即见「什么情况会触发、内置怎么处理、本插件追加什么、这个数填了会怎样」
- 输入不再被「抢键盘」（v0.3.0）：所有数字框输入时自由书写、不被中途改写；每个框明示可填范围（如「可填 0~600 秒」），失焦后自动校验——超范围自动修正并明确提醒「已自动修正为 X」
- 主/子智能体分治：主智能体失败自动继续，子智能体只做请求重试（它彻底失败时主智能体会收到错误并自行重派——各司其职，不越权）

兼容性

| dsh 版本 | 兼容 | 说明 |
| 0.1.7-alpha.1 / alpha.2 | ✅ | 首发支持版本 |
| 0.2.0-rc.1 | ✅ | 已通过 0.2.0-rc.1 插件兼容性校验（peerDependencies 实测） |
| 0.2.0-rc.2 | ✅ | 已逐包核对其余 API 契约，零修改兼容，peer 声明覆盖 |
| 0.2.1-alpha.3（最新） | ✅ | 加载器重试不变量逐条核对，与 v0.3.1 修复实现一致；真实环境实测 |

dsh 0.2.0 起要求插件在 package.json 的 peerDependencies 中声明兼容范围，本插件已声明
^0.1.7-alpha.1 || ^0.2.0-rc.1 || ^0.2.0-rc.2 || ^0.2.1-alpha.3，安装时自动通过校验，无需豁免参数。

设置页导览

dsh Web UI → 设置 → 自动重试，从上到下：

| 板块 | 内容 |
| 总开关 + 实时通知 | 一键停用整个插件；通知弹窗独立开关 |
| 触发情况 | 8 种失败情况逐项勾选 + 各自重试次数（可填 0~20） |
| 主智能体 | 补充重试、自动继续（延迟/熔断上限/继续文案）、截断继续、无响应看门狗（判定时长） |
| 子智能体 | 补充重试开关 + 三段白话说明（是什么/失败会怎样/与主智能体的区别） |
| 高级 | 间隔模式（指数退避/固定间隔）与各参数 |
| 内置重试策略 | 只读信息卡：各 provider 生效中的内置策略 |
| 数据看板 | 点击加载的统计面板（默认零请求） |

配置保存即热生效，无需重启 dsh。

安装

进入 profile 目录
cd ~/.dsh/profiles/web

方式 A：插件命令安装（自动处理 patch 与 bundles）
dsh plugin add github:zxmqq1234/dsh-auto-retry

方式 B：手动安装
1) pnpm add github:zxmqq1234/dsh-auto-retry
2) profile 的 cordis.patch.yml 追加：
- id: auto-retry
name: dsh-auto-retry
3) profile 的 package.json 在 dsh.profile.bundles 数组加入 "dsh-auto-retry"

重启 dsh web，设置页即出现"自动重试"板块

本地开发：pnpm add file:<插件目录>（复制安装，重建后需重装）或 junction 链接（mklink /J）。

从源码构建

npm install
npm run build # 产出 lib/index.js + lib/client.js（产物已随仓库提交，装包无需构建）
npm test # 构建产物 + 回归测试

设计原则

1. 追加而非替代：尊重 dsh 内置重试，只在它耗尽或不覆盖时出手，绝不双重重试。
2. 人始终在环上：手动停止至高无上；自动继续前留介入窗口（倒计时看得见）；熔断防失控；全程可观测、可审计。
3. 默认值即推荐值：装完基本不用调；想更快恢复，开看门狗、把判定时长调到 120 秒。

反馈与贡献：Issues · 觉得好用请点个 Star ⭐