messages 协议：历史里一条 tool input 不是合法 JSON，会让整条会话永久无法恢复

[Laplus777]

messages 协议：历史里一条 tool input 不是合法 JSON，会让整条会话永久无法恢复

Summary

b0641b83fc（"feat(llm): default DeepSeek to Messages with Files parity"）把默认协议从 chat-completions 切到 messages 之后，历史中只要存在一条 arguments 不是合法 JSON 的 tool call，该会话就永久无法再打开。

原因是 messages 适配器在序列化历史时会校验每条工具输入（protocols/messages/serialize.ts:16-22），一条不合法即拒绝整个请求；而恢复会话必须重放整份历史，于是每次都失败、无法自救。

同一份历史在 chat-completions 下可正常使用（该路径不做此校验），这也是升级前该会话一直可用的原因。模型偶发生成非法 JSON 是生成侧问题，但让它升级为"整条会话报废"的是适配器缺少容错。

一个容易踩偏的实现细节（本贴的核心）

同一份工具参数在会话日志里存了两份，两处都可以独立损坏，而只有其中一份会被校验：

副本	位置	是否被 serialize.ts 读取
tool/call 事件的 data.arguments	事件流	❌ 不读
assistant/message 的 tool-call 内容块 arguments	消息内容（message.content）	✅ 序列化器读的是这里

serialize.ts:24-36 的 assistant() 遍历的是 message.content，:33 对每个 tool-call 块调用 toolInput(block.arguments)。

这是结构性的，不是巧合：消息派生只接受"表面事件"，而 tool/call 不在其中——packages/core/session/src/index.ts:315-318：

function isMessageEventType(type: unknown): type is SurfaceEventType {
  return type === 'system/message' || type === 'user/message'
    || type === 'assistant/message' || type === 'tool/result'
}

tool/call（写入点 packages/core/agent-loop/src/tool-calls.ts:264）永远不进入序列化器接收的 Message[]，因此被校验的只有 assistant/message 内容块里那一份。

实测后果：把 tool/call 事件那份修好后，会话仍然打不开——必须连内容块那份一起修。诊断时若只检查事件副本（或只看会话日志里的 type=tool/call 行），会得出"已修复"的错误结论。建议诊断工具同时检查两处。

Reproduction

1. 在 messages 协议（即当前默认）下运行会话，期间某次工具调用的 arguments 由模型生成为非法 JSON。本例是模型在中文正文里使用了未转义的英文双引号：

   {"description": "……最快，但"某个说法"就仍然没有仓库内证据。", "label": "……"}
                          ↑ 未转义，把 JSON 字符串提前闭合
   

   正确写法应为 \"某个说法\"，或按中文排版改用全角引号。

2. 该轮不会立即报错：工具照常执行、后续步骤照常进行，坏记录被原样写入会话日志。

3. 之后任意一次恢复该会话 → 序列化整份历史 → 失败：

   本轮运行失败  DeepSeek Messages historical tool input is invalid JSON
   

4. 此后该会话每次恢复都失败，无法继续，也无法压缩自救。

Current behavior

protocols/messages/serialize.ts:16-22 直接抛错，整个请求被拒：

function toolInput(raw: string): Record<string, unknown> {
  let value: unknown
  try { value = JSON.parse(raw) } catch (_invalidToolHistoryJson) {
    throw new LlmError('DeepSeek Messages historical tool input is invalid JSON', 'INVALID_REQUEST')
  }
  return object(value, 'INVALID_REQUEST')
}

用户侧只得到这一行，不含 callId / 工具名 / 位置，无法定位是哪一条坏在哪里；该会话只能放弃。

本机实测（DSH 0.1.6-alpha.1，Windows 11，deepseek-official / deepseek-flash）：

项	值
规模	42 条会话、共 15,152 次 tool/call
命中	1 条
坏记录	工具 ask_user_question，seq=167，内容块索引 2，arguments 全长 911 字符
位置	该 far 文件第 103 个 zstd 帧 —— 第 1 行 assistant/message（含该 tool-call 块）；第 2 行是同一参数的 tool/call 事件副本
错误	Expected ',' or '}' after property value in JSON at position 389
形态	arguments 内 82 个双引号全部未转义（含结构引号），解析器直到正文引号处才迷路；断点 389 正是紧跟 …最快，但 之后的那个裸引号

修复验证：将正文引号成对替换为全角引号、结构引号保持裸引号后，JSON.parse 通过，语义完整保留（"某个说法" → “某个说法”），会话恢复可用。注意两处副本都要改：只改 tool/call 事件那份时，会话依旧打不开（本机实测）。

Expected behavior

建议至少实现第 1 条：

1. 序列化时容错：遇到不可解析的工具输入时降级而非抛错——丢弃该调用的输入（保留"这里发生过一次调用"这一事实）并记录诊断。仓库内已有同类先例：protocols/messages/replay.ts:39-46 的 readReplay() —— 捕获 INVALID_REPLAY_STATE 后调用 onDegrade 并返回 undefined，即"丢弃不可用元数据 + 记警告 + 保留内容"；
2. 写入历史前校验：持久化 tool call 之前校验 arguments 是否可解析，不可解析则就地归一化，避免坏记录进入 durable log；
3. 错误可诊断：报错时带上 callId / seq / 工具名，便于用户定位。

Environment

• DSH 0.1.6-alpha.1（0d1f50007f），Windows 11
• deepseek-official / deepseek-flash（DeepSeek-V41-Flash），协议 messages（默认）
• 相关提交：b0641b83fc；相关代码：protocols/messages/serialize.ts:16-22、:33、protocols/messages/replay.ts:39-46、packages/core/session/src/index.ts:315-318
• 相邻现象：Discussion #2770（同属"长会话不可继续"，但成因不同）
• 如需会话样本（含坏记录，且两份副本中一份已修一份未修，可精确隔离缺陷）可在本贴回复索取

[PerryLink]

你的结论我对着 master（0d1f50007f，也就是你实测的 0.1.6-alpha.1）逐条核实过，全部成立，master 行为与你实测一致：serialize.ts 仍在读取时直接抛错，两份副本只有 content 块那一份被校验，你的修复方法（两份都改、全角引号）与源码相符。你要的三条改进目前一条都没有实现。

核对结果：

1. 抛错点原样存在。 packages/llm/llm-deepseek/src/protocols/messages/serialize.ts:16-22 的 toolInput()，catch 里就是 throw new LlmError('DeepSeek Messages historical tool input is invalid JSON', 'INVALID_REQUEST')（:19）；assistant()（:24-37）遍历 message.content，:33 对每个 tool-call 块调用 toolInput(block.arguments)。你贴的代码段和行号一字不差。
2. "两份副本、只读一份"成立，而且是结构性的。 序列化器只接收派生的 Message[] 历史；而消息派生只走表面事件（packages/core/session/src/index.ts:315-318 里 surface 类型只有 system/user/assistant/message 和 tool/result，tool/call 不在其中），所以 tool/call 事件的 data.arguments（写入点在 packages/core/agent-loop/src/tool-calls.ts:264）永远不会进入序列化器——被校验的只有 assistant/message 内容块里那份。这解释了"只修事件副本打不开"，也让"诊断工具必须两处都查"成为硬要求。
3. chat-completions 路径确实不做这个解析。 我在 protocols/chat-completions/serialize.ts 里没有找到对 tool 参数的任何 JSON.parse（该目录里唯一的 parse 是 adapter.ts:350 解析错误响应），与"同一份历史在旧协议下可用"的观察一致；b0641b83fc（"feat(llm): default DeepSeek to Messages with Files parity"）在 master 上确认存在。
4. 一个路径勘误： 你引的"降级先例" protocols/messages/translate.ts:52-53 已经移位——master 上那两行是 thinking 块的分支；真正的"丢弃元数据 + 记警告 + 保留内容"先例现在在 protocols/messages/replay.ts:39-46 的 readReplay()（捕获 INVALID_REPLAY_STATE → onReplayDegrade → 返回 undefined）。
5. 现状补充： messages 的流式翻译现在会拒绝 provider 侧的非法 tool JSON（protocols/messages/translate.ts:155-156 malformed('tool input is invalid JSON')），但这只管新流、不管历史里已存在的坏记录，也不构成你建议的第 2 条（持久化前校验）。报错仍是单行，无 callId/seq/工具名（未实现你的第 3 条）。

你的修复实操没有需要修正的地方；唯一想强调的风险：改日志时必须保持 seq 连续（packages/core/session/src/index.ts:579-581）并备份原文件。你那份"一份已修、一份未修"的样本我没法在本机复现验证（未验证：42 会话 / 断点 389 / 82 个引号这些细节来自你的实测，代码层面无法证伪）。如果你贴出那两条坏记录的前后几十字节，我可以帮你复核两份副本的一致性。

[Laplus777]

两处都收到了，感谢逐行核对。三点回应：一处勘误我照改、一处你补的解释比我原来的更本质、你提的疑点我查了。

1. 勘误接受并已改

protocols/messages/translate.ts:52-53 我引错了——master 上那两行现在是 thinking 分支。正确先例是 protocols/messages/replay.ts:39-46 的 readReplay()：捕获 INVALID_REPLAY_STATE → onDegrade(error.message) → 返回 undefined，即"丢弃不可用元数据 + 记警告 + 保留内容"。原贴已更正。

2. 你补的结构性解释比我原来的更本质

我原来只说"序列化器恰好遍历 message.content"，是描述现象。你给的 packages/core/session/src/index.ts:315-318 才是根因：

function isMessageEventType(type: unknown): type is SurfaceEventType {
  return type === 'system/message' || type === 'user/message'
    || type === 'assistant/message' || type === 'tool/result'
}

tool/call 不属于表面事件类型，结构上不可能进入派生的 Message[]——所以两份副本分叉是必然的，不是偶发。已把这段补进原贴，你引的 tool-calls.ts:264 写入点也一并标注了。

3. 你问的字节级细节（脱敏后）

坏记录是 seq=167 的 assistant/message 内容块 tool-call（blockIndex=2，ask_user_question，arguments 全长 911 字符）。在已解析出的字符串里逐字符统计：

引号总数 82   已转义（\"）= 0   裸引号（"）= 82
前 12 个裸引号位置: 1, 11, 16, 23, 26, 31, 34, 37, 40, 53, 56, 64

即包括所有结构引号在内，一个都没转义。断点 position 389 处的码点：

… [383] 。 [384] 最 [385] 快 [386] ， [387] 但 [388] 0x22(") [389] 额 …

形态（首 80 字符，原文）：

{"questions": [{"header": "验证力度", "id": "verification", "options": [{"description": "…

断点前后：…只补文档和测试缺口。最快，但 " 额外批准 15 条"这个说法就仍然没有仓库内证据。", "label": …

—— 模型在中文正文里用了英文引号且未转义。注意这是会话内容中夹杂的用户项目细节，所以只给位置和形态，不贴上下文原文；如果你需要完整坏记录做复核，我可以按你指定的方式私下提供。

你提的"改日志要保持 seq 连续"我复核了（session/src/index.ts:579-581 确有该断言）。我的修复是只替换帧内字节、不增删事件，实测 seq 0→3590 连续、无重复/倒退/跳跃，帧数也保持不变（2337）。

4. 你提的重试疑点：查清了，而且我原贴写错了

你说"413 不在默认重试集合里，所以 5/5 很可疑"——完全正确，我核实：

retry-policy.ts:18-24  DEFAULT_RETRYABLE_CODES = [EMPTY_RESPONSE, RATE_LIMIT, SERVER, TIMEOUT, TRANSPORT]
我们那次的 policyKey     = ["normal",5,["EMPTY_RESPONSE","RATE_LIMIT","SERVER","TIMEOUT","TRANSPORT"],…]

INVALID_REQUEST 不在其中。而会话日志里：

含 413 的 assistant/attempt: 5 次，位于 turn 76/77/78/79/80，各回合均 step=1 单次尝试
期间 llm/retry 事件: 0

所以那不是自动重试，是我在 5 个不同回合各手动重发了一次（间隔 11 分钟 / 11 分钟 / 10 分钟 / 22 小时——人手操作的节奏）。UI 上那句"已重试模型请求 (5/5)"来自什么机制我没有确证（未验证），但会话事件层面的自动重试为零，与你的判断一致。原贴那段因果表述已更正为"413 不被自动重试"。

5. 你提的 turn/end 前后日志

单次 413 回合的完整事件序列（turn 76，2026-09-15T12:42:38Z，同一毫秒级窗口）：

agent/inbox/spliced → turn/start → agent/inbox/spliced
→ step/start(step=1) → user/message → request/header
→ assistant/attempt  ← 失败：DeepSeek Messages request failed (413) / INVALID_REQUEST / status 413
→ step/end → turn/end

即失败发生在恢复后的第一步、第一次请求，请求已经构造并发出（request/header 存在），在响应阶段被拒；没有任何工具调用发生。

6. 关于 contextWindow / maxTokens 的建议

谢谢，但有个反向证据要补充：同一条会话在升级前（默认 chat-completions）一直可用，而协议切换并不改变历史内容——所以"缩小单请求规模"未必是主因，触发面的改变更可能是关键变量。我保留这个建议，但把预期放得很低。

再次感谢——你指出的两处（降级先例位置、重试集合）都让我修正了原文。