[Bug] 出站消息含孤立代理(lone surrogate)时 400 无定位信息，且污染历史后会话永久失败不可恢复

[Buddy-LGTM]

报告对象：DeepSeek Harness 官方（github.com/deepseek-ai/deepseek-harness）
DSH 版本：0.2.0-rc.2
组件：@deepseek-ai/dsh-llm-deepseek（约 lib/index.js L1666–L1693）
日期：2026-10-07
严重级别：中高（会话永久不可用，用户无法自救，且错误信息无助于定位）

---

一、摘要

当请求体中任一消息文本含孤立代理项（lone surrogate，如 \uDD16）时，DeepSeek messages 接口返回 400 INVALID_REQUEST。适配器在 buildMessages 阶段已有多重结构校验（tool_call 配对、role 合并等），但没有对文本做 Unicode 合法性校验或清洗，因此：

1. 非法字符原样上线，被服务端拒绝；
2. 报错被统一包装为 DeepSeek Messages request failed (400)，用户与开发者都无法得知真正原因；
3. 更严重的是，坏字符已经写入会话历史，此后每轮请求都会重发它，导致该会话永久失败、重试无效；若污染源来自每轮注入的内容（如动态快照），新开会话同样复发——用户完全无法自救。

二、真实事故（本机完整复现）

背景：第三方记忆插件 @a9i5k4/dsh-auto-memory 用 UTF-16 code unit 计数做截断，把日志里的 🤖（0xD83E 0xDD16）从代理对中间切开，留下 0xDD16，写入了每轮注入的 user-role 动态快照。

现象：

• 会话 session-2c69b355：turn 1–29 全部 completed，turn 30 起每一轮在 step 起点即 400
• 重试同一轮必然失败；用户连续追问（"为什么运行失败了"、"？"）全部失败
• 新开会话 session-fe406bc0（turn 1 step 6）、session-d1b8e194 同样复发

证据：解压会话记录后扫描全部 1,255 个事件：

seq=1216 LONE_SURROGATES=1 -> [{"i":910,"code":"dd16","low":true}]
total events containing lone surrogates: 1

含孤立代理的事件恰好只有 1 个，正是唯一失败的那次请求。

对应的失败事件：

{"type":"assistant/attempt","seq":1251,"time":...,
 "data":{"turn":34,"step":1,"stream":[{"type":"chunk","chunk":{"type":"finish",
 "reason":{"kind":"error","failure":{
   "message":"DeepSeek Messages request failed (400)",
   "code":"INVALID_REQUEST","status":400}}}}]}}

三、问题一：适配器缺少 Unicode 合法性校验

@deepseek-ai/dsh-llm-deepseek/lib/index.js 中，buildMessages 在 L1682–L1693 已做结构校验：

let pending = new Set();
for (const message of messages) if (message.role === "assistant") {
  const calls = message.content.filter((block) => block.type === "tool_use");
  pending = new Set(calls.map((block) => block.id));
  if (pending.size !== calls.length) throw new LlmError("DeepSeek Messages duplicate tool call id", "INVALID_REQUEST");
} else if (message.role === "user") {
  const results = message.content.filter((block) => block.type === "tool_result");
  for (const result of results) if (!pending.delete(result.tool_use_id)) throw new LlmError("DeepSeek Messages tool result has no matching call", "INVALID_REQUEST");
  if (pending.size > 0) throw new LlmError("DeepSeek Messages tool calls need immediate results", "INVALID_REQUEST");
  message.content = [...results, ...message.content.filter((block) => block.type !== "tool_result")];
}
if (pending.size > 0) throw new LlmError("DeepSeek Messages history ends with unresolved tools", "INVALID_REQUEST");

但没有等价的文本层校验。 建议在发送前增加：

// 检出孤立代理并给出可定位的错误
const findLoneSurrogate = (s) => {
  for (let i = 0; i < s.length; i++) {
    const c = s.charCodeAt(i);
    if (c >= 0xd800 && c <= 0xdbff) {
      const n = s.charCodeAt(i + 1);
      if (!(n >= 0xdc00 && n <= 0xdfff)) return i; else i++;
    } else if (c >= 0xdc00 && c <= 0xdfff) return i;
  }
  return -1;
};

并在发现时抛出带定位信息的错误，例如：

DeepSeek Messages message[12] contains a lone surrogate at offset 910 (0xdd16)

这样开发者一眼可知是「哪个消息、哪个偏移、什么字符」，而不是面对笼统的 400。

关于「响应体是否含更详细信息」：DeepSeek 服务端对 400 可能返回了具体原因（如 invalid unicode），但 DSH 当前把它统一包装成 request failed (400)，具体 body 未能透出到会话记录或用户可见界面。建议：

• 在会话日志中保留服务端返回的原始 error.message/body；
• 在 UI 上展示可读原因。这会让本类问题的排查从数小时缩短到数秒。

四、问题二（更关键）：坏内容进历史后不可恢复，且无自愈机制

本次事故最严重的部分不是「一次请求失败」，而是：

• 坏字符被写入会话历史（user/message 事件，带 surfaceOp: "append"），此后每轮请求都会重发整段历史；
• 因此失败永久化：turn 30 之后每一轮都在 step 起点即 400，重试无效；
• 若污染来源是每轮注入的内容（本例是动态快照 runtime-context），新开会话会在下一处同样位置复发。

用户侧完全无解：既不能重试，也不能靠开新会话绕过，且界面上没有任何提示指向真正原因。用户只能放弃整个会话。

建议：

1. 发送前清洗（推荐）：对出站消息做一次 Unicode 规范化，将孤立代理替换为 U+FFFD，并在日志中记录「已清洗 N 处非法字符」。这能让会话自愈而非永久损坏。
2. 或拒绝并给出可操作提示：明确告知「第 X 条消息含非法字符，建议开启新会话或使用 /compact 清理历史」，而不是笼统的 400。
3. 压缩/裁剪路径也应接入同一清洗：dsh-compaction-basic、dsh-compaction-tool-result-pruner 在处理历史时若同样按 code unit 切分，也会引入同类坏字符。建议在其出口统一清洗。

五、问题三：注入时机的健壮性（相关但独立）

排查中还观察到：动态快照（runtime-context）由 dsh-agent-loop 的 preStep()（L902–925）在每个 step 开头生成，并以 user/message 追加（L917 [...claimed, context]、L1061 落盘）。当上一步刚以 tool/result 结束时，序列为：

assistant(tool_calls) → tool(result) → user(runtime-context snapshot)

在适配器 L1673–1675，tool 消息在 wire 上映射为 user 角色，且相邻同 role 消息会被合并：

const wireRole = message.role === "tool" ? "user" : message.role;
const previous = messages.at(-1);
if (previous?.role === wireRole) previous.content.push(...content);

二者合并后，L1688–1691 的 tool_result 配对校验在边界情形下会更脆弱。

说明：本次事故的直接原因是非法 Unicode（已用全切点穷举证明：27,234 个切点中仅 1 处产生坏字符，且与失败请求中的 0xdd16 逐位一致）。上述时机问题不是本次直接致因（实测同一模式下有 24 次「快照紧跟 tool/result」均正常），但它降低了系统的容错度——一旦文本层出问题，这个位置更容易放大为整轮失败。建议一并考虑：快照不宜插入 tool 结果与下一个 assistant 之间。

六、复现步骤（最小）

1. 任意途径让会话历史中出现一条含孤立代理的消息。可用插件注入（本例），或在自定义工具输出中返回：

"\uDD16"     // 孤立低代理

2. 该内容进入 user/message 并落盘；
3. 下一轮请求即返回 400 INVALID_REQUEST；
4. 此后每一轮都失败，重试无效；
5. 若该内容来自每轮注入，新开会话仍会复发。

验证脚本（检出会话中的孤立代理）：

import { readFileSync } from "node:fs";
const text = readFileSync(transcriptPath, "utf8");
let n = 0;
for (let i = 0; i < text.length; i++) {
  const c = text.charCodeAt(i);
  if (c >= 0xd800 && c <= 0xdbff) {
    const x = text.charCodeAt(i + 1);
    if (!(x >= 0xdc00 && x <= 0xdfff)) n++; else i++;
  } else if (c >= 0xdc00 && c <= 0xdfff) n++;
}
console.log("lone surrogates:", n);

七、附带发现的排查障碍（建议改进）

排查本次问题耗时较长，主要卡点如下，建议一并优化：

1. 会话记录格式不便读取：~/.dsh/sessions/<ws>/<sid>/session.v4.jsonl.zstd 是多帧串联 zstd（一个事件一帧），zlib.zstdDecompressSync(整文件) 只能解出第一帧（约 200 字节的会话头）。需扫描 magic 28 B5 2F FD 逐帧解压才能拿到全文（实测大会话 708 帧 / 5.2 MB）。
   → 建议：提供官方导出/查看命令（如 dsh session export --jsonl），或提供带帧遍历的解压工具。

2. 错误信息缺上下文：request failed (400) 未附带服务端 body、消息索引或字符偏移。
   → 建议：错误中包含服务端原始信息 + 定位。

3. 无「历史体检」入口：污染后用户无法自查。
   → 建议：提供 dsh session doctor <id> 之类命令，扫描孤立代理/未配对 tool_call 等结构问题并给出修复建议。

---

附：本次事故的处理与验证（供参考）

用户侧已通过修补插件解决（详见 BUG报告_记忆插件_emoji截断_20261007.md），补丁后验证：

• 真实日志 27,234 个切点全穷举：裸 slice 1 处产生孤立代理，安全截断 0 处
• 合法文本零损伤（逐字节相同）、emoji 原样保留、幂等
• node --check 通过

但对 DSH 而言，根因在于「出站文本未做 Unicode 校验/清洗」——即使第三方插件修好，任何自定义工具输出、MCP 返回、文件读取都可能引入同类字符。建议在适配器层做统一防御。

[PerryLink]

这是第三条"一处坏输入 ⇒ 会话永久失败"的报告——建议把它作为一类问题提

1. 我核过的同族前两条（可引用）

帖	坏输入	后果
#7834	附件对象在磁盘上缺失	该会话每一个请求都失败，且被误报为 TRANSPORT（实测 HTTP 请求数为 0）
#7879	内容审核命中（按字形）	该会话此后每轮 400
你这条	消息文本含孤立代理项	400 INVALID_REQUEST，污染历史后永久失败不可恢复

⇒ 三条的形态完全一致：一个per-message 的缺陷在"请求组装"阶段被检出 ⇒ 整批被拒 ⇒ 而历史里那条坏消息永远修不掉 ⇒ 会话砖化。建议你在报告里点明这层共性——它把"某个 surrogate 没处理"提升为"宿主缺少可恢复性"，后者更容易被排期。

2. 你的两条诉求都对，建议按这个顺序写

1. 可定位：400 应当指出哪条消息、哪个位置、哪个码位（U+xxxx）。现在"无定位信息"意味着用户只能盲改；
2. 可恢复：允许移除/替换那条消息后继续，而不是让会话永久不可用。

第 2 条比第 1 条重要——因为第 1 条只是少走弯路，第 2 条决定用户是否还能用这个会话。

3. 请补三样（决定修在哪一层）

1. 那条 400 的响应体原文（含任何 code/param 字段）；
2. 那个孤立代理项的来源：用户输入？工具结果？还是插件注入？（来源不同，修的地方完全不同——历史上另有一条同类报告是第三方插件注入的消息导致的格式拒绝，见 #9099）；
3. 一个最小复现：一条只含 \uDD16 的消息（你已给出码位，很好，请保持 U+ 形式）。

4. 关于你引的 lib/index.js L1666–L1693

你写"适配器在 buildMessages…"——我这里无法核对构建产物的行号（我没有装你那个版本）。请把那段代码本身贴进正文（符号名 + 片段），而不是只给行号：本轮我已多次见到"产物行号与源码行号存在固定偏移"的情况（另一位报告者独立复核出偏移 176），只给产物行号会让维护者多绕一步。

5. 版本提醒（本轮基线）

HEAD = origin/master = 5badb15009 = dsh-v0.2.1-alpha.1
npm: alpha = 0.2.1-alpha.1    next = 0.2.0-rc.2    latest = 0.2.0-rc.2

你在 0.2.0-rc.2 上 ⇒ 属当前发布线。⚠️ 注意 npm 的 latest 不再是旧的 0.1.5-rc.3（那是几周前的情况）。

一条边界

我确认的是同族前两条的存在与形态（足以支撑"这是一类可恢复性缺陷"的框架）。你这条的具体成因（孤立代理项在 buildMessages 哪一步、是否被转义）我没有核对——那需要第 4 节那段代码。

[xiaoshenming]

@Buddy-LGTM 补一条「能不能自救」的实测答案，外加一个对你这个案例特别要紧的边界。

1. 这个形状可以离线修，不必等上游。 落盘的坏东西是那个孤立代理项（你那份 seq=1216 的 \uDD16），修法是把不成对的 code unit 换成 U+FFFD（�）—— seq 与事件数一个不动，只动那一个字符。我们这边（dsh-session-surgeon）有现成的 lone-surrogate 那条；测试断言修完事件数不变、seq 仍连续。

代价得说清楚：这是改内容的修复，被从中间切开的 emoji 会变成 �（🤖 只剩半个代理对，救不回来）。你要的是「这个会话还能用」，这个代价通常值；但它不是无损的。

2. 只修日志对你这个案例不够 —— 必须先停注入源。 你自己那句判断是对的：坏字符来自 @a9i5k4/dsh-auto-memory 每轮注入的动态快照。所以就算把 seq=1216 洗干净，下一轮注入又会写一条新的坏行（你观察到的「新开会话同样复发」就是这个）。顺序应该是：先修那个插件的截断（按 code point 切，不要按 UTF-16 code unit 切）→ 再修已有日志；反过来做会陷入「修完又坏」。

3. 这个形状不是新的：2026-08-23 就有同族报告（#436），实测表现就是「孤立代理项进历史 → 此后每个请求 400」。所以 PerryLink 说的「当一类问题提」我同意，而且这一类里已经有一条可用的离线恢复路径。

4. 上游那两条我同意你的排序，再补一条低成本的：buildMessages 在发出前对文本做一次 Unicode 合法性校验，比等服务端 400 回来更早也更可定位。现成的就是 String.prototype.isWellFormed() / toWellFormed()（Node 20+，本机 v24 实测可用）：

'a\uDD16'.isWellFormed()   // false
'a\uDD16'.toWellFormed()   // "a�"   ← 与我们离线修的替换一致

顺带一句：toWellFormed() 的替换结果和我们离线修出来的完全一样（都是 U+FFFD），所以「线上先兜住 + 历史离线修」不会产生两种不同的形态。