[BUG] 工具输出含未配对 UTF-16 代理项会让整个会话永久 HTTP 400（错误信息无法诊断）

[yu633]

环境

• DSH 0.1.5-rc.1（Windows 11），provider deepseek-official，model deepseek-flash
• 同时核对了 npm 上最新发布版 0.2.0-rc.2（2026-09-29）：同样没有相关处理（见文末）

现象

一个约 50 轮的长会话，从某一轮开始，之后每一轮都在 200–300ms 内失败，UI 只显示：

本轮运行失败：DeepSeek API error (HTTP 400)

只发「你好」也一样失败，刷新页面、换措辞都无效——会话实际已不可用，且报错完全没有指向性。

根因

工具输出（tool/result）文本里混入了一个未配对的 UTF-16 代理项。

来源是很常见的写法——对含 emoji 的字符串按码元截断：

const line = "1234567890🔴";   // 🔴 = U+1F534 = D83D DC34
line.slice(0, 11);             // 在第 11 个码元处切断 → 末尾留下孤立的 \uD83D

这个孤立代理随 tool/result 写入会话后：

1. 适配器序列化请求体时，JSON.stringify 把它写成 \ud83d 转义；
2. DeepSeek 的 JSON 解析器拒绝该转义，返回 400，且响应是 Content-Type: text/plain；
3. dsh-llm-deepseek 的错误处理只从 JSON.parse(body).error.message 取文案（0.2.0-rc.2 里是 const text = await response.text(); try { raw = JSON.parse(text) } catch {}），遇到 text/plain 就退化成通用文案，用户看不到真正原因；
4. 该事件已在会话 surface 上，之后每一次请求都携带它 → 永久失败。

压缩也救不了：压缩/摘要请求本身同样带着这段历史，而且 web profile 里 compaction-basic、command-compact、tool-result-pruner 默认是 disabled。

最小复现（不依赖 DSH）

POST https://api.deepseek.com/chat/completions
Content-Type: application/json

{"model":"deepseek-flash","messages":[{"role":"user","content":"A\ud83dB"}],"max_tokens":16,"stream":false}

实际返回：

HTTP/1.1 400
content-type: text/plain; charset=utf-8
x-ds-trace-id: 1023278350278cb45f454bba42afa15f

Failed to parse the request body as JSON: messages[0].content: unexpected end of hex escape at line 1 column 72

对照组（成对代理、合法 emoji）返回 200，说明只与「未配对」有关，与 emoji 本身无关：

{"model":"deepseek-flash","messages":[{"role":"user","content":"A\ud83d\udd34B"}],"max_tokens":16,"stream":false}
→ 200 application/json

为什么值得修

• 一个码元就能把整个会话钉死，且用户可见信息零指向性，排障成本极高；
• 触发路径是 agent 的正常写法（slice(0, N) 截断工具输出），不是用户误操作；
• DSH 自己在别处已经承认了这个风险类别：dsh-tools 里有 LONE_SURROGATE = /[\ud800-\udfff]/gu；dsh-compaction-tool-result-pruner 专门按 Unicode 码点切片并注明 "so a retained boundary cannot split a surrogate pair"。缺的只是 append / transport 层的兜底；
• 换任何走 JSON 的 provider（Messages / OpenAI 风格协议）同样会中招。

建议修复（两处，改动都很小）

1. append 层规范化（更彻底）：dsh-util-values 的 walkJsonValue 对 typeof current === "string" 是原样 assign。而该函数的文档说明它会拒绝「非无损 JSON」（BigInt、循环、稀疏数组、-0、特殊原型）——未配对代理正好是无法经 UTF-8 往返的字符串，属于同一不变式的漏项。建议在字符串分支把未配对代理规范化为 U+FFFD。规范化比拒绝更安全：不会让工具调用直接失败，且改这一处之后会话日志、日志导出、所有 provider 一起干净。
2. 错误体解析：非 JSON 的 4xx/5xx 响应应把截断后的原文透出（例如 DeepSeek API error (HTTP 400): <body 前 N 字符>），否则任何网关/解析层的 400 都会退化成同一句无用文案。
3. 顺带：这个 400 在 API 侧返回 text/plain 而非 JSON 错误体，客户端无法结构化解析，建议官方一并看看。

临时绕过（已验证）

向会话日志追加一条 replacement 事件即可恢复：复制原 tool/result 的 data，把文本里的未配对代理换成 U+FFFD，以新 seq 追加，并带

{ "sourceEventSeqs": [<原 seq>], "surfaceOp": { "op": "replace", "startSeq": <原 seq>, "endSeq": <原 seq> } }

（与 tool-result-pruner 使用的机制一致。）重新打开会话后即可继续。我这边用这个方法把那个 50 轮会话救回来了，并回放验证过修复后的请求返回 200。

影响版本

已核对 0.2.0-rc.2 的 dsh-llm-deepseek 与 dsh-util-values：grep surrogate|D800|FFFD|isWellFormed 均 0 命中，问题仍在。

---

TL;DR (English)

An unpaired UTF-16 surrogate anywhere in a tool/result text (e.g. produced by str.slice(0, N) cutting an emoji in half) is serialized as a lone \uD83D escape. The DeepSeek endpoint rejects the whole body with HTTP 400 and a text/plain body, and since providerError() only reads a JSON error.message, the UI collapses it to DeepSeek API error (HTTP 400). Because the poisoned event stays on the session surface, every later turn in that session fails permanently. Fix suggestion: normalize unpaired surrogates to U+FFFD in dsh-util-values's string branch (the same lossless-JSON invariant it already enforces for BigInt/circular/-0), and surface non-JSON error bodies. Still present in 0.2.0-rc.2.

[yu633]

另记一个不相关的独立缺陷（已单独开帖，便于跟进）：新建会话 / “在新窗口继续”产生的会话不会 attachSession 到工作区，而 bootstrap() 的孤儿收编只在注册表首次初始化时执行一次，于是这些会话在其它客户端的工作区列表中完全消失（本进程内仍可见，容易误判为数据丢失）。

→ #8405

[xiaoyuyu6420]

根因分析很完整（那个按码元 slice 的惯用法确实是常见来源）。补一条给已经被锁死会话的用户的恢复路径——坏的是一行 tool/result，行级手术就能救，不需要重编号：

1. 老三样：停 dsh 进程、整个 session 目录拷一份留底；
2. 定位：解压日志（zstd 帧逐个解），逐行 JSON.parse 后按 code unit 扫孤立代理——高位代理 [\uD800-\uDBFF] 后面不跟低位代理 [\uDC00-\uDFFF]（或反之）即命中。直接在解压后的 JSON 文本上跑正则也行，但先 parse 再扫更稳（转义形态不会骗过你）。命中的行就是那条 tool/result；
3. 修：把孤立代理替换成 U+FFFD（替换符）或直接删掉该字符——语义上这是被截断的半个 emoji，本来就不该在；
4. 该行在哪个 zstd 帧就只重编那个帧，其余帧字节不动；
5. 放回前对全文件再跑一遍孤立代理扫描（应 0 命中）。

另外给排查者的一个提醒：provider 侧差异可以当临时逃生门——DeepSeek 的 JSON 解析器拒孤立代理转义，但不是所有 provider 都拒（同族的 #3315 有跨 provider 实测）。不过换 provider 只是绕过，日志里那颗雷还在，下次换回来还会炸，文件级清理才是根治。

上游修复方向你文末应该已经隐含了：tool/result 入库前对文本做一次「配对代理合法性」清洗（或至少 serialize 时把孤立代理替换成 U+FFFD），比让每个 provider 各自硬扛要对。