前言¶
在 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 尚未就绪。
