前言¶
在 DSH 裏跑 Agent 回合時，模型往往已經向界面流式輸出了大段正文，隨後才因上游 provider 以終端錯誤結束本輪。默認情況下，這段「用戶已經看見、會話裏卻可能留不下」的文本容易隨失敗回合一起丟失，下一輪上下文也接不上。常見做法是手動複製粘貼或重問一遍，既費事也不穩定。
下面介紹 RomioLA 維護的實驗性插件 DSH Response Recovery（倉庫 RomioLA/dsh-response-recovery）。它在兼容的 DSH 核心上，把失敗前已可見的流式文本寫成會話裏一條持久的 assistant 消息，並通過 Session 的 deriveMessages 等機制供後續回合讀取；它不改動 provider 的 finish reason、過濾結果或原始回合錯誤本身。
需要 upfront 說明：資料標明該插件爲 Experimental，尚未通過常規 DSH 插件管理器/Profile 的完整安裝驗收，也未在社區市場列出；官方未發佈的 vanilla DSH Desktop 0.2.1-rc.2 不能直接啓用。普通用戶暫不應把生產環境 DSH、Profile 或 Session 拿來試裝。
這是什麼¶
DSH Response Recovery（npm 包名 dsh-response-recovery，版本 0.1.0-rc.1，MIT 許可）的定位是：在終端上游失敗之後，保留此前已經在界面上流式可見的 assistant 文本，並作爲原會話中的持久消息寫入 Session。
維護者爲 RomioLA。插件通過 Cordis 加載（cordis.patch.yml），在兼容宿主中激活後自動運行，無單獨 UI 或手動命令。它只寫入已經流式可見的正文，不復制 hidden reasoning、憑證、系統提示或未完成的 tool call，也不繞過 provider 內容過濾或靜默改寫錯誤事件。
核心功能¶
恢復策略¶
資料中的 Recovery policy 可概括爲：
- 僅最後一步失敗的回合有資格恢復。
- 在該步的多次失敗 attempt 中，選取可見文本最多的一次；並列時取最早的 attempt 序號。
- 不拼接多次 attempt、不恢復隱藏推理、不執行未完成的 tool call、不用 AI 給 prose 打分、不額外發起 provider 請求。
- 同一 turn 若已有 recovery 消息，則不再恢復；恢復內容必須與源流式文本完全一致。
已知限制：按長度選取 attempt 不評估語義質量。資料另提到 dsh-purge-community 1.6.60 在 silent retry 與 Usage 統計上存在獨立問題，本插件不修復也不保證相關統計準確，且不增加額外 token 計費。
與會話、Web 的關係¶
在具備 Recovery-aware 能力的 DSH 核心上：
- 恢復內容成爲原會話中的 durable assistant 消息。
- 可通過核心的 Session 歷史（含
deriveMessages）讀取；在支持的 reload 之後仍可用。 - 後續某次模型請求是否帶上該條，取決於是否同一 Session 且上下文組裝未截斷、摘要或排除該 recovery 消息。
- Web Chat 將 recovery 後的 assistant 消息視爲 interrupted。
- Recovery 消息不計入 provider Usage；Session Format Version 與事件類型保持不變，舊消息仍爲原生格式。
若升級後的核心仍安裝，即使卸載本插件，歷史上已寫入的 recovery 消息在覈心與 V4 讀取器仍支持時仍可能對模型可見；將會話降級回 vanilla 0.2.1-rc.2 不保證 Web Usage 等展示仍正確。
兼容性與核心契約¶
插件要求 DSH 核心暴露 RESPONSE_RECOVERY_CONTRACT_VERSION=1，包括 Session 擴展、awaited 的 Agent Loop 失敗鉤子、Token Meter 與 Web 投影變更，以及 V4 relationship validator。vanilla DSH Desktop 0.2.1-rc.2 不提供上述能力，無契約時插件拒絕激活；資料未列出已識別的官方兼容發行版。
所需核心補丁發佈在 RomioLA 個人 fork：RomioLA/deepseek-harness，分支 feat/20261030-01-response-recovery，提交 be3d6eef82408807d4d2c6dd826f08632d937487。該補丁自官方 dsh-v0.2.1-rc.2 源碼衍生，未合併或隨官方 DSH 發佈。插件源碼在 RomioLA/dsh-response-recovery。
Session Format Version 4 還需配套的 Recovery-aware relationship validator（Git Closure 01 文檔所述）：recovery 消息是在終端 failed turn 之後追加的原生 assistant/message；V4 補丁限制爲同 turn、同 step、failed turn/end 之前 assistant attempt 的一條精確可見文本拷貝，並拒絕僞造來源、僅 reasoning/tool 文本、重複及過晚的普通 assistant 消息。
安裝與啓用¶
資料未給出已通過驗收的常規 dsh plugin add … 一類命令；package.json 中 "private": true，包未發佈到 npm。dsh.bundle 中的 manifest（cordis.patch.yml）是安裝聲明，不能用來單獨打上所需的核心補丁。
不要在未修改的 DSH 0.2.1-rc.2 上安裝。 實驗性源碼方式需同時滿足：
- 本地構建並運行隔離的 DSH 宿主，合入上述 fork 的 Recovery-aware 變更（含 V4 validator）。
- 取得插件源碼 checkout，並在該宿主中解析其聲明的 peer 依賴（
@deepseek-ai/cordis^4.0.0、@deepseek-ai/dsh-session/@deepseek-ai/dsh-llm>=0.2.1-rc.2；Node >= 22）。 - 配置隔離測試 Profile，加載本 bundle 的
cordis.patch.yml。
在兼容宿主中激活後，插件自動運行。停用方式：禁用 Cordis 條目或從測試 Profile 移除 bundle（若曾手動添加 Cordis 行需單獨刪除）。卸載插件不會刪除已保存的 assistant 歷史。
倉庫內可執行測試：
npm test
對應 package.json 中的：
node --experimental-transform-types --import ./tests/preload.mjs --test tests/*.test.mjs
進一步說明見倉庫 docs/VALIDATION.md、docs/UPSTREAM_PR.md；歷史可行性報告見 docs/ARCHITECTURE_BLOCKER.md。資料註明：Recovery-aware 核心的 typecheck、build、定向 Vitest 與真實 Agent Loop/Cordis 激活在隔離測試中已通過；完整瀏覽器 E2E 與外部插件管理器/Profile 安裝路徑仍爲 NOT VERIFIED。
典型驗證步驟¶
資料建議用合成場景做實驗驗證，無需敏感生產對話：
- 構造一條流式輸出的 assistant 回答，隨後觸發終端 provider 錯誤。
- 檢查 Chat 中是否出現 recovery 後的 assistant 消息。
- 執行 Session reload，確認
deriveMessages等仍可讀。 - 發起下一次 mock 模型請求，確認上下文行爲符合預期（是否包含 recovery 取決於 Session 與上下文組裝策略）。
適用場景與注意¶
適合誰： 已在本地維護 Recovery-aware DSH 核心 fork、用隔離 Profile 做 Agent/Session 實驗的開發者；需要驗證「長回答流式到一半因上游失敗而斷檔」時能否把可見正文落盤到 Session 的場景。
務必注意：
- 插件以當前 DSH 進程的權限運行；安裝前請閱讀源碼與 MIT 許可證，僅在隔離環境試驗。
- 分發對普通 DSH 用戶仍受阻：官方尚未提供 Recovery-capable 構建，且依賴 V4 原生格式補丁；vanilla
0.2.1-rc.2不受支持。 - 社區插件目錄 skillhub.cn 上的 RomioLA/dsh-response-recovery 頁 與 GitHub 源碼均爲公開信息來源；該目錄爲社區站點，與 DeepSeek / 幻方無官方從屬關係，不宜當作官方應用商店入口理解。
資料保留一條用戶報告的歷史驗收：某次生產環境 Turn 34 通過官方 persistence API 恢復約 3,753 可見字符（sourceAttemptSeq=732），並完成磁盤 reload 與 deriveMessages；此爲歷史報告，非 Git Closure 01 在私有 Session 上的復現，原文未收錄。
結尾¶
DSH Response Recovery 針對的是 Agent 回合在上游終端失敗時已可見流式文本防丟失這一具體問題：在契約兼容的核心與 V4 validator 之上，按既定策略寫入 Session，並依賴 Session 歷史供後續回合使用。當前仍屬實驗源碼與 fork 核心配套方案，普通安裝路徑與市場 listing 尚未就緒。
