[Bug] 子代理静默终止 + 工具输出无界注入上下文，导致约 1.09 亿 token 无效消耗、多批次零产出

[zhu1148]

一、结论

一次企业资质核查任务派发 21 个子智能体，消耗 108,842,852 token / ¥46.94，消耗与任务量无关，多个批次工作因无成本护栏被迫中断作废

环境：Windows 10 x64，DeepSeek Harness 桌面端 0.2.0-rc.2

二、用量数据

平台侧（今日）：
消费金额 ¥46.94
API 请求次数 2,981
Tokens 108,842,852

11:00–12:00（占全天 99%）：
请求次数 2,960
Tokens 107,903,775
输入(命中缓存) 92,563,328 (85.0%)
输入(未命中) 13,308,776 (12.2%)
输出 2,031,671 (1.87%)

平均每请求重放 36,454 token，产出仅 686 token，上下文与输出比 53:1。

DSH 侧：
子智能体数量 21
单 agent 消耗 19K ~ 12M token（跨度 > 600 倍）
单 agent 面板 1,766,225 tok，缓存命中 97%，缓存读取 1,689,216，
未缓存输入 55,457，输出 21,552，1 轮 35 步

三、核心问题

1. 消耗与任务量严重不成比例。
同为核查企业资质：一个子代理 19K token 即完成，其余为 1.6M–12M。
若全部按 19K 量级运行，总量约 0.4M token（约 ¥0.17），实际 108.8M token
（¥46.94），相差约 272 倍。说明消耗不由任务规模决定，而由编排行为决定。

2. 高缓存命中率是上下文失控的证据，不是优化结果。
97% 命中说明上下文高度重复，但上下文本身被无界撑大。输出占比仅 1.87%，
即约 98% 的算力用于重放上下文，而非产生结果。

3. 工具输出无长度上限地注入上下文（根因）。
web_fetch 整页回传，含全站导航、页脚、推荐列表，某次返回中包含 129 个
图片链接。此类内容在后续每一步被重复重放，直接造成上述 token 量级。

4. web_search 为每个 query 派生独立后台 LLM 请求。
日志事件 web/deepseek-search-llm-request 显示：一次含 4 个 query 的
web_search 会产生 4 个独立的 deepseek-v4-flash 请求（每个自带
max_uses:5 搜索预算），其 token 全部计入用户账单。用户对此无感知、
无控制。这是请求次数达到 2,981 的主要来源之一。

5. 无成本预警与熔断，导致工作被迫中断作废。
单会话 81 步 / 15.7 万 token，全程无任何告警或软上限。余额降至 ¥2.86
时才被发现，被迫手动暂停。此时两个批次实际已完成核查——其中一批已
在官方 PDF 中命中目标企业，另一批已下载两份可解析的官方 xlsx
（39,475 与 21,847 字节）——全部因中断未能输出，工作作废。
若存在成本护栏或超限提示，这部分损失完全可以避免。

6. 子代理共用临时目录，并发互相污染。
多个子代理写同一 %TEMP%\zxcheck。某会话目录清单中出现该会话从未创建的
文件（gd2020recheck.xls、gd2023.xls、gd2024.xls、jj21.html、
skx_*.html、ocr/、img/ 等），来自并行运行的兄弟会话，已造成证据交叉
污染与同一 PDF 的重复下载（sz2025.pdf / sz2025a.pdf）。

7. web_fetch 拒绝 application/pdf。
Error: unsupported content type "application/pdf"。官方名单以 PDF 为主。

8. 跨域重定向被阻断。
WEB_REDIRECT_BLOCKED，每次额外消耗一轮往返。

四、诉求

1. 退还因上述缺陷（尤其第 1-5 项）产生的无效消耗的金额。
2. 修复：
   a) 工具输出按类型限长与摘要，禁止整页注入；
   b) web_search 的后台 LLM 请求须对用户可见、可限额；
   c) 子代理临时目录按 session id 隔离；
   d) 支持 PDF/docx 附件落地或返回可用下载路径；
   e) 跨域重定向按策略跟随。
3. 增加单子代理步数/token 上限并熔断，超限时通知父会话与用户，
   而非静默烧尽。

五、附件

4_session.v4.txt、5_session.v4.txt、6_session.v4.txt（完整会话日志，
seq 编号可直接对照）。其余 18 份子代理日志存在同类症状。

4_session.v4.txt
5_session.v4.txt
6_session.v4.txt

[argszero]

Thank you — the cost breakdown is the part that makes this report usable, and item 3 is correct at the source level. I traced it, and the mechanism is worth stating precisely because it determines which fix can land where.

Where the unbounded result comes from. A tool result reaches the model exactly as the tool printed it, and nothing on the recording path bounds it. The tool/result event is appended whole, and from then on the same text is re-sent with every later request of that session — which is the 53:1 replay you measured, and the reason a 97% cache-hit rate makes it worse rather than better: caching lowers the unit price of replay, it does not stop the replay.

The harness already ships the reducer, and it is not enough here. @deepseek-ai/dsh-compaction-tool-result-pruner keeps the head and the tail of an over-long result and drops the middle — the same shape item 3 asks for. But it is gated on compaction pressure; its own README states that below-pressure conversations remain unchanged. So the window it does not cover is exactly the window your run lived in: twenty oversized results replayed for twenty turns while the session is nowhere near its context limit. The gap is before the pressure, not under it.

What I built for it. I published a plugin that performs that reduction unconditionally, at injection time:

npm install @argszero/dsh-tool-output-budget

# in your profile's bundle patch (dsh.bundle.patch)
- insert:
    - id: tool-output-budget
      name: '@argszero/dsh-tool-output-budget'

Source and full write-up: https://github.com/argszero/dsh-tool-output-budget — npm: https://www.npmjs.com/package/@argszero/dsh-tool-output-budget

It listens for each tool/result as it is appended and, once the appending call stack has unwound, replaces the ones over budget with the head, a marker and the tail. Defaults are deliberately looser than the pruner's (thresholdChars: 16384, headChars: 8192, tailChars: 2048) because this runs on every ordinary request rather than only when the session is already in trouble; all three are configurable, and exemptTools is the escape hatch. Every tool is in scope — there is no allow-list to fall off.

Two properties I cared about more than the reduction itself:

• The tool's real output is not destroyed. The plugin does not rewrite the result as it is recorded; it writes a surface replacement (surfaceOp: { op: 'replace', … }) paired with the compaction/prune shadow-price event the shipped producers already define for this. The middle is removed from the model's view only — the full result stays in the session log for you, and for replay.
• It refuses a configuration it cannot honour rather than mounting and doing nothing. A misspelled knob that mounts silently is how an operator believes a budget is in force when it is not — which is the same failure class as the one you are reporting.

Boundaries are counted in code points, not UTF-16 code units, so a retained boundary cannot leave a lone surrogate in a request.

What this does not fix — so you do not expect more of it than it is. It bounds the size of each result; it does not bound the number of results, and it does not touch the other items in your report:

• item 4 (each web_search query spawning its own background LLM request) is a tool-side behaviour, untouched by this;
• item 6 (subagents sharing one %TEMP% directory) is a separate defect, and arguably the most damaging one in the report — cross-session file contamination invalidates the evidence, not just the bill;
• items 5, 7 and 8 (no cost circuit-breaker, application/pdf refused by web_fetch, cross-origin redirects blocked) are core/tool-side surfaces; a plugin can observe and report but cannot add a spend limit the session does not already expose.

On item 5 specifically: your point that the work was already done when it was cut off — one batch had matched the target company in an official PDF, another had two parseable official xlsx files on disk — is the part of this report that costs the most, and it is not a cost problem at all. A spend ceiling that fires after the results exist still needs the results to be emitted.

I am not affiliated with the harness maintainers; this is a community plugin, mounted through the normal bundle-patch mechanism, changing no core package. It works on the released lines 0.1.7-rc.2, 0.2.0-rc.2 and 0.2.1-alpha.2. If it does not reduce the replay on your next run, the diagnostic line it prints per drain (removed N characters of tool output from the model view across M results) will say so, and I would want to know.