Bug 报告：(1) spill 截断标记已写入但完整内容仍被持久化；(2) 超长工具结果未计入上下文计量，误导问题排查

[dawnray]

Bug 报告：(1) spill 截断标记已写入但完整内容仍被持久化；(2) 超长工具结果未计入上下文计量，误导问题排查

概述

当工具结果超过 spill（溢出）阈值时，DSH 的 spill 机制会在末尾追加 "(Omitted NNNNN bytes. Full formatted result stored at: ...)" 标记——但完整的、未截断的内容仍然被持久化进会话历史（session.jsonl.zstd）。截断标记只是"装饰"，实际内容并未被截断。

后果：任意大的工具结果（例如一个 49 KB 的 Select-String 输出，其中含一条 13,170 字符的超长单行 minified JSON）会成为该会话此后所有 LLM 请求上下文的永久组成部分。在本案例中这直接"毒化"了一个会话（其触发的服务端崩溃详见配套的 vLLM 报告）：该会话此后的每一次 LLM 调用都在精确的 ~19 秒后以 TRANSPORT "Connection error." 失败，inputTokens: 0。会话无法恢复，除非执行 /compact；且故障表现伪装成网络问题。

环境

• DSH：@deepseek-ai/dsh@0.1.1-rc.2（npx，web profile）
• 操作系统：Windows 11，Node v24.13.0
• Provider：OpenAI 兼容端点（GPUStack），模型 deepseek-v4-flash
• 工作区：D:\Downloads\test_dsh

复现步骤

1. 启动一个 dsh web 会话，连接任意 OpenAI 兼容 provider。
2. 让 agent 执行一个输出中包含超长单行的 shell 命令，例如：

$files = Get-ChildItem "C:\Users\<user>\.dsh" -Recurse -File |
  Where-Object { $_.Extension -in '.yml','.yaml','.json' }
foreach ($f in $files) {
  $hits = Select-String -Path $f.FullName -Pattern "web|fetch" -ErrorAction SilentlyContinue
  if ($hits) {
    Write-Output "--- $($f.FullName) ---"
    $hits | ForEach-Object { "  :$($_.LineNumber) $($_.Line.Trim())" }
  }
}

Select-String 会原样打印匹配行。minified JSON 文件（如 .pnpm-workspace-state-v1.json）会产生超过 13,000 字符的单行输出。本案例中的工具结果总计 49,614 字符 / 660 行 / 最长行 13,170 字符。

3. 工具结果返回时末尾带有 spill 标记：

(Omitted 14361 bytes. Full formatted result stored at: C:\Users\...-pwsh.txt. Use read with offset/limit, or grep this path to search within it.)

4. 检查持久化的事件（解包 session.jsonl.zstd）：对应的 tool/result 事件包含的是完整的 49,614 字符内容，而不是截断版本。

实际行为

• session.jsonl.zstd 中的 tool/result 事件持有完整输出（已验证：全文长度 49,614）。
• 该会话此后的每一次 LLM 请求都以完整内容作为 tool 消息体。
• 针对 vLLM/GPUStack 后端，该请求会确定性地杀死服务端流（见配套 vLLM 报告）：此后所有调用都以 Connection error. / TRANSPORT 失败，inputTokens: 0，每次约 19 秒。
• 重启 DSH 无效（历史从磁盘重放）。只有 /compact（将被遮蔽的历史区间替换为摘要）才能移除该内容。

期望行为

• spill 阈值触发时，持久化的 tool/result 应只包含截断后的头部 + spill 标记 + 文件路径；被省略的字节不应再持久化进消息体（它们已经存在于 spill 文件中）。
• 或者/此外：在进入历史之前，对包含病态行长度的工具结果（例如单行 > N KB）进行防护，无论总大小如何。

来自受影响会话的证据

会话事件（已解包）：tool/result，seq 99865，turn 242 step 2，time = 2026-08-24 13:35:21（+08:00）：

• 内容文本长度：49,614
• 行数：660；最长行：13,170 字符（来自 ~\profiles\web\node_modules\.pnpm-workspace-state-v1.json 的匹配行）
• 末尾带有 spill 标记 "(Omitted 14361 bytes…)"——但其上方仍承载着完整载荷。

紧随其后的事件：下一个 LLM 步骤（seq 99868，13:35:40.955）以 {"kind":"error","failure":{"message":"Connection error.","code":"TRANSPORT"}} 失败，inputTokens: 0；5 次重试全部以相同方式失败（每次约 19–21 秒）；该会话再未恢复（turn 242–245 及以后，跨越了一次完整的 DSH 重启）。

脱离 DSH、用原生 openai SDK 对同一 provider 以完全相同的内容做的最小复现：

messages = [
  {role:"user", content:"查一下配置"},
  {role:"assistant", content:null, tool_calls:[{id:"c1", type:"function", function:{name:"pwsh", arguments:"{}"}}]},
  {role:"tool", tool_call_id:"c1", content: <49,614 字符的结果原文>},
  {role:"user", content:"reply ok"},
]

结果：APIConnectionError: Connection error.（cause 为 TypeError: fetch failed），3/3 次复现，耗时 19,015–19,024 ms——与 会话内失败完全一致。将工具内容替换为同等总大小的良性文本则成功；失败是内容特异的（见 vLLM 报告），这也正是 DSH 侧截断之所以重要的原因：DSH 无法修复服务端，但目前它未能启用自己的防御。

---

缺陷 2：超长工具结果内容未计入上下文计量，误导问题排查

概述

当完整的 49,614 字符工具结果被持久化并随此后每一次 LLM 请求发送时（provider 面板证实：每次请求约 73.78 K tokens），DSH 的上下文计量（由 dsh-context 插件 v0.24.x 呈现）却报告该会话上下文非常小（至多几十 K；在"中毒"回合之后它显示接近 0%/对 200 K 窗口的极低占用）。

上下文计量器没有把这类内容（超长工具结果 / 带 spill 标记的结果）计算在内，导致排障期间最重要的单一诊断信号——"实际发送的请求到底有多大？"——错了一个数量级。

影响

在对上述中毒会话长达数小时的诊断过程中，被低估的上下文读数主动把调查带偏了：它使得"请求中含有过大/病态内容"这一假设在早期就被排除，使排查转向网络、连接池、进程状态和 compact 等理论——全部是死胡同。直到提取 provider 侧的 token 计数（约 73.78 K/请求）并重放实际持久化的内容，才揭示真相。

一个排除了"实际仍会被发送的内容"的上下文计量器，会给用户虚假的信心，并恰好在最需要的时候拖延根因分析。

复现步骤

1. 复现缺陷 1（大工具结果进入历史）。
2. 观察前后（dsh-context）的上下文读数：几乎不动，仅显示窗口的很小一部分。
3. 与同一批请求的 provider 侧用量对比（如 provider 控制台/面板的 token 计量）：请求携带了数万 token，可归因于该持久化的工具结果。

期望行为

• 上下文计量必须包含下一次请求中实际发送的所有内容：system 提示、工具 schema、全部消息文本（含完整的工具结果体；或在缺陷 1 修复后，被发送的截断体）。
• 理想情况下，计量器还应提供按消息的分解视图，使得单条病态消息无需手工解包 session.jsonl.zstd 即可被发现。

修复建议（两个缺陷）

1. Spill 截断：spill 标记发出时，只持久化截断后的头部 + 标记 + spill 路径——绝不持久化完整载荷。
2. 行长度防护：在进入历史前，额外对病态的单行长度设上限（如 >2–4 KB/行），独立于总大小。
3. 上下文计量：计量实际发送的内容，包括工具结果体。