reasoning leaks into the content channel on live traffic — known issue, not force-reproducible; boundary tracing added to catch and fix

[warelik]

中文 TL;DR

已知问题,记录在案:thinking 模型偶尔把 reasoning 写进 CONTENT 通道。只能在真实会话中偶发复现,受控探针无法复现。已有多代防御:#238(空答案救援)、#241(救援精度)、#243(前导 <think> 块从 CONTENT 重定向到 thinking);另有 #247(出口逐字去重)、#248(会话连续性)、#249(边界结构化日志,门控默认关)。下一步:开着 tracing 抓现场,抓到后另开 PR 提修复。

Что известно

• Thinking-модели изредка выдают reasoning в content-канал: живые наблюдения показывают вывод, который крошится и крутится на месте; клиенты сохраняют это как видимый текст и пересылают обратно — получается петля.
• Воспроизводится только в живых сессиях. Контрольные зонды (несколько формулировок, несколько моделей) возвращают reasoning в нативном канале, в content чисто — честный статус зафиксирован в fix(messages): reroute leading think-tagged content to the thinking channel — break reasoning-as-text loops (opt-in, default OFF) #243.
• Поэтому каждое поколение защиты строилось по полевой сигнатуре, а не по репродукции:
  • fix(devin-connect): rescue thinking-only finishes with a corrective nudge — unstick agentic loops on swe-1-7 + drop poisoning empty assistant turns #238 — rescue пустых (reasoning-only) ответов;
  • fix(devin-connect): rescue nudge quotes the failed attempt's reasoning tail — one fresh nudge per rescue + field-0 guard (layer 2) #241 — точность rescue (хвост reasoning в nudge, одна попытка, field-0 guard);
  • fix(messages): reroute leading think-tagged content to the thinking channel — break reasoning-as-text loops (opt-in, default OFF) #243 — перекладка ведущего <think>-блока из content в thinking-канал (до rescue-решения).

Что дальше

• feat(trace): WINDSURFAPI_LEAK_TRACE — structured reasoning/content boundary logs for catching live reasoning leaks (opt-in, default OFF) #249 — структурированные логи границы reasoning/content (WINDSURFAPI_LEAK_TRACE, default OFF): каналы, состояние маркеров, ограниченные сэмплы, reqId/acct. Цель — поймать инцидент живьём.
• Поимка → отдельный PR с фиксом следующего слоя.
• Смежное: feat(chat): incremental reasoning/content dedup — release on divergence, suppress only a verbatim duplicate at stream end (default ON) #247 убирает безвредное следствие (дословный дубль reasoning в content на стриме), feat(session-continuity): survive single-dialog history compaction — root-anchor fallback + tail-anchored overlap; acct= in reuse log (opt-in, DEVIN_CONNECT_SESSION_REUSE) #248 держит continuity на длинных прогонах.

Если у кого-то есть пойманный живой пример (сырой ответ, где reasoning виден в content) — это самый короткий путь к репродукции; приложите, пожалуйста, сюда.

[dwgx]

把 #249 评审里的一条挪过来，因为它直接影响这个 issue 写的下一步。

你在这里的计划是「开着 #249 的 tracing 抓现场」。我审 #249 时驱动了它的标记表，它认不出 <think>：

"<think>reasoning</think>"   -> null          ← 追踪看不见
"<thinking>x</thinking>"     -> ["<thinking>","</thinking>"]
"◁think▷y"                   -> ["◁think▷"]

leak-trace.js:29 的 THINK_MARKERS 是 ['<thinking>', '</thinking>', '◁think▷']。而 #243 里你把 THINK_OPEN 定为 <think>，整个分类器建立在那个方言上。

我核过这不是疏漏：<think> 在 master 里根本不是标记字符串，是 #243 引进来的，所以 #249 那个分支引用不到。但两个 PR 是一批 —— 合并后就会出现「钓竿钓不到被追踪的那个方言」，而这个 issue 的标题正是以它命名的。

建议在 #249 合并前给 THINK_MARKERS 补上 '<think>' / '</think>'。注释里那句 "Extend here when another model ships a different marker" 说明你已经预留了位置。

其余我在 #249 的评审里答了：门控关闭时热路径确实只多一次 env 读 + 布尔比较（四个调用点的采样构造都在条件内部，我原本怀疑的调用点参数求值不成立），三个埋点的分层选得准。

[warelik]

中文 TL;DR

已修:#249 的 THINK_MARKERS 现在包含 <think> / </think> —— 钓竿认得出这个 issue 命名的方言了(head 4f39142,单测 + 突变钉住)。

"<think>reasoning</think>"   -> ["<think>","</think>"]   ← 修复前 null

同批还带了两条来自 #249 评审的加固:settle 探针在 error/abort 出口记 outcome(全空行不再冒充「什么都没发现」);.env.example 写入实测量级(2000 token 回答 ≈ 2000 行 ≈ 215 KiB)。#249 合并后这里的「开着 tracing 抓现场」计划不受方言盲区影响。