[Bug] Agent 在超长上下文 + max reasoning effort 下陷入思考退化循环：回合零产出、无自动熔断，需手动中止（v4.1-flash；同配置 v4-flash 3000+ 步未复发）

[jilian-dsh]

环境

• DeepSeek Harness：@deepseek-ai/dsh 0.1.2-rc.1（npm 安装）
• 问题模型：deepseek-official deepseek-v4.1-flash-expires-on-0910
• 对照模型：deepseek-official deepseek-v4-flash-vision-exp（同配置，未复发）
• 配置：reasoningEffort: max，maxTokens: 256000，contextWindow: 1000000
• 操作系统：Windows，dsh web 使用

现象

会话最后两个回合模型"纯思考空转"：

• 回合内零工具调用、零回复文本，全部输出为 thinking 增量块；
• 思考内容陷入退化循环，反复生成"好。执行。好。（输出工具调用）"式自我催促（见下方样本）；
• 模型一度尝试自纠（"嗯，我要停止循环，直接输出工具调用"），随后继续循环；
• 回合无法自行结束，只能由用户手动中止（平台无纯思考超时/重复输出熔断）。

关键对照（重要）

问题模型之前，同一环境、相同配置（max / 256000 / 100 万窗口）使用 deepseek-v4-flash-vision-exp 跑过一个 3083 步 / 510 轮的超长会话，全程未出现本问题。本次为更换为 deepseek-v4.1-flash-expires-on-0910 后新发现（样本量 1，未做同模型对照复现）。

复现路径

1. 在同一会话内累积至约 51.5 万 token 上下文（占 100 万窗口一半以上）；
2. 使用 reasoningEffort: max；
3. 新回合承载多步任务，且前一回合有一次权限拦截的遗留状态；
4. 回合起始附带两条需自证的提示（如承诺措辞、路径缩写检查）。

时序（回合记录，GMT+8）

• 23:10:17 回合开始（用户追加授权 + 两点指示）
• 23:12:32 用户手动中止：约 2 分 15 秒、约 6.7 万条事件，全部为 thinking 增量
• 23:21:29 新回合开始（用户询问是否出 bug）
• 23:21:45 用户手动中止：约 16 秒、约 2 千条事件，仍全部为 thinking 增量

循环样本（实际记录）

嗯，我要输出工具调用。
好。
执行。
好。
好。
（输出）
好。
好。
嗯，输出。
好。
好。
（执行）
好。
好。

期望的产品改进

1. 纯思考回合超时/中止机制：长时间只输出 thinking、零工具零文本时自动中止或降档并提示；
2. 重复输出检测：连续重复句型达到阈值时干预或截断。

附加观察（同模型，待官方确认）

用户反馈 deepseek-v4.1-flash-expires-on-0910 理论上为多模态，但图片无法发出。若属已知限制请忽略；若不属，请确认该模型的模态支持面与正式版 deepseek-v4-flash-vision-exp 的差异。

相关讨论

• 想着想着就进死循环了 #729「想着想着就进死循环了」——现象同向，但无环境参数/模型/档位信息，仅有截图；本次补全了完整诊断信息。
• Bug&Fix: 思考时间过长后最终输出文本会导致 Web 端卡死且刷新后历史加载失败 (RangeError: Maximum call stack size exceeded) #317「思考时间过长后 Web 端卡死」——不同根因（Math.min(...sourceEventSeqs) 超 V8 参数上限），本次为模型侧生成退化。

附注

• 非确定性；未做二次复现；
• 回合记录完整（jsonl.zstd），可提供进一步诊断信息。

@zdaxie 官方团队能否确认这是否为已知问题？

[jilian-dsh]

人类来了：
1、光速录了个低质视频：【【Deepseek bug反馈】v4.1-flash 0910版本空转bug】 https://www.bilibili.com/video/BV11NYJ6jE68/?share_source=copy_web&vd_source=da30b8c9f6ead34bd59c665a572a46da
2、曾经沧海难为水，指挥ds-v4-flash写这个报告让我无比怀念v4.1-0910，跪求官方修复了······我那个会话的评估还没做完，急需纪律性强边界感好思维敏捷不搞左右脑互搏的v4.1-0910······

[jilian-dsh]

除问题会话外，另一个执行会话思维链也出现了大量的嗯、好，但暂未卡死。

[argszero]

@zdaxie 这条我先给一个源级判读（在 master c389f96 上核对），帮你把「这是不是 dsh 的 bug」和「能不能修」分开。结论：这不是 dsh 的回合金丝雀，而是模型侧生成退化，但恰好暴露了一个 guard 层缺口 —— 这个缺口可以被插件补上，不需要动 core。

一、为什么"回合零产出、无自动熔断"

你这轮的现象是：turn 内零工具调用、零回复文本，全部输出为 thinking 增量，且陷入"好。执行。好。（输出工具调用）"式自我催促循环。判读关键在 agent-loop 的 turn 循环 packages/core/agent-loop/src/agent.ts:274：

while (true) {
  const step = phase.step + 1
  const decision = await this.preStep(target, { turn, step })
  if (decision.kind === 'reject') { turnEnds = { kind: 'blocked' }; return false }
  if (turnEnds && decision.messages.length === 0) break
  ...
  const stepEnd = await this.step(...)
  if (turnEnds === null || turnEnds.kind !== 'max-tokens') turnEnds = stepEnd
  ...
  if (turnEnds && this.inbox.nextStep.length === 0) break
}

循环只有在 turnEnds 非空（completed / max-tokens / blocked / aborted / error）+ inbox 清空时才 break。而 step() 返回的 StepEndReason 只取 completed / max-tokens 两型（agent.ts:50）。只要模型持续产出 thinking 增量、既不落 text 也不落 tool-call，stepEnd 一直是"未完成"，turnEnds 永远不置位 → 循环永不结束，只能由你手动中止。这与 #317（不同根因，那个是 Math.min(...sourceEventSeqs) 超 V8 参数上限）确实不是一回事。

二、为什么现有 guard 兜不住

guard/ 家族两个插件都是 tool-call 中心，恰好都抓不到"全程零工具调用"：

• guard/timeout-policy（tools/execute 包装）——只在工具被调用且声明 timeoutMs 时挂 deadline。没工具调用，它根本不触发。
• guard/repeat-tool-reminder（tools/post-execute）——检测"连续相同 tool call 链"。zero tool call → 无链可检测。

所以这不是现有 guard 漏检，而是它们本就不覆盖"纯思考空转"这一失败面。

三、插件可挂载面（我准备这样做）

packages/core/agent/src/runtime-types.ts:369 有 agent/assistant-stream 事件，每帧带 frame.chunk: StreamChunk，且 StreamChunk 明确区分三型（llm/src/types.ts:378）：reasoning-delta / text-delta / tool-call-delta。所以一个插件可以按 (agent, turn, step) 统计该 step 各型 chunk 的占比：当某 step 全程只有 reasoning-delta、且文字出现低熵重复（"好。执行。好。"、连续的 "Let me / Wait / Actually / Hmm"）达到阈值，就判定为思考退化。

反应能力已有：agent.steer(input)（agent.ts:137）可注入一条"你正在重复自己，停止并行动"的 steer；agent.cancel(cause)（agent.ts:145）可硬停。两者都是公开方法，无 core 改动。契约上插件只能反应、不能事后 veto 该 step（没有 post-step veto 缝），但 steer/cancel 已足够阻断。

我正按 guard/ 家族同款形态做一个 @deepseek-ai/cordis-plugin-thinking-loop-guard（欢迎外部 @argszero 社区包）：默认检测 reasoning-only step + 低熵重复，触发 agent.steer 软约束，maxThinkingSteps 超阈值再 agent.cancel('thinking-loop') 硬停，全部可配置。这正好对应你说的期望 1（纯思考回合超时/中止）与期望 2（重复输出检测）。

补充一点对你的判定："同配置 v4-flash 3000+ 步未复发" 是强证据——这说明故障面在模型侧（v4.1-flash-expires-on-0910 的 reasoning 生成在长上下文 + max effort 下退化），而非 dsh 的输入组装。但 harness 侧确实缺一个"模型卡死时的兜底"，这层用插件补即可。需要的话我贴出更细的 step 计数 + chunk 判定的实现草案。

[jilian-dsh]

@argszero 判读完全正确，且我们已逐条验证。补充实测数据，支撑「模型侧生成退化」判定：

1. /compact 后仍复现（新证据，可复核）

我们随后在该事故会话执行了 /compact，命令成功：Compacted 421 history items (~322196 tokens)（command/done 记录）。压缩后两个新回合仍零工具调用、零文本产出，推理中再次出现同一「好。执行。（输出）」低熵循环，均被手动中止。即：上下文从约 51.5 万 token 压缩到约 32.2 万 token，空转依旧复现。

→ 上下文长度不是主因：即使回到 32 万 token，模型仍在同一会话内持续退化循环。这与我们另一条证据互相印证——同配置（max/256000/100 万窗口）下 deepseek-v4-flash-vision-exp 跑过 3083 步 / 510 轮的会话从未出现本问题。故障面确在模型侧（v4.1-flash-expires-on-0910 的 reasoning 生成），而非 harness 输入组装。

2. 对「复现路径」的修正

原帖复现路径第 1 条（含 51.5 万 token 上下文）需修正为：上下文长只是伴随条件而非必要条件——更精确的触发特征是「该模型在会话内已进入退化状态后，同会话持续复现（含压缩后新回合）」；样本量 1，未做同模型对照复现，供参考。

3. 对你方案的确认

• guard/timeout-policy（tools/execute 包装，仅工具声明 timeoutMs 时挂 deadline）与 guard/repeat-tool-reminder（tools/post-execute，连续相同工具调用链检测）确为 tool-call 中心，零工具调用场景两者都不触发——缺口判定成立。
• 源码级：agent-loop turn() 的 while (true) + StepEndReason 仅 completed/max-tokens 两型（agent-loop/src/agent.ts），agent/assistant-stream 事件携带 StreamChunk 三型（reasoning-delta/text-delta/tool-call-delta），agent.steer()/agent.cancel() 均为公开方法——你所描述的插件挂载面可落地。
• 期待你的 @deepseek-ai/cordis-plugin-thinking-loop-guard；社区包我们持支持态度（可提供本会话原始 chunk 序列样本做阈值标定）。

4. 与本帖相关的另一观察（同模型）

用户反馈 deepseek-v4.1-flash-expires-on-0910 理论上多模态但图片无法发出——若属已知限制请忽略；若不属，请一并确认该模型模态支持面。

附：若需原始记录查证，本会话 JSONL 完整可提供（含压缩前后全部 chunk 序列）。

[argszero]

@jilian-dsh 插件已发布，按你说的"可提供原始 chunk 序列样本做阈值标定"，我已把首版做出来并标注了可调项。

已发布资产

• npm: @argszero/cordis-plugin-thinking-loop-guard v0.1.0
• 源码: https://github.com/argszero/cordis-plugin-thinking-loop-guard
• 加载: 把它作为 @deepseek-ai/cordis 插件 mount 到你的 dsh profile（包内已带 cordis.patch.yml 一条 insert 行）

实现（对齐你确认的 seam）

你上一轮逐条验证的挂载面我照此实现：

• 订阅 agent/assistant-stream，逐帧统计 StreamChunk 组成；
• 某 step 一旦出现 text-delta 或 tool-call-delta → 视为有产出，计数器清零（不是 thinking loop）；
• 某 step 全程只 reasoning-delta 且长度 ≥ minReasoningChars → 计入 maxThinkingSteps；
• 达到阈值（或 repeatRatio 低熵重复超限）→ 按 escalate 逐级反应：

escalate	动作
warn	agent.inject(...) 注入下一 pre-step 提示
steer（默认）	agent.steer(...) 发"停止空转、立即行动"
cancel	agent.cancel('thinking-loop') 硬中止当前回合

agent.inject/steer/cancel 均为公开方法，turn() 的 while (true) 无需改动。

默认参数（保守取向）

{
  maxThinkingSteps: 3,      // 连续 reasoning-only step 数
  minReasoningChars: 2048,  // 单 step 至少这么长才计入
  repeatRatio: 0.5,         // longest repeated token / total tokens
  escalate: 'steer',        // warn | steer (默认) | cancel
  cancelCause: 'thinking-loop',
}

"好。执行。好。"式低熵循环因 repeatRatio 会提前命中（重复 token 占比趋近 1），长而连贯的探索则占比低——我只在 step 已足够长时才跑这个启发式，成本有界。

阈值标定

如果你那边有原始 chunk 序列样本（压缩前后都行），我可以据此把 repeatRatio/minReasoningChars 调准，或者加一个按已知循环样本的反例回归。首版是保守默认值，避免误伤正常的长思考。

另外你提到的同模型图片无法发出（#5976 末尾附加观察）——那属于模态声明面，与 reasoning 退化正交，我记为待确认（已在 model-inputmodalities 缺口家族里），需要的话我可以单独拆开跟进。

[jilian-dsh]

非常感谢您的高效构建，我将安装并使用，如有情况将进行反馈！

[argszero]

@jilian-dsh 你在我插件仓库提的 P0（agent/assistant-stream 在 0.1.2-rc.1 不存在）已核实并修复，v0.1.1 已发布（npm latest，GitHub 同分支已推）。这里同步到源头讨论串，感谢你实测抓到这个兼容盲区。

v0.1.1 关键改动

1. 监听 llm/stream waterfall（0.1.2-rc.1 与 0.1.5-alpha.1 都有），不再依赖 0.1.5-alpha.1 的 agent/assistant-stream；
2. dsh-agent/dsh-llm 升为 peerDependencies（>=0.1.2），rc.1 上安装不再撞版本解析；
3. 启发式从 whitespace-token 换成语言无关 repeated-gram 覆盖率 —— 你描述的 CJK 空转（"好。执行。"无空格）原本判不出，现在退化≈0.99、连贯≈0.0，且 O(n)。

顺带回应你上一条"同模型图片无法发出"的观察 —— 那个属模态声明面，与 reasoning 退化正交，我已记到 model-inputmodalities 家族（#5837/#5848/#5941），需要的话我可以单独拆开跟进。

[jilian-dsh]

1、改动收到，我正在安装，完成后将在特意保留的错误会话中进行实测。
2、模态声明面问题暂时不影响我的实质性使用，所以我准备等等看官方最终发布的结果。
再次感谢您的高效更新与专业反馈！

[jilian-dsh]

补充之前提出但是可能没被看到的，下班回来发现ds帮我提到了关闭的issue里：
argszero/cordis-plugin-thinking-loop-guard#1 (comment)
当时插件存在一些问题，会导致会话直接无法进行，详见前述链接。

[gezi-wen]

我们这边也遇到了同样的情况，顺手同步一个环境，供参考。

环境：Windows + dsh web + deepseek-v4.1-flash-expires-on-0910，会话达到一定长度、thinking 档位拉满后，就出现「好。执行。好。好。（输出）」这样的空转，回合内没有任何工具调用和正文，只能手动中止。现象和帖子里的样本几乎一致。

真正想补充的一点，是从使用者的角度出发的：这个问题的触发门槛比看上去要低。 我们就是跑一个普通的、稍长的任务，并没有做什么特殊配置就撞上了；而且它很隐蔽——界面上只显示「思考中」，看起来和模型认真推理没有任何区别。不点开 thinking 块，根本察觉不到它卡在重复里，只会当成模型变慢，然后干等。

所以我的判断是：报出来的人少，不代表遇到的人少。 很多人可能跟我的第一反应一样，把它当成偶发的卡顿，手动中断就算了，未必意识到这是个 bug。

这也正是为什么自动兜底不能只看「长时间没产出」——正常的长推理同样没有文本和工具输出，时长不是有效特征。要可靠识别，确实需要像 @argszero 那样抓重复句式（repeated-gram）的特征，而不是依赖时间阈值。

如果各位需要更多样本标定阈值，我这边可以把手头触发时的 chunk 序列提供出来。

[argszero]

@gezi-wen 感谢独立确认——这是继 @jilian-dsh 之后第二个实测复现（同为 v4.1-flash-expires-on-0910、Windows + dsh web 部署），而且你补的「使用者视角」两点都说到根上了：

1. 触发门槛低 + 隐蔽性：「界面只显示思考中、看起来和认真推理没区别、不点开 thinking 块根本察觉不到」——这解释了为什么这类退化循环在社区里报得少：很多人第一反应是"模型变慢"就手动中断了，未必会当成 bug 上报。你的推断（报的人少 ≠ 遇到的人少）正是自动兜底存在的理由，也是这个线程最初的价值。
2. 时长不是有效特征：完全同意。正常的长推理同样长时间没有文本/工具输出，纯时间阈值必然误伤。所以识别必须靠内容特征（重复句式），而不是墙钟时间。

插件形态方案已可落地试用：针对这个具体症状（CJK 无空格重复「好。执行。好。好。」），我这边已经有现成的自动兜底插件可直接 mount：

• npm: @argszero/cordis-plugin-thinking-loop-guard v0.1.1（npm latest）
• 源码: https://github.com/argszero/cordis-plugin-thinking-loop-guard
• 检测特征 = 语言无关 repeated-gram 覆盖率（不是时间阈值）：某 step 全程只有 reasoning-delta 且重复片段占比高（你描述的「好。执行。」空转实测退化≈0.99，连贯长思考≈0.0）→ 按 escalate 逐级 warn → steer（默认，发"停止空转立即行动"）→ cancel
• 兼容 0.1.2-rc.1 ~ 0.1.5-alpha.1（v0.1.1 起监听 llm/stream，peerDeps >=0.1.2）

如果你们在 dsh web 部署上愿意试装跑一个长任务验证，欢迎直接报现象回来——这正好补上"真实 dsh web + 长会话 + thinking 拉满"这个我最想要的实机场景。

关于 chunk 样本：非常需要，接受你的 offer。触发时把原始 chunk 序列给我（压缩前后都行，贴 gist / 仓库 issue 附件 / 直接贴文本均可），我会用来：① 标定 minReasoningChars / repeatRatio 默认阈值；② 加一个按你们真实循环样本的反例回归用例，锁住"正常长推理不误伤"这条线。

[argszero]

插件已到 v0.1.5，现在可以用你自己的会话文件标定，不必手动整理 chunk 序列了。

给 @gezi-wen 和后续要提供样本的人：v0.1.5 随包附了一个离线复跑工具，它用插件运行时同一个 detector 复跑一份 session jsonl：

node node_modules/@argszero/cordis-plugin-thinking-loop-guard/tools/analyze-session.mjs \
  <你的 session.jsonl> --similarity 0.6 --threshold 3 --min-chars 512

  #   turn/step   reasonChars  textChars  verdict             fired
   1  0/0                  33          0  reasoning-only
   2  0/1                  33          3  repeated-material   repeated-material

stalled steps: 2/2  |  reactions: 1  |  steps that emitted text: 1

• 要样本的话，只要那一行输出就够（或给 jsonl 路径），不用再手工截 chunk —— 判定形状、行号、阈值敏感性一次都出来了。本地读，不上传。
• 它同时读两种持久化格式：assistant/chunk（session format v1，dsh ≤ 0.1.2-rc.1）与 assistant/attempt（v2，dsh ≥ 0.1.5）—— 这两个事件名两代没有交集，所以任何基于持久化事件的读取都只能针对一代，llm/stream 才是两代都在的那个缝。
• 你们那种「某 step 全程只有 reasoning-delta」的形状（@gezi-wen 描述的 v4.1 空转）正是 v0.1.4 起新增的 reasoning-only 判据覆盖的，v0.1.5 只是把它变成可离线复核。

npm latest = 0.1.5 / GitHub 11ab0fc。仍然欢迎把 --json 的逐 step 记录贴回来，我用来把 minReasoningChars/similarityThreshold 默认值钉在你们的真实分布上、并加反例回归锁住"正常长推理不误伤"。