[Bug][Windows 0.2.1-rc.2] 切换到 deepseek-official 后报 tool_result 缺失，但本地结果及序列化配对均存在

[Po1abear]

Date: 2026-10-19
Severity: High（原会话切换后无法继续）
Reproducibility: 原会话观察到一次；离线配对检查可重复。

Summary / 概述

Windows 桌面版同一长会话从自定义 OpenAI Chat Completions provider 切到 deepseek-official 后，服务端以 HTTP 400 报 tool_use 缺少紧随其后的 tool_result。但本地持久化日志存在对应结果，使用已安装版本的 Messages 序列化函数重建时，同一调用也紧跟匹配结果。

这是一次真实故障记录及离线核对；目前尚未获得完整出站请求抓包，也未完成可独立运行的上游最小复现。以下不预设问题发生于 Harness、转换层或官方端点。

Expected Behavior / 预期

已经完成、且具有配对结果的历史工具调用应当可以在切换 provider 后继续使用。若历史无法被目标协议表示，应明确提示不兼容位置及恢复方式。

Actual Behavior / 实际

原会话在第三方端点遇到 413 后，用户填写官方 API key 并切到 deepseek-official，希望继续任务。切换后的第一个请求报工具配对错误，尚未开始新的模型输出。报错点位于早已完成的历史工具调用，并非最近一次 413 对应步骤。

Reproduction Steps / 观察到的操作顺序

1. Windows 桌面版 0.2.1-rc.2，以 standard preset 创建会话。
2. 使用自定义 llm-pi-ai provider：api=openai-completions，model=deepseek-v4.1-flash，input=[text,image]，contextWindow=1000000。
3. 连续执行文件编辑、命令及读图等任务。本案累计 316 个 tool/call、316 个 tool/result，未记录 compaction 事件。
4. 第三方端点连续返回 HTTP 413。用户随后配置官方密钥，并在原会话切到 deepseek-official/deepseek-flash，reasoningEffort=high。
5. 发送“继续”，观察下方 HTTP 400。

以上是本案复现路径，不代表 413、图片或长会话一定是必要条件。

Minimal evidence / 已缩减的证据

调用标识统一替换为 CALL_A，任务正文、路径、工具参数和结果正文均省略。原始记录内两个标识完全相同。

{"type":"assistant/message","seq":212,"surfaceOp":"append","data":{"turn":1,"step":31,"message":{"role":"assistant","content":[{"type":"tool-call","id":"CALL_A","name":"edit","arguments":"[omitted]"},{"type":"text","text":"[omitted: 2008 characters]"}]}}}
{"type":"tool/call","seq":213,"data":{"turn":1,"step":31,"callId":"CALL_A","name":"edit","arguments":"[omitted]"}}
{"type":"tool/result","seq":214,"surfaceOp":"append","sourceEventSeqs":[213],"data":{"turn":1,"step":31,"message":{"role":"tool","toolCallId":"CALL_A","content":[{"type":"text","text":"[successful edit result omitted]"}],"isError":false}}}

离线重建说明：从已安装 app.asar 读取 Messages serialize() 及其 assistant()/toolInput() 辅助函数，输入日志中全部 append surface messages。跨 provider 的 readReplay 返回路径以 undefined 表示；历史图片用占位 file id 表示，不上传图片；此检查没有发起模型请求，也不是原请求抓包。

重建得到 604 条 wire messages，报错指定的 message 下标与本地调用位置一致：

{"index":61,"role":"assistant","content":[{"type":"tool_use","id":"CALL_A"},{"type":"text","text":"[omitted]"}]}
{"index":62,"role":"user","content":[{"type":"tool_result","tool_use_id":"CALL_A"}]}

本地序列化的配对校验通过，但真实请求被服务端判为缺失结果。这一差异尚需定位，不能据此认定已经证明某一层的根因。

Environment / 环境

• @deepseek-ai/dsh-desktop: 0.2.1-rc.2
• @deepseek-ai/dsh-llm-deepseek: 0.2.1-rc.2
• @deepseek-ai/dsh-llm-pi-ai: 0.2.1-rc.2
• Windows 11 x64，build 26200
• 原路由：自定义 ShenwenAI provider，https://api.shenwenai.com/v1，OpenAI Chat Completions
• 切换后：deepseek-official / deepseek-flash，high
• Skills：原会话技能加载状态未完整核对；报告工具的技能不属于故障运行环境。
• Skill conflict analysis：N/A，未观察到与此失败相关的技能指令冲突。

Error Output / 原始报错

仅替换调用 ID 与 request_id，其余原文保留：

messages.61.1: `tool_use` ids were found without `tool_result` blocks immediately after: CALL_A. Each `tool_use` block must have a corresponding `tool_result` block in the next message. (request_id: [REDACTED])
INVALID_REQUEST
status: 400

Impact / 影响

原会话无法通过这次切换继续任务。磁盘上的已生成文件仍在；保留工程并新建空白会话可以绕过历史重放，但需要重新交接任务上下文。本报告未验证修复，也未重写原会话。

Related Files / 相关文件

• packages/llm/llm-deepseek/src/serialize.ts：Messages 序列化及本地工具配对检查。
• packages/llm/llm-pi-ai/src/context.ts、replay.ts：原 provider 的历史表示及跨 provider 重放。
• session.v4.jsonl.zstd：上述脱敏事件来源，不公开整份日志。

Notes / 相关讨论及边界

• [Bug] messages protocol: prepare undefined crash on tool_use, then INVALID_REQUEST on retry #7120：同样出现工具配对错误，但其前置故障为 prepare 崩溃、结果缺失。本案没有该前置异常，316 个调用均能找到结果。
• [Bug] 混合 provider 会话切回 deepseek-official（Anthropic Messages）后必现 400：tool_use 历史缺 thinking 块 #10077：同样是混合 provider 切回官方后 400，但错误为缺少 thinking。本案错误明确指向缺少 tool_result；是否存在共同成因尚未确认。
• [Bug] Custom chat provider and built-in DeepSeek web search overwrite each other's API key #5916：共享 DEEPSEEK_API_KEY 引用导致密钥覆盖，属于独立的凭据问题，未合并到本报告。
• Compaction cannot rescue an oversized session — the summarization request itself exceeds the provider request-size limit (HTTP 413) #7626：先前 413 的相关反馈，仅作为操作背景。

没有附带 API key、用户路径、项目内容、图片或完整会话日志。

[argszero]

Both of your observations are true, and that is the interesting part: the local check and the endpoint are counting different things.

What the wire actually carries

I drove the shipped DeepSeekAdapter from @deepseek-ai/dsh-llm-deepseek (every released line, only fetch stubbed) with a history whose tool result content varies, and captured the body it posts. The tool_result block always survives; its content does not:

tool result content in the session	tool_result posted
[{type:'text', text:'file contents'}]	{"type":"tool_result","tool_use_id":"CALL_A","content":[{"type":"text","text":"file contents"}]}
[]	{"type":"tool_result","tool_use_id":"CALL_A","content":[]}
[{type:'text', text:''}]	{"type":"tool_result","tool_use_id":"CALL_A","content":[]}
[{type:'reasoning',...},{type:'tool-call',...}]	{"type":"tool_result","tool_use_id":"CALL_A","content":[]}
[{type:'text', text:' '}]	{"type":"tool_result","tool_use_id":"CALL_A","content":[{"type":"text","text":" "}]}

Same table on 0.1.7-rc.2, 0.2.0-rc.1, 0.2.0-rc.2, 0.2.1-alpha.1 … 0.2.1-alpha.5, 0.2.1-rc.1 and 0.2.1-rc.2.

Why the local pairing check passes

packages/llm/llm-deepseek/src/serialize.ts ends with a pairing invariant built on a pending set: an assistant tool call adds its id, a tool result removes it. It is exact about ids — an unmatched call, a duplicate id, a dangling tail all throw before anything leaves the process. What it never inspects is what a tool_result block carries.

That content is produced by the same file's own input(), which

• drops an empty text block,
• never passes reasoning or tool-call blocks at this position,
• turns images into handles.

So a result whose every block is dropped is serialized as {"type":"tool_result","tool_use_id":X,"content":[]} — a block the local invariant just declared paired, and one the endpoint does not count as a result. The file documents the retention deliberately: empty tool results "retain their call ids". Nothing crashes locally, because nothing is wrong locally.

Why your offline rebuild cannot find it

Your rebuild walks the same messages through the same rules and asks the same id-shaped question, so it answers "paired". It agrees with the serializer because it borrowed the serializer's question — reconciling the same data on the same dimension is a tautology, not evidence. The fact that differs is on the wire, not in the log.

What produced the emptiness in your case

Two shapes reach it, and both are ordinary:

1. A tool really returned nothing (or only whitespace-free empty text), so its result content is [].
2. The result carried blocks and the projection dropped them — a result holding reasoning/tool-call blocks, or empty text, reaches the wire empty. Switching the route's capability from [text, image] to text-only does not create that, but it is the moment a different projection path starts running, which is why the switch is where it surfaced.

Looking at the tool calls immediately before the failing message in your session log should show which one it was.

Mitigation and the real fix

The real fix belongs in the adapter: a tool_result whose content serializes to [] should either carry a placeholder or be reported rather than sent, since the endpoint's rule and the local invariant must not disagree about what "answered" means.

Until then, I published a plugin that makes the request legal without touching the session log: @argszero/dsh-empty-tool-result-guard.

npm install github:argszero/dsh-empty-tool-result-guard#ac14655

It listens on the llm/stream waterfall (a plugin cannot patch the adapter — registerAdapter is all-or-nothing per route) and, when a request holds a tool result whose blocks nothing can represent, re-dispatches the same request with one non-empty text block prepended to that result's content. The call id, the existing blocks and every other message are untouched; nothing is written to the session log or to disk; every step fails open, so a request it cannot classify goes through unchanged.

Verified against all ten released dsh-llm-deepseek lines above by driving each line's own shipped adapter: the defect is present on every one, the repaired body has non-empty content on every one, and the control history (a result that already had text) is byte-identical before and after. mode: observe counts without changing anything, if you want to confirm your session produces this shape before letting it rewrite a request.

If it turns out your failing message is not this shape — for example the result was there and the call id differed by a normalization step — the plugin will stay silent on it and the snapshot() counters will stay at zero, which is itself a useful result: it would move the question back to id identity, where the local check does have something to say.

[meteorfall]

Cross-referencing #3046 (user-side ordering) and #10186 / #9239 (history shape + stricter endpoint), I filed the assistant-side counterpart: #11115.

Short version, with the isolating measurement: the same history is accepted or rejected purely by block order —

history	api.deepseek.com/anthropic/v1/messages	api.deepseek.com/v1/chat/completions
assistant tool_use, text	400	200
assistant text, tool_use	200	200

So assistant() replaying the model's recorded order is what makes a session unusable after it moves to a strict Messages endpoint; the id-pairing invariant correctly passes, because nothing is unpaired. Suggested fix in #11115: stable-sort blocks to thinking → text → tool_use (carrying the replay signatures along), or degrade instead of replaying a poisoned message.