[Bug] 会话历史包含孤立 UTF-16 代理码元后，所有后续请求持续返回 HTTP 400 INVALID_REQUEST

[bailong-Hakuryu]

问题摘要

DeepSeek Harness 的一次工具结果中写入了一个孤立的 UTF-16 高代理码元 U+D83C。该内容被持久化到会话日志后，会在后续请求中进入 messages[40].content。DeepSeek API 随即持续返回 HTTP 400；由于 Harness 每次继续会话时都会重放同一段历史，用户重复点击“继续”或切换模型都不能恢复这个会话。

本次诊断通过单变量对照确认：原始请求返回 HTTP 400；只把这个孤立代理码元替换为 Unicode 替换字符 U+FFFD，其余请求字段和内容保持不变，请求返回 HTTP 200。

此外，API 的错误响应正文是纯文本，Content-Type 为 application/octet-stream。当前适配器只尝试调用 response.json()，解析失败后丢弃正文，因此界面仅显示笼统的 DeepSeek API error (HTTP 400) 和 INVALID_REQUEST，没有显示服务端已经提供的具体原因。

用户可见现象

在同一个任务中发送“继续”后，界面连续出现：

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

再次发送“继续”仍然得到相同错误。将模型从 deepseek-v4-pro 切换到 deepseek-v4-flash 后，问题仍然存在。

环境

• 操作系统：Windows
• Shell：Windows PowerShell
• Node.js：v24.19.0
• DeepSeek Harness：本地源码运行
• 启动方式：pnpm dsh web
• Web 地址：http://127.0.0.1:3080
• 故障会话：session-3e91e9ab-242d-48ff-8d50-6fd368b833c4

API Key、请求头中的授权值和完整请求正文均未包含在本报告中。

复现步骤

目前已经从故障会话中得到确定性复现请求：

1. 加载会话 session-3e91e9ab-242d-48ff-8d50-6fd368b833c4。
2. 保留事件 seq: 75402 的 tool/result 文本，其中索引 1552 是孤立高代理码元 U+D83C。
3. 继续该会话，使这段历史进入 DeepSeek Chat Completions 请求的 messages[40].content。
4. 发送原始请求，服务端返回 HTTP 400。
5. 仅把 U+D83C 替换为 U+FFFD，不修改模型、消息顺序、工具调用、推理内容或其他请求字段。
6. 再次发送请求，服务端返回 HTTP 200。

触发异常的会话事件信息：

session: session-3e91e9ab-242d-48ff-8d50-6fd368b833c4
seq: 75402
event type: tool/result
tool: run_code
text index: 1552
invalid UTF-16 code unit: U+D83C
wire location: messages[40].content

实际结果

原始请求返回：

HTTP 400
Content-Type: application/octet-stream

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

Harness 界面只显示：

DeepSeek API error (HTTP 400)
INVALID_REQUEST

预期结果

Harness 在发送请求之前应保证所有模型可见文本都是 well-formed Unicode。工具输出或持久化事件中即使含有孤立 UTF-16 代理码元，也不应导致整个会话永久无法继续。

如果服务端返回非 JSON 错误正文，Harness 应在安全长度限制内显示或记录该正文，使错误信息能够指出具体消息字段和解析位置。

对于已经包含不可发送历史的会话，产品应提供可发现的恢复方式，例如从上一成功步骤分叉，或在明确告知用户后规范化异常文本并重试。

确定性对照结果

请求	唯一变化	结果
原始故障请求	无	HTTP 400
修复后的对照请求	U+D83C 替换为 U+FFFD	HTTP 200

原始请求的相关统计：

messages: 41
request body: 389246 bytes
reasoning_content: 203775 characters
isolated UTF-16 surrogate code units: 1

工具调用 ID、工具参数 JSON 以及 tool-call/tool-result 关联均正常，没有发现孤立或未匹配的工具调用。

为什么重复“继续”无法恢复

异常字符已经写入持久化会话事件。后续每轮请求都会重新序列化并发送完整相关历史，因此每次重试都会再次携带同一个 U+D83C。这不是一次性的网络错误，单纯重试不会改变请求内容。

切换模型也不会修复历史消息，因此 deepseek-v4-pro 和 deepseek-v4-flash 都表现为 HTTP 400。可行的临时恢复方式是从异常事件之前的成功步骤分叉，避免重放该事件。

用于验证服务、账户和凭据正常的成功分叉会话：

session: session-4c2a4357-b300-4f7e-8f41-c8b8a4b545b9
parentSession: session-3e91e9ab-242d-48ff-8d50-6fd368b833c4
seedLength: 65978
result: successfully completed 19 steps

已排除的原因

根据原始请求检查和对照实验，已经排除：

• API Key、账户或网络整体不可用；
• deepseek-v4-pro 模型名无效；
• 单一模型故障，因为切换到 deepseek-v4-flash 后仍然返回相同错误；
• Windows 文件沙箱或 NTFS ACL；
• 请求体总大小或上下文总长度本身；
• tool-call 与 tool-result ID 不匹配；
• assistant 消息同时包含文本和工具调用。

相关实现位置

1. 请求序列化没有规范化非 well-formed UTF-16 字符串

packages/llm/llm-deepseek/src/serialize.ts 中的 flattenText() 直接拼接文本，serializeAssistant() 也直接传递文本。随后 JSON.stringify() 生成请求体，但发送前没有检查或规范化孤立代理码元。

相关代码：

• serialize.ts 中的 flattenText()
• adapter.ts 中的请求序列化与发送

建议同时调查异常码元的最初来源，特别是所有按 UTF-16 代码单元截断工具结果、日志内容或上下文的路径。若截断点落在代理对中间，原本合法的补充平面字符也会变成孤立代理码元。

2. 非 JSON 错误正文被丢弃

packages/llm/llm-deepseek/src/adapter.ts 在 response.ok === false 时只调用 response.json()。本次服务端返回 application/octet-stream 纯文本，因此 JSON 解析进入空 catch，服务端的具体错误正文没有传递给用户。

相关代码：

• adapter.ts 的非成功响应处理

3. 持久化坏历史缺少恢复入口

一旦异常文本进入会话日志，用户在原会话内无法通过重试修复。界面也没有提示用户从上一成功步骤分叉，导致表面上相同的 INVALID_REQUEST 可以无限重复。

修复建议

1. 在 DeepSeek 请求序列化的统一出口规范化所有字符串字段。运行时支持时可使用 String.prototype.isWellFormed() 和 String.prototype.toWellFormed()；也可以实现等价的、经过测试的替换逻辑，将孤立高/低代理码元替换为 U+FFFD。
2. 检查所有文本截断路径，确保按 Unicode 码点或 grapheme 边界截断，至少不能在 UTF-16 代理对中间切断。
3. 处理非成功响应时，先读取一次正文，再根据 Content-Type 尝试解析 JSON；无法解析时保留经过长度限制和敏感信息处理的纯文本错误。
4. 错误信息应至少包含 HTTP 状态、提供方错误正文、request ID（如果响应头提供）以及可定位的字段路径。
5. 为不可回放会话提供恢复操作，例如“从上一成功步骤分叉”，并在检测到 Unicode 规范化问题时给出明确提示。

建议的回归测试

• user 文本包含孤立高代理码元；
• user 文本包含孤立低代理码元；
• assistant 文本和 reasoning_content 包含孤立代理码元；
• tool result 包含孤立代理码元；
• 合法代理对保持原字符，不被错误替换；
• 文本截断点恰好位于代理对中间；
• 持久化会话包含异常码元时仍可安全回放；
• HTTP 400 返回 JSON 错误正文；
• HTTP 400 返回 text/plain 或 application/octet-stream 正文；
• 非 JSON 错误正文过长或包含潜在敏感信息时，日志和界面执行安全截断与处理。

影响

任何工具输出、外部文件内容或截断逻辑只要产生一个孤立 UTF-16 代理码元，就可能使当前会话的所有后续请求失败。由于错误会随会话历史持久化，用户无法通过普通重试恢复；同时，当前错误处理隐藏了服务端正文，使问题容易被误判为模型、网络、API Key、上下文长度或工具调用关联故障。

隐私说明

本报告没有包含 API Key、Authorization 请求头或完整会话正文。若维护者需要原始请求进行复现，建议通过私密渠道传输，并在分享前移除凭据、个人路径和无关会话内容。

[xiaoshenming]

官方加载器拒读之后，磁盘上的 session.jsonl.zstd 不会自己好。我做了一个只修会话文件的插件：

https://github.com/xiaoshenming/dsh-session-surgeon

默认 dry-run；--apply 会先写 .bak.<utc>，不会发明缺失的 seq。中间帧损坏 / 文件头坏了会直接 refuse。

git clone https://github.com/xiaoshenming/dsh-session-surgeon.git
cd dsh-session-surgeon
dsh plugin --profile web add link:"$(pwd)"

重启 dsh web 后，左侧「会话医生」可以扫描、看对话、复制会话 ID、预览修复。欢迎把 scan / inspect 输出贴过来（不要上传整份 ~/.dsh/sessions）。

[wangxue16292016]

谢谢您的来信，我会及时处理。