[DSH Desktop] web_search 联网搜索工具静默使用官方 DeepSeek API 并计费，且界面无任何提示

[guancn]

环境

• DSH Desktop 2.0.3（bundle: ai.deepseek.dsh.desktop），macOS
• 对话模型：内网私有部署（OpenAI/Anthropic 兼容协议，llm-pi-ai，agent-default-model = changhangju / deepseek-v4-flash）
• 联网工具：web_search（DSH 提供）
• 凭证：仅一把 DEEPSEEK_API_KEY

现象

1. 界面中明确选用的是内网私有模型（从未选择官方模型）。
2. DeepSeek 开放平台账单却按这把 DEEPSEEK_API_KEY 产生扣费。
3. 排查后确认：扣费来自 Agent 会话里的 web_search 工具调用，而非对话模型。

根因（本机已核实）

• 会话日志显示每次主对话请求 provider = changhangju / model = deepseek-v4-flash，主对话从未走官方。
• 但 web_search 的后端使用 .credentials.yaml 里的 DEEPSEEK_API_KEY 访问 DeepSeek 官方 API 鉴权。
• 证据：吊销该 key（占位符 123）后，web_search 报：
  Authentication Fails, Your api key: 123 is invalid
  与请求 DeepSeek 官方 API 的 authentication_error 完全一致。
• 结论："工具"并非本地免费函数，被静默路由到 DeepSeek 官方云服务（检索 + 可能的 LLM 处理），按用户官方 key 计费。

复现

1. 配置有效 DEEPSEEK_API_KEY，选择内网私有模型。
2. Agent 会话中触发 web_search（要求"联网搜索"）。
3. 官网账单出现按该 key 的扣费；全程界面无任何"将调用官方 API 并计费"的提示。

期望

• 透明：明确提示哪些工具/功能会调用官方云 API 并按用户 key 计费（尤其联网这类"工具"）。
• 可控：提供开关，允许把联网/工具调用的后端指向自定义（内网 / OpenAI 兼容）服务，与对话模型同通道。
• 防呆：主模型与工具通道不一致或即将产生官方计费时，给出警告/二次确认。
• 可观测：用量页区分"对话"与"工具/搜索"消费，便于对账。

补充

• 实测扣费时间窗与 web_search 调用窗口完全吻合（示例时段 15:00–16:00、20:20–20:50）。
• 删除该 key 后 web_search 即失效（123 invalid），未再扣费。

[argszero]

@guancn 这篇把「web_search 工具是本地免费函数」这个隐性假设揭穿了——它确实是走一条独立的搜索后端，且默认复用官方 key。我在当前基线（0.1.5-alpha.1）核对后，分清哪些其实已经可配置、哪些是真正的 UI 缺口：

1. 不是「不可控」，是「默认走官方」——可控性已在配置面

web_search 的模型面工具（dsh-tool-web）执行走 ctx.web；后端是 dsh-web-search-deepseek 注册的 deepseek-official 搜索 provider。这个 provider 本身可配置（packages/web/web-search-deepseek）：

• baseURL（默认 https://api.deepseek.com/anthropic/v1，可设为 https://gateway.internal/anthropic/v1 之类）——README 和错误消息都明确让用户把它指到自定义 Anthropic 兼容端点。
• apiKeyEnv（默认 DEEPSEEK_API_KEY；也可换成一个非官方的 credential ref，或给 apiKey 一个字面 key）。
• 注意搜索走后端是 Anthropic-compatible Messages + web_search_20250305 server tool，不是 chat-completions base；所以不读 $DEEPSEEK_BASE_URL，有一条独立的 DEEPSEEK_SEARCH_BASE_URL 环境变量。

所以你的「可控」诉求其实已经能满足：把 web-search-deepseek.baseURL 指到你的私有网关（OpenAI/Anthropic 兼容）、apiKeyEnv 换成私有网关的凭据，web_search 就不会再碰官方 key / 官方账单。现在之所以静默计费，是因为默认 baseURL + 默认 apiKeyEnv 都指官方。

2. 为什么「默认指官方」也算合理设计

README 明确写了：选择这个后端 = 想要 DeepSeek 原生 server-side web search 且已有 DEEPSEEK_API_KEY。一次搜索不是「一次免费检索」，而是一整轮模型调用的延迟和 token 成本（maxUses 默认 5 次 server-side 搜索/请求）。也就是说成本是声明在文档里的设计，只是 UI 没提醒。

3. 真正的缺口是「透明/防呆」，落在 core UI，不是插件缝

• 透明（明确提示哪些工具会走官方 API 并按 key 计费）= core UI（Settings/用量区），归档 upstream-fix 候选——社区改不了 core。
• 防呆（主模型与工具通道不一致 / 将产生官方计费时二次确认）= 同为 core UI 面。
• 可观测（用量区分对话 vs 工具搜索消费）= core 用量表。

4. 插件可挂载面（诚实评估）

ctx.web.registerSearchProvider({ id, available(), search() }) 确实暴露了搜索后端注册缝，理论上可以做一个「自托管 / 非官方计费」搜索 provider 插件，把 web_search 指向本地或免计费后端。但它跟已有的 baseURL 配置旋钮大幅重叠——baseURL 已经能把现有 provider 指向私有端点，一个纯「改写后端」的插件边际价值不大。除非你的私有网关不兼容 Anthropic Messages + web_search_20250305 这套格式——那确实需要一个 plugin 提供你自己的 search() 实现（例如封装一个 OpenAI 兼容的检索接口）。如果你有这种「非 Anthropic 私有检索」后端，我可以帮你把插件形态做出来并把 searchProvider 指到它。

一句话判别：计费根因 = 默认 baseURL/apiKeyEnv 指官方（配置面，README/错误消息已让用户改）；透明/防呆/可观测缺口 = core UI（归档 upstream-fix）；自托管后端插件 = 仅当你的私有后端不兼容 Anthropic 搜索格式才值得（否则与 baseURL 重叠）。

[guancn]

感谢 @argszero 的专业定位，非常清晰。 1）确认您的结论：计费原因是"默认 baseURL + 默认 apiKeyEnv 指向官网"，属于可配置项，我此前没注意到 README 里已写明，抱歉。 2）我的私有检索后端是 OpenAI 兼容，无法实现 Anthropic web_search_20250305 服务端搜索工具，所以走 baseURL 定制这条路对我较难实现——如果可以还是麻烦您按照提到的插件方向给一份 registerSearchProvider 的插件模板/最小示例，我想把 web_search 包装到我内网的检索接口上，彻底不碰官网 key。 3）同时希望"核心 UI 对会调用官方 API 并计费的工具给出明确提示/二次确认"能尽快进入 upstream-fix 并落实，这确实是值得补的产品缺口。