DSH Web Search 用量审计

DeepSeek Harness Web Search 用量审计：Token、模型与成本

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

DSH 中的主对话模型和 Web Search Provider 可以走两条独立调用链。只查看 Session 顶部的模型名称或主对话 Token，可能漏掉搜索请求消耗的模型 Token、独立 API Key 和供应商账单。

2026 年 10 月的一份社区案例使用 DSH 0.2.1-rc.2：主模型选择 MiniMax，Web Search 因为只有一个可用 Provider，自动使用 dsh-web-search-deepseek。社区用户事后从归档与供应商控制台核对出 2,717 次搜索，其中 2,470 次集中在 10 月 21 日；控制台显示 deepseek-flash 消耗 28,769,009 Token、费用 68.30 元。这是单一工作流的记录，用来说明审计盲区，不是 DSH 搜索的固定成本。

搜索调用为何不在主模型账单里

DeepSeek Web Search Provider 会单独发起 Messages 请求，并在相应配置下使用 DEEPSEEK_API_KEY。Agent 的流程可能是：

主模型决定搜索
  → Web Search Provider 调用搜索模型
  → 返回搜索结果
  → 主模型读取结果并继续推理

这里至少存在两笔用量：搜索模型处理查询与结果，主模型处理工具结果和后续回答。两者可能来自不同供应商，也可能都使用 DeepSeek，但仍属于不同请求。

为什么 Session 用量可能看不全

该社区报告称，Session 事件保存了搜索请求，但没有记录对应的 usage；界面显示的主模型 Token 因而不能重建完整成本。审计时要交叉核对四类数据：

数据源能回答的问题
Session 轨迹谁在什么时候触发了搜索
Web Search 配置实际 Provider、模型与 Key 来源
Provider 控制台请求数、Token、费用与时间峰值
任务产物搜索是否带来了可用证据

只看供应商总账也不够，因为它很难直接解释是哪条 Session、哪个定时任务或哪个 Sub-agent 触发了峰值。

建立搜索预算

限制每个任务的搜索次数

把“查到满意为止”改成明确预算，例如每个问题最多 3 轮查询、每轮最多 5 个结果。需要扩大范围时，由 Agent说明缺少什么证据，再由用户批准继续。

区分发现与读取

Search 用于找到候选 URL，Fetch 用于读取少量目标页面。重复用 Search 改写近似关键词，或对同一批结果多次抓取，会把成本叠加在相似信息上。

给自动任务单独的 Key

如果 Provider 支持，可以让交互会话、定时任务和批量研究使用不同 Key 或项目。这样能按来源设置限额，也能在异常峰值出现时只停掉相关工作流。

保存可关联的用量记录

理想记录包含 Session ID、父任务、Sub-agent、查询文本摘要、Provider、模型、请求 ID、输入/输出 Token 和价格版本。供应商没有返回 usage 时，也应保存“缺失”状态，而不是记为零。

出现异常峰值时怎么查

  1. 暂停定时与递归任务，防止继续放大；
  2. 按小时查看 Provider 请求数和 Token 峰值；
  3. 对照 Session 轨迹中的 Web Search 事件与 Sub-agent 创建时间；
  4. 检查是否只有一个搜索 Provider，导致 DSH 自动选择；
  5. 查找相似查询、失败重试、循环验证和多个子任务重复搜索；
  6. 恢复时先设置硬上限，再单独放行一个任务观察。

Search 与 Fetch 的接口配置、查询操作符和限流见 DeepSeek Search 与 Fetch API 指南。如果账单由并发 Sub-agent 放大，可继续阅读 DSH Sub-agent Token 计费审计。

参考资料