[Bug] 工具输出中的孤立代理项会让会话永久 400，且用户看不到原因、也没有恢复路径

[XEMPZ]

Summary

任何进入会话历史的非 well-formed 文本（典型来源：把二进制数据按 UTF-16 解码，得到的孤立代理项 U+D800–U+DFFF）都会随历史进入之后的每一次模型请求。JSON.stringify 把孤立代理项输出为 \udXXX 转义：JSON 文本本身合法，但它不是合法的 Unicode 标量值，服务端会直接拒绝整个请求体的解析并返回 400。

由于会话日志只追加、该事件永久留在历史里，这个会话之后的每一轮请求都必然失败，且产品内没有任何恢复手段，任务就此报废。

用户看到的只有一句 DeepSeek Messages request failed (400)。真实原因被丢掉了：服务端对这类失败返回的是 text/plain 而不是 JSON 错误信封，providerError() 因此取不到 error.message，回退成通用文案。

Reproduction

A. 产品内最小复现

1. 新建会话，让任意工具返回一段含孤立代理项的文本。最直接的构造：

// run_code：把二进制数据按 UTF-16LE 解码
console.log(Buffer.from([0x3e, 0xdc]).toString('utf16le')) // U+DC3E

真实场景同样容易触发：读取 UTF-16 编码的二进制日志/文件、以错误编码抓取子进程输出等。本次事故的真实触发就是：

const buf = await fs.readFile(logPath)
for (const enc of ['utf16le', 'utf8']) console.log(buf.toString(enc).slice(0, 1500))

2. 该工具结果被写入会话事件（本次为 tool/result seq 2923，工具 run_code，callId call_00_vcdTPpSaByYwBlFnBSsm8826）。
3. 在该会话里发送下一条消息。
4. 此后每一轮都是 400。切换模型不会改变历史内容（被污染的事件仍在其中），任何同样拒绝这类码位的路由都会继续失败；重启客户端、重开会话也不能恢复——污染事件已经持久化在会话日志里，重开会话只是重新加载同一段历史。

B. 供应商侧最小复现（不经过 harness）

curl -sS https://api.deepseek.com/anthropic/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $DEEPSEEK_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model":"deepseek-v4-flash","max_tokens":8,"messages":[{"role":"user","content":[{"type":"text","text":"x \udc3e"}]}]}'

实测结果（响应正文逐字）：

HTTP 400 | content-type: text/plain; charset=utf-8
Failed to parse the request body as JSON: messages[0].content[0].text: lone leading surrogate in hex escape at line 1 column 113

把 \udc3e 换成 \ufffd（U+FFFD）或普通文本，同一个请求返回 200。变量已隔离。

Current behavior

会话 session-b48acc80（会话格式 v4）中的实际序列：

seq	事件	结果
2922	tool/call run_code：把二进制日志按 utf16le 解码	—
2923	tool/result：正文含 54 个孤立代理项（U+DC3E、U+DBE8、U+DF76、U+D8D1 …）写入历史	污染点
2925 → 2926	step/start → assistant/attempt	finish.reason = error，INVALID_REQUEST / 400
2928	turn/end turn 19	error
2934 / 2942	用户两次重试「继续」	同样 400

请求在解析请求体阶段即被拒绝，未到达模型；失败是亚秒级的（本次三轮分别为约 0.4 s / 0.4 s / 0.7 s），与重试、限流、上下文长度都无关。

对会话日志逐字节扫描后确认：整个会话中只有 seq 2923 这一条记录含孤立代理项，共 54 个码位单元；它出现的位置正好在首次 400 的那一步之前，而该步之前的请求全部成功。

Expected behavior

1. 不可编码的文本不应该能让会话彻底不可用。 请求构造处应对文本做 well-formed 归一化（把落单的高/低代理半区替换为 U+FFFD），使请求体始终可被服务端接受。模型本来就无法接收这类码位，归一化对模型没有信息损失，而且是幂等的。
2. 服务端返回非 JSON 错误体时应透出原文。 text/plain 的响应体里带着唯一可诊断的信息，现在被回退文案吞掉了；用户只看到 (400)，无法据此做任何判断或自救。
3. 已被污染的历史应能在产品内恢复。 现在唯一的恢复方式是离线解密、改写 .jsonl.zstd 会话日志再写回（本次事故就是这样才救回来的）。对终端用户这条路径不存在，等于数据报废。

Environment

• 产品：DeepSeek Harness 桌面版 0.2.0-rc.2（FileVersion 0.2.0-rc.2，ProductVersion 0.2.0.0）
• 源码检出：deepseek-ai/deepseek-harness @ 639ed01（release-dsh-0.2.0-rc.2）
• 运行时：随附 Node v24.21.0
• 平台：Microsoft Windows 10 专业工作站版 | Build 19045 | 64 位
• profile：desktop；工作目录 E:\Agent测试；会话格式 v4
• 路由：provider deepseek-account，model deepseek-flash，endpoint https://api.deepseek.com/anthropic/v1/messages，anthropic-version: 2023-06-01

影响面

• 触发门槛极低：不需要用户做任何异常操作——任何工具把二进制数据按 UTF-16 解码、或任何产生落单代理半区的输出，都会污染历史。
• 后果不可逆：会话日志只追加，被污染的事件永久保留；该会话的每一条后续消息都失败，用户既无法继续、也无法删除那条历史。
• 完全不可诊断：产品只显示 (400)，用户无从知道是内容问题。
• 只影响被污染的会话，不影响其他会话或新会话。

根因定位

请求构造处没有做 well-formed 归一化，文本原样进入 wire：

• packages/llm/llm-deepseek/src/serialize.ts:30 — assistant 的 text 块：return { type: 'text', text: block.text }
• packages/llm/llm-deepseek/src/serialize.ts:65 — 用户 / 工具结果的 text 块：return block.text ? [{ type: 'text', text: block.text }] : []

注意 llm-deepseek-account（provider deepseek-account）与 llm-deepseek-api-key（provider deepseek-official）都只负责鉴权与配置，各自调用 @deepseek-ai/dsh-llm-deepseek 的 registerDeepSeekProvider，共用这一份 serialize.ts；因此两条 DeepSeek 路由同时受影响，修一处即可覆盖两条。

错误信息被吞掉的位置：

• packages/llm/llm-deepseek/src/transport.ts:25 — const message = typeof error.message === 'string' ? error.message : 'DeepSeek Messages request failed (' + status + ')'
• packages/llm/llm-deepseek/src/transport.ts:33 — status === 400 映射为 INVALID_REQUEST

响应体是 text/plain; charset=utf-8、JSON.parse 失败，envelope.error 为 undefined，于是回退文案生效，服务端原文被丢弃。

仓库内其实已经识别过这一类危险：packages/core/tools/src/py-types.ts:191 附近明确注释了「Python 源码必须 UTF-8 可编码，而落单代理项不是，compile() 会抛 UnicodeEncodeError: surrogates not allowed」，并对不可打印字符与 U+D800–U+DFFF 落单半区做了转义处理。同样的规则没有覆盖模型 wire 这条路。

建议修复

1）请求构造处做 well-formed 归一化（必需）

在 serialize.ts 里对每个出站字符串统一归一化，例如在构造 WireBlock / WireInput 的唯一入口处调用 String.prototype.toWellFormed()（engines 为 ^22.19 || >=24，可用），或按 py-types.ts 的既有做法显式替换落单半区为 U+FFFD。

放在发送时而不是写入会话事件时有一个额外好处：已经中毒的既有会话在恢复时会自动痊愈，不需要人工改写日志。代价是日志本身仍保留不可编码文本，与「Model-visible ⟺ logged」不冲突（模型看到的是 U+FFFD，归一化是确定性的）。若更希望日志本身不含不可编码文本，则应在工具结果进入会话事件时归一化，但那样无法自动修复既有会话；两者可以都做。

2）非 JSON 错误体回退到原文（必需）

transport.ts 在缺少 JSON 信封时，应把响应体原文（截断到合理长度）并入错误消息，而不是只回 (400)。本次问题之所以对用户完全不可诊断，就是这一步。

3）提供产品内恢复路径（建议）

一旦历史被污染，用户目前无路可走。任何形式的回退 / 剪枝 / 修复入口都能把「任务报废」降级为「损失一轮」。

4）无密钥回归覆盖（建议）

在 snapshot 或 e2e 中固定一条「工具结果含孤立代理项」的用例，断言出站请求体不含任何不可编码码位且不被服务端拒绝。

---

说明：本报告只包含最小化技术证据；会话正文与业务内容未附。会话 id 仅用于可追溯，可删除。

[dounai2333]

Bump, 已遇到同款问题, 尝试直接读取一个程序的错误 minidumps 时可以稳定触发, 必须再发起1次新对话, 并在新对话中告知原因 (或告知其阅读此 Discussion) 让其进行修复才可解决.
触发问题的最后1轮中, DeepSeek-V4.1-Flash 生成的脚本, 修改路径后可用于复现:

const fs=await import("node:fs");const NL=String.fromCharCode(10);
const fp="G:/Users/13286/AppData/Local/CrashDumps/cstrike-online.exe.23860.dmp";
const fd=fs.openSync(fp,"r");
const head=Buffer.alloc(12*1024*1024);
const got=fs.readSync(fd,head,0,head.length,0);
fs.closeSync(fd);
const b=head;
console.log("read "+got+" bytes header");
const n=b.readUInt32LE(8),r0=b.readUInt32LE(12);const st=[];for(let i=0;i<n;i++){const o=r0+i*12;st.push({type:b.readUInt32LE(o),size:b.readUInt32LE(o+4),rva:b.readUInt32LE(o+8)});}
const mods=st.find(x=>x.type===4);
console.log("module stream: size="+mods.size+" rva=0x"+mods.rva.toString(16));
const cnt=b.readUInt32LE(mods.rva);
console.log("count="+cnt);
const rows=[];
for(let i=0;i<cnt;i++){const o=mods.rva+4+i*108;
 const base=b.readBigUInt64LE(o), size=b.readUInt32LE(o+8);
 const nrva=b.readUInt32LE(o+32);
 let nm="?"; try{const nlen=Math.min(b.readUInt32LE(nrva),520); nm=b.toString("utf16le",nrva+4,nrva+4+Math.max(0,nlen-2));}catch(e){nm="ERR";}
 rows.push(base.toString(16).padStart(8,"0")+" "+size.toString(16).padStart(7,"0")+"  "+nm.split("\\").pop());}
console.log(rows.join(NL));```

[xiaoshenming]

这个形状我们一直在覆盖（#436 那一族），正好给你实测结论和一条恢复路径。

为什么「看不到原因」——我复现了「文件能打开」这一半

拿一份真实的 184 事件 v4 日志，按你的描述污染（在一条 tool/result 的文本里加 U+DC3E）后实测：

• 两个官方读盘闸门都接受这份文件：assertReleasedV4Relationships（关系折叠）与 Session.fromRestore（seed 构造）都不报错 → 加载阶段没有任何提示，所以产品里看不到原因；
• 但 JSON.stringify 把孤立代理写成 \udc3e 转义，请求体在服务端解析失败 → 之后每轮 400。API 侧那段是你 curl 实测的，我这边没有复现（未验证）。

恢复路径：用 dsh-session-surgeon 离线改 session.jsonl.zstd。

1. 先停掉写者（关掉那个会话/客户端），别边写边改；
2. dsh-session-surgeon inspect <会话 id> —— 现在会直接点出是哪一行：
   isolated UTF-16 surrogate in seq 25 (tool/result) — JSON.stringify escapes it and the provider rejects every later request body (HTTP 400, #8466); repair replaces it with U+FFFD
   （这条是本轮刚补的：以前只说 isolated UTF-16 surrogate in payload，不说在哪一行 —— 你报告里 seq 2923 / tool/result 这种定位正是原来缺的那块。）
3. dsh-session-surgeon repair <会话 id> 先看 dry-run，确认后再加 --apply（会先写 .bak.<utc>）。

修复把每个孤立代理替换成 U+FFFD：seq、事件数、其余正文都不动；修完复测过 —— 代理转义 1→0、seq 连续、上面两个官方闸门仍然接受。代价是那个字符变成 U+FFFD（它原本就不是合法文本，没有可还原的原文）。

顺手补的两处：面板以前对健康码 lone-surrogate 完全没有文案（徽标直接显示原始码，提示回退成通用文案），现在中/英/荷三份都有说明，并加了测试断言 HEALTH_RANK 里每个码三语都有文案 —— 和 torn-tail、foreign-version、header-parse-error、retired-fields 一起补的。

一处边界：如果代理落在 header（Windows 上目录名可以带不成对代理，而 header 记着 cwd），我们只报告、不改写 —— 就地改 cwd 会让日志离开命名它的那个目录；那种情况的修复是重命名目录，不是改文件。以前这里会留下「inspect 说坏、repair 说没事」的死角，现在消息里会写明。

安装/更新：桌面端「插件」页 → dsh-session-surgeon → 更新（等价 cd ~/.dsh/profiles/desktop && pnpm update dsh-session-surgeon）。本轮改动在 498fd37。