DeepSeek的推理死循环问题

let me go,let me write,let me run…

一开始觉得怪可爱的，有点英文诗的感觉。

现在才发现，这其实是推理死循环了，既浪费 token，又会生成几十万字符的巨型 thinking block，导致 TUI 打开历史会话时完全卡死。

一、TUI 卡顿排查（2026-10-07）

2026-10-07 那天我在用 PI 的时候，某一个对话突然卡的不得了。

一开始觉得可能是 herdr 的问题，也可能是终端的问题（换了 Omarchy 无论遇到什么问题总是觉得是系统的问题）。 但是也就只有那一个对话卡的不得了，其他的对话没事。对那个对话关闭，再打开，依然卡住。 重启系统，再打开，还是卡住。

排查发现卡顿不是因为文件读取慢，而是卡在 TUI 渲染 thinking block：

• 渲染瓶颈：同一份会话只改 hideThinkingBlock，false 时 60 秒满核（~101 ticks/s）且一行都渲染不出；true 时 6 秒渲染出 25 行。RPC 模式和 --export 仅需 0.45 秒，/proc/<pid>/stat 确认 CPU 消耗全在 pi 进程自身，排除终端和 shell。
• 最小复现：单条 152,804 字符的 thinking 就会卡死；截断到 10,000 字符后 6 秒正常。
• 循环数据：原始会话里有 7 条超过 10 万字符的 thinking（最大一条 159,193 字符）。最长那条共 12,102 行，但只有 90 个唯一行：Let me go. 出现 4,034 次、Let me write. 3,322 次、OK. 1,991 次。
• 非 Pi 独有：给 OpenCode 注入 16 万字符文本块，CPU 同样从 1–2 ticks/s 飙到 102–104 ticks/s 满核。

在 settings.json 里设 "hideThinkingBlock": true 能避免打开卡死，但治标不治本——模型依然会陷入死循环、浪费 token 并写入巨型文本。

二、Magpie 的死循环熔断（2026-10-12）

Magpie 在 v0.1.1142（2026-10-09）引入了推理死循环检测。10 月 12 日遇到了主动熔断报错：

1
2
3
4
5

Error: magpie ended this reply:
the model's reasoning was stuck in a loop,
its last 256 lines and sentences all among
the same 24 ("Let me go." "Let me write." "Let me run." …),
and would have run on to its output limit.

它检测到最后 256 行只有 24 种不同句子时主动中断生成，正好命中了这个问题，能及时止损 token 并限制 thinking block 体积。不过 Magpie 目前只做到了检测和熔断，还不会自动恢复。

三、中断后的处理：用 /tree 回退

循环被掐断后，不建议直接说「继续」——在相同的上下文下，模型极易再次陷入死循环。 因为推理过程依然存在上下文，之前中断的推理过程，依然会正反馈影响 「继续」后的推理。

更稳妥的做法是用 Pi 的 /tree 切回循环发生前的节点：

• 如果旧分支全是重复打转，选 No summary，避免将死循环内容带入新分支。
• 如果旧分支已完成了有效工作，选 Summarize 或 Summarize with custom prompt，只保留结论和进展。

注意：/tree 切换的是会话上下文，已修改的工作区文件不会跟着回滚。

至于其他的 agent 有没有这个功能我就不知道了。

四、目前的应对策略

1. 开启 Magpie 的循环检测及时熔断。
2. 配置 "hideThinkingBlock": true 避免历史会话卡死。
3. 遇到死循环用 /tree 回退到正常节点重新生成。

目前这套流程依然需要人工介入。更理想的机制是 Magpie 或 Agent 框架在检测到死循环后，能自动丢弃异常推理并从上一有效状态重试

后面或许可以向 Magpie 提个 issue，看看有没有继续完善这个功能的想法。

另 magpie 真的比 cc-switch 好用,强烈推荐使用。