本轮运行失败 deepseek request extension preparation failed 怎么修？DSH plugin 请求扩展报错排查

这句报错的完整形态是「本轮运行失败 / DeepSeek request extension preparation failed」，报错码 REQUEST_EXTENSION——报错 X → 执行 W：先按「重启会话 → 重装相关插件 → 看日志定位扩展」三步收口，把那个把整轮请求拖垮的扩展来源找出来（来源）。 它发生在适配器 fetch 之前，所以典型特征是零网络流量，网络、代理、鉴权、配额一口气都能先排除。这是一篇「先救火、再分流」的排查指引；真正深挖「坏插件包」那条根因链，看《request extension 失败：一个坏插件包拖垮官方线路》。

「deepseek request extension preparation failed」报错是什么意思

它表示 DeepSeek Harness 的一次请求在「扩展准备」阶段就失败了：适配器在真正发出 HTTP 之前，会先并发跑所有请求扩展贡献者，只要其中一个抛错，整轮请求就被判失败并包装成 REQUEST_EXTENSION（来源）。 三个关键事实：

1. 失败在 fetch 之前 —— 请求根本没发出去，所以「零网络流量」是它最好认的指纹。
2. 它是一个「请求扩展」的问题 —— 出错的多是那些在发请求前往请求里附加信息的贡献者，例如采集当前活跃插件包的诊断字段。
3. 它会把整批拖垮 —— 准备阶段用 Promise.all 并发执行，一个贡献者拒绝就整体拒绝，于是每一轮都失败。

先看它和相邻报错的分工，别混为一谈：

记住一句话：看到 REQUEST_EXTENSION，先别怀疑网络，先怀疑「某个请求扩展在本地准备阶段抛错了」。

DeepSeek Harness 报 request extension 失败怎么修：重启会话、重装插件、看日志

修复分两层：先做「止血」——把当前轮次重新跑起来；再定位「出血点」——找到把请求拖垮的那个扩展来源。 按四步走：

1. 重启会话，先确认症状是否持续 —— 关掉当前会话新建一轮，重发一次消息。预期：如果只闪了一次就恢复，多半是偶发；若每轮都报同一句，说明是确定性问题，继续往下。
2. 确认是不是只有官方线路受影响 —— 在同一 profile 下换到别的路由发一次。预期：别的路由正常、只有官方线路每轮失败，就把范围缩到官方线路独有的那个请求扩展贡献者上。
3. 重装相关插件 —— 把最近新增或更新过的插件在插件面板里卸载再装一次，或先临时移除。预期：某个包目录被更新器掏空、或 manifest 缺字段时，重装能把它补齐，报错随之消失。
4. 看日志、展开 cause 定位到具体扩展 —— 翻会话日志里该轮的记录，展开错误对象的 cause。预期：cause 里会点名那个包或 manifest 路径；这一层信息才是真正可操作的线索。

展开 cause 之后常见的两类形态：

1. 指向一个无法解析的活跃插件包 —— 报错文案里带「cannot resolve active package」之类字样，说明某个包在磁盘上找不到可读的 package.json。
2. 指向一个「有 name 缺 version」的 manifest —— 说明向上找到的那份 package.json 声明了 name 却没有 version，落在了校验范围之外。

一个容易被忽略的细节：修好之后通常不需要重启宿主。 失败的解析结果不会被缓存，所以补上缺失字段或恢复坏掉的包目录后，下一个请求就能恢复；这也意味着「重启」不是解法本身，只是让你重新尝试一次而已。

与 broken package 分支怎么区分

同一个 REQUEST_EXTENSION 报错背后至少有两类触发路径——「某个插件包本身坏了」与「生成的 manifest 天生缺字段」，判据是看 cause 指向的是包目录还是 manifest；这两条路径的完整成因与修法已在《request extension 失败：一个坏插件包拖垮官方线路》里逐条写过，本篇只负责把「先救火、再分流」这一层做完。

同族里还有一条要分清的：TRANSPORT 是传输层的兜底标签，表示失败没能被归类，与「请求准备阶段被扩展拦下」是两回事——区分要点与排查顺序见《DeepSeek Harness messages transport failed 排查》。

排查 DSH plugin 请求扩展报错前的须知

在装、卸、更新任何 DSH插件 之前先记下变更点，能让下一次 REQUEST_EXTENSION 的定位快上不少。 三条须知：

1. 先认指纹再动手 —— REQUEST_EXTENSION 等于「零网络流量 + 本地准备失败」，先用这一点把网络层整套排除。
2. 变更要有迹可循 —— 插件增删、版本更新都集中管理，排查时先问「最近动了什么」，DSH Plugin Hub 的已安装列表与系统日志可以对照着看。
3. 报错文案会吞线索 —— 当前界面只渲染最外层那句，真正的 cause 需要你主动展开，别只盯着那句 preparation failed 发呆。

使用 DSH plugin 的注意事项与局限

1. 一个坏扩展就能拖垮整轮 —— 准备阶段用 Promise.all，没有逐包容错，所以「只有一个包有问题」也足以让官方线路全挂。
2. 好处是修好即恢复 —— 失败的解析不缓存，补上缺失字段或恢复包目录后，下一个请求就正常，不必重启宿主。
3. 别把相对路径入口当免疫 —— 相对、绝对、file URL 入口只在「找不到 manifest」时静默省略；一旦向上找到的 manifest 存在但畸形，照样抛错。
4. 报错不给包名是当前缺口 —— 这一步往往要你自己临时加打印或看宿主日志才能拿到 cause。
5. 官方是否已修以版本为准 —— 该链路是文档写明的严格契约，修复状态请以你安装的官方版本说明为准，别默认「下个版本就好了」。

与其在一堆报错里猜是哪个扩展把请求拖垮，不如用 DSH Plugin Hub 把插件的安装与变更都摆在明面上：通知中心记着每一步操作轨迹，装了哪个、什么时候装的都查得到，下次再报 request extension preparation failed 时能直接对着记录复盘。

来源：#6497、#7678。