dsh-retry-boost

1. 安装并启动 DeepSeek Harness：npx @deepseek-ai/dsh web
2. 在终端执行上面的安装命令（CLI 会解析插件并核验来源）
3. 用 dsh plugins list 确认已安装，必要时重启 Harness 生效

插件以当前 dsh 进程的权限运行，安装时可能执行代码。请先通读仓库源码与许可证，确认无破坏性命令与越权访问；本站只做索引，不对第三方插件安全性作担保。

事实信息来自公开插件目录快照（2026-10-01），介绍文案由本站再加工。

以下为插件仓库 README 全文（原始内容，由公开目录抓取整理）。

# dsh-retry-boost

遇到网关瞬时故障（429 限流/断流/超时）时自动退避重试、直到任务完成——一个 DSH
插件，启动时把防断流 `retryPolicy` 热注入到所有 `llm-pi-ai` provider。
再也不用手动发「继续」了。

[English README](./README.en.md)

---

## 问题背景

网关返回 **`429 insufficient_quota`**（商汤 SenseNova 和很多 LLM 网关都这么措辞）时，
DSH 的错误分类器会先命中 `isQuotaExceededError` 把它归为 **`QUOTA`** 码，
而不是通用的 429 → `RATE_LIMIT`。

DSH 内置重试（`dsh-llm-retry`）只重试 `retryableCodes` 列表里的错误码。而**默认**策略是：

```text
retryableCodes: [EMPTY_RESPONSE, RATE_LIMIT, SERVER, TIMEOUT, TRANSPORT]   // ← 没有 QUOTA
maxRetries: 5
backoff: 500ms → 10s
```

`QUOTA` 不在列表里 → 瞬时 `429 insufficient_quota` 直接 **fail-fast**：
一次都不重试、turn 立刻死掉，手动「继续」也会再撞同一堵墙。上游同源问题：
[deepseek-ai/deepseek-harness discussion #892](https://github.com/deepseek-ai/deepseek-harness/discussions/892)
（目前 0 回复，官方尚未修复）。

## 解决方案

插件启动时把一份加宽的 `retryPolicy` 写入 `llm-pi-ai` 设置命名空间，
llm-pi-ai 的 settings `onChange` 会**热生效，无需重启**。注入的策略：

```text
retryableCodes: [EMPTY_RESPONSE, RATE_LIMIT, QUOTA, SERVER, TIMEOUT, TRANSPORT, PI_AI_ERROR, UNKNOWN]
maxRetries: 50
backoff: 1s → 60s，抖动 0.2（指数退避）
```

效果：瞬时 429 / 断流 / 超时会被指数退避**重试直到任务完成**——就是把商汤生产
环境里用的那个 settings.yaml 补丁产品化，让任何人都能一键装上。

## 为什么做成插件而不是只改 settings.yaml？

- **一条命令安装**——对*所有* provider 生效，不只是你手改的那一个。
- **跟着新 provider 走**——以后新增 provider，下次启动自动套用。
- **可配置**——`fill` / `boost` / `force` 三种策略，重试预算可调。
- **透明**——注入的策略会出现在 `settings.yaml` 里，看得见、改得动；
  插件幂等，绝不和你手改的配置打架。

## 与 dsh-chat-continue 的区别

| | dsh-retry-boost（本项目） | [dsh-chat-continue](https://github.com/Chu-m/dsh-chat-continue) |
| --- | --- | --- |
| 定位 | **第一道防线**——让 DSH 内置重试真正生效 | **第二道防线**——内置重试耗尽后兜底重试 |
| 机制 | 给所有 `llm-pi-ai` provider 注入 `retryPolicy`（走官方重试链路） | 拦截 `agent/request-error` 自己重发失败的请求 |
| 退避 | 指数退避 1s → 60s + 抖动 | 固定间隔 |
| 手动确认 | —— | 可选弹窗通知 |
| 安装 | `github:hhb1028/dsh-retry-boost#main` | `@wuxjs/dsh-chat-continue` |

两者**互补**：单独用本项目即可；也可以叠上 chat-continue 作为最后的兜底网。

## 环境要求

- DSH `>= 0.1.1-rc.1`（支持 `dsh.bundle.patch` 宿主插件）
- Node.js `>= 20`

## 安装

```bash
dsh plugin --profile <你的profile名> add "github:hhb1028/dsh-retry-boost#main"
```

发布到 npm 后（见 [Roadmap](#roadmap)）：

```bash
dsh plugin --profile <你的profile名> add dsh-retry-boost
```

然后重启 DSH。日志里会出现类似：

```
dsh-retry-boost: injected retry policy for "sensenova" (mode=normal retries=50 backoff=1000ms->60000ms codes=8)
```

注入后的策略会出现在 profile 的 `settings.yaml` 中
`llm-pi-ai.providers.*.retryPolicy` 下——可以随意手动修改。

## 配置项

在合并进 profile 的 `cordis.patch.yml` roster 行（或 DSH 的插件配置界面）里调整：

| 键 | 默认值 | 含义 |
| --- | --- | --- |
| `strategy` | `fill` | `fill` = 只处理**没有**显式 `retryPolicy` 的 provider；`boost` = 对显式配置的也合并缺失错误码并抬高上限；`force` = 全部替换为插件策略 |
| `mode` | `normal` | `normal` = 有界重试；`always` = 无限重试（⚠️ 慎用，永远重试下去） |
| `maxRetries` | `50` | `normal` 模式下的重试次数上限 |
| `initialDelayMs` | `1000` | 首次退避延迟 |
| `maxDelayMs` | `60000` | 退避上限 |
| `jitterRatio` | `0.2` | 抖动比例（0–1） |
| `retryableCodes` | 上面 8 个码 | 需要重试的失败码 |

## 卸载

```bash
dsh plugin --profile <你的profile名> remove <名字>
```

卸载后注入到 `settings.yaml` 里的 `retryPolicy` 段**不会自动删除**——手动清掉
（或卸载前先用 `force` 策略并恢复你自己的值），即可回到 DSH 默认行为。

## 工作原理

1. 启动时读取 `llm-pi-ai` 设置命名空间。
2. 按 `strategy` 为每个 provider 规划目标 `retryPolicy`（`lib/policy.js` 纯函数，
   全量单元测试）。
3. 通过 DSH 的 settings provider 合并写入：经 llm-pi-ai 校验（与 `dsh-llm`
   的 `RetryPolicySchema` 完全一致）→ 持久化到 `settings.yaml` →
   `installSettingsSection` 的 `onChange` 热生效。
4. 写入幂等：已达标时再次运行产生空 patch，绝不反复改写。

## 开发

```bash
npm test        # 单元 + 真实 schema 集成 + apply 流程测试（node --test）
npm run check   # 语法检查
```

无构建步骤——纯 ESM。schema 集成测试会把生成的策略跑过框架**真实**的
`RetryPolicySchema` / `resolveRetryPolicy`，保证注入的 patch 永远不会被设置校验拒绝。

## Roadmap

- [ ] 发布到 npm（`dsh-retry-boost`）
- [ ] llm-pi-ai 配置变化时自动重跑策略（目前是启动时）
- [ ] 可选的设置页面（Settings → Retry Boost）

## 许可证

MIT