v2.1.9 正文重复输出保护与压缩阈值口径

变更

修复：正文里的重复输出现在也会被拦下。 此前保护只监控 reasoning_content，而线上观测到的「疯狂输出」发生在正文里：抓包里是「我执行。」重复 127230 行、唯一行只有 1 个，推理侧却只有 3736 字符、重复覆盖 23%，永远达不到阈值，于是既不中断也不重试。

正文现在单独一路计数，并用独立的错误码 upstream_output_loop 与推理侧的 upstream_reasoning_loop 区分开，调用方据此判断「模型在思考里打转」还是「重复正文正在刷屏」。正文比推理更保守：除共用的「窗口内不同项不超过 12、重复覆盖至少 95%」外，还要求出现最多的那一行占 75% 以上，避免两行或三行交替重复的表格、代码块被误截。

写出闸门同步扩到正文。正文从第一帧就压住，命中时客户端仍是零字节，可以整段丢弃并在同一账号上重发；出现超过 32 字符的长行、空行或第三种短行即判定不是短行循环并立即放行，正常回答通常只多等一个行尾。正文另有 8 秒独立时限与 32768 字符上限，没有换行的短回答不会被压到推理侧的 60 秒。命中后压住的那段重复正文在重发用尽时也直接丢弃，只写错误帧，避免用户先看到一屏重复输出再看到失败。

修正压缩阈值口径。 客户端模型目录里 deepseek-v4.1-flash 的 auto_compact_token_limit 由 466666 提到 900000。466666 是早期按 1.5 倍输入估计缩小的保守值，而 1.5 倍已在网关侧退役；现在客户端按上游原值计数，900000 正好是 1000000 窗口的 9/10，与 Codex 内置默认口径一致，不再出现「远没到临界就压缩」。global:hy3 的 120000 保持不变：192000 窗口配 64000 最大输出，留出的余量是刻意的，不是同一个 1.5 倍造成的。

部署

热更新即可，不需要重建容器：

docker compose pull
docker compose up -d

网关与面板镜像都已发布 v2.1.9。管理台「重复推理保护」开关现在覆盖推理与正文两条流，文案已同步更新。

已知边界

保护仍是启发式：合法的重复短行可能误报，无换行的循环不在覆盖范围，正文侧另有「占多数的一行」与空行两道防线来减少误截。业务本来就需要大量重复短行时，可以按密钥关闭这项保护。

压缩阈值写在客户端模型目录里，不由网关下发。若发现压缩时机仍不合适，先核对实际生效值——它是 auto_compact_token_limit 与 context_window 九成的较小值。