DSH REQUEST_EXTENSION 故障排查

DeepSeek Harness REQUEST_EXTENSION 故障排查

作者
DeepSeekAgent.io 编辑部
发布
更新

当 DeepSeek Harness 显示“本轮运行失败”并附带 DeepSeek request extension preparation failed、REQUEST_EXTENSION 时，问题通常还没有到达模型 API。DSH 会在发送请求前运行一组请求扩展，为调用补充插件清单等信息；其中一个扩展失败，旧版本便可能在真正的 HTTP 请求发出前终止整轮对话。

这类故障容易被误判为 API Key、额度、网络或模型不可用。判断顺序反过来会更有效：先确认失败是否发生在请求准备阶段，再检查最近安装、卸载或修改的插件与 Profile，最后才排查 Provider。

先看它是不是 REQUEST_EXTENSION

典型现象包括：

  • 每条消息都立即失败，自动生成会话标题也可能同时失败；
  • 界面显示 DeepSeek request extension preparation failed；
  • 错误代码是 REQUEST_EXTENSION；
  • DeepSeek Provider 受影响，其他 Provider 可能仍可调用；
  • 直接调用同一 API Key 可以成功，DSH 内的调用却在很短时间内失败；
  • 日志没有模型侧的请求 ID、HTTP 状态码或限流信息。

最后两项不是绝对条件，但它们能帮助区分“本地准备请求失败”和“请求已经到达模型服务后失败”。如果日志包含 401、402、429 或 Provider 返回的请求 ID，应转向凭证、额度和限流排查，而不是继续修改插件。

请求在哪里中断

DSH 的调用链可以简化为：

用户消息
  → 读取当前 Session 与模型配置
  → 运行请求扩展
  → 合并扩展字段
  → 向模型 Provider 发出 HTTP 请求
  → 处理流式响应

plugin-package-inventory-deepseek 是触发这类故障最多的扩展之一。它会读取当前 Loader 中的活动插件，把可识别的包整理为 dsh_plugin_packages。模型调用并不依赖这份清单才能理解用户消息，但旧实现会把扩展准备视为一个整体：任意活动条目无法解析，整个准备阶段便失败，后面的 HTTP 请求不会发生。

因此，“只有 DeepSeek 模型失败”并不能直接证明 DeepSeek API 有问题。更可能的原因是 DeepSeek 请求路径启用了这项特定扩展，而其他 Provider 没有经过同一段准备逻辑。

四类常见根因

1. 插件卸载后留下失效条目

插件市场或手动安装曾经把一个 Bundle 挂载到 Profile，卸载时却留下空目录、旧状态记录或无法解析的 Loader 条目。DSH 仍把它视为活动项，请求扩展却找不到对应包。

这类故障往往紧跟在“安装—停用—卸载—重启”之后出现。应先在 Plugins 页面或 Plugin Manager 中核对当前 Profile 的已安装 Bundle 与活动 Plugin，不要直接清空整个 node_modules 或 Profile 目录。

2. 本地文件插件没有完整包身份

Profile 可以引用本地 .ts、.js、.mjs 文件或目录，但插件清单扩展需要把活动项映射到 npm 风格的包身份。最近的 package.json 如果只有 name 而没有非空 version，或目录根本没有可用 manifest，解析就可能失败。

本地插件应放在拥有独立 package.json 的目录中，并至少声明：

{
  "name": "my-dsh-plugin",
  "version": "0.1.0"
}

这里的版本用于标识插件包，不会把插件自动发布到 npm。

3. Windows junction 或模块回退链接失效

在 Windows 与 pnpm 工作区中，junction、相对符号链接和 Profile 的模块回退目录可能组合出失效路径。插件本身存在，Loader 也可能已经激活它，但请求扩展从另一个解析锚点查找包时得到 cannot resolve active package。

升级后首次出现、错误中包含 @deepseek-ai/dsh-* 官方包名，而且重新保存 API Key 没有任何变化时，应优先检查安装与 Profile 的包解析状态。不要因为错误出现在模型调用界面，就反复更换 Key。

4. Profile Patch 中仍有旧插件配置

插件文件已经移动或删除，cordis.patch.yml 中的条目却仍然启用；或者条目的包名、目录和实际安装结果已经不一致。DSH 启动成功并不代表每个活动项都能被请求扩展再次解析。

先定位最近改动的条目，再通过 Plugins 页面停用它。确实需要手动处理时，应先备份当前 Profile，只把目标条目标记为停用，不要注释或删除一大片无关配置。

推荐的排查顺序

第一步：记录版本和完整错误

确认 DSH 主包或 Desktop 所带的版本、当前 Profile、操作系统，以及错误是否包含 REQUEST_EXTENSION。不要只记录“本轮运行失败”，因为不同失败代码对应完全不同的链路。

第二步：确认请求是否到达 Provider

查看失败时间、HTTP 状态、Provider 请求 ID 和服务端用量。几十毫秒内失败且没有任何 Provider 记录，通常说明问题仍在本地准备阶段。已经产生服务端状态码时，应按该状态码处理。

第三步：回看最近的插件变化

按时间倒序检查：

  1. 刚安装或更新的第三方 Bundle；
  2. 刚卸载但仍显示在 Profile 中的条目；
  3. 本地文件或目录插件；
  4. 刚迁移过的 Profile；
  5. Windows 上升级后遗留的模块链接。

一次只停用一个可疑条目并重新测试。这样才能确认根因，也避免把正常插件一起移除。

第四步：核对 manifest

对本地或第三方插件检查最近的 package.json：name 和 version 应是非空字符串，入口文件应真实存在，Profile 中记录的名称应与安装结果对应。

第五步：恢复而不是重建

优先使用 Plugin Manager 停用、移除或重装明确有问题的 Bundle。不要把删除整个 ~/.dsh、Profile 或 node_modules 当成第一步；这些操作会抹掉能够定位问题的状态，还可能影响 Session 和其他插件。

临时恢复方案

在仍采用旧失败策略的版本中，如果已经确认是 plugin-package-inventory-deepseek 导致，而且需要先恢复对话，可以在当前 Profile 中临时停用该扩展。停用后，请求不再携带 dsh_plugin_packages 字段，但基本模型调用仍可继续。

这是一种隔离手段，不是永久修复。完成工作后仍应找到损坏的插件条目、补齐 manifest 或修复安装状态。若扩展错误来自其他安全或权限能力，也不应简单忽略。

v0.2.1-alpha.2 改变了什么

在较早版本中，一个请求扩展抛错可能直接终止整个模型调用。v0.2.1-alpha.2 调整了失败处理：单个扩展出错时记录可归因的警告，并允许请求继续，重复故障也不会无限刷屏。

这让“插件清单损坏”不再必然等于“所有对话不可用”，但它没有修复每一种损坏的插件状态。警告仍然说明当前配置不完整；如果缺失的是权限、安全策略或任务所需上下文，就不能把降级执行当成正常状态。

npm 的 latest 与 next 目前仍指向 0.2.0-rc.2，普通安装不会自动获得 alpha.2。需要验证新行为时应固定完整版本号，并先备份 Profile 与 Session：

npx @deepseek-ai/[email protected] web

快速判断表

现象优先检查
REQUEST_EXTENSION，没有 HTTP 状态码插件清单、Profile 与本地包解析
只在 DeepSeek Provider 出现DeepSeek 请求扩展与 dsh_plugin_packages
安装或卸载插件后开始失败残留 Loader 条目与 Bundle 状态
本地文件插件启用后失败最近 package.json 的 name、version 与入口
Windows 升级后官方包无法解析junction、pnpm 链接与 Profile 模块回退
出现 401、402、429API Key、余额、权限或限流
alpha.2 中对话继续但出现警告定位失败扩展，修复配置，不要长期忽略

相关阅读

参考资料