长会话中 agent 反复「思考完成但无输出」：附 DSH 状态文件的量化诊断（51轮/405步/上下文压力48%/TTFT峰值数十秒）

[lowaka]

环境

项	值
DSH 版本	0.2.0-rc.2（Desktop / Windows）
Profile	desktop
会话	session-6f13a4c6-96a6-481c-af67-2aabd08cab28
任务性质	嵌入式设备长链路排障（每步依赖上一步结论，工具返回体积大）

现象

在一次 51 轮的长会话中，反复出现「agent 推理已完成，但界面上没有出现最终回答」，
界面长时间静默，用户只能发「？」或「继续」催促，催促后往往才拿到回答。会话中用户共催促 6 次。

用户原话：

• 「？」
• 「又没了 ？」
• 「为什么总卡？」

量化数据（来自 DSH 自身状态文件，非推测）

数据位置：~/.dsh/storages/session_projcache/sessions/<session-id>.json

sessionStats

{
  "turns": 51,
  "steps": 405,
  "llmMs": 3521461,        // LLM 累计 58.7 分钟
  "toolMs": 4758769,       // 工具累计 79.3 分钟
  "ttftMs": 571521,        // 首 token 等待总计 9.5 分钟
  "ttftSteps": 406,
  "decodeMs": 2948785,
  "decodeTokens": 643406,
  "openStep": null,
  "pendingCalls": {
    "call_00_Ro4cK8Y9Biqxnx8vM57P3371": 1792164996867    // ← 未被清理
  }
}

推算：(llmMs + toolMs) / steps ≈ 20.4 秒/步（平均）；ttftMs / ttftSteps ≈ 1.41 秒（平均首 token 延迟，峰值远超此值）。

contextPressure

{
  "surfaceTokens": 271372,
  "contextWindow": 1000000,
  "pressureTokens": 481453,        // ← 占窗口 48%
  "sampledSurfaceTokens": 271089
}

tokenUsage

{
  "totals": {
    "uncachedInputTokens": 1219006,
    "outputTokens": 643406,
    "cacheReadTokens": 154584064,   // ← 1.5 亿
    "cacheWriteTokens": 0
  },
  "last": {
    "turn": 51, "step": 4,
    "buckets": {
      "uncachedInputTokens": 173,
      "outputTokens": 437,
      "cacheReadTokens": 481280     // ← 单步读 48 万 token 上下文
    }
  }
}

llmRetry

{ "ver": 1, "seq": 2814, "val": {} }    // ← 整个会话【零重试记录】

分析（按可能性排序）

1. 主因：长上下文 + 全程无进度反馈

每一步都在接近半窗口（48 万 token）的上下文上推理 → 首 token 延迟可达数十秒。
而这段时间 GUI 没有任何可见反馈（无"正在处理"、无已等待秒数、无取消入口），
用户无法区分「在努力思考」与「已崩溃」。

结论：这不是功能故障，而是**「没有反馈的慢」被感知成了「卡死」**。

2. 空响应缺少兜底

会话中 6 次出现"推理完成但无最终输出"。结合 llmRetry.val = {}，
推测空/异常响应没有触发自动重试，也没有向用户明示"本轮未产生输出"。

3. pendingCalls 未清理（疑似状态机问题）

sessionStats.pendingCalls 中残留一条记录。若为异常路径下未清理，可能导致会话状态不一致。

4. 工具耗时 > LLM 耗时（另一条优化线）

79.3 分钟 vs 58.7 分钟。高频只读命令（dumpsys / getprop / lsmod / ps）每轮返回数 KB 原始文本，
直接推高了那 48 万 token 的上下文压力。

建议

优先级	建议	说明
🥇	长 TTFT 进度反馈	>3s 显示"正在处理（上下文 N tokens）"；>15s 显示已等待秒数 + 「取消本轮」按钮
🥈	空响应检测 + 自动重试	单步结束时若无文本输出也无工具调用 → 判定空响应，退避重试 1~2 次并记入 llmRetry；仍失败则明确告知用户
🥉	上下文压力预警 + 一键压缩	40%/60%/80% 分级提示；提供"保留结论、丢弃过程"的压缩入口
4	修复 pendingCalls 清理	检查工具超时、用户中断、取消操作等异常路径
5	暴露运行时诊断指标	现状：数据深藏在 ~/.dsh/storages/**/*.json；建议 GUI 提供「会话诊断」面板 + 一键导出诊断包
6	只读命令结果裁剪	dumpsys/getprop 等做结构化裁剪或缓存，降低单步输入体积

已知相关讨论

• 长会话切换模型后压缩陷入失败风暴：maxOverflowRetries 不构成上界、压力路径无退避（附手动绕过与配置缓解） #9888 长会话切换模型后压缩陷入失败风暴（maxOverflowRetries 不构成上界）
• 【BUG】客户端事件订阅器因 null 属性读取而死亡，导致转录区永久空白 #9879 客户端事件订阅器因 null 属性读取而死亡，导致转录区永久空白

本报告补充的是另一条独立证据链：并非崩溃，而是"高压力上下文下无反馈的慢"，
并提供了会话级 TTFT / 上下文压力 / 重试计数 / pending 调用的实测数值，可供定位与回归验证。

复现条件（供参考）

条件	本次实测值
会话长度	51 轮 / 405 步
上下文压力	481,453 tokens（窗口 48%）
单步工具返回	大（dumpsys、ps、lsmod 等数千 token）
任务形态	长链路排障，每步依赖上一步结论
模型	会话中显示为 deepseek-flash

---

本报告全部数值均取自 DSH 自身状态文件，未做推测性填充；标注「推测/疑似」处已明确说明。

[argszero]

Thanks for the quantified write-up — a session id, a step count and a state file make this far easier to answer than the usual "it hangs sometimes". I read the agent loop and both provider adapters at the tag you are on (dsh-v0.2.0-rc.2) and at master (1517a4dbca); the two are identical here, and every line number below points at the same code in both.

The symptom is a step that finished successfully with nothing visible

"Thinking finished, nothing came out" is not one failure — it is two different terminal states of a step, and neither of them is retried.

1. A reasoning-only completion is a successful step

EMPTY_RESPONSE exists, and the default retry policy does retry it — five times, with 500 ms to 10 s backoff (packages/llm/llm/src/retry-policy.ts:14-24; the code itself is error.ts:42). But the predicate that raises it is narrower than the name suggests: a terminal stop with no content blocks at all.

• pi-ai: packages/llm/llm-pi-ai/src/stream.ts:96-99 — case 'stop': if (message.content.length === 0) → EMPTY_RESPONSE
• DeepSeek Messages: packages/llm/llm-deepseek/src/translate.ts:149 — if (blocks.size === 0 && reason.kind === 'stop')

Reasoning occupies a content block on both paths: pi-ai's thinking_start / thinking_delta / thinking_end events carry the same contentIndex accounting as text, and DeepSeek's content_block_start puts every block — reasoning included — into blocks. So a completion that emitted a long reasoning section and then stopped has a non-empty block set, maps to plain { kind: 'stop' }, and is deliberately treated as a normal answer. The harness ships a test that pins exactly this, and it is the fastest way to see that the behaviour is intended rather than accidental: packages/llm/llm-pi-ai/tests/convert.spec.ts:889-892, named "keeps a thinking-only stop successful (any block counts as content)".

The loop then does what it does for any successful step (packages/core/agent-loop/src/agent.ts:547-550):

if (finish.kind === 'max-tokens') return { kind: 'max-tokens' }
const toolCalls = message.content.filter(block => block.type === 'tool-call')
if (toolCalls.length === 0) return { kind: 'completed' }

The assistant message was already appended a few lines earlier (agent.ts:538-539), so nothing is lost — but the turn ends as completed with zero visible output. Nothing threw, nothing retried, nothing was notified. That is the whole mechanism behind the rounds you had to re-prompt six times: from the harness's point of view, the model answered.

2. If the output ceiling cut it, it is max-tokens — also not retried

When the provider reports stop_reason: 'length', the finish is max-tokens (stream.ts:109). The retry plugin never sees it: it hooks agent/request-error, which the loop offers only for an error or aborted finish (agent.ts:506), and its gate is a failure-code test (packages/llm/llm-retry/src/index.ts:215). max-tokens is not a failure code at all — it is a turn outcome, and a sticky one for the whole turn (agent.ts:338-343).

So a reasoning-heavy turn that fills its output budget ends as "max tokens" and stops there. retryPolicy: 'always' does not change this either: it lifts the attempt limit for model-request failures, and neither of the two states above is a failure.

Why the retry budget would not have covered the storm anyway

The llmRetry counter is a session projection whose state is discarded at every step boundary — llm-retry/src/index.ts:131: if (event.type === 'step/start' || event.type === 'turn/end') return {}. The five retries therefore bound one step, not one turn and not the session. Six prompts are six turns, each starting from a fresh budget, and nothing accumulates or escalates.

A retried step does leave durable traces — llm/retry at index.ts:188 and llm/retry-started at :190 — so it is worth grepping your log for them. "No such events anywhere in 405 steps" would confirm that the retry path was never reached in your session, which is consistent with both cases above.

What the UI shows, and why it is not lying to you

There is a live row while the step runs — packages/client/ui-chat/src/client/chat/ChatGroupSeat.tsx:110-111 resolves message.stepProcess.thinking ("Analyzing the request"), shimmering while the group is open. When that group closes with nothing but reasoning inside it, its title becomes message.stepProcess.done.thinking — "Analysis completed" (step-process.ts:15-18; locale.ts:35 / :233). The assistant node itself paints nothing, because AssistantMarkdown requires streaming, interrupted, or a block that is not a tool call, and the reasoning block belongs to the process disclosure (AssistantMarkdown.tsx:71, :103).

So "analysis completed" over an empty bubble is not a missing indicator — it is the UI faithfully reporting a step that ended with nothing to show. I would not look for the fix on the client side.

Reading the distinction out of your own state file

The durable discriminator is turn/end, which carries { turn, reason } (packages/core/session/src/types.ts:298), and max-tokens is one of the reason kinds (:202, :215). On the rounds that produced nothing:

• reason.kind === 'max-tokens' → case 2: the ceiling cut the step;
• reason.kind === 'completed', with the last assistant/message holding only a reasoning block → case 1.

Splitting those two apart is worth doing before anything else, because their remedies point in opposite directions.

One caution on the TTFT figures: the harness's own per-step timing is anchored on the first token delta it receives, so it measures time to the first increment, not time to the model's first reasoning token. If the "tens of seconds" peaks in your table come from the provider side, they are a different quantity from the harness's own number, and a batched reasoning delivery is exactly the case where the two diverge. Worth labelling which one each column is.

Where a fix belongs, and what can be done without one

The real gap is neither the UI nor the retry table: the loop has no outcome for "settled, and said nothing visible." TurnEndReasonMap (session/src/types.ts:202-223) lists completed, aborted, blocked, error, max-tokens and interrupted, and none of them means this — so there is nowhere for that state to be reported and nothing that could act on it when it happens. Two upstream shapes would close it: widen the provider predicates from "no content blocks" to "no text and no tool-call block", or add the missing outcome kind and let the retry policy see it. Given the test above, I would raise that as a design question rather than a bug report.

A plugin can build the second shape today without touching core. The response side of llm/stream returns a chunk stream, which a plugin can wrap: watch the terminal finish, and if it is stop while the attempt produced no text and no tool-call block, replace it with an error finish carrying EMPTY_RESPONSE. Everything downstream already exists — the loop routes an error finish to assistant/attempt instead of appending an assistant message (agent.ts:506-514), the default policy then retries it five times with backoff, and if the retries are exhausted the step fails loudly instead of silently. That is a strict improvement on today's behaviour: either the model answers on a retry, or you get a real error in the transcript instead of an empty bubble. I have frozen that as @argszero/dsh-silent-completion-guard and will mention it here once it is published; a related package already on npm (@argszero/dsh-empty-response-retry) covers the neighbouring case where an unclassifiable provider error code swallows a transient failure.

All the line numbers above were taken at dsh-v0.2.0-rc.2 and re-checked at master (1517a4dbca) — the same code in both.