前言¶

在 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