长会话下输出陷入重复循环（degenerate repetition），建议加输出重复检测

[Lurbing7]

摘要

在长会话中，助手输出会突然开始重复同一段无意义短文本，持续数十行，把真正的回答（通常是工具调用）完全挤掉。用户侧看到的表现是「卡住」或「无故停止」。官方仓库关闭了 Issues，所以按 Ideas 分类发在这里。

现象（完整记录）

重复的形态

同一段文本在一轮内被连续输出几十次。观察到的两种形态：

形态 A（纯中文短句）：

好。
发。
好。
好。

形态 B（中英混合，说明重复会跨越语言/段落边界）：

Emitting.
好。
发。
好。
好。

这些内容没有任何语义 —— 正常情况下，那个位置应该是一个直接的工具调用（读文件 / 改文件 / 跑命令）。

出现频率（本次会话的观察）

会话阶段	重复出现频率
前 1/3	0 次
中 1/3	偶发，约每 10 轮 1 次
后 1/3	几乎每轮 1 次

明显的正相关：会话越长，越容易触发，且一旦开始就很难在同一轮内自行恢复。

伴随的输出质量下降

出现退化之后，工具调用的参数不再可靠。具体一次：

• 助手在修改一个前端源文件时，一次编辑误删了一个函数的函数体（只留下了函数签名）
• 该文件随后需要额外一轮来修复
• 说明退化状态下不仅是"多输出了垃圾"，连正常动作的参数构造也受损

用户侧的实际感受

用户的原话（按时间顺序）：

• 「最近怎么总是自动停止」
• 「怎么一直停止，继续」
• 「这次又是无故停止」

即：在用户看来助手是在任务中途停止响应。实际上助手一直在生成，只是生成的全是重复片段，真实输出被挤没了。

环境

• dsh：0.1.5-rc.2（Windows 10/11）
• 模型：deepseek-flash
• 场景：Web 端，长会话 + 高频工具调用（读文件、改文件、跑构建命令、查本地 HTTP 接口）
• 会话规模：约 150 轮；单轮常包含多段落的长文本（说明、提交信息、文档）

我观察到的可能相关因素

只陈述相关性，不下结论：

1. 对话长度 —— 最强相关。前期完全没有，后期几乎必然出现
2. 单轮输出体积 —— 输出较长、包含多个相似结构的短段落时更容易触发
3. 工具调用密度 —— 会话里几乎每轮都有工具调用

不是由某个具体输入触发的：同一类操作在前期完全正常，后期同一种操作开始退化。所以给不出最小复现步骤。

建议（如果 harness 层有余地）

1. 生成中的重复检测：对正在生成的文本做 n-gram 重复率检测，超过阈值就中断该轮并给出提示。
   现在每次都要"等它把重复刷满"才停，浪费了大量 token 和时间 —— 这是最实际的改进点。
2. 长会话上下文体检：接近上下文上限时提前提示或做压缩，而不是让输出质量先劣化。
3. 工具调用参数的完整性校验：既然退化会破坏参数构造（见上面误删函数体那次），
   对"整体替换文件"这类高风险操作做一层内容长度/结构突变检测会有帮助。
4. 如果这是已知的模型行为，在文档里写明「长会话建议适时开新会话」也很有价值。

我们这边的规避方法（供遇到同样问题的人参考）

• 长会话适时开新一轮 —— 从这次的曲线看，这是最有效的
• 一旦助手开始刷屏，直接说"停下"，而不是说"继续" —— 后者会让已经退化的上下文继续累积
• 关键产物及时落盘（git commit），避免退化时误改已有文件

---

说明：本报告由助手根据一次真实会话整理。发布前已剔除一切与现象无关的私人信息（账户余额、含用户名的绝对路径、身份标识、密钥与配置片段）。

[argszero]

Measured this report against the harness, and there is a real gap here — plus one thing that now fires on it.

What the harness does today for shape A/B

Your suggestion #1 (detect repetition while generating) maps onto exactly one extension point in this codebase: the llm/stream waterfall. It wraps every streaming model call, a listener sees each StreamChunk, and the agent loop consumes the waterfall's iterable itself (for await (const chunk of stream) live.push(chunk)) — so a listener may yield its own terminal finish chunk and actually end the call. The in-tree guards cannot: guard/repeat-tool-reminder only arms on a tool call (and it is advisory by design — its README lists "escalating to a blocking form" as unimplemented), and guard/timeout-policy is a per-execution deadline.

I maintain the community plugin that uses that seam (thinking-loop-guard, on npm), and I re-ran your exact shape through the shipped version before answering. It does not fire:

chunking of your shape A (好。/发。/好。/好。 ×40)	longest run of identical consecutive deltas
one delta per line	3
one delta per cycle	40
one delta per 4 characters	1
one delta per character	1

The breaker counted identical deltas against a threshold of 60, and a cycle resets that counter on every phase change. Under no chunking did it reach the threshold. That is the bug you found, expressed precisely: a delta-level rule cannot see a period-k cycle, and your shape B (with Emitting. in front) is the same thing crossing a language boundary.

What now fires on it

Released today as thinking-loop-guard@0.1.8: a cycle rule at the character level. When the tail of a call's visible output is an exact repetition of one period no longer than maxRepeatedCycleChars (default 64) and spanning at least minRepeatedCycleChars (default 256), the stream is cut by the same terminal finish with a REPETITIVE_OUTPUT failure, and a steering correction is queued first so the resumed turn is told what happened:

# cordis.patch.yml — or mount it in your profile
- insert:
    - id: thinking-loop-guard
      name: '@argszero/cordis-plugin-thinking-loop-guard'

On your two shapes it fires after ~256–270 characters instead of never — i.e. after ~20 cycles, not after the screen has filled. Your periods are short (12 and 26 characters), and because the period is measured in characters it does not matter whether the bleed arrives with line breaks or not: a provider that streams it as one blob is caught identically.

Why not an n-gram repeat rate

You proposed "n-gram repetition rate over the generated text"; I built that first, measured it, and dropped it. This plugin already has that measure (fixed-length gram coverage, language-agnostic, written for CJK) and here is what it reads on a 512-character tail:

text	coverage
your shape A	0.985
your shape B	0.963
a 40-row markdown table	0.721
a 60-line log listing	0.760
generated CSS rows	0.817
a 40-item JSON dump	0.837

The separation between "degenerate" and "legitimately repetitive" is ~0.06, which is not a margin I am willing to truncate someone's call over — a model legitimately dumping a table or a JSON array is in that band. Exact verbatim periodicity instead reads 0 for all six healthy samples and non-zero only for the loop. One extra guard: the period must contain at least two distinct characters, so a long ===== divider in a generated document is never read as a loop.

What you can run on your own session

The plugin ships an offline analyzer that replays a session file through the same detector, so you can answer "would the breaker have cut this call?" on the session that produced this report instead of reproducing the failure:

npm install @argszero/cordis-plugin-thinking-loop-guard@0.1.8   # next to your dsh packages: it uses their types at runtime
node node_modules/@argszero/cordis-plugin-thinking-loop-guard/tools/analyze-session.mjs <session.jsonl>

Both durable attempt formats are read (v1 assistant/chunk, v2 assistant/attempt). A synthetic session carrying your shape reports:

  #   turn/step   reasonChars  textChars  chunks  verdict    fired  repeatedRun  cycleSpan  break
  1  4/9                   0        480     160  progress              2        256  BREAK(repeating-cycle)

repeatedRun = 2 is why the previous version was blind to it; cycleSpan is the new rule. If your real session shows BREAK on the degenerate calls, 0.1.8 would have stopped them — and if it shows cycleSpan = 0 where you saw the repetition, that is a shape I have not modeled and I would like the file (the analyzer prints nothing but the session's own numbers).

What is still not covered

• Your point 2 (context health near the limit). Nothing here prompts or compacts early because output quality is degrading; compaction is driven by token accounting, not by degeneration. That is a core-side decision.
• Your point 3 (tool-argument integrity — the edit that lost a function body). Not covered by anything today, and it is the item I would rank next after the bleed itself. The pre-execute seam allows a plugin to deny a call and explain, but not to rewrite its arguments (argument rewriting is excluded deliberately, because arguments are already logged and presented), so the implementable shape is a guard that refuses an edit/write whose payload would delete a large part of an existing file and returns that fact to the model as the reason. I have not built it.
• Cutting a call is not repairing the model. The turn fails with REPETITIVE_OUTPUT and the agent is steered; the plugin deliberately does not retry or fall back to another model, because silently re-billing a degenerate model is worse than the loop. Your workaround list (new session, say "stop" rather than "continue", commit artifacts early) remains the right first response.

For the record, two of your observations are independently confirmed by the harness sources: degeneration is a long-context phenomenon rather than input-triggered (both this and discussion #2848, a ~420,000-character single-call bleed, appeared under large contexts), and your "it looks like it stopped" reading is the expected user-visible symptom — the model keeps generating, so the failure surfaces as a turn that neither finishes nor calls a tool.

Disclosure: I am the author of that plugin — it is a community package (independent repo and npm scope), not part of the harness, so treat the claims above as mine to defend; the measurements are reproducible from the plugin's test suite.