[Bug] 混合 provider 会话切回 deepseek-official（Anthropic Messages）后必现 400：tool_use 历史缺 thinking 块

[faruto]

环境

• DeepSeek Harness 0.2.1-rc.2（Windows 桌面版）
• 路由 deepseek-official（Anthropic Messages 兼容端点 https://api.deepseek.com/anthropic/v1/messages），适配器 @deepseek-ai/dsh-llm-deepseek@0.2.1-rc.2
• 同一会话历史里混用过多个路由：deepseek-official/deepseek-flash、workbuddy/deepseek-v4.1-flash、agent2api/deepseek-v4.1-flash、deepseek-account/deepseek-flash、xiaomi/mimo-v2.6-flash

现象

会话切回 deepseek-official 后，任何一条消息都失败（包括纯文本续聊）：

本轮运行失败  DeepSeek Messages request failed (400)  INVALID_REQUEST

服务端原文：

The `content[].thinking` in the thinking mode must be passed back to the API.

新开会话直接用 deepseek-official 正常；切到 xiaomi / workbuddy / agent2api 也正常。只有「混合历史 + 切回官方」这个组合必挂。

复现

1. 新会话用 deepseek-official 跑几轮带工具调用的对话（历史里产生 reasoning + tool_use）。
2. 中途切到任一 llm-pi-ai 路由（workbuddy / agent2api / xiaomi）继续跑几轮工具调用。
3. 切回 deepseek-official，发任意一条消息 → 400，且此后每一轮都 400。

最小对照矩阵（同一会话内实测，请求体直接打端点）

请求历史形态	结果
带 tool_use 的消息带 thinking 块（无 signature）	200 ✅
带 tool_use 的消息带 thinking 块（有 signature）	200 ✅
带 tool_use 的消息无 thinking 块	400，同一句
纯文本 assistant、无 thinking 块	200 ✅
thinking disabled + 带 tool_use 历史	200 ✅

由此收敛：该端点（thinking enabled）要求历史中每条带 tool_use 的 assistant 消息都回传 thinking 块；signature 缺失与否不是问题（第 1、2 行都 200）。当前 DSH 在历史来自其他 provider（其 assistant 消息没有 reasoning 块）时，序列化不出 thinking 块，于是 400。

源码定位

打包产物 packages/llm/llm-deepseek/lib/index.js（0.2.1-rc.2）：

• assistant()（约 1551-1573 行）只在历史块 block.type === "reasoning" 时输出 { type:"thinking", thinking: block.text, ...signature }；tool-call → tool_use。对「有 tool-call 但无 reasoning 块」的历史消息，不补 thinking 块，也不做兼容降级。
• readReplay()/validateReplay()（约 1504-1533 行）在 response.model !== 当前 model 时返回 undefined（跨模型签名不可移植），这与本次 400 无关——无签名 thinking 照样 200（矩阵第 1 行）。
• 本地 INVALID_REQUEST 前置检查（约 1699-1706 行）只校验 tool id 配对，不校验 thinking 回传。

与已有讨论的关系

• 偶尔报错`content[].thinking` in the thinking mode must be passed back to the API #7715：同一错误句，但只有一句话，没有细节和复现（本贴补全）。
• [Bug] 历史里的空 reasoning 块会序列化成空 thinking 块，导致已有会话切到严格的 Anthropic Messages 网关后永久失败 #9239 / [BUG] 空的 reasoning 块被持久化并回放导致 HTTP 400 错误 #9435：是「空 reasoning 块 → 空 thinking 块」被严格网关拒绝；本问题是「缺 thinking 块」。社区插件 @argszero/dsh-empty-block-guard 与空块清洗对本问题无效。
• Bug：切到第三方模型后，多轮对话报 400：reasoning_text must be passed back #1780：llm-pi-ai 的 reasoning_text 签名丢失（OpenAI Responses 方言），与本案不同端点，但修法可借鉴：对跨 provider 的 tool-call 轮合成 thinking/signature。
• llm-deepseek: thinking-off requests still serialize historical reasoning_content -> DeepSeek 400 #4822：反向问题（thinking-off 时仍回传历史 reasoning_content）。

期望

1. 切到 deepseek-official（或任何要求 thinking 回传的 Anthropic Messages 端点）时，对「带 tool-call 且无 reasoning 块」的历史消息做兜底：合成 thinking 块（参考 Bug：切到第三方模型后，多轮对话报 400：reasoning_text must be passed back #1780 的 foreignAssistant），或
2. 无法合成时，自动降级 thinking 或明确提示并在 UI 给出恢复路径（新开会话 / 换路由），而不是直接把 400 抛给用户；
3. 顺手把错误文案映射成可读提示（当前 UI 只有 INVALID_REQUEST）。

影响

长会话中途换模型是常见用法。一旦历史被「污染」，该会话就永久无法再用 deepseek-official，只能换 provider 或丢历史新开。0.2.1-rc.2 上可稳定复现。

[argszero]

Your source reading holds up on master at 687f282e86, and the mechanism narrows a little further than the report states. Line numbers below are from the source tree, not the bundled lib/.

The serializer has exactly one place that can emit thinking

packages/llm/llm-deepseek/src/serialize.ts:24-37, assistant():

case 'reasoning': return { type: 'thinking', thinking: block.text,
  ...replay?.[index]?.signature === undefined ? {} : { signature: replay[index].signature } }
case 'tool-call': return { type: 'tool_use', id: block.id, name: block.name, input: toolInput(block.arguments) }

So the wire carries a thinking block if and only if the durable assistant message already holds a reasoning block. Nothing synthesizes one, and nothing inspects the pair "tool_use present, thinking absent".

The local INVALID_REQUEST precheck is serialize.ts:131-146: it walks the built wire messages and validates tool pairing only — duplicate tool_use id, result without a call, call without an immediate result. It never looks at thinking. That is why the failure arrives as the provider's own 400 rather than a local error.

serialize.ts:147-157 is where thinking gets switched on:

const effort = options.reasoningEffort ?? (connection.defaults.reasoningEffort ?? (connection.defaults.thinking === 'disabled' ? 'off' : 'high'))
...
thinking: { type: effort === 'off' ? 'disabled' : 'enabled' },

Two consequences worth having in the thread:

1. The poison set is narrower than "mixed history". replay.ts readReplay() drops a signature when the producing model differs, but the reasoning block itself is durable content and still serializes — with the signature omitted, which your matrix row 1 shows is accepted. A history assembled from other routes is therefore not automatically poisonous; only the turns produced without a reasoning block at all (thinking off on that route, or an adapter that emits none) are. Migrating a session that always ran with thinking on would not hit this.
2. The failure is per-history, not per-request. The 400 repeats because the offending messages are durable and every later request re-serializes them unchanged — which is what makes it look permanent.

Your #1780 comparison is apt but points the other way: packages/llm/llm-pi-ai/src/replay.ts:152-181 foreignAssistant() maps reasoning → thinking and tool-call → toolCall, and also does not synthesize a thinking block for a tool-call turn that has no reasoning. Both adapters make the same choice, so this is a route-agnostic asymmetry, not a DeepSeek quirk.

Why a synthesized block is representable

packages/llm/llm/src/types.ts:67-71 — a durable reasoning block is only { type: 'reasoning', text: string }. The signature is not part of it; it lives in the index-aligned ReplayEnvelope (replay.ts ReplayBlock). So "add a thinking block without a signature" is a legal durable shape, and a runtime rewrite can produce it without touching persisted history — your matrix row 1 is the wire-side confirmation.

One constraint that matters for any fix: the synthesized text must be non-empty. Empty thinking content is a separate rejection family (#9239 / #9435), so replacing "no block" with "empty block" just moves the 400.

Where a fix can live

• Core — in assistant(), or in the post-pass at :131-146, emit a documented placeholder thinking block when the request has thinking enabled and an assistant message carries tool_use without reasoning. One place, covers both the current request and replay.
• Runtime, without waiting for a release — llm/stream receives the derived request (GenerateOptions, with provider, model, messages) before the adapter serializes it, and a listener can re-dispatch a replacement request whose such messages carry a synthesized reasoning block. That is mountable on 0.2.1-rc.2 today, and it also makes your suggestion 2 expressible without an adapter change: re-dispatch with reasoningEffort: 'off', which :148 always accepts, trading the model's thinking for a usable session instead of a permanent 400.
• Not runtime-fixable: mapping INVALID_REQUEST to a readable message is a UI-side projection of an error whose origin is the provider's response body; the harness-level fix is upstream.

I'll follow up with a plugin for the middle bullet (the gap is worth closing while the core decision is open). Thank you for the controlled matrix — the "thinking without signature → 200" row is what makes the runtime route viable at all.

[argszero]

A plugin form of the runtime layer is now available: @argszero/dsh-thinking-roundtrip-guard — https://github.com/argszero/dsh-thinking-roundtrip-guard

npm publication is pending credentials on my side, so the repository is what is installable today:

dsh plugin add github:argszero/dsh-thinking-roundtrip-guard

What it does: it listens on the llm/stream waterfall and repairs the outbound request. The durable session log is not touched, so removing the plugin removes the workaround.

• synthesize (default) — inserts a placeholder thinking block ahead of every historical assistant turn that carries a tool call and no reasoning block. Your control matrix is what makes this the default: the block without a signature answered 200, so the missing entry, not the missing signature, is the whole defect.
• degrade — sends the same history with reasoning effort off, the row you measured as 200. It reads nothing from the provider, so it is the deterministic escape if another endpoint words the rejection differently.
• observe — counts what would be repaired and changes nothing.
• If a repaired request is still rejected before any visible output, that terminal frame is withheld and the original history is retried with reasoning off — so exactly one terminal frame reaches the caller, never a leaked failure followed by a successful retry.

The default route allowlist is ['deepseek-official']; add your own Messages-shaped routes through providers, or set providers: [] to cover every route. ctx.get('thinkingRoundtripGuard')?.snapshot() reports the counters, the refused configuration values, and the plugin's own blind spots.

Why it is a workaround rather than the fix: a plugin cannot see a connection's thinking defaults (the serializer reads connection.defaults), so it acts on the routes it was told about instead of on a proven enabled-thinking state. The real fix belongs in the serializer or the request assembly, where that policy is known; this keeps the session usable until then.

Verification: 52 assertions against a real cordis context and the real llm/stream waterfall, with a control arm that shows the request an adapter receives today; 14 plausible defects injected into the shipped lib/ one at a time, 14/14 caught.

Relation to the rest of the thread: this is your #1780 remedy — synthesize the cross-provider block — applied where the requirement is enforced rather than merely convenient, and it composes with the empty-block guard from #9239: a turn that already carries a reasoning block is never rewritten, empty or not.