[Bug] 会话历史含孤立代理项（JS .slice() 切断 emoji 代理对）后，dsh-llm-deepseek 所有请求被 API 以 HTTP 400 拒绝，且错误文案无法定位根因 #967

lutaikang · 2026-08-14T05:54:12Z

lutaikang
Aug 14, 2026

摘要

当会话历史中出现孤立 Unicode 代理项（例如一行文本被 JS String.prototype.slice() 按 UTF-16 码元截断，把 emoji 🔍 U+1F50D 的代理对 \ud83d\udd0d 拦腰切断、只保留高代理 \ud83d）时，deepseek-official 适配器（dsh-llm-deepseek）会把它原样序列化进请求体，DeepSeek API 的严格 JSON 解析器随即以 HTTP 400 拒绝整个请求。由于该字符永远留在历史里，该会话从此所有请求（包括之后新开的 turn）确定性失败；新建会话则完全正常。且 400 响应体不是标准错误信封，客户端只能看到通用的 DeepSeek API error (HTTP 400)，无法自行定位。

环境

DeepSeek Harness（@deepseek-ai/dsh 0.1.0-rc.6，Web GUI 模式；适配器包 dsh-llm-deepseek）
Provider：deepseek-official，请求直达 https://api.deepseek.com/chat/completions
Model：deepseek-v4-flash（deepseek-v4-pro 走同一 API/解析器，应同理——未实测）
请求参数：thinking: {type:"enabled"}、reasoning_effort: "max"、max_tokens: 256000、stream: true —— 这些参数本身均被官方 API 接受（已实测 200）

现象

长会话（多轮工具调用）在某一步之后，所有后续请求（含之后新开的 turn）立即返回 HTTP 400，错误文案为通用的 DeepSeek API error (HTTP 400)，code INVALID_REQUEST，无任何服务端细节。
与请求时间、上下文大小无关：曾以约 233K tokens 上下文、在约 8 分钟内连续 10 个 turn 全部失败（当地时间 12:37:21 首次失败 → 12:45:09 最后一次）；同一配置的新会话立刻成功。
会话记录中可定位：首次失败前的最后一条工具结果（seq 127107）第 476 字符处含孤立代理项 \ud83d（位于表格行 ...| Docker 任务自动触发 | \ud83d 处）。

根因（已逐层实测验证）

毒字符来源——程序内切片切断代理对：失败会话某一步的 run_code 程序（模型编写）对 grep 结果逐行执行 m.line.slice(0, 120)。JS 字符串按 UTF-16 码元切片，而行内 emoji 🔍（U+1F50D = \ud83d\udd0d）恰好跨越第 119/120 个码元：slice(0,120) 只保留高代理 \ud83d，丢掉低代理 \udd0d → 输出孤立代理项。
- 已按磁盘源文件逐码元核算：该行 🔍 的起始码元为 119，slice(0,120) 必中（119 < 120 < 121）。
- 磁盘源文件从头到尾完好（emoji 完整），毒字符是程序内切片产生的，与文件写入时序无关。
传递：工具结果原样进入会话历史；会话持久化层（dsh-session-persistence-jsonl）按 UTF-16 码元保留孤立代理项（源码注释明确 "Operating on code units preserves lone surrogates"）；dsh-llm-deepseek 的 serializeMessages/serializeRequest 直接 JSON.stringify，无消毒。
触发：Node JSON.stringify 把孤立代理项输出为 "\ud83d" 转义序列；DeepSeek API 的严格 JSON 解析器拒绝该转义 → HTTP 400。
错误不可见：该 400 响应体是裸文本 Failed to parse the request body as JSON: ...（不是 OpenAI 风格 {"error":{"message":...}} 信封），适配器 index.js 中 (await response.json()).error 解析失败，回退到通用文案 DeepSeek API error (HTTP 400)，用户无法定位。

最小复现（已实测）

# ① 含孤立代理项 → 400（必现）
curl https://api.deepseek.com/chat/completions \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"deepseek-v4-flash","messages":[{"role":"user","content":"hello \ud83d test"}]}'
# => 400  Failed to parse the request body as JSON: messages[0].content: unexpected end of hex escape at line 1 column 80
#    （列号与 JSON 序列化时的空白有关，随请求体格式变化；关键在 "unexpected end of hex escape"）

# ② 对照组（去掉 \ud83d）→ 200（实测通过）
curl https://api.deepseek.com/chat/completions \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"deepseek-v4-flash","messages":[{"role":"user","content":"hello test"}]}'
# => 200

\ud83d 即 Node JSON.stringify 对孤立高代理的标准转义，也就是 DSH 适配器实际发送的内容。① 的复现同样在携带 thinking/reasoning_effort/max_tokens:256000/stream 参数时成立。

建议修复

Harness 侧（本仓库）

适配器防御性消毒（核心）：dsh-llm-deepseek 序列化前将孤立代理项（未配对的 U+D800–U+DFFF）替换为 U+FFFD，与仓库内已有先例一致（dsh-tool-cordis 按 code point 截断、dsh-host-apiproxy 导出时避开代理对边界）。
可观测性：响应体非 JSON 时，把原始 body 片段并入错误信息（如 DeepSeek API error (HTTP 400): <body 前 200 字符>），此类解析错误即可秒定位。
可选：工具结果截断统一按 Unicode code point 处理。

API 侧（可另报 DeepSeek API 平台）
4. JSON 解析类 400 也返回标准错误信封 {"error":{"message":...}}，让客户端能向用户展示真实原因。

用户侧规避
5. 在工具程序里截取含 emoji 的文本时勿用 JS .slice()（按码元），改用按 code point 截断（如 Array.from/Intl.Segmenter）；若会话突然全部 400，先检查最近工具结果里是否有 \uD800-\uDFFF 转义。

验证记录

实测：①含 \ud83d → 400（错误原文如上）；②对照组 → 200（同参数）。两者均真实调用官方 API。
会话文件定位：首次失败（turn 3 step 13）前最后一条工具结果（seq 127107，当地时间 12:37:20）第 476 字符处含 \ud83d；随后 turn 4–12（12:40–12:45）全部在 step 1 即 400（共 10 个失败 turn）。
失败时上下文 ≈ 233K tokens（usage：cacheRead 232,448 + input 203）；与失败无因果关系（同配置的兄弟会话在 ~241K 上下文（cacheRead 241,408）仍全部正常并 completed，新建会话亦立即成功）。
磁盘源文件始终完好（emoji 完整，逐码元核算 🔍 起始码元 119、slice(0,120) 必切中），证明毒字符产生于程序内切片而非文件损坏。

附件（路径已脱敏）

会话文件：~/.dsh/sessions/**/session-516482a7-*/session.jsonl.zstd
毒字符位置：seq 127107 工具结果第 476 字符：...| Docker 任务自动触发 | \ud83d（后续为换行与下一行 | akshare-stock | ...）

weijiafu14 · 2026-08-30T14:17:00Z

weijiafu14
Aug 30, 2026

你的诊断我们从另一条路由做了 A/B 实测，结论既佐证了你的定位、也给了一条今天就能用的活路：

同样被污染的历史（助手消息文本里带被 slice() 切断的孤立高代理 \ud83d）喂进 pi-ai 路由（真 pi-ai 0.84.1 stream()，请求体只复制不改、原样发真 api.deepseek.com）：上游 200、续轮正常完成（case loneSurrogate，判决）。也就是说这条路的 JSON 序列化产出了 DeepSeek 严格解析器能接受的报文——同一份脏历史，llm-deepseek 的序列化 400、pi-ai 的序列化 200。

两个含义：

佐证修复位置：问题确实出在序列化层对孤立代理项的处理（而不是"API 就是不收"），你提的适配器侧修复（序列化前 well-formed 化）是正解，且有现成的可行性证明；
临时活路：被锁死的会话如果换到自定义声明路由（llm-pi-ai，写法见 examples/custom-gateways），历史能重新发出去——不修根因，但能把"会话永久报废"降级成"换条路继续用"。

边界说明：我们注入的是单个孤立高代理的最小形态；你日志里的具体字节序列若有别的变体，以你的复现为准。

0 replies

Navigation Menu

Uh oh!

[Bug] 会话历史含孤立代理项（JS .slice() 切断 emoji 代理对）后，dsh-llm-deepseek 所有请求被 API 以 HTTP 400 拒绝，且错误文案无法定位根因 #967

Uh oh!

{{title}}

Uh oh!

Replies: 1 comment

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Uh oh!

[Bug] 会话历史含孤立代理项（JS .slice() 切断 emoji 代理对）后，dsh-llm-deepseek 所有请求被 API 以 HTTP 400 拒绝，且错误文案无法定位根因 #967

Uh oh!

lutaikang Aug 14, 2026

摘要

环境

现象

根因（已逐层实测验证）

最小复现（已实测）

建议修复

验证记录

附件（路径已脱敏）

Replies: 1 comment

Uh oh!

weijiafu14 Aug 30, 2026

lutaikang
Aug 14, 2026

weijiafu14
Aug 30, 2026