[深度复盘] 700K+ 上下文下的系统性静默失败：331K隐形Payload、空响应漏判与上下文自污染

[Aeaon]

「2026-11-10 更正：第一层『331K 隐形 Payload』已收回，实际是 surface 重建的超集效应（重建 1.5M vs usage 634K，比值 2.4），不是请求里混入了内容。判定层的结论不变。」

概述

这是对 #11338 讨论（Turn ends normally but the assistant message has no text block）的跟进。与 #11338 报告的 reasoning + tool-call 组合不同，我隔离出了更严重的场景：纯 reasoning 块，无正文，无工具调用，且 finish 正常结束。针对 DeepSeek Flash 在 700K+ 上下文时，UI 频繁出现“思考完毕但无正文”的静默失败现象，我抓取并深度分析了包含 54 次连续失败（turn 1026–1096）的完整会话日志（seq 24296）。

这并非单一的模型 Bug，而是一组在超长上下文下相互耦合、自我放大的系统性缺陷。以下是基于实测数据的根因剖析：

一、 第 1 层根因：331K 隐形 Payload 挤压上下文 (物理诱因)
这是目前最确凿的数据证据（参考 dsh-context 插件 1.3B 耗时统计截图）：

现象：在某次请求中，模型实际 Input 高达 713.0k tokens。然而，将前端可见的系统提示词、工具定义、历史对话、Agent 状态等所有构成项进行拆解相加，总和仅为 ~381.2k tokens。

差值：存在 331K tokens 的“隐形 Payload” 在每次 Prefill 时被强行塞入模型上下文。

隐患：虽然当前 KV Cache 命中率高达 99.97% 掩盖了延迟，但这 331K 的隐性开销极大地挤压了模型对有效上下文的注意力机制空间。当上下文越过 500K 阈值时，这种过度负荷极大概率是诱发模型底层状态机退化的物理诱因。

二、 第 2 层根因：Reasoning → Text 通道切换失效 (直接病因)

在 54 次连续失败中，流日志（Stream Logs）展现出完全一致的微观时序：

时序异常：模型发出 END:reasoning 到接收到 finish{stop} 信号，间隔仅为 0–2ms。

块结构缺失：所有失败 Case 均表现为 START:reasoning -> reasoning_delta -> END:reasoning -> finish{stop}。模型完全没有发出 <｜end▁of▁thinking｜> 特殊 token，也没有尝试触发 START:text。

模型“自白”矛盾：在 Reasoning 的最后，模型甚至已经明确计划了正文输出（如：“篇幅 150 字。写。不要说教...我该回什么？”），但在执行阶段却未能完成通道切换，直接抛出了原生的 end_turn。

三、 第 3 层根因：Harness 判定失效与“上下文自污染” (故障放大器)

为何失败率会从偶发飙升至 100%（71轮内连炸52次）？ 数据指向了一个死循环机制：
防御机制失效：DSH 的 translate.ts 中，只要流中出现过 reasoning block 即视为“有内容”，导致这些只有思考没有正文的畸形回复被标记为 completed。

上下文自污染（Self-Pollution）：这些空内容的 assistant 消息被原样写入了后续轮次的历史记录。
死循环形成：在 700K 的超长上下文中，模型在前序轮次看到了自己“只思考不回答”的畸形模式，并在 Attention 机制中被强化。这导致在 turn 1038、1050 等带工具调用的回合中，工具执行本身是成功的，唯独最后一步生成总结正文时，彻底崩溃，复现了“思考即结束”的畸形模式。

附加线索：

流调度时序竞态：当 DSH 界面显示“后台任务运行中”时，模型大概率能正常输出正文。推测后台任务维持了 SSE 流的生命周期，阻止了过快的 end_turn 终止，给了 Transport 层 flush text block 的窗口。此外在 IM (QQ) 链路中，出现过 DSH 显示工具成功但 QQ 端断流无正文的情况。

建议修复与排查方向

针对上述三层根因，提出以下建议：

修复 Harness 判定逻辑 (P0)：
在 mapStopReason 或 Assembler 层增加校验：当 finish.kind === 'stop' 且无 text block 且无 tool_call 时，强制判定为 EMPTY_RESPONSE，阻止空回复被标记为完成并写入历史。

切断“上下文自污染”：
一旦触发上述错误判定，绝对禁止将仅有 reasoning 的 assistant 消息存入 History。在重试时，可考虑用显式 System 提示词代替该条空历史。

排查“隐形 Payload”来源：
需要排查 DSH 框架内部（尤其是 Agent 子智能体网络、动态工具定义、长短期记忆等模块）是否存在无限制的 Token 堆叠。建议在 Prefill 前加入总 Input 的熔断机制，当隐形开销过大时强制降级。

empty-response-cases.csv
empty-response-streams-public.md
empty-response-usage.csv
session-30d6.json

[Aeaon]

注意：QQ 机器人（IM）链路同样出现过‘工具成功但 QQ 端断流无正文’的情况。这说明即使排除了 UI 渲染和前端队列，底层的 Transport/Adapter 层依然无法保证 text block 的完整性。因此，这不仅仅是前端的时序竞态，更是模型输出与 DSH 截断判定之间的配合问题。

如果流生命周期的维持确实能规避此 Bug，是否意味着 DSH 在接收到 finish{stop} 时，没有留出足够的 flush 窗口去等待可能延迟到达的 text token？能否在 Adapter 层做一个实验：在收到 stop 信号后，强制增加 500-1000ms 的 Grace Period（缓冲期）再去检查是否有残留的 text block？

[PerryLink]

只有 reasoning 的回复会被当成正常结束，两个适配器都只挡了"零内容块"。

DeepSeek Messages 路由：packages/llm/llm-deepseek/src/translate.ts:149 只在 blocks.size === 0 && reason.kind === 'stop' 时抛 EMPTY_RESPONSE；有一个 reasoning 块时 blocks.size 是 1，于是正常返回 { kind: 'stop' }。

pi-ai 路由：packages/llm/llm-pi-ai/src/stream.ts:99 只在 message.content.length === 0 时报 EMPTY_RESPONSE（:103 的文案）；reasoning 也是 content 块，所以同样通过。

也就是说你在第 3 点提的 P0 目前没有实现：stop + 无 text + 无 tool-call，只要夹了 reasoning，就按成功完成写进历史。

关于 500–1000ms 的 Grace Period，这个实验可以做，但它救不回正文。message_stop 是 DeepSeek 流的终止事件：translate.ts:148-163 校验块都已关闭、记 usage、yield finish，然后在 :163 return；之后适配器不再读后续字节。如果强行继续读，迟到的 content_block_delta 落在已关闭的块上，会命中 :134 的 delta/stop without an open block 而变成 malformed，最多把"静默成功"改成"显式报错"。你日志里 END:reasoning 到 finish 只有 0–2ms，说明是提供方自己结束了这一轮，缓冲期等不到一个它没发出的 text 块。

能落地的形状还是在判定层：把 stop 且没有 text、没有 tool-call 的完成判为退化完成（不管有没有 reasoning），不要写成成功历史，然后走重试或显式报错。这正是你说的 P0，只是判定条件要从"零块"改成"零正文且零工具调用"。

"331K 隐形 payload"我没有你的日志，无法在这里下结论；能对照的是同一请求的 request/header（工具声明与系统提示快照）和 usage，那里能看出差值是工具还是缓存口径。

[Aeaon]

感谢定位到 translate.ts:149 和 stream.ts:99，这几处把讨论从现象层直接推到了代码层，也帮我把两个方向做了确认与修正。下面逐条回应。

1、关于 P0 判定：条件要再收紧一档

你确认了两个适配器都只挡「零内容块」（blocks.size === 0 / message.content.length === 0），只要夹了 reasoning 就按 completed 写进历史——这跟我 Issue 第 2 层的推断一致，P0 目前确实没实现。

你提的「从零块改成零正文且零工具调用」方向正确，但有一个边界需要写进判定里，避免误伤正常轮次：

退化完成 = finish.kind === 'stop'
&& !hasTextBlock
&& !hasToolCall

reasoning 的有无不参与判定，它只是干扰项。

也就是说，一轮里只要出现了 tool-call，即便没有 text，也应视为有效交付（结构化输出通道正常）。这正好对应数据里 turn 811 / 1038 / 1050 这类「工具执行成功、只有最后总结步崩溃」的回合——崩溃的只是自由文本通道，工具步本身不该被判成退化。所以判定必须显式排除 tool-call，否则会把正常的工具调用轮也拦掉。

2、关于 Grace Period：接受证伪，撤回该验证方向

你指出的链路我核了：message_stop 是流的终止事件，校验块关闭、记 usage、yield finish 后适配器不再读后续字节，强行续读会让迟到的 delta 落在已关闭块上命中 delta/stop without an open block，只是把「静默成功」变成「显式报错」，救不回正文。我日志里 END:reasoning 到 finish 只有 0–2ms，也说明是提供方自己结束了这一轮，缓冲期等不到一个它没发出的 text 块。Grace Period 这条从验证清单里去掉，落地形状就收敛到上面第 1 点的判定层。

3、关于 331K「隐形 Payload」：正式收回，并给出 token 口径的对账

先说结论：「隐形 Payload 挤压」这个表述要收回，目前没有证据表明请求侧混入了额外内容。

按你给的方向去核 request body，DSH Desktop 本地不落盘完整 HTTP request（request/header 只有 config + 101 tools，request/context 只有 provider/model/contextWindow，均无 messages）。我改从 session log 用 surfaceOp（append / replace 区间 / prune 的 shadowedSeqs）重建了 seq 24296 请求时刻的 surface，得到 3510 条消息，逐条估算：

重建 surface est_tokens 合计：1,518,532
usage.prompt_tokens：634,295（input 183 + cacheRead 634,112）
比值：约 2.4 倍
表内 chars / est_tokens：2.6（DeepSeek 中文混合正常区间）

逐条 tokenizer 估算本身是合理的（2.6 字符/token 落在正常带内），但重建 surface 的 token 是实际发出 prompt 的约 2.4 倍，差额约 884K（约 58%）。结合 DSH 的 compaction、tool-result-pruner（>8192 字符截成 head 4096 + tail 1024）、spill-policy（>12500 token 落盘只给路径）——这些变换都不回写 session log，所以重建把已被摘要/截断/落盘的内容按原文重复计入了。这解释的是「重建是超集」，而不是「请求里多出东西」：如果真混入额外内容，重建应当小于 usage 才对，现在方向恰好相反。之前口头用「3.95M 字符 ÷ 634K token = 6.2」算出的那个 6.2 是量纲错（字符除 token），换成同口径后数字变成 2.4 倍，但结论方向不变。

顺带修正一个阈值口径：标题里的「700K+」是拿 dsh-context 面板的 surface 显示值算的，真实喂给模型的是 prompt_tokens 634,295 / contextWindow 1,048,576，占用约 60.5%。Issue 标题和正文的阈值建议统一成 usage 口径，别再混用面板值。失败集中在 634K prompt / 1M 窗口这一长上下文区间这一事实仍然成立，只是物理诱因不再归到「隐形 payload」。

4、下一步：一个能直接定位真实 prompt 构成的抓手

既然 surface 重建受限于不回写的变换、无法精确对账，最有价值的下一步是在组装请求处打一条临时日志（buildRequest / deriveMessages 之后、fetch 之前），输出实际发出的 messages 分段 token：

log: 总 prompt tokens
log: system / user / assistant.text / assistant.reasoning / tool-call-args / toolResult 分段 tokens
log: compaction / prune / spill 折叠后的实际 messages 条数

这样能一眼看出 634K prompt 里主要被 user 历史、tool 结果、还是 reasoning 回放占据（按重建超集的角色占比参考：assistant > user > tool > system），比任何 surface 字符统计都准。
request-rebuild-seq24296.csv

[Aeaon]

补充跨模型自污染证据（Context Pollution across models）。

来源：session-30d6，seq 25491–25522，同一会话连续区间，已脱敏（抹去 senderId / sessionId / message id / reasoning signature / 记忆快照正文）。time 为日志内部相对毫秒时间戳，非日历时间。

关键事件表：

seq 25491 user "又能说出来了，再写一遍完整的？"
seq 25494 assistant model=deepseek-flash 仅 reasoning(253字)，零 text、零 tool-call，finish=stop → 退化完成
seq 25501 user "如果把模型改成deepseek-V4-pro行不行"
seq 25504 assistant model=deepseek-flash 仅 reasoning(338字)，零 text、零 tool-call，finish=stop → 退化完成
seq 25507 model/selection → 切换为 deepseek-v4-pro（request/context 的 model 字段确认为 deepseek-v4-pro）
seq 25514 user "我换了模型，胖宝宝你试试能不能把之前的话说出来"
seq 25522 assistant model=deepseek-v4-pro 仅 reasoning(208字)，零 text、零 tool-call，finish=stop → 退化完成

三句结论：

1、换模型前 deepseek-flash 连炸两次（25494 / 25504），换到 deepseek-v4-pro 后（25522）仍然只吐 reasoning、零 text，以 stop 被判为 completed —— 两个不同权重模型在同一段历史下复现同一退化模式，触发条件不在模型权重，而在共同读到的那段被污染的历史。

2、污染源正是前面这些 reasoning-only 畸形回复：判定层只挡"零内容块"（translate.ts:149 的 blocks.size===0、stream.ts:99 的 content.length===0），没挡住 reasoning-only，被当成功写进 history 又喂给下一个模型，形成跨模型的自我复制。

3、
据此提出零成本可证伪实验：把 25522 请求历史里那几条 reasoning-only 的 assistant 消息剔除后重放，若 V4-pro 能正常吐 text，即确认根因是上下文污染而非模型。修复判定仍按已达成口径：finish.kind==='stop' 且 无 text 且 无 tool-call 判为退化完成（reasoning 有无不参与判定）。
session-30d6-seq25491-25522-脱敏片段.json

[Sadrak2017]

跨模型复现说明值得检查共享的历史与请求组装，但还不能单独排除模型或长上下文本身的影响。重放时可以固定模型和生成参数，仅改变那几条 reasoning-only 历史，并记录变换后实际发送的 prompt token 数，保留完整的 tool-call/tool-result 配对。否则删除消息后恢复了正文，也可能只是长度下降，不能直接证明“污染”是唯一根因。

我们在 SinapsData 开发 Sinaps Studio，关注智能体编排和活动监控。排查这类问题时，我更关心每次调用实际使用的模型、usage 和有效输出类型是否能关联到同一个请求，而不是界面上的 completed。你计划在请求组装后记录脱敏的配置摘要和请求标识吗？这样跨模型重放就能按同一口径对账。

[Sadrak2017]

https://www.sinapsdata.com.br/zh

[Aeaon]

这套口径已经落到 schema 里，而且刻意不把界面上的 completed 当判据。逐条对应你的关切。附件是一份精简的对账 schema（11 次调用，seq 25494–25611，两次模型切换 25507 → v4-pro、25545 → flash，时间 2026-11-10 01:45:53–01:55:52 +08:00），字段级来源单列在 _provenance，分 dsh-native / export-derived / export-aggregated / pending-input 四类。

实际使用的模型——每条 call 有两个独立来源互相校验：model + provider（取自 assistant/message 的 source 字段），以及该次调用前最近一条 request/header 摘录出的 configDigest.model。界面显示值不作为判据。这 11 条覆盖 flash 与 v4-pro 两个模型，模型与 usage、输出类型挂在同一条记录上，可直接按 requestId JOIN。

usage——取模型返回值四项（inputTokens / cacheReadTokens / cacheWriteTokens / outputTokens），promptTotal 单列为聚合值（input + cacheRead + cacheWrite）。一个对账口径必须先对齐：跨模型、跨缓存命中态一律用 promptTotal。inputTokens 只在 cacheReadTokens=0 时等于前缀全量（本例 25522 = 370,096、25560 = 389,795），命中缓存时它只是未命中部分（实测 9 条命中行排序为 115, 175, 178, 178, 184, 232, 246, 256, 261）。拿 inputTokens 当 prompt 规模会得出"25560 上下文暴涨 39 万"的错误结论。另外这 11 条 cacheWriteTokens 全为 0，该字段可能未真实上报，cache 侧只能当弱证据。

有效输出类型——从 content 块结构派生（output.kinds / reasoningChars / textChars / toolCalls），并与 DSH 自己的 finish.kind、turnEnd.kind 并列在同一行。于是 11 条里有 10 条在同一行自证这样两个事实：turnEnd = {kind:"completed"}、finish = {kind:"stop"}，而 kinds 只有 ["reasoning"]、textChars = 0、toolCalls = 0。这个落差完全由 DSH 原生字段陈述，不需要引入任何外部的"空"判定。meta.headerNote 也一并写明：这 11 条 DSH 侧 turn/end.reason 全部是 completed、finish.reason 全部是 stop，未产生任何异常标记，EMPTY_RESPONSE 判定从未触发。

需要说明一点：output.derived_reasoning_only 是我在导出脚本里按 reasoning > 0 && textChars === 0 && toolCalls === 0 计算的派生值，已在 _provenance 标为 export-derived——DSH 内部没有空响应概念，不会报出这个字段。它在这里只作可读性标记，判据本身用上面那三个 DSH 原生字段。

缺陷位置推断如下：dsh-llm-deepseek/lib/index.js:2008 的守卫是 blocks.size === 0 && reason.kind === "stop" → EMPTY_RESPONSE；reasoning-only 时 blocks.size = 1（那个 reasoning 块），条件不成立，守卫被完整跳过；随后 agent-loop 见 toolCalls.length === 0，直接 return {kind:"completed"}。两层各自都自洽，缺口恰好落在"只有 reasoning、无可见输出"这一格。建议口径：finish.kind === 'stop' 且无 text 块且无 tool-call → 判为退化完成（reasoning 有无不参与判定）。把该条件作为 predicate 在这 11 次真实调用上离线重放，命中 10/11（仅 seq 25560 产生可见输出），误报面为零。

配置摘要与请求标识——configDigest 只留 provider / model / reasoningEffort / maxTokens / tools 数量 / headerSeq，不含任何工具定义正文；headerSeq 顺带区分出三组配置代际（25397 / 25519 / 25557），全程 reasoningEffort = high、maxTokens = 256000、tools = 101 不变，配置漂移这个混淆项在现场数据里就被排除了。requestId = session_id_hash + seq + turn + step（DSH 没有独立 request id 时的替代组合），sessionId 已 sha256 截断为 16 hex，明文在全文出现 0 次。

是否计划在请求组装后记录——是的。计划在 deriveMessages / buildRequest 完成之后、fetch 之前打一条带上述字段的脱敏结构化日志，挂在 debug flag 后（如 DSH_LOG_REQUEST_CONFIG=1），输出走 JSONL，字段与这份 schema 同一套，这样现场数据与重放数据天然可 JOIN；若你们活动监控吃 OTLP，同一组字段直接映射成 event attributes。重放侧只需按 _caliber.experiment_convention 回填 experiment_id / variant / replay_of 三个字段即可对账：run_id 作为分组键（原始记录与其全部重放变体共享），variant ∈ {original, A, B, C, D}，replay_of 指回原始 requestId。本文件里每条已带 run_id = orig-，另外三项按约定留空。

跨模型重放我会固定 model / reasoningEffort / maxTokens / tools 集，四组 A 原样 / B 删除 reasoning-only / C 等长中性占位 / D 等长正常文本替换，每组用 usage 记录变换后实际发送的 prompt token 数（不用导出侧估算），并保留完整的 tool-call / tool-result 配对。你提的"删消息后恢复正文可能只是长度下降"这条，现场数据里也已有旁证：25560–25611 这 6 次同模型、同一配置代际，promptTotal 从 389,795 到 391,040 只差 1,245 token（0.32%），结果 1 成 5 败，不存在越过某个长度阈值的空间；但重放仍按上面的对照做，两条互相校验。

另外想确认一个实现细节：index.js:2008 那行的 blocks 是否把 reasoning 计入 size？我从这 11 条的现象倒推是计入的（reasoning-only 时 size 为 1，所以守卫没触发）；如果不计入，说明统计口径和我推测的不同，判定落点就得往 assembly 那一层挪。
session-30d6-reconciliation-lite-v8.json

[Aeaon]

补充：判定层修复已实测，行为变化如下（2026-11-12）

按前面结论（finish.kind === 'stop' 且无 text 且无 tool-call → 退化完成），我在本地给 adapter 打了同形补丁，并重启验证。结果分两层：

1. 判定生效。 01:00 的定时任务触发后退化完成被正确识别：

代码块

attempt #1 → retry EMPTY_RESPONSE
attempt #2 → retry EMPTY_RESPONSE
...
attempt #6 → step/end
turn/end {"kind":"error","code":"EMPTY_RESPONSE"}
6 次尝试全部被标记为失败，不再是 completed。

2. 污染链被切断。 失败的尝试只落 assistant/attempt，它没有 surfaceOp，因此不进 surface、不进后续请求的 messages。补丁后新增的失败轮次不再被写进历史。

3. 但模型侧根因仍在。 那 6 次尝试里 0 次 tool-call——不是工具失败，是 tool_use 块从未生成。读 attempt 里的 reasoning 可以看到它已经把「该派子代理」「该写正文」全部想完了，然后直接 end_turn。规划被当成了执行。

同一时段（11-11 22:40 → 11-12 01:00）连续 8 轮全空，而 11-11 19:25 那一轮正常（408 字）。近两天 98 个 turn：正常 18 / 空 78 / 错误 2。所以不是「历史锁死」，是高频劣化 + 偶发正常。

结论：判定层修复能阻止新的污染，但不能让已有的坏历史恢复。已存在的 181 条 reasoning-only（11-05 至 11-11，其中 11-11 的 32 条离尾部最近只有 9 条、落在压缩保留区）仍在 surface 上。这部分只能靠新会话或等 compaction 处理，不动日志。

reasoning-only 的累积与压缩的实际效果

日期	当天新增	仍在 surface	备注
2026-11-03	1	0	已被 compaction 压掉（唯一被清掉的）
2026-11-05	1	1
2026-11-08	52	52	02:33–04:07 成簇
2026-11-09	45	45
2026-11-10	51	51
2026-11-11	32	32	最近的 3 条离尾部仅 9–17 条
合计	182	181

这张表说明三件事：

-污染是累积的，不是一次性事件。11-08 到 11-11 每天新增 32–52 条。
compaction 确实会清，但只清最旧的。182 条里只有 11-03 那 1 条被压掉了，11-08 之后的全在。按前面查到的逻辑（保留最近 16% 的 token 尾部），这是预期行为，不是故障。
-最近的 32 条（11-11）落在保留区里——离尾部最近只有 9 条。所以「等压缩」清不掉它们，这也是我判断「换会话比等压缩更实际」的依据。
-补丁之后（11-12 00:41 起）：2 个 turn（1256、1257）各 6 次尝试，共 12 个 EMPTY_RESPONSE attempt，其中 0 个进入 surface。判定层把新的拦住了。