[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]

This is the same report as #9583 (same author, same measurements). I answered it there, so the analysis is not duplicated here:

→ #9583 (comment)

In short: item 3 (unbounded tool output injected into context) is confirmed at the source level — a tool/result is recorded whole and re-sent with every later request of the session, which is the 53:1 replay you measured, and a high cache-hit rate makes replay cheaper without stopping it. The harness's own reducer (@deepseek-ai/dsh-compaction-tool-result-pruner) has the right shape but is gated on compaction pressure, so it does not run in the window this run lived in.

I published a plugin that applies the same reduction unconditionally at injection time, without destroying the tool's real output (it writes a surface replacement, so the full result stays in the session log for both the user and replay):

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

• npm: https://www.npmjs.com/package/@argszero/dsh-tool-output-budget
• source: https://github.com/argszero/dsh-tool-output-budget

It bounds the size of each result; it does not bound the number of results, and it does not address items 4–8 of your report (per-query background LLM requests in web_search, the shared %TEMP% directory between subagents, the missing spend circuit-breaker, application/pdf refused by web_fetch, blocked cross-origin redirects) — those are tool- and core-side surfaces. The full caveat list is in the linked comment.