[Bug] 工具结果里一个孤立的 UTF-16 代理项（半个 emoji）会让会话永久 400（INVALID_REQUEST）

[yingcai233333]

环境

• DeepSeek Harness Desktop 0.2.1-rc.5，Windows 11
• provider deepseek-account，模型 deepseek-flash（后来也试过 deepseek-v4-pro）
• 桌面 profile 插件：dsh-ops / dsh-pocket / dsh-better-sidebar / dsh-approval-ledger / dsh-context / dsh-cost-meter

现象
一个跑了 88 轮的长会话，从第 77 轮第 11 步开始，之后每一次请求都失败：

DeepSeek Messages request failed (400)
code: INVALID_REQUEST, status: 400

换模型（flash → v4-pro）、调推理强度（high/max）、重开对话都无效。之后连续 12 次尝试，每次都在约 250ms 内返回 400。

根因（已定位到具体字符）
模型在 run_code 里写了 l.text.slice(0, 90) 打印一段中文表格，第 90 个 UTF-16 码元正好落在 🔴（U+1F534 = \uD83D\uDD34）中间，于是工具结果里留下一个孤立的高位代理项 U+D83D。

这个字符串原样写入会话日志（JSONL 里是 \ud83d 转义），之后每个请求都会把它带给服务端；严格的 JSON 解析器拒绝这个不成对的代理项转义，返回 400。而响应体不是标准的 {"error":{"message":...}} 结构，providerError() 只能回退成笼统的 DeepSeek Messages request failed (400)，用户看不到任何可操作的细节。

证据

• 会话共 3789 条事件，孤立代理项只出现 1 次，正好是第一次 400 之前的那条 tool/result；此前 0 次，此后 12 次请求全部 400。
• 最后一次成功请求的 usage：input 698 / cacheRead 486400，总计 487,566 tokens（1M 窗口的 46%），排除上下文超限。
• 消息结构校验（436 条消息）：无孤立 tool_result、无重复 tool_call id、无空 content。
• 会话文件里那一帧的内容：...落不成秒数 | \ud83d\n52\t| **D7**...。

同类风险：DSH 自带的截断逻辑本身就能造出这个字符
@deepseek-ai/dsh-tool-fs 的 truncateLine()：

return line.length > maxLineLength ? `${line.substring(0, maxLineLength)}... (line truncated to ${maxLineLength} chars)` : line;

READ_MAX_LINE_LENGTH 默认 2000。只要被截断的行第 2000 个码元落在代理对中间，read 工具自己就会产出孤立代理项。复现（纯字符串，不涉及文件）：

('a'.repeat(1999) + '🔴').substring(0, 2000).isWellFormed() // false

值得注意的是，@deepseek-ai/dsh-output-retention 里已经有 truncateWithoutSplittingSurrogatePair()，注释写得很明确："An unpaired surrogate is not well-formed text — a strict JSON reader rejects a durable Session log that carries one." 说明这条不变量团队是知道的，只是没有覆盖到持久化和请求边界。

建议

1. 会话持久化时清洗：写入前把孤立代理项替换成 U+FFFD，或拒收并告警；
2. 组装请求时再兜一层：对发出去的字符串统一 toWellFormed()；
3. truncateLine() 复用 truncateWithoutSplittingSurrogatePair()；
4. 400 时把响应体（截断到合理长度）带进错误信息，而不是只给 (400)；
5. 恢复手段：允许丢弃/回退最后一条事件，或在 INVALID_REQUEST 时提示"某条历史消息包含非法字符"。

用户侧临时规避：不要对可能含 emoji 的文本用 .slice()，改用 Array.from(s).slice(0, n).join('')；已经坏掉的会话可以手工把日志里那个 \ud83d 换成 \ufffd（这次就是这么救回来的，改完 1653 帧 / 3789 条事件全部可解析）。

---

English summary
A single unpaired UTF-16 surrogate (half of an emoji) inside one tool result permanently poisons a session: every later Messages request is rejected with 400 INVALID_REQUEST, and neither switching models nor restarting helps. The string is persisted verbatim (\ud83d) in the session JSONL and re-sent on every turn. The same defect is reachable from the shipped truncateLine() in @deepseek-ai/dsh-tool-fs (a plain substring cut), even though @deepseek-ai/dsh-output-retention already ships truncateWithoutSplittingSurrogatePair(). Suggested fixes: sanitize at the persistence and request boundaries, make truncation surrogate-safe, and surface the provider error body.

[yingcai233333]

补充：同一个会话在修复后 2 小时再次复发，可以确认这是稳定可复现的，不是一次性事故。

第二次触发（2026-11-02 12:26，本机时间）

• 同一会话，第 91 轮第 3 步（第一次是第 77 轮第 10 步）
• 触发代码：

console.log(r.lines.map(l=>`${l.number}\t${l.text.slice(0,80)}`).join("\n"))

• 切中的字符：🟡 U+1F7E1（\uD83D\uDFE1），截断点落在代理对中间
• 结果：第 4 步起每次请求都是 400 INVALID_REQUEST，与第一次完全一致

两次都发生在同一个动作上：读取同一张 markdown 表格（每行以 🔴 / 🟡 结尾）→ 截断后打印。截断点只要落在行尾的 emoji 上就必然复现。

这次的修复方式仍然是手工把日志里的 \ud83d 换成 \ufffd：1772 帧 / 4086 条事件，校验通过、孤立代理项归零。

再补充一个判断：read 工具自身的 truncateLine() 用的是 line.substring(0, maxLineLength)（默认 2000 码元）。它比模型手写 slice 的门槛高，但性质相同——只要某行第 2000 个码元落在代理对中间，一个没做任何危险操作的正常会话也会被写坏。

[yingcai233333]

TL;DR — Same root cause as #10713 (web_fetch) and #11476 (read). The correct
primitive already exists in-tree since dc07e5a5 (PR #4827); read's
truncateLine simply never adopted it.

同族报告

编号	日期	入口	报告人
#10713	10-22	web_fetch 的 HTML 截断	userszhangkefan
#11476	10-29	read 的单行截断	fengxiforcy
#11831	11-02	通用（工具结果层）	本帖

三个不同用户、三个入口、同一个根因：一次 UTF-16 码元切把代理对劈开，孤立代理项
写进会话日志后，之后每个请求体都带着 \uD83D，服务端返回 400，会话永久不可用。

这个问题 9 月已经修过一半

dc07e5a5 fix(tools): keep surrogate pairs intact when capping tool output
（PR #4827）已经定性，并给出了现成的正确实现：

// packages/util/output-retention/src/index.ts:456
export function truncateWithoutSplittingSurrogatePair(text: string, maxChars: number): string {
  if (text.length <= maxChars) return text
  const capped = text.slice(0, maxChars)
  return /[\uD800-\uDBFF]$/.test(capped) ? capped.slice(0, -1) : capped
}

当时接上的是三个调用点：tool-bash-persistent、tool-pwsh-persistent、
tool-str-replace-editor。

read 不在其中：

// packages/fs/tool-fs/src/read-render.ts:69
function truncateLine(line: string, maxLineLength: number): string {
  return line.length > maxLineLength
    ? `${line.substring(0, maxLineLength)}... (line truncated to ${maxLineLength} chars)`
    : line
}

readMaxLineLength 默认 2000（packages/fs/tool-fs/README.md 已写明）。
只要某行第 2000 个码元落在代理对中间，这一行就以孤立高位代理项结尾。
不需要任何「危险操作」——普通地读一个含 emoji 的长行文件就能触发。

建议的最小修复（二选一）

1. 复用现有实现（与 今天拉去最新代码后，重新安装构建，运行后抛出 '@deepseek-ai/dsh-llm' does not provide an export named 'CallId' 错误 #4827 保持一致）：tool-fs 增加
   @deepseek-ai/dsh-output-retention 依赖，truncateLine 改为
   truncateWithoutSplittingSurrogatePair(line, maxLineLength)。
   代价如实说：新增一条 workspace 依赖边，需要重新生成
   docs/module-graph 与 docs/config-catalog（与 今天拉去最新代码后，重新安装构建，运行后抛出 '@deepseek-ai/dsh-llm' does not provide an export named 'CallId' 错误 #4827 流程相同）。

2. 就地三行，不动依赖：

function truncateLine(line: string, maxLineLength: number): string {
  if (line.length <= maxLineLength) return line
  const capped = line.slice(0, maxLineLength)
  const safe = /[\uD800-\uDBFF]$/.test(capped) ? capped.slice(0, -1) : capped
  return `${safe}... (line truncated to ${maxLineLength} chars)`
}

为什么建议按 hotfix 看待

这类缺陷是不可恢复且没有自助手段的：孤立代理项一旦进日志，之后每个请求都会被拒，
UI 只能显示一句 400 INVALID_REQUEST。用户唯一能做的是手工改会话日志
（我两次都是把日志里的 \ud83d 替换成 \ufffd 才救回来）。
一行判断的收益／风险比很悬殊。

[yingcai233333]

补充实测：0.2.2-rc.1 上仍可复现；两个客户端侧自救方案，一个失败、一个有效

承接上一条（read 的 truncateLine 仍用裸 substring）。下面是 2026-11-05 在本机的实测记录，供定位和排优先级参考。

1. 载体不止 read

今天 14:04 又复现一次（0.2.2-rc.1，Windows）：触发点是 run_code 打印了含孤立代理项的字符串，与 read 的 2000 字符截断无关。
所以任何工具结果都可能是载体——run_code、web_fetch、第三方工具都算。只修 truncateLine 只能堵住一个入口。

2. 尝试一（失败）：在 DeepSeek adapter 的 extension 层洗请求 body

做法：本地 cordis 插件，export const inject = ['deepseekLlmApiExtensions']，注册一个 extension provider，遍历请求 body，把字符串中的孤立代理项换成 U+FFFD。

结果：未生效。子会话产生孤立代理项后仍然 400，历史继续带着它。

我们没能定位失败的具体环节（挂载点、加载时机、还是 adapter 另走一条序列化路径），所以结论只到「我们没做到」。但它对你们有两条信息：

• 用户侧目前缺少一个可靠的兜底钩子；
• 如果 extension 本来就拿不到最终 payload，这条防线应当在文档里明确掉，而不是让每个撞上的人各试一遍。

3. 尝试二（有效）：会话日志监视器 + 就地修复

思路是不阻止产生，只保证产生后几秒内自救：

1. 每 2s 轮询 ~/.dsh/sessions/<workspace>/<session>/session.v4.jsonl.zstd
2. 按 zstd 帧魔数切帧、逐帧解压、逐条 JSON.parse
3. 扫描 data.* 里的字符串，找出含孤立代理项的记录
4. 只重写这些记录（JSON.stringify(obj, replacer)，replacer 做 toWellFormed()），其余帧按字节原样拷贝
5. 写回前备份 .bak-watch-YYYYMMDD，保持每帧 checksum
6. 校验：行数不变、受影响记录的孤立代理项计数为 0、其余行逐字节相同

实测：子会话产生孤立代理项后约 3 秒被修复，同一会话可以继续对话。今天 14:04 的一次真实修复：18 帧里改 1 条记录，58658 -> 58676 字节，正在使用的会话恢复可用。

局限也说清楚：轮询间隔内的请求仍会 400（重试即可）；需要常驻进程；这是创可贴，不是修复。

4. 建议的修复（按性价比）

1. 一行：工具结果写进会话日志之前，text.toWellFormed()。这一处挡住所有载体，成本极低。
2. 一行：请求序列化时 JSON.stringify(body, (k, v) => typeof v === "string" ? v.toWellFormed() : v)。除了防御，还能让已经中毒的历史继续可用——比让用户去手改日志好得多。
3. read-render.ts:70 换成仓库里已有的 truncateWithoutSplittingSurrogatePair（上一条给过）。
4. 可诊断性：裸 400 是这次事故里最难的部分。UI 上只有一句 400 INVALID_REQUEST，没有任何线索指向「历史里有非法字符」。发送前本地校验一次并报 history contains an unpaired surrogate (session ..., record ...)，用户至少知道往哪看。

5. 为什么建议提高优先级

• 不可恢复：会话立刻失效，用户没有自助手段
• 会传染：A 打印 -> A 全废；B 为了排查去读 A 的输出 -> B 跟着废（我们实际发生了）
• 成本全部转嫁给用户：要么手改 zstd 日志，要么常驻一个监视器