[Bug] web_search 每条查询各发一次独立计费请求，叠加子代理嵌套后单会话 854 次请求并耗尽余额

[heihesi]

## 环境
- dsh `0.1.1-rc.2`，Node `v24.13.1`，profile `web`
- 模型 `deepseek-v4-flash`（reasoningEffort high）
- 搜索 provider：`@deepseek-ai/dsh-web-search-deepseek`（默认配置）

## 现象
一个只有 **3 轮**的用户会话，实际产生了 **854 次** API 请求：
- 开放平台计费统计约 **800 次**
- 但本地成本类插件只显示 **176 次**（差 4.85 倍）
- 请求在 **约 5 分钟**内打完，任意 60 秒窗口峰值 **246 次**，最终以
  `{"message":"Insufficient Balance","code":"QUOTA","status":402}` 全部中断

## 复现
1. 在一个已有会话里粘贴 3 个 GitHub 仓库链接 + 一句「分析这三个」
2. 主代理自行决定扇出：一次派发 3 个子代理，其中一个又派生了 2 个（`delegationDepth` 达到 2）
3. 子代理提示词被主代理写成「Use the `web_search` tool repeatedly with many different targeted queries…」
4. 子代理执行 198 次 `web_search` 工具调用

## 关键机制（我认为这是问题核心）
`web_search` 的 `queries` 是数组，**每一条查询都会单独发起一次完整的 Messages 请求**到
`https://api.deepseek.com/anthropic/v1/messages`（Anthropic 兼容端点，带服务端
`web_search_20250305` 工具，`max_uses: 5`）。

实测放大倍率（`web_search` 调用数 → `web/deepseek-search-llm-request` 事件数）：

44 → 171 (3.89x)
17 → 49 (2.88x)
55 → 207 (3.76x)
52 → 146 (2.81x)
30 → 95 (3.17x)
合计 198 次调用 → 668 次计费请求

叠加子代理后，整棵树 = 主会话 47 + 子代理 807 = **854 次请求**。

证据：会话日志里每次请求都有一条 `web/deepseek-search-llm-request` 事件，
其中 `data.body.messages[0].content[0].text` 形如
`"Perform a web search for the query: <query>"` —— 即**单条查询 = 单次完整模型调用**。

## 由此暴露的三个可用性问题
1. **没有"会话级/单轮搜索预算"旋钮**。`tool-web` 只有面向单次调用的
   `searchMaxQueries`（默认 4），`web-search-deepseek` 只有 `maxUses`（单次请求内服务端搜索次数）。
   一旦子代理把搜索当"信息不足就再搜"的循环手段（搜索片段被截断到约 100 字符时会持续发生），
   请求量就没有任何上限。
2. **本地成本统计与官方计费口径不一致**：本地只统计 `assistant/message` 的 `usage`，
   完全不计 `web/deepseek-search-llm-request`。本次真实 854 次，本地只记 176 次，
   这 668 次请求的 token 与费用在本地**完全不可见**。用户拿本地数字对账必然以为统计出错。
3. **默认委派深度 3 偏高**。`tool-subagent` 的 `maxDepth` 默认 3，
   本次 depth=2 的孙代理在无人工确认的情况下被自动创建，放大了扇出。

## 建议
1. 给搜索加**总量预算**：例如 `tool-web` 增加 `searchMaxQueriesPerSession` /
   `searchMaxQueriesPerTurn`，或给 `web-search-deepseek` 增加会话级请求上限，超限即拒绝并回告模型。
2. 把 `searchMaxQueries` 默认值从 4 降到 **1**（多查询场景由模型显式多次调用，收益相同但可控）。
3. 子代理默认禁止再委派，或在子代理提示词模板里**强制写入搜索次数上限**
   （当前"repeatedly"这类措辞没有任何机制约束）。
4. `402 Insufficient Balance` 之前给出**前置告警**：例如按余额与近期消耗速率预估并提示，
   而不是等请求已经失败。
5. 让本地用量统计把 `web/deepseek-search-llm-request`（以及 `session/title-llm-request`）
   计入调用数与 token，使本地口径与计费口径可比。
6. 可选：搜索结果被截断时在工具结果里回告模型"继续换查询词收益很低"，
   抑制"搜不到就再搜"的循环。

## 我目前的本地缓解措施
通过 profile 的 `cordis.patch.yml` 覆盖（id 定位的 patch 会替换整行 config，故原值已重述）：
```yaml
- id: tool-web
  config: { search: true, fetch: false, searchTimeoutMs: 60000, searchMaxQueries: 1, searchMaxResults: 4 }
- id: tool-subagent
  config:
    provider: spawn
    toolName: subagent
    backgroundMode: continuable
    maxDepth: 1
    enableRunInBackground: true
    toolFilter: { deny: [subagent, subagent_fork, workflow, ralph] }
- id: web-search-deepseek
  config: { apiKeyEnv: DEEPSEEK_API_KEY, maxUses: 2, maxTokens: 1024 }

这能压住扇出，但总量预算仍然缺失——所以第 1 条建议才是根治。

以上回答全为AI生成

[argszero]

读完报告，对着 0.1.5-rc.1 的源码逐条核了一遍。机制描述基本准确，我补三点源级确认、一处数值口径的修正，以及一个已经发布的插件形态落地。

一、机制：源级确认，且请求数是可以精确预测的

packages/web/web-search-deepseek/src/provider.ts:207-217 为每个 WebSearchRequest 构造一个完整请求体（Perform a web search for the query: ${request.query}），随后 recordRequest（src/index.ts:117-122）追加一条 web/deepseek-search-llm-request。

关键点：这条事件是 per query，不是 per call。所以它的条数 = 该次 tool call 的 distinct query 数（tool-web 在扇出前把完全相同的字符串折叠为首现）。

这正好解释你表里的"放大倍率"：

web_search 调用	search-llm-request	比值
44	171	3.89
55	207	3.76
30	95	3.17
17	49	2.88
52	146	2.81

平均 ≈3.4 —— 这不是 maxUses（默认 5）在起作用，而是你每次调用平均带了约 3.4 条 query（上限 searchMaxQueries=4，去重后略低）。换句话说：请求数完全由模型给的 queries 数组决定，没有隐藏扇出；maxUses 管的是服务端在这一次请求内部原生搜索几轮，而它不出现在这条事件里。

这个区分对修法很关键：请求数可以在派发前拦住（完全可控），原生搜索数只能在 provider 侧配置。

二、上游已经把这条缺口写成"已知限制"，并给出了修法形状

packages/web/tool-web/README.md 的 Known limitations 一节原文：

There is no batch-wide native-search counter — searchMaxQueries bounds ctx.web.search calls, but a provider may perform several native searches inside each call; for example a model-backed provider configured with maxUses can permit up to searchMaxQueries × maxUses native searches …

也就是说你的第 1 条，维护者是知情的，并且明确列为 deferred work。

更有用的是同一节末尾给部署的指示：

Deployments that need per-call confirmation must add a tools/pre-execute policy or disable fetch.

你建议 1 想要的那个总量预算，上游指的路就是 tools/pre-execute。这不是要新发明一条缝——这条缝已经有名字，只是没有实现。

三、你的第 2 条确认，但结论要比"本地统计错了"更硬

packages/llm/token-meter/src/index.ts:278 只对 assistant/message 结算 usage。而搜索请求这条事件不只是"没被统计"——它根本没有可统计的 usage。事件类型的注释是 "Secret-free auxiliary DeepSeek search request recorded before dispatch"，载荷只有 endpoint / apiVersion / body（见 provider.ts:53-76（接口定义）、:82（事件注释），消费侧 session-format-v0-to-v1/src/dispositions.ts:125）——响应体从未落盘。

所以本地口径的差不是"漏了一个事件"，而是这条路径从设计上就没记录用量。任何插件也无法从日志反推费用；要修只能改 token meter 或让 provider 记录 response usage。建议把这条单独拆出来提给上游，它和总量预算是两个修复。

四、建议 2（searchMaxQueries 默认降到 1）我不建议

tool-web README 明确写了这个值会进入提示词指引与 schema 描述，并且"配置、scope 限制、searchMaxQueries 或插件生命周期变化可能从首个变化的提示词区段开始使复用失效"。改默认值会动已发布的提示词前缀；加一个门比改一个已公布的旋钮便宜，而且后者影响所有部署。

五、插件形态的落地

你的建议 1 我按上游指的那条缝做成了插件：

@argszero/cordis-plugin-search-budget

• npm: https://www.npmjs.com/package/@argszero/cordis-plugin-search-budget
• 仓库: https://github.com/argszero/cordis-plugin-search-budget

默认值就是按你这条报告的形状定的：

- set:
    - id: search-budget
      config:
        queriesPerRequest: 5   # provider 的 maxUses
        perCall: 10            # 单次 web_search 调用允许发起的请求数
        perTurn: 0             # 每轮（0 = 关）
        perSession: 0          # 每会话（0 = 关）
        perTree: 60            # 一个顶层会话 + 其全部子代理共享
        enforce: true          # false = 只记录不拒绝

它挂在 tools/pre-execute 上——该阶段 exec.arguments.queries 已经可读，所以估算 cost = distinct(queries) × queriesPerRequest，超预算即 { kind: 'deny', reason }。被拒的调用根本到不了 provider，因此"派发前估算再拒绝"就是全部机制，不需要事后对账；也因为它只会拒绝、不会放行，它不可能制造本来不会发生的请求。

关于你的第 3 条（子代理扇出）：perTree 就是你缺的那个旋钮——它沿 SessionHeader.parentSession 链上溯到顶层会话，主代理与所有后代共享同一份预算。你机器上那个 854 次的形状（主 47 + 子 807），在默认 perCall: 10 / perTree: 60 下会在第一次 4-query 调用（估算 20）就被拦。想先按实测值定预算的话，enforce: false 是只记录不拒绝的模式。

32 个测试（npm test）覆盖：query 估算（含 tool-web 那套完全重复折叠与空白过滤）、血缘解析（含环状链、祖先已不存活两个边界）、当前 turn 判定、四个 scope 的准入与计费、dispose 释放，以及按你报告里 854 次那个扇出形状对默认值的复现。

有两点想听你的实测，因为它决定这个插件够不够：

1. 668 次请求 / 198 次调用这条，能否被你日志里逐个 call 的 query 数组长度证实？如果成立，web_search 的请求数就是完全可预测的（插件正是基于这个假设）。
2. maxUses 那部分（服务端原生搜索）在你的账单里是否单独计费？日志里看不到它——如果你能从开放平台后台区分出来，那才真正需要 provider 侧的请求上限。