每轮固定空等约 24–28 秒：assistant/message 已发出，但 tool/call 要到 turn/start+30s 才执行

[oiwenwen]

环境：DSH 桌面版（Windows 11），profile desktop，provider deepseek-account，model deepseek-flash，reasoningEffort 关/低。2026-10-27 复现。

现象

每一轮对话，助手文本很快就出来了（用户侧观感 3–5 秒），但：

• 如果这一轮要调工具：工具要等到「本轮开始 + 30 秒」才真正执行
• 如果这一轮不调工具：turn/end 同样在「本轮开始 + 30 秒」

也就是说，每轮都固定多付 24–28 秒，跟回答长短无关（31 个字的回复也是 30.0 秒）。

关键证据（会话日志 session.v4.jsonl.zstd）

turn 257（用户发图，助手要调 pwsh）：

+  0.00s  turn/start
+  0.08s  step/start
+  1.25s  session-log-deepseek/delivery-accepted
+  6.04s  assistant/message   ← 助手文本已完整产出
+  6.04s  tool/call           ← 工具调用已发出
+ 30.05s  job/registered      ← 工具才开始跑（空等 24.01 秒）
+ 30.59s  tool/result
+ 30.59s  step/end

turn 245（无工具调用）：

+  0.00s  turn/start
+  0.08s  step/start
+  0.08s  user/message
+  0.79s  session-log-deepseek/delivery-accepted
+  1.76s  assistant/message
+  1.76s  step/end
+ 30.03s  turn/end            ← 空等 28.27 秒，其间没有任何事件

注意：空等段内一个事件都没有，不是某个慢请求，是「等一个到点才放行的东西」。

复现规律

• 100% 复现，每轮一次
• 只影响每轮的第一个动作；越过 30 秒后，同一轮后续工具立即执行（实测 0.03 秒）
• 与回复长度无关（31 字 / 200 字都一样 30.0 秒）
• 桌面端与 IM 端（微信 dsh-im）都一样
• 计时基准是 turn/start，不是 assistant/message

已排除

怀疑对象	结论
微信/IM 通道分段发送	桌面端同样慢，排除
dsh-im 的 deferred-delivery-coordinator.pollDelayMs（默认 30s）	改成 2s 并重启，无变化；且该段是 IM 侧逻辑，解释不了 desktop turn/end
session-log-deepseek 会话日志上传	用 cordis.patch.yml 禁用后重启，仍然 30.0 秒
meow-memory 插件	只读事件做投影，无阻塞钩子
DRAIN_TIMEOUT_MS = 30_000	属内置 Anthropic Beta SDK 的 _SessionToolRunner_drain，与本路径无关
streamIdleTimeoutMs	默认 300,000ms，量级不符

猜测

模型响应流可能没有及时给出结束信号，agent loop 在等一个「流收尾 / 用量回传」之类的信号，等到某个 30 秒兜底才继续；因为计时从 turn/start 起算，所以表现为整轮固定 30 秒。

期望

1. 这个 30 秒兜底在哪个模块，能否配置；
2. 或者确认这是 provider 侧流式行为导致的，并给出规避方式。