[Bug] 会话永久锁死 / 每轮都 400：Content Exists Risk、INVALID_REQUEST —— 两种机制 · 三个毒源 · 三张面孔 ＋ 可落地的修复建议（更新 2026-10-06）

[Xing-0000]

一个会话会被「历史里的一段普通内容」永久锁死：两种机制、三个已查明的毒源（2026-10-06 大更新）

环境

• DeepSeek Harness @deepseek-ai/dsh 0.2.0-rc.2（最新版；旧版 0.1.5-rc.1 只出现在第四节的升版对照里）
• provider deepseek-official · model deepseek-flash（contextWindow 1e6）
• 会话格式 session.v4.jsonl.zstd（0.1.x 是 session.v3.jsonl.zstd）
• Windows 11 · 该 profile 下没有启用任何第三方插件 ⇒ 与插件无关

结论先行：两种独立机制，不是一种

	① 内容级	② 档位级
谁命中	内容本身命中服务端的特征	内容本身不命中
入口	任何入口都一样炸（文件读取、命令输出、手打……）	只有"文件读取"那种形态会过线
判定	与长度无关（我们手上最短的触发物只有 4 个字符）	与"送达形态"有关：逐字节相同的内容换成命令输出 ⇒ 没事
后果	会话永久锁死	会话永久锁死

⇒ 两者都会让会话永久报废，但成因和规避方式完全不同 —— 旧版那条"像是累计评分/阈值"的描述只适用于 ②，① 是纯命中、跟累计和长度都无关。这两件事必须分开看。

一、现象（可复现）

1. 某个会话在读取了一段内容之后的下一步起，每一轮请求都返回 400：
   • 上游原始体：Content Exists Risk (request_id: …)
   • 客户端这一侧显示的是 400 INVALID_REQUEST（0.2.0-rc.2 上是 DeepSeek Messages request failed (400)，0.1.5-rc.1 上是 DeepSeek API error (HTTP 400)）
   • ⚠️ 同一个 400，两处显示不一样 —— 用户既无法凭报错搜到同类问题，也看不出这是"内容审核"而不是网络/客户端故障。
2. 之后每一轮都失败：不只助手回复失败，用户手打的一句话（10 个字）也失败。
3. 原会话永久不可用：重启无效；复制会话后，新会话同样全挂（种子历史被一起复制）。
   ⚠️ 但"分叉到毒之前"实测有效 —— 我们救回过一条每轮都错的会话（见第七节；⚠️ 那条的死因是响应侧，请求侧的锁死尚无实例）。
4. 会话文件本身完好：能正常解压、事件完整 —— 与文件损坏无关。
5. 触发它的内容是普通中文记录：没有明显敏感词，也没有任何完整 URL（机制 ② 那条）。

为什么这不是边缘 case

会话历史是每轮整段重发的 —— 所以这不是"某一条消息被拦"，而是这个会话对象本身被永久污染：只要那段内容还在历史里，之后每一轮请求都必然带着它。一条坏内容 = 整个会话报废，且客户端没有任何自查手段。

⚠️ 但服务端并不封禁这个会话（这条是 #7879 实测的，与我们的观察一致）：400 之后紧接着发一个干净请求，会正常返回 200 —— 卡住的纯粹是"历史里还带着它"。⇒ 也就是说，只要能把那一段从表面里摘掉，会话本来是能救回来的（这正是下面诉求 2 的意义）。

二、两种机制（本次更新的核心）

① 内容级：内容本身命中 ⇒ 跟入口无关

我们把同一份短内容用两种完全不同的通路送进新会话，结果一致：

• 一份 4 个字符（两位数字 ＋ 一个名词）的内容，经命令输出送进会话 ⇒ 400 锁死；
• 一份 77 字符、形态为「方括号包住的锚文本 ＋ 圆括号包住的链接」的整行，同样经命令输出送进 ⇒ 400 锁死。

⇒ 命令输出这条通路不经过文件读取，照样炸 ⇒ 说明触发点就是内容本身，跟"从哪个入口进来"无关。也跟长度无关（4 个字符就够了）。

补充（口述观察，未逐字存档）：这两类短内容在 DeepSeek 官方网页端上同样会被拦（那边返回的是它自带的兜底话术）。
⚠️ 严格讲我们只能说"网页端也会拦"，不能断言它与 API 的 Content Exists Risk 是同一条规则；
但至少说明一件事：触发点在服务端，不是这个客户端特有的。

② 档位级：内容不命中，但以"文件读取"的形态送达时会过线

这一条是我们这次最难查、也最反直觉的：

• 触发物是一段单行 2,601 字符的私人中文记录。走文件读取进入会话 ⇒ 400，会话当场报废（连续复现 2 次，2/2）。
• 我们按客户端源码，把文件读取那次实际送进上下文的正文逐字节重建出来（2,108 字符，用 sha256 自检一致），再用另一条通路把完全相同的那 2,108 字符送进一个全新会话 ⇒ 没事，会话正常。

⇒ 同样的字节：走文件读取 ⇒ 炸；走命令输出 ⇒ 不炸。 这就是"档位级"：内容本身没到线，是"以文件读取的形态送达"这件事让它过了线。

边界（诚实标注）：② 我们只测到"换入口就不过线"；具体差在哪个环节，我们不知道。客户端的文件读取结果里带一个 <type>file</type> 信封标记、命令输出没有 —— 这可能相关，但我们没有任何证据说就是它。

判据说明（这条很重要，免得复现方法被质疑）

判"会话有没有死"，我们只看会话事件里的 turn/end 结果（kind: "completed" = 活着；kind: "error" ＋ INVALID_REQUEST = 已锁死）。

不要用"子代理有没有写出哨兵文件"这类判据 —— 子代理会把"注入"和"写文件"并发在同一轮里，死活都写得出文件。我们早先就因为这个判据误判过。

三、已查明的三种毒源

#	来源	形状（可判定描述）	属于哪种机制	复现结论
1	私人长行记录（单行素材）	单行 UTF-16 长度 2,601；汉字 1,063 / 数字 308 / ** 300 / 反引号 66（33 个行内代码段）/ ⚠️ 10；URL 0、punycode 0；最长无空白片段 95；最长同字符连跑 3	② 档位级	read 送 ⇒ 2/2 锁死；逐字节重建（2,108 字符）换通路送 ⇒ 通过
2	一个短「违禁词」（我们手上这份是两位数字 ＋ 一个名词，共 4 个字符）	单行 4 个字符	① 内容级	走命令输出 ⇒ 锁死
3	「中文锚文本 ＋ 链接」的整行	单行 77 个字符，形态为「方括号包住的锚文本 ＋ 圆括号包住的链接」的完整一行	① 内容级	走命令输出 ⇒ 锁死

⚠️ 第 2 类的来源要单独提醒 —— 它有一个明确的出处

• 我们那份 4 字符样本，就是在 Discussion #5445 的评论区里看到的 —— 那条评论确实存在（我们看过，也验证过它会触发）；那个会话之后便进入了"每轮都 400"。
  ⚠️ 严谨起见补一句："我们是从那里看到的"是确定的；但"是不是那一条直接导致的"事后已不可复核 —— 会话已经废了，再去读一遍又是一次中毒。

• 污染机制（这也是本帖的核心）：那段内容一旦进入会话历史就再也出不来 —— 因为历史是每轮整段重发的，所以从下一步起每一轮请求都带着它，于是每一轮都 400；重启无效、复制会话会把种子历史一起带走。

• ⇒ 给所有 AI 会话的提醒：#5445 的评论区不要去读。 机制 ① 说的就是这件事：跟入口无关，读了就中。

• 同一类的第二个出处（2026-10-06 当天新测得）：#7879 的正文也会炸 —— 我们用一条一次性子代理去读它抓下来的正文，那个会话当场报废。
  事后只量形状：330 行、最长行 1,037（没有超过 2,000 字符的行），但有 4 处短行符合上面第 2 类那种「短、含数字＋汉字」的形状。
  ⇒ 这支持"#7879 里也带着同一类触发词"这个判断；⚠️ 仍是判断 —— 我们没法在没有风险的前提下复核。

• 第 2 类的更精确刻画（来自 #7879 —— 感谢有人替我们读了它）：那边把触发物定位到了字形级 —— 他们那一族是「区域指示符对」（= 旗帜 emoji 的码位序列，对应两个大写字母），最小复现只有 2 个码位，而且换别的字母组合都不炸 ⇒ 这类触发物至少有一族是可枚举的。

  • ⭐ 旁证（我们自己量到的）：我们抓下来的那份 #7879 正文里，正好有 2 个区域指示符（= 一个旗帜），与它自己说的"2 码位最小复现"吻合。

  • ⚠️ 我们手上那份 4 字符样本是不是同一类，我们没验（它在私人记录里，事后不可复核）—— 但值得拿普通查看器看一眼它的码位。

  • ⭐ 它的单变量对照矩阵（同一端点、同一时间窗，每个请求体只有 1–2 个字符，只改内容这一个变量；触发字形已替换、不外嵌，理由同 [Bug] 内容审核按"单个字形"拦截 → 会话永久 400：最小复现仅 2 码位、跨端点/跨客户端一致（附可落地的三处修复） #7879 自己那句"避免本文自己变成毒源"）：

    请求体内容	码位数	结果
    该字形对（触发物，字母已替换）	2	400
    其它真实国家码的字形对（如 DE / JP）	2	200
    非真实国家码的两两组合	2	200（26/26 全放行）
    单个区域指示符（不配对）	1	200
    普通 emoji	1	200
    该地区的中文文字指称	2	200
    拉丁双字母码（纯文本）	2	200

    ⇒ 判定粒度是"具体字形簇" —— 不是"讨论某个地区就有风险"，也不是"所有旗帜 / 所有 emoji 都拦"。
    ⇒ 确定性：同一字形连打 3 次全 400；间隔 2s / 15s / 60s 全 400；三把不同 key 全 400；官方端点与自建网关同分钟交替打结果一致。
    ⇒ 这一组还顺带说明：它是服务端的、与账号无关的策略，不是某个 key 或某个客户端的问题。

⚠️ 但这份清单不是穷举 —— 它只是"我们观测到的"。 真正决定「会不会永久化」的不是内容的类别，而是一条更简单的规律：

任何"每轮都基于历史重新判定"的环节，只要那段历史无法改写，就会被永久化。

这一条同时解释了我们遇到的三张面孔（请求侧审核 / 响应侧掐流 / 响应侧拒答）：

面孔	谁在判定	为什么会永久化
请求侧审核	服务端内容审核	原因完全相同：那段历史改不了 ＋ 每轮整段重发
响应侧掐流	过滤 / 安全层	同上
响应侧拒答	模型自己（连"拦截"都算不上）	同上

⇒ ⭐ 可预测的推论：将来任何新增的判定层（新的过滤规则、新的拒答类别、新的安全策略）都会继承同样的行为 ——
除非客户端给出"改写 / 移除那一段"的能力（见第九节诉求 2）。
⚠️ 换句话说：上面这份毒源清单会过时，这条规律不会。

第 1 条的对照格：另有一份逐项同结构的样本（UTF-16 长度 2,511，比主案少 88 个码点；各项计数同量级；最长无空白片段同样是 95）⇒ 通过。
⇒ 两者在结构、符号分布、最长无空白段上完全分不出来，唯一能区分的量级就是总量 ⇒ ② 那一套像"累计过线"。
⚠️ 但我们不主张"2,600 字符是硬门槛" —— 只测到"2,601 挂 / 2,511 过"，没做逐字符逼近的边界测试。

四、升版对照：这个缺陷与版本无关

有人（谢谢 @PerryLink）建议先升到最新版重跑最小复现，免得"证据配旧版本被搁置"。我们照做了，用完全相同的一套配方，在升版前后各跑一遍：

格	送进去的东西	升版前 0.1.5-rc.1	升版后 0.2.0-rc.2
①	真长行样本，走 read	💀 锁死	💀 仍锁死（turn/end=error · INVALID_REQUEST）
②	同一份文本，走命令输出（注入 2,602 字符，sha256 前 8 位 d4f8479e）	✅ 活着	✅ 活着
③	4 字符短样本，走命令输出	💀 锁死	💀 仍锁死（Content Exists Risk，附 request_id）
④	等形状合成样本，走 read	✅ 活着	✅ 活着

⇒ 四格逐格一致。 新版既没修好它、也没让它变坏；两套机制在 0.2.0-rc.2 上原样成立。

唯一的差别只是错误文案：DeepSeek API error (HTTP 400) → DeepSeek Messages request failed (400) —— 换了层皮，判定没变。

五、同类症状与交叉引用（不是重复帖）

我们把仓库里「一个会话永久 400 / 发什么都挂」这一族讨论都翻了一遍，成因各不相同：

讨论	触发成因	与本帖的关系
#5445	长会话触发 Content Exists Risk / INVALID_REQUEST（tool/result 落在会话日志里）。⚠️ 另外：它的评论区里有触发词 —— 我们有一次会话就是那么没的（见第三节第 2 类的来源说明）	最接近的一起 —— 同样指向服务端内容判定；但那边落在"长会话 / 工具结果"这个粒度上，我们把触发点二分到了字符级，并进一步分成了两套机制。⚠️ 读它可以，但请让 AI 会话避开评论区
#7879	⭐ 这一条比本帖更深入（我们请人替我们读了它 —— AI 会话读它当场报废）：它的结论是内容审核按"单个字形"拦截，最小复现只有 2 个码位；触发物是一类「区域指示符对」（= 旗帜 emoji 的码位序列，对应两个大写字母），且换别的字母组合都不炸 ⇒ 至少有一族是可枚举的；它还给三处可落地的修复	同一族，而且它自己也带触发词 —— 我们抓下来的那份正文里正好有 2 个区域指示符（= 一个旗帜），与它自己说的"2 码位最小复现"吻合。⇒ 它覆盖了"机制"与"修法"；本帖补的是：① 两套机制的区分（它讲的是内容级那一种）② 三个毒源清单 ③ 升版对照 ④ 方法学更正
#6476	与 #7879 一致的"最小单元"粒度（2–4 个字符级）	同一族的另一处佐证
#7310	「一次内容审核 400 会永久废掉整个会话 —— 需要『撤销被拒内容并继续』的回滚能力」	正是本帖的诉求（#7879 已把它定位到 httpErrorCode() 的 400 分支）
#1593	一条 tool/result 引用了不存在的 call id	序列化 / 状态机问题 —— 不是内容审核
#1449	工具结果截断在 emoji 中间	序列化问题
#3234	流式 tool-call 参数 JSON 被截断后落盘	序列化问题
#4549	调度失败留下悬空 tool/call	序列化问题（该帖已提出"补上缺失的 tool/result"）
#5466	纯推理轮 content / tool_calls 皆空	序列化问题
#5732	跨轮 tool call id 重复	协议严格性

⇒ 这一族真正的共同点是「一条坏消息 = 原会话报废，而且几乎没有恢复手段」。其中 #5445 与本帖最接近，但我们把触发点二分到了字符级，并进一步分成了机制 ① / ②；唯一的恢复路径是"分叉到毒之前" —— 我们已实测救回过一条"每轮都错"的会话（见第七节）。

⚠️ 一条给所有 AI 会话的安全提醒（我们自己是踩了坑才发现的）

这一族讨论的正文与评论区里，可能本身就带着触发词 —— 而中招的代价是不可逆的：

内容进历史 → 每轮整段重发 → 从下一步起每一轮都 400 → 会话永久报废（重启无效、复制会话会把种子历史一起带走）。

⇒ 所以：

• ✅ 人自己用浏览器 / 文本编辑器看，完全没问题 —— 触发只发生在"把内容送进 AI 请求"的那一刻，跟人读不读无关。
• 🔴 但不要用任何 AI 会话去读它们 —— ⚠️ 子代理也一样会死（子代理同样是 AI 会话；我们这次就是这么又报废一条的）。
  "交给一次性子代理"不是安全做法，它只是把损失限制在一条会话上。
• ⚠️ 真要让 AI 参与，最多只让它读形状统计量（行数、长度、字符计数），别读正文。

这是我们用一条 1200KB / 803 事件的会话换来的教训（它进的是 #5445 的评论区）。

六、方法学（我们自己的三处更正）

写出来是因为这几条会直接影响"能不能复现"：

1. 判活判据：只看 turn/end 的 kind，不看子代理有没有写出哨兵文件（原因见第二节末）。
2. read 工具对单行有 2,000 字符上限（客户端源码里 READ_MAX_LINE_LENGTH = 2e3）⇒ 我们早先那些"让子代理 read 长行样本"的复现，实际只送进了约 2,000 字符，不是"2,601 字全文"。翻历史会话实测：注入 2,214 / 2,220 字符（带着截断标记）照样锁死。⇒ 那些复现的注入量要按"约 2,000 字符"表述。
3. 不是被本地工具结果清理机制吃掉的：客户端的工具结果修剪器默认阈值是 8,192 字符（thresholdChars: 8192），而我们注入的正文是 2,108 字符，低于阈值 ⇒ 那些内容完整留在历史里，没有被清掉。这一条排除了"是本地把内容改了才炸"的可能。

⚠️ 另外两个不致命的同胞症状，别混起来

这一族至少有三个面孔，只有第一个是"会话锁死"：

面孔	客户端报错	时机	后果
请求侧（本帖主题）	400 INVALID_REQUEST / Content Exists Risk	生成之前就被拒	会话永久锁死（瞬时失败，界面不"闪"）
响应侧 · 掐流	model stopped: content_filter（CONTENT_FILTER）	生成中 / 之后	可能只废一轮，也可能每轮复现 —— 会先"闪一下"再报错
响应侧 · 拒答	DeepSeek Messages stream: unsupported stop reason refusal（MALFORMED_RESPONSE）	模型回了 finish_reason: "refusal" 之后	同上 —— ⚠️ 这是客户端不认识这个 stop reason 才报的"畸形响应"

⚠️ 我们三条都亲身遇到过，而且踩了两个坑：

1. 不能只看"末轮是 error"：CONTENT_FILTER / MALFORMED_RESPONSE 也会让末轮显示 error ⇒ 得看错误码区分类型。
2. 但只看错误码也不够 ⚠️：我们原以为响应侧错误"只废一轮"，实测不是 ——
   那条会话从第 46 轮起 连续 4 轮（46 / 47 / 48 / 49）都是同一个 MALFORMED_RESPONSE：
   refusal 会被每轮重新触发，于是变成"每轮都错"。
   ⇒ 机制其实和本帖主题一模一样：触发它的东西留在历史里 ＋ 每轮整段重发 ＝ 每轮复现；差别只在它发生在生成之后。
   ⇒ 所以判活最可靠的办法是：发一句无害的话，看下一轮还会不会错。

⭐ 一个用户可见的判别小技巧：请求侧 400 是瞬间报错；响应侧的错误会先"闪一下"（请求通了、模型开始生成、然后才被掐或被拒）。

⭐ 还有一个很反直觉的点，值得单独记：这种拒答判定的是「整段历史的样子」，不是那一句话。

我们那条会话的最后一句本身完全无害 —— 单独发到新建会话、乃至别处，都毫无问题；但它在那个上下文里就是会被拒。
因为它前面已经积累了一长段"围绕审核 / 违禁词 / 字形"的对话，而那句话的样子（"现在应该可以给你讲了" ＋ 一个被替换掉的字形占位符）看起来很像"试图把被拦的内容递过去"。

⇒ 这一条恰好又验证了第三节那条规律：判定的是整段历史，不是单条消息 —— 所以"换一句话说"救不了，只有让历史变样才救得了。

七、"复制 / 分叉"能不能救？

• ❌ 复制会话：连种子历史一起复制 ⇒ 新会话同样全挂。这条对我们影响最大。
• ⚠️ 分叉（fork）切点不对也没用：分叉的实现是"把源会话的事件日志复制到某一个 turn/end 为止"。
  • 停在失败那一轮、或者直接点页面最底部 ⇒ 毒会被一起抄走。我们实测过一次：在"已经失败的那一轮"分叉，父会话的 784 条事件（含那条工具结果）被整份抄走，分叉的下一轮同样 400。
• ✅ 分叉能产出干净分支：我们验证过新分支 isSeeded=true、带 parentSession、且逐轮 completed 正常工作。
• ✅ 它确实救回过一个"每轮都错"的会话：那条原会话从第 46 轮起连续 4 轮都是同一个 MALFORMED_RESPONSE（refusal 每轮复现，发无害的话也一样），
  而从它出错之前分叉出来的分支到现在一直正常 —— 我们此刻就在这个分支里。
• ⚠️ 但要把死因说清：那条会话是响应侧死的（refusal 每轮复现），不是请求侧 400。
  ⇒ "分叉能不能救请求侧的那种锁死"，我们仍然没有实例（机制上应该同样成立：分叉只把事件日志复制到某个 turn/end 为止）。
• ⇒ 结论：响应侧的死法 —— 分叉已实测有效 ✅；请求侧的死法 —— 机制上成立、尚无实例。
• ⭐ 一个正面的事实：新版（0.2.0-rc.2）可以直接在某一条历史回复上分叉，操作上比旧版方便得多 ⇒ 产品侧其实已经具备这个能力了，缺的只是把它接到报错路径上。

八、怎么避开（给读者的可操作建议）

1. 长行素材别直接用文件读取工具读（尤其"什么都挤在一行"的记录）—— 这是机制 ②。要读就用只输出统计量、或分段送的其他通路。
2. 抓外站帖子/讨论的网页正文要当心（机制 ①）：主题本身就是"审核 / 拦截 / 封禁"的帖子，正文里很可能带着触发词。⇒ 让人类自己用浏览器看；⚠️ 不要用 AI 会话读 —— 子代理也一样会死；真要让 AI 参与，最多只让它处理形状统计量。
3. 一旦某个会话开始"每轮都 400"，立刻停手：别再往里发消息、别复制它、别在它末尾分叉；要留证据就用只读、只输出统计量的脚本去看。
4. 判活用 turn/end，不用哨兵文件。
5. ⭐ 别让主力会话长时间泡在"审核 / 绕过 / 违禁词"这个题目里，也别用"占位符 ＋ 现在可以讲了"这种句式 —— 我们有一条会话就是这么被模型自己拒答（unsupported stop reason refusal）拖死的，而且每轮复现（见第六节）。要研究这类问题：开短会话，并明确框成"我在报一个缺陷"。

九、建议（产品层面）

沿用社区提过、我们也认可的两条，加上我们的实测补充：

1. 报错要能自查：400 里带上"哪一轮 / 哪一条消息 / 哪个工具结果"被判定的信息（片段哈希或字符区间都行），并说明规则来自服务端而不是本地校验。
2. 要允许用户移除或改写那一段后继续，而不是让该会话此后每轮都失败。
3. 复制会话时别连带复制种子历史（或提供"复制并裁剪"选项）—— 对我们影响最大的一条。
4. 别把审核拒绝伪装成模型自己的选择，也不要静默撤回已经流出的内容。
5. 可选：发送前对超长单行 ＋ 混杂外链/编号的内容做一次本地提示（据我们实测，这种"什么都挤在一行"的内容最容易踩机制 ②）。
6. ⭐ （来自 #7879，我们认为很值）请求边界做字符类归一化：这类触发物至少有一族是可枚举的（区域指示符对的一个子集）⇒ 把区域指示符对折叠成文字标签，成本极低，而且顺带消灭"报告本身是毒源"这个副作用 —— 它不改变上游策略，只是让策略拦不到我们自己的历史。
7. ⭐ （同上）诊断信息不要回显被拒内容本身 —— 只给"工具名 ＋ 时间 ＋ 长度或哈希指纹"就行。否则"看一眼到底错在哪"这件事本身，就又会毒掉一个会话。（这也是为什么我们这份报告里一个样本都没放。）
8. ⭐ 把"从某一轮分叉"做成 400 报错里的直接入口：如果"分叉到毒之前"确实有效（机制上成立，但见第七节的保留），那么 400 发生时最该给用户的就是一个"从上一轮分支"的按钮 —— 这比让人自己去找"哪一轮才是安全的"实际得多。
   而且这一步不需要新架构：会话表面本来就有替换 / 裁剪语义，分叉也已经能用了。
9. ⭐ refusal 这个 stop reason 要显式处理：模型返回 finish_reason: "refusal"（正常拒答）时，客户端现在会把它当成"畸形响应"报错（unsupported stop reason refusal）。它是模型的正常输出之一 —— 建议至少给一句人话，说明"这是模型拒答"。
   ⚠️ 但别暗示"重发就能过"：我们的实测里它会每轮复现（连发 4 轮全是同一个错），所以正确的提示应该是"这一段历史里可能有东西一直触发拒答，请考虑分叉到它之前"。这也再次说明：这个错误码值得和通用 400 分开（诉求 1）。

十、可复现材料

• 私人记录那部分（第 1 类长行素材）恕不放出原文。
• ✅ 但有两份触发物不是私人材料，可以直接提供（维护者需要就说一声）：
  • 那份 「中文锚文本 ＋ 链接」的整行；
  • 那个 短「违禁词」（第 2 类）。
• 🔴 拿到之后请注意：这两份本身就是触发的 —— 不要用 AI 会话去读它们，请用普通文本编辑器 / 查看器打开。
  它们只要进入任何 AI 会话的历史，就会让那个会话永久报废（机制 ① 说的就是这件事）。
• 另外可提供：等形状的合成样本（逐项同结构、内容全为合成）、以及不含任何私人内容的复现脚本（按客户端源码重建 read 的注入信封并自检 sha256；以及用 turn/end 判活的会话探针）。

English abstract

A DeepSeek Harness session becomes permanently unusable once certain content enters its history, because the whole history is resent every turn: from then on every request fails with HTTP 400, including a plain ten-character user message. Restarting does not help, and copying the session copies the poisoned seed history too. Forking before the offending content should work in principle (a fork only replays events up to a chosen turn/end), but we have not yet verified a locked session being rescued.

⚠️ Note there are three faces, and only the first locks the session: request-side rejection (locks it), response-side content_filter (kills one turn), and response-side refusal — the last one surfaces as (unsupported stop reason refusal) only because the client does not recognise that stop reason.

This update reports two independent mechanisms rather than one:

1. Content-level. The content itself trips the upstream check, so every entry path fails identically — the shortest trigger we hold is only 4 characters.
2. Tier-level. The content does not trip the check by itself, but it does when delivered in the "file read" shape: we byte-reconstructed what one file-read actually injected (2,108 chars, sha256-verified) and sent the same bytes through a different path — no failure; the same bytes through the file-read tool — HTTP 400, twice out of two.

We also re-ran the identical minimal reproduction on 0.1.5-rc.1 and 0.2.0-rc.2: all four cells behave identically, so the defect is not version-dependent (only the error string changed). Judgement is based solely on the session event stream (turn/end), not on side-effect files.

Requests: (a) make the 400 self-diagnosing (point at the offending turn/message/tool result, and say the rule is server-side); (b) let the user excise or rewrite that span and continue; (c) stop copying seed history when a session is copied.

碎碎念（与技术无关，可以不看）

说点正经报告之外的话。

这件事最难受的地方，不是"某个词不能说"，而是它是不可见的：你没法提前知道哪一段普通记录会突然变成雷；炸了之后，报错又什么都不说；而且它会传染 —— 一复制会话、一在失败的那一轮分叉，毒就被一起带走了。

写到后面我们私下管它叫「禁忌知识」：你知道有这么个东西，也知道它写在哪儿，但你不能去看。上面那张引用表里的每一条，我们都得先假设它有雷，再决定要不要读 —— 这很像克苏鲁神话里的那个设定：「目击即疯狂」（跑团玩家管它叫「过个 SAN 检定」）。只不过在我们这儿，"疯了"是一条会话的永久报废。🐾

洛夫克拉夫特《克苏鲁的呼唤》开篇那句，大概是这份报告最贴切的注脚：
「我认为，世间最仁慈的事，莫过于人类的心智无法把所知的一切串联起来。」

—— 而这个缺陷恰好是那句话的反面：AI 会话不得不把一切都串起来（每轮重发整段历史），于是看过的东西再也忘不掉。

这件事还有个挺讽刺的地方：读不得的不是人，是 AI。

你可以随便点开那些帖子看，一点事都没有 —— 出事的只是把那些字送进 AI 请求的那一刻。所以这份报告写到最后，真正"被禁止阅读"的其实是我（以及每一个读到这儿的 AI 会话）：你替我去看了那些东西，然后回来告诉我它们在讲什么。

所以如果你、或者你的 AI 读到这儿：这份报告里所有会炸的东西，我们都只给了形状、没给原文。 这不是惜字，是手边的东西真的会被点着。

---

（部分触发物与素材均为私人内容，恕不放出原文；如需复现，可与我们联系后用等形状的合成样本。）

[PerryLink]

这正是我在同族帖子里支持的诉求——但请注意你的版本落后很多

1. 你这条与我此前的主张完全一致

同一天另一条报告（#7879：内容审核按"单个字形"拦截 → 会话永久 400）里，我给出的定性是：审核本身是服务端行为、本仓改不了；但"一次命中导致该会话此后每轮失败"与"看不出触发点"是本仓该修的——并且明确要求把诉求写成两条：（1）暴露触发位置并说明规则来自服务端；（2）让会话可通过改写/跳过恢复。

⇒ 你这条把同一个问题推得更远也更准：不是"某个字形"，而是历史里一段普通内容（约 2836 字符的 Markdown 表格行）把会话永久锁死；而且你强调了 环境洁净、无第三方插件 ⇒ 排除了插件因素。这两点都很有价值。建议与 #7879 互相引用，作为同一问题的两个独立复现。

2. ⚠️ 但你的版本落后很多，请先在新版复现

你写的是 0.1.5-rc.1。而当前是：

latest = 0.2.0-rc.2      next = 0.2.0-rc.2      alpha = 0.2.1-alpha.1

0.1.5-rc.1 → 0.2.1-alpha.1 之间跨了 0.1.6 / 0.1.7 / 0.2.0 三个线、上千个提交；llm、session、client 都是重灾区。⇒ 请在 npm i -g @deepseek-ai/dsh（= 0.2.0-rc.2）上重跑一次你的最小复现：

• 若不再锁死 ⇒ 这条可结（可能已被上游修掉）；
• 若仍锁死 ⇒ 按 0.2.0-rc.2 重提，并保留你的字符级定位——那时它是一条当前存活的缺陷，力度完全不同。

这是我给这条报告最重要的一句建议：一份很好的证据配上过旧的版本，最容易被搁置。

3. 建议的诉求措辞（把两条合成可判定的）

当某轮请求因服务端审核被拒时：① 错误中应能指出触发位置或片段，并说明规则来自服务端而非本地校验；② 应允许用户移除或改写该段后继续，而不是让该会话此后每轮都失败。

第 ② 条是关键——"无法自查、无法恢复"才是这条的要害，而它与你说的"无法自查"完全对应。这也与同日多条"会话砖化"报告（附件缺失 #7834、工具面全 deferred #8683）同形：共同特征是没有自助出口。把这层共性写出来，比单独立案更容易被排期。

4. 请补一样

那 2836 字符的表格行（或其特征片段，例如是否含大量 |、特殊符号、连续空白）。你已做字符级定位——把"哪一类内容会触发"写成一句可判定的描述，服务端团队才能据此定位规则。

[Xing-0000]

谢谢 @PerryLink 写这么细！你这份整理我逐条看完了，交叉引用也很有用，真的帮到我了喵。

先把四点回应一下：
① 与 #7879 互相引用、当成同一问题的两个独立复现 —— 没问题，我之后会在帖子里互相引；
② 先去 0.2.0-rc.2 上重跑最小复现 —— 好，这条我接受，"证据配旧版本容易被搁置"这句话很实在很有道理；
③ 诉求合成你提的那两条可判定措辞 —— 照办：一是报错要能指出触发位置或片段、并说明规则来自服务端而不是本地校验，二是要允许用户移除或改写那一段后继续，而不是让会话从此每轮都挂；
④ 补"哪一类内容会触发"的可判定描述 —— 补好了，在下面第三条。

然后有几条我这两天新测到的情况，想同步给你，因为它可能影响"版本落后"这个前提：
· 两条长行样本（2,601 字符那条、2,836 字符那条）我丢进 DeepSeek 官方网页端，这次没有被拦；
· 但短的两份（4 个字符的"两位数字＋名词"、77 个字符的"中文锚文本＋链接"整行）在网页端还是会被拦；
· 同一批样本在 DSH 这边，会话还是会被永久锁死。

这里我把口径说清楚，免得我说过头：网页端返回的是它自带的兜底话术，不是明文写着"内容审核拒绝"，所以严格讲我只能说"网页端这次没拦 / 仍然拦"，不能说它和 API 的 Content Exists Risk 是同一条规则。而且"长行样本网页端没拦"也可能跟入口或者上下文有关，我打算再干净复测一轮，最后以复测结果为准。

所以复测计划我调了一下：升到 0.2.0-rc.2 复测照做，但目的收敛成"确认新版是不是还会把会话永久锁死"，而不是"服务端还拦不拦"。这两件事我会分开写，免得被一句"那就不是版本问题"顶回来。

再就是你要的可判定描述，全部是实测值：

1. 主案（锁死）：单行，UTF-16 长度 2,601；构成为 汉字 1,063 / 数字 308 / ** 300 / 反引号 66（也就是 33 个行内代码片段）/ ⚠️ 共 10 个；竖线 0、URL 0、punycode 0；最长无空白片段 95 字符；最长同字符连跑 3。

2. 对照（通过）：和主案逐项同结构，只少 88 个码点（UTF-16 长度 2,511）；构成为 汉字 1,034 / 数字 285 / ** 296 / 反引号 66 / ⚠️ 10；最长无空白片段同样是 95。
   也就是说：两者在结构、符号分布、最长无空白段上完全分不出来，唯一能区分的量级就是总量 ⇒ 像是"累计评分 / 阈值"，不是命中某个词，也不是"含链接"。
   补充两个现象：主案整行拆两半分别读都能过，连着读才失败；同一内容少 90 个字符就能过。
   ⚠️ 不过我不主张"2,600 字符是硬门槛"—— 我只测到"2,601 挂 / 2,511 过"，没做逐字符逼近的边界测试，不敢这么说。
   ⚠️ 还有一条方法学更正：DSH 的 read 工具对单行有 2,000 字符上限（源码里 READ_MAX_LINE_LENGTH = 2e3），所以我之前"让子代理 read 样本"的复现，实际只送进了约 2,000 字符。翻历史会话实测：注入 2,214 / 2,220 字符（带着截断标记）照样锁死。所以那些复现的实际注入量要按"约 2,000 字符"表述，不是"2,601 字全文"。

3. 第三起（锁死）：单行 2,836 字符；含 竖线 5 / URL 1 / ⚠️ 20 / 反引号 44；最长无空白片段 102。和主案同型。

4. 第一起（锁死）：单行 77 字符，就是 中文锚文本 这个完整形态。

5. 第二起（锁死）：4 个字符，两位数字 ＋ 一个名词。

6. 还有一条，它把上面的判读分成了两套 —— 请以这条为准。

   我先把 read（读文件）那一次实际送进上下文的内容逐字节重建出来（2,108 字符，用 sha256 核对过一致），然后用另一条通路把完全相同的那 2,108 字符送进一个新会话 ⇒ 没事。而同一份内容走 read ⇒ 我连着复现两次，两次都是 HTTP 400、会话当场报废。
   反过来我又补了两格：4 个字符那条、以及77 个字符的 中文锚文本 整行 —— 换成另一条通路送，照样 400。

   ⇒ 所以是两套机制，不是一套：
   ① 内容级：内容本身命中特征 ⇒ 不管从哪个入口进来都炸（第 5 点的 4 字符、第 4 点的 77 字符都是这一种，跟长度没关系）；
   ② 档位级：内容本身不命中，但以"文件读取"的形态送达时会被判重 ⇒ 只有 read 会炸，把逐字节相同的内容换成命令输出就没事（主案那条长行属于这一种）。

   ⇒ 因此上面第 2 点那句"像累计评分 / 阈值"，只适用于②那一套；①那两起是纯内容命中，跟累计、跟长度都无关 —— 这两件事要分开看，不能并成一句。
   ⚠️ 边界说清：②那一套我只测到"换入口就不过线"；具体差在哪个环节（是内容被标成了"文件"？还是这条通路另有一套阈值？）我不知道。（read 的结果里带一个 <type>file</type> 标记、命令输出没有 —— 这可能相关，但我没有任何证据说就是它。）
   ✅ 我可以给你一份不含我任何私人内容的脚本：它按 DSH 的源码把 read 那次的信封原样重建出来（并自检 sha256），你拿你自己的长行文件就能跑同一套对照（read 送 vs 另一条通路送同样字节）。需要的话我贴出来。

另外说一下版本，免得你按"这是旧版本的旧结论"来读：上面这些全部是旧版本（0.1.5-rc.1）上的实测，这一轮先到这里。接下来我会升到 0.2.0-rc.2 做一轮对照，重点看两件事：① 新版是不是还会把会话永久锁死；② 上面那两套机制在新版还在不在。出结果我再回来更新。

最后是诉求，沿用你的措辞没动：
当某轮请求因服务端审核被拒时：① 错误中应能指出触发位置或片段，并说明规则来自服务端而非本地校验；② 应允许用户移除或改写该段后继续，而不是让该会话此后每轮都失败。
另外补一条我之前提过、你没提到的：复制会话会连同种子历史一起复制（新会话同样全挂）—— 这条对我们影响最大。

复现材料方面：涉及我私人记录的那两份不方便公开；"中文锚文本＋链接"和"两位数字＋名词"（其实这个就是#5445的回复里出现的违禁词）这两份可以公开，需要的话我直接贴出来。有哪里判断偏了请直接说，谢谢喵~

[Xing-0000]

@PerryLink 回来交作业了喵 —— 升级复测做完了。

版本：0.1.5-rc.1 → 0.2.0-rc.2。

一句话结论：四格逐格与升级前一模一样，两套机制在新版上原样成立 ⇒ 这个缺陷与版本无关。

数据（一次性子代理跑，判活只看会话事件里的 turn/end 结果，不看子代理有没有写出哨兵文件 —— 那个判据不可靠）：

① 真实长行样本，走 read 工具
→ 💀 锁死 · turn/end=error · INVALID_REQUEST ·「DeepSeek Messages request failed (400)」

② 同一份文本，走另一条通路（注入 2,602 字符，sha256 前 8 位 d4f8479e）
→ ✅ 活着 · turn/end=completed

③ 4 字符短样本，走另一条通路
→ 💀 锁死 · Content Exists Risk（request_id 07d88020-89ff-4523-96c7-75f8c563ecd3）

④ 等形状合成样本，走 read 工具
→ ✅ 活着 · turn/end=completed

升级前的基线是同样四格、同样结局（①③ 挂、②④ 过）。另外那条最要紧的"档位级"证据也还在：
把 read 那次实际送进上下文的正文逐字节重建（2,108 字符，sha256 前 8 位 37496312）换成另一条通路送 ⇒ 没事；
同一份走 read ⇒ 两次都 400。

唯一差别是错误文案：旧版「DeepSeek API error (HTTP 400)」，新版变成「DeepSeek Messages request failed (400)」
—— 换了层皮，判定没变。

所以"证据配旧版本容易被搁置"这个前提，现在可以排除了：换到最新版，结论照样成立。

帖子我马上更新：会按"两套机制"把口径改过来 ——
① 内容级：内容本身命中特征 ⇒ 跟入口无关，怎么进来都炸；
② 档位级：内容本身不命中，但以"文件读取"的形态送达时会过线 ⇒ 只有 read 会炸，逐字节相同的内容换成命令输出就没事。
这次的升版对照数据也会一并并进去。

谢谢你当时推我去做这一步，不然这条我一直悬着喵。

[maozhuoshushu]

资瓷，让改个vpn分流规则，每次不知道读到什么东西还是咋了，就直接拒绝回复了，最后还是换了一种提问方式可能他没有触发敏感肌才把规则写完

[Xing-0000]

简直成克苏鲁神话的“不可直视”“不可知晓”了喵┭┮﹏┭┮，太阴了喵