前言¶

在 DeepSeek Harness（DSH）里跑智能体时，模型调用一旦因 429、5xx 或短暂网络问题失败，整轮任务往往直接结束。若上一步刚跑完耗时较长的工具，就要人回来重新发起，代价很明显。DSH 内置的 @deepseek-ai/dsh-llm-retry 只能在 provider 粒度上配置，退避固定为「指数 + 抖动」，maxRetries: 0 还表示「不重试」，与「一直重试直到恢复」的语义相反。

下面介绍的 dsh-model-retry 由社区维护者 Dorufoc 发布，分类为模型推理。插件接管 LLM 重试链路：按 provider/model 单独设定次数与冷却方式，并对自动审查等直接模型调用在瞬时错误时重试，避免把限流误判成「审查拒绝工具」。

这是什么¶

dsh-model-retry（当前插件版本 0.2.0，MIT 许可证）为 DSH 提供按模型的失败重试策略：重试次数（0 表示无限，且按 agent 步独立计数）、固定或递增冷却，以及针对 auto review 等单次 ctx.llm.stream() 调用的瞬时错误重试。验证环境为 DSH Desktop 0.2.1-rc.2（desktop profile）；同一 RC 系列内预期可用，跨 RC 可能发生破坏性变更。

安装后插件通过 cordis.patch.yml 停用内置 llm-retry，由本插件实现同形状执行器，并继续发出与原生一致的 llm/retry、llm/retry-started 会话事件，聊天重试卡片与日志格式不变。未配置任何模型时默认 unconfigured: inherit，行为与原生 provider retryPolicy 一致。

相对内置重试补了什么¶

另外，工具自动审查在审查模型返回 429/5xx 等时，原先会被当成审查失败并拒绝执行工具；插件在 llm/stream 瀑布上只对可重试错误码、且尚未产出内容的失败重试，真实的审查拒绝（正常 stop + JSON）永不重试。

核心功能¶

1. 按模型的次数与冷却：retries、delayMode、delaySeconds、incrementSeconds、maxDelaySeconds，以及可重试错误码白名单（默认含 EMPTY_RESPONSE、RATE_LIMIT、SERVER、TIMEOUT、TRANSPORT）。
2. 按步计数：同一步内多次失败共享计数，进入下一步从 1 重新开始。
3. 自动审查限流不误杀：429、5xx、超时、传输中断、空响应会重试；认证与参数错误仍立即失败。
4. 两种配置入口：设置 → 模型 → provider 卡片中的「失败重试」；以及设置 → 模型重试（全量视图、默认模板、unconfigured 策略）。
5. 可中断：点「停止」、轮次取消、agent 销毁会打断正在等待的重试。
6. 纯 JavaScript bundle：仓库即可安装，无单独构建步骤；需要 Node >=20（用到 AbortSignal.any）。

服务端 Retry-After（providerRetryAfterMs）在不超过 maxDelaySeconds 时优先；该字段目前主要由官方 DeepSeek 适配器透出，openai-completions 等路由不一定有。

安装与启用¶

插件以当前 dsh 进程权限运行，安装前应阅读仓库源码与 LICENSE。社区目录页：skillhub.cn/plugins/Dorufoc/dsh-model-retry（与 DeepSeek / 幻方无官方从属关系）。

Host 模块在启动时载入；DSH 模块热重载默认关闭，首次安装或修改配置后需重启对应 Host 或桌面应用，仅刷新页面不会重新加载 Host 模块。

Web Host（推荐从 GitHub 安装）¶

dsh plugin --profile web add github:Dorufoc/dsh-model-retry
dsh --profile web --dump-config

确认输出中出现 name: dsh-model-retry 后，重启 Web Host 并刷新页面。

桌面版（desktop profile）¶

先完全退出应用，再执行：

dsh plugin --profile desktop add github:Dorufoc/dsh-model-retry
dsh plugin --profile desktop list

也可从本地目录安装，例如：

dsh plugin --profile desktop add D:\path\to\dsh-model-retry

卸载¶

dsh plugin --profile web remove dsh-model-retry

卸载后内置 llm-retry 会重新启用；需重启后生效。

典型用法¶

在设置界面配置¶

在 设置 → 模型 → 任一 provider 卡片 展开「失败重试」，按模型设置次数与冷却；在 设置 → 模型重试 可查看全局默认模板与未配置模型的处理策略。

在 cordis.patch.yml 中配置¶

写入目标 profile 的配置层，在 model-retry 插件的 config 下例如：

- id: model-retry
  name: dsh-model-retry
  config:
    unconfigured: inherit
    defaults:
      retries: 5
      delayMode: fixed
      delaySeconds: 2
      incrementSeconds: 2
      maxDelaySeconds: 120
    models:
      yundu/gpt-6-astra:
        retries: 0
        delayMode: increment
        delaySeconds: 1
        incrementSeconds: 2
        maxDelaySeconds: 60
      sensenova/kimi-k3:
        retries: 5
        delayMode: fixed
        delaySeconds: 3
        maxDelaySeconds: 30

retries: 0 表示无限重试。delayMode: fixed 时每次冷却相同；increment 时第 1/2/3 次重试前等待分别为 delaySeconds、delaySeconds + incrementSeconds、delaySeconds + 2×incrementSeconds（示例：1s / 3s / 5s）。

若自动审查所用模型配额窗口较长，可为该模型加长冷却，例如：

models:
  deepseek-account/deepseek-flash:
    retries: 5
    delayMode: increment
    delaySeconds: 30
    incrementSeconds: 30
    maxDelaySeconds: 300

改完配置后重启 Host 或桌面应用；可用 dsh --profile <name> --dump-config 核对 model-retry 行与配置层是否生效。

适用场景与注意¶

适合谁：常用第三方 token 计划或转发 API、易遇 429；希望不同模型用不同重试次数或固定/线性冷却，而不是接受全 provider 统一的指数退避；开启工具自动审查且不希望审查模型短暂限流导致整步工具被拒。

务必注意：

• 插件默认不改行为，需在界面或 YAML 中为具体模型写策略。
• 与另一插件同时接管 agent/request-error 或 llm/stream 时可能冲突，只应保留一个重试执行器。
• 插件不发起网络请求、不收集遥测，只读配置与 DSH 公开扩展点。
• DSH 处于开发者预览，扩展点可能变化；不兼容时请向 Issues 附上 DSH 版本。

维护者提供的离线验证：node scripts/run.mjs selftest 与 npm test（依赖可解析的 DSH peer 包，否则测试会 SKIP）；端到端方法见仓库 docs/verification.md。

结尾¶

dsh-model-retry 把重试次数与冷却规律交到按模型配置的粒度，并在 agent 步与直接 llm/stream 两条路径上统一策略，同时修复自动审查因瞬时 API 错误误判为工具拒绝的问题。若你正在 DSH 上长期跑 agent，且受 provider 级、固定指数退避限制，可先按 profile 安装、为易抖动的模型写好 retries 与 delayMode，再观察会话中的重试卡片是否与预期一致。

• 社区目录：https://www.skillhub.cn/plugins/Dorufoc/dsh-model-retry
• 源码与文档：https://github.com/Dorufoc/dsh-model-retry