dsh-auto-retry
dsh 自动重试插件：请求级补充重试 / 回合级自动继续 / 无响应看门狗 / 实时通知 / 统计看板 适合网络环境较差、需要挂机运行长任务并监控重试状态的用户。
インストール
npx -p @deepseek-ai/dsh dsh plugin --profile web add github:zxmqq1234/dsh-auto-retryドキュメント
README 全文を読む ↗dsh-auto-retry —— 让 dsh 在烂网络里也能自己爬起来
DeepSeek Harness（dsh）自动重试插件：报错自动重试、中断自动继续、挂起自动唤醒、 每一步右上角弹窗告诉你，数据看板还原每一次重试的真相。
兼容：dsh
0.1.7-alpha.1~0.2.0-rc.1（已通过 0.2.0-rc.1 插件兼容性校验） 作者：zxmqq1234 · GitHub · License: MIT
你是不是也遇到过
深夜挂着一个长任务，你切去干别的，回来一看——界面停在半截，模型没下文了。 你以为它还在跑，其实现已中断 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 被截断时自动续写；连续截断同样计入熔断，不会无限续写。
为什么安全：你手动点停止的回合永不自动继续（插件只恢复"看门狗取消"和"真报错"两种情况， 你按的停止键永远算数）；每一次重试和继续都写入会话日志，事后可查。
🔔 二、实时通知（默认开）
每次重试、继续、看门狗出手，界面右上角实时弹窗，3 条轮播、4 秒自动消失：
┌───────────────────────────────────────┐
│ 已自动重试 │
│ zai/glm-5.3-flash · 限流(429)（2/5） │
└───────────────────────────────────────┘
从此"后台到底发生了什么"一目了然——再也不用盯着屏幕猜。 不想要弹窗？设置页一键关掉，静默执行，看板里照样留痕。
📊 三、数据看板（不点击不加载，零打扰）
设置页底部的可折叠看板，点开才请求数据。它回答你最关心的问题：
- 到底重试了多少次？ 总重试次数，且内置重试和本插件追加分开设——"假没重试"之谜在这里现出原形
- 平均几次能救活？ "平均重试次数成功"：含重试的成功回合平均吃了几次重试
- 哪种错在作妖？ 按错误码分布（限流多还是超时多？）
- 哪个 AI 不靠谱？ 按 AI（provider/模型）分布——哪个模型、哪个中转爱出问题一目了然
- 最近趋势如何？ 按日统计（重试/继续/失败回合），今天 / 近 7 天 / 近 30 天 / 全部自由切换
- 逐条明细：时间、类型、AI、错误码、第几次、来源（内置/补充）、延迟，最近 200 条
数据持久化在本地（~/.dsh/auto-retry-stats.json，滚动保留 5000 条），跨重启不丢。
📖 四、透明与掌控（把"为什么"讲给你听）
- 内置策略展示：设置页直接展示每个 provider 当前生效的内置重试策略（模式/次数/可重试错误码/退避参数/流空闲超时），和本插件的关系一目了然
- "为什么没重试就停了"说明卡：五种"停住"的真相（内置重试太快不可见 / 零重试错误 / 空响应当成功 / 流挂起无超时 / 输出截断）逐条讲透
- 全量悬浮提示：8 种触发情况、每个开关、每个输入框，悬停即见"什么情况会触发、内置怎么处理、本插件追加什么、这个数填了会怎样"
- 主/子智能体分治：主智能体失败自动继续，子智能体只做请求重试（它彻底失败时主智能体会收到错误并自行重派——各司其职，不越权）
设置页导览
dsh Web UI → 设置 → 自动重试，从上到下：
| 板块 | 内容 |
|---|---|
| 总开关 + 实时通知 | 一键停用整个插件；通知弹窗独立开关 |
| 触发情况 | 8 种失败情况逐项勾选 + 各自重试次数 |
| 主智能体 | 补充重试、自动继续（延迟/熔断上限/继续文案）、截断继续、无响应看门狗（判定时长） |
| 子智能体 | 补充重试开关 + 三段白话说明（是什么/失败会怎样/与主智能体的区别） |
| 高级 | 间隔模式（指数退避/固定间隔）与各参数 |
| 内置重试策略 | 只读信息卡：各 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（产物已随仓库提交，装包无需构建）
设计原则
- 追加而非替代：尊重 dsh 内置重试，只在它耗尽或不覆盖时出手，绝不双重重试。
- 人始终在环上：手动停止至高无上；自动继续前留介入窗口；熔断防失控；全程可观测、可审计。
- 默认值即推荐值：装完基本不用调；想更快恢复，开看门狗、把判定时长调到 120 秒。
反馈与贡献：Issues · 觉得好用请点个 Star ⭐