[反馈] web_search 的两个成本相关点：调用 token 未计入会话用量、单次调用成本偏高

[freerunningkid]

先说明来意：这是在日常使用中做了一次费用对账后整理的反馈，目的是把可复现的事实和证据摆出来，供团队评估，也供社区参考。dsh 的整体体验很好（插件化结构、prompt cache 的命中率都很省心），下面两点是我们在真实任务里遇到的实际差异，绝无指责之意；如果有理解偏差，欢迎随时指正。

环境：dsh 0.1.5-rc.1（npx 安装）· Windows 11 · deepseek-official / deepseek-flash · preset lean · reasoningEffort: high
时间：2026-09-12 09:00–12:00（周六，全闲时价）· 任务：一个"本地大模型服务化 + 硬件行情"调研（42 个会话 / 39 个委托子代理 / 1,430 step / 233 次 web_search）

---

一、web_search 的调用 token 未计入会话用量，本地可见花费约为账单的一半

dsh-web-search-deepseek 每次搜索会发起一次独立的 Anthropic 兼容 Messages 调用。从我们能观察到的三个位置看，这次调用的 usage 没有归属到发起会话：GUI 的 stats 胶囊、session_projcache.json、以及会话 JSONL 中 assistant/message.usage。

同一时间窗的对照（本地 = 逐条累加 assistant/message.usage；账单 = 平台用量明细导出 CSV）：

口径	未命中输入	缓存命中输入	输出	折算（闲时价 1 / 0.02 / 4 元每百万）
本地会话日志	3,839,642	108,633,216	1,228,322	¥10.92
平台账单	12,276,871	110,405,120	1,944,657	¥22.26

差额：未命中输入 +8,437,229、输出 +716,335；本地可见部分约为账单的 49%。

定位过程（可与上表互相印证）

时段	本地 step	账单 request_count	web_search 次数	账单 miss	本地 miss	差额	账单 out	本地 out	差额
09:00	43	44	0	55,259	55,144	+115 (0.2%)	46,438	46,433	+5
10:00	91	124	9	736,777	344,818	+391,959	122,298	90,590	+31,708
11:00	1,221	1,856	223	11,484,835	3,439,680	+8,045,155	1,775,921	1,091,299	+684,622
12:00	75	78	1	238,373	216,453	+21,920	62,811	60,175	+2,636

观察到的规律：

• 完全没有搜索的那一小时，本地与账单只差 0.2%，说明本地记账本身是完整的，缺的是搜索这一路；
• 出现搜索的时段差额随即出现，且每次搜索约 36.3k 未命中 + 7.8k 命中 + 3.1k 输出；
• 账单 request_count 2,024 vs 本地 step 1,355，多出的约 669 次 ≈ 232 次搜索 × ~2.9 轮服务端检索（默认 maxUses: 5）。

带来的不便

1. 客户端无法据此自证花费，也不便在任务进行中做成本控制；这次排查需要我们额外导出账单、逐小时反推才能定位。
2. 所有基于 tokenUsage 的展示（stats 胶囊、/compact 的占用估算、contextPressure）在搜索密集的任务上会明显偏低。
3. agent 自身也难以据此自我节流：本会话第一版成本结论就少算了一半，直到拿到账单才发现。

一点建议（供参考）

1. 如果设计上允许，把搜索调用的 usage 归属到发起会话（或单列一个桶，如 searchTokens: {uncachedInput, cacheRead, output}）并让 tokenUsage 投影一并暴露；
2. web_search 的返回值里附上本次搜索的 token/成本，agent 就能即时调整检索策略；
3. 在文档或设置页 Web search 段落显式说明"一次搜索 = 一整轮 Messages 调用（服务端最多 maxUses 轮检索）"。目前这句只在 package README 里出现，使用者不容易第一时间看到。

---

二、网页调用单次成本偏高

我们理解这是接口能力所限（README 已说明 DeepSeek 没有独立检索端点，"one search costs a full model turn"），只是希望把实测数字反馈上来，便于评估默认值：

项	实测（默认 maxUses: 5 / maxTokens: 4096）
单次搜索	36.3k 未命中输入 + 7.8k 命中 + 3.1k 输出 ≈ ¥0.049（闲时）
本次任务 233 次	¥11.34，约占当日账单 51%
对照 web_fetch	纯 HTTP，无模型调用费用（仅页面文本进入 agent 上下文）

一次常规的多子代理调研（每个子代理检索若干次）累计下来就是十几元，而且这部分在客户端还不可见（见第一点）。几点不成熟的想法：

1. 默认值是否可以考虑收紧：maxUses: 5 → 2、maxTokens: 4096 → 1024。我们这边实测这两个值仍然够用，单次成本约降到 ¥0.02；或至少在设置页标注这两个字段的成本影响，交给使用者决定。
2. 让搜索成本对 agent 可见、可预算（同第一点的建议 2）。
3. 若条件允许，提供按次计费的检索后端，或支持把检索路由到独立的搜索服务：目前的实现把"检索"与"读网页"合并在一整轮模型调用中，无法只为检索付费。

---

三、附带发现：默认 contextWindow: 1_000_000 使 auto-compaction 未触发

同一批数据里：42 个会话、1,430 step、上下文最高约 192k，compaction 事件 0 次。原因是 dsh-compaction-basic 的阈值 = thresholdRatio(0.8) × contextWindow，而 DeepSeek 适配器默认窗口为 1,000,000 → 阈值约 80 万 tok，实际很难达到。

这一点本身不产生额外费用（有 prompt cache 兜底），但会带来一个隐性风险：上下文只增不减，若缓存未命中，同一批约 1.1 亿 tok 的重发会从 ¥2.2 变为 ¥220（命中 ¥0.02/M 与未命中 ¥1–2/M 相差 50–100 倍）。是否可以考虑默认按模型真实可用长度声明窗口，或在 contextPressure 达到一定比例时给出提示？

---

四、复现方式与说明

# 逐调用累加本地 usage（含 reasoningTokens）
python dsh_usage_verify.py
# 与平台导出账单逐小时对账
python dsh_reconcile.py

两个脚本只对数据源（会话 JSONL / 平台导出 CSV）做纯统计，不含密钥或个人信息，需要的话我可以把脚本与逐会话明细贴上来。

需要说明的是，以上判断来自已发布包的 README 与编译产物（npx 安装，无源码树），如果搜索 usage 其实归属在别处、或本地对账方式有误，请随时指出，我这边会立刻更正。

五、我们侧已做的临时缓解

web-search-deepseek:
  maxUses: 2      # 默认 5
  maxTokens: 1024 # 默认 4096

改后经 web/deepseek-search-llm-request 事件确认请求体为 max_tokens=1024, max_uses=2。这只是我们侧的临时缓解，计量归属的差异依然存在，最终如何取舍还是以官方判断为准。

[AETAVK]

补充：相同的搜索用量漏记问题与代码定位

我们也遇到了官方账单与 DSH 本地会话用量不一致的情况，排查后发现相同的搜索 usage 记录缺口，补充以下信息。

核查版本：@deepseek-ai/dsh-web-search-deepseek@0.1.5-rc.2，基于已安装包的编译产物。（检查上游 master@ddefc45fbc7f与0.1.6-alpha.2包后，发现尚未修复）

缺口在搜索 provider 的响应处理阶段，而不只是 UI 展示或统计遗漏。

对应上游路径：

• packages/web/web-search-deepseek/src/provider.ts
• packages/web/web-search-deepseek/src/index.ts

当前调用链：

DeepSeekSearchProvider.search()
  → recordRequest({ endpoint, apiVersion, body })
  → fetch(Messages API)
  → response.json()
  → mapAnthropicResponse(payload)
  → 返回 { sources, truncated: false }

具体观察：

1. recordRequest 在发送前执行，写入 web/deepseek-search-llm-request，仅保存请求参数，没有响应 usage。
2. mapAnthropicResponse() 提取搜索结果，但未读取或传递顶层 usage。这条请求使用原生 fetch，不经过主对话的 LLM 调用链。

期待修复~