[Bug] 仅用账号登录（未配置任何 API key）时 web_search 100% 失败于 WEB_PROVIDER_CREDENTIAL_MISSING，且界面无任何引导

[laurence8023]

感谢维护 DSH。这里报告一个入口级的问题，并附最小复现与包内配置证据，供参考。

环境限定：本条针对官方 DSH 桌面版（DeepSeek Harness 桌面应用，运行时 @deepseek-ai/dsh-desktop-runtime@0.1.7-rc.2，DSH_HOME = ~/.dsh，profile desktop，Nightly 渠道），并走账号登录通道。不是社区打包的 DSH Desktop，也不是 npx @deepseek-ai/dsh web 的 CLI / Web 形态。为免混淆，下文所说的「DSH」均指这一官方桌面版。

环境

• 官方 DSH 桌面版（DeepSeek Harness 桌面应用），桌面运行时 @deepseek-ai/dsh-desktop-runtime@0.1.7-rc.2，Nightly 渠道
• Windows 11 x64
• DSH_HOME = C:\Users\<user>\.dsh，profile = desktop
• 聊天通道：账号登录（agent-default-model.provider = deepseek-account），对话正常
• 未在 Models 页或插件页配置过 API key；refs 中没有 DEEPSEEK_API_KEY
• 现象日期：2026-09-25

现象

只使用账号登录、不额外配置 API key 的情况下：

1. 对话正常。
2. 每次 web_search 调用都会失败，原文如下：

Error: DeepSeek search has no API key for "DEEPSEEK_API_KEY"; store it through the
credentials service (the web Models page writes it), export it in the launching
environment, or set a literal "apiKey" in the web-search-deepseek config

3. 同一次会话里 web_fetch 可以正常使用，因此判断与网络无关，而是搜索通道的凭据问题。
4. 错误码为 WEB_PROVIDER_CREDENTIAL_MISSING。

也就是说：装的是官方包、登录的是官方账号、用的是默认配置，但联网搜索从第一次使用起就不可用，界面上也暂未看到相关提示。

我们排查到的原因（基于安装包内配置与文档整理）

1. 搜索提供方的凭据引用固定为 DEEPSEEK_API_KEY，不随聊天通道变化。dsh-base 的 patch 中：

- id: web-search-deepseek
  name: '@deepseek-ai/dsh-web-search-deepseek'
  config:
    apiKeyEnv: DEEPSEEK_API_KEY

2. 账号登录写入的是另一类凭据：deepseek-account-platform 通过 credentialKey("deepseek-account-platform", "default") 保存 PKCE grant；按 @deepseek-ai/dsh-credentials 文档，凭据文件分为 refs（简单密钥引用）与 records（结构化授权）两段。账号登录写的是 records，并不写 refs.DEEPSEEK_API_KEY。
3. 于是这两条凭据目前互不填充：搜索解析 refs，账号登录写 records。
4. 包内注释也印证了这一设计假设，dsh-base 原文：

# DeepSeek search resolves the same DEEPSEEK_API_KEY
# credential the Models page manages for chat, at each search

该假设在「聊天也用 API key」时成立；而当用户走的是账号登录通道时，这一点似乎还没有对应的覆盖方式。
5. 另外了解到：账号授权本身应当也可以访问推理端点（deepseek-account-platform 配置中 inferenceOrigin 为 https://api.deepseek.com），但搜索提供方固定走 apiKeyEnv 这条引用，不会去解析账号 grant。

复现步骤

1. 全新安装官方 DSH 桌面版，启动后仅用账号登录（不在 Models 页 / 插件页填任何 API key）。
2. 确认对话正常。
3. 在会话中触发一次联网搜索（例如「搜索一下 X」）。
4. 观察：web_search 返回上述 WEB_PROVIDER_CREDENTIAL_MISSING；web_fetch 仍正常。

一点建议（仅供参考，按投入产出排序）

以下几项供参考，任选其一都会有帮助：

1. 提示层面：账号登录用户首次触发 web_search 时，给出可操作引导（「网页搜索需要单独的 API key，请前往 设置 → 插件 → 网页搜索 配置」），而不只是一个错误码。这与 Notify users when switching chat provider that web search has its own config #6023 的建议方向一致。
2. 通道层面：可否考虑让账号授权也能被搜索提供方解析——例如 apiKeyEnv 解析不到时回退到账号 grant；或在 Models 页说明两条通道（账号登录 / API key）各自覆盖哪些能力。
3. 可观测性：与 web_search auxiliary calls bill tokens that never reach the session log #7195 一并考虑——搜索是独立计费的辅助调用，目前不进会话日志，用户较难对账。

与已有讨论的关系

• Notify users when switching chat provider that web search has its own config #6023、web_search 固定请求官方端点，导致自配网关的用户搜索必现认证失败 #408 讨论的是已配置 key 的用户在切换提供方后，搜索的端点／凭据不跟随。
• [DSH Desktop] web_search 联网搜索工具静默使用官方 DeepSeek API 并计费，且界面无任何提示 #6038、web_search auxiliary calls bill tokens that never reach the session log #7195 讨论的是已配置 key 的用户，搜索按该 key 计费且计费不可见。
• 我们遇到的是更靠前的一种情况：账号登录用户手上没有任何 key，搜索从一开始就不可用。此前的讨论大多以「用户已有一把 key」为前提，因此这个入口场景此前似乎未被覆盖。

关联讨论

• Notify users when switching chat provider that web search has its own config #6023 Notify users when switching chat provider that web search has its own config
• [DSH Desktop] web_search 联网搜索工具静默使用官方 DeepSeek API 并计费，且界面无任何提示 #6038 [DSH Desktop] web_search 联网搜索工具静默使用官方 DeepSeek API 并计费，且界面无任何提示
• web_search auxiliary calls bill tokens that never reach the session log #7195 web_search auxiliary calls bill tokens that never reach the session log
• web_search 固定请求官方端点，导致自配网关的用户搜索必现认证失败 #408 web_search 固定请求官方端点，导致自配网关的用户搜索必现认证失败

感谢阅读。如需补充证据（refs / records 结构或 app.asar 内配置原文），我随时可以提供。

[PerryLink]

WEB_PROVIDER_CREDENTIAL_MISSING 是设计内的失败——但"界面无引导"这条你也说对了，原因在一个细节里

1. 为什么"账号登录 + 无 API key"必然失败

packages/web/web-search-deepseek/README.md:49：

项	默认	说明
apiKeyEnv	DEEPSEEK_API_KEY	每次搜索通过 ctx.credentials 解析；没有该服务时从进程环境解析。值缺失时调用以 WEB_PROVIDER_CREDENTIAL_MISSING 失败

而 :157 把这条路解释得更清楚：

Dynamic credential availability resolves inside the operation — the synchronous availability check can establish that a resolver exists but cannot query an asynchronous credential store, so a selected keyless provider fails the search with WEB_PROVIDER_CREDENTIAL_MISSING; the stable web_search schema stays registered.

⇒ 这正是你的情形：账号登录只提供对话通道，搜索通道仍然要 DEEPSEEK_API_KEY；于是 provider 是"已选中"的、工具也照常注册，但每次调用都在凭据解析那一步失败。它不是崩溃，而是设计上"没有凭据就别调"。

2. "界面无任何引导"——关键在于那段引导是写给模型的

:68 写明：失败信息会指名解析到的搜索端点、说明搜索端点配置与对话是分开的、并指向 Settings > Plugins > Plugin configuration > Web search（该页不可用时给出 DEEPSEEK_SEARCH_BASE_URL 与 web-search-deepseek.baseURL）——但紧接着一句是关键：

The model-facing web_search tool surfaces this text under its own error wrapper.

也就是说：这段引导首先是给模型看的，用户能不能看到，取决于模型有没有把它转述出来。你看到的是一个裸的 WEB_PROVIDER_CREDENTIAL_MISSING ⇒ 很可能就是它没有被转述（或被渠道截断）。

所以你的诉求应当精确到这一点：不是"加引导"（引导已经写了），而是"把这段引导直接呈现给用户，而不是只交给模型转述"。这是一个呈现层的问题，比"补文案"更容易落地。

3. 两条具体建议

1. 把"当前搜索通道是否可用"显示在界面上（例如设置页/输入框附近提示"搜索需要 API key，当前未配置"）——尤其在账号登录这种"看起来一切都好"的入口下，否则用户只会以为是网络问题；
2. 或在首次调用时给一次性提示，并附上你那句"搜索端点配置与对话分开"——这是用户最需要知道的一句话。

4. 版本提醒

你在官方桌面版 @deepseek-ai/dsh-desktop-runtime@0.1.7-rc.2 —— 就是当前最新（tag dsh-v0.1.7-rc.2），无需先升级。

一条边界

我确认的是该错误码的成因与那段引导的存在（来自包内文档原文）。**"桌面版界面上是否真的没有展示它"**以你的实机观察为准——我没有跑桌面版验证呈现层。