[Bug] tool_addition blocks can only be in system messages — 会话中途技能/工具目录变化后，该会话在 Anthropic 官方端永久 400 INVALID_REQUEST

[zjm13800138000]

环境

• DeepSeek Harness Desktop 0.2.1-rc.2（ProductVersion 0.2.1.0），channel nightly
• Windows 11 x64
• 内置 @anthropic-ai/sdk（含 BetaToolRunner，支持 tool_addition / tool_removal）
• 会话模型原本指向一个自建 Anthropic 兼容端点（本机局域网内另一台机器上的推理服务），复现时把模型切到 Anthropic 官方端点

现象

切换模型后该轮直接失败，UI 显示：

本轮运行失败 messages.340: `tool_addition` blocks can only be in `system` messages
(request_id: 3ee02c50-1f9f-4871-a0bd-859aab4745c6)

同一个会话切回自建 Anthropic 兼容端点则正常，说明这个块确实被发出去了，只是官方端校验更严。

复现条件

1. 长会话运行中，会话中途工具/技能目录发生变化（客户端收到 "The available skill catalog changed. This complete catalog replaces every earlier available-skills list…" 这类系统提示，同时 runtime context 变化）。
2. 下一次请求里出现 tool_addition 内容块。
3. 此时上游是 Anthropic 官方端点 → 400，整轮失败。

代码定位

resources/app.asar 第 181310–181312 行（另有 182083–182085、212480 两处相同实现）：

content.push({ type: 'tool_addition', tool: { type: 'tool_definition', definition } });
// ...
return { role: 'system', content };

SDK 生成的这条消息 role 是 system，位置本来是对的。但官方 API 报的是 messages.340 里该块不在 system 消息中——说明在 SDK 之后、发请求之前，有一层把 role:'system' 的消息转成了普通消息（Anthropic 的 messages 数组不接受 system 角色，system 是顶层参数）。怀疑问题出在这个 provider 适配层的转换。

期望行为

tool_addition / tool_removal 块应当：

• 放进顶层 system 参数（或官方 API 允许的位置），或
• 在适配层保留其 system 角色，不要在转换时降级为 user/assistant 消息。

已确认：不是一次性，会持续失败

同一个会话连续三轮全部失败，错误码 INVALID_REQUEST，messages.340 位置不变，request_id 各不相同：

3ee02c50-1f9f-4871-a0bd-859aab4745c6
72ef9659-f48c-423a-8fef-203a6595ad9f
24b34428-4cf1-4e6d-93e2-cdfa0aec2608

说明这条含 tool_addition 的消息已经留在会话历史里，之后每次请求都会重发，重试无法恢复。该会话在切到官方端点前是正常的，切回自建 Anthropic 兼容端点也正常。

影响：一旦某个长会话触发过工具/技能目录变更，它在 Anthropic 官方端点上就永久不可用（只能开新会话，或换宽松的上游）。这不是偶发失败，是会话级不可恢复。

同类报告（同族问题，但不是同一条）

先更正：早先用 search/issues 查 repo:deepseek-ai/deepseek-harness tool_addition 得 total_count=0，这个查询不覆盖 Discussions，所以当时"没人报过"的结论不成立。
2026-10-22 改用 Discussions 列表 API 逐页扫标题+正文：最新 3,400 条（共 104 页 ≈10,300 条，未登录 API 限额 60 次/小时，其余 6,900 条未扫）中 tool_addition / can only be in "system" messages 命中 0 条 → 这条错误文案应是首次报告。

但"历史里某个块不合法 → 官方端每条后续请求永久 400、会话作废"这一族已被反复撞到，可作交叉引用：

• [Bug] 会话历史包含孤立 UTF-16 代理码元后，所有后续请求持续返回 HTTP 400 `INVALID_REQUEST` #436 [Q&A] 会话历史包含孤立 UTF-16 代理码元后，所有后续请求持续返回 HTTP 400 INVALID_REQUEST
• [Bug] 会话历史含孤立代理项（JS .slice() 切断 emoji 代理对）后，dsh-llm-deepseek 所有请求被 API 以 HTTP 400 拒绝，且错误文案无法定位根因 #967 [General] 同族根因：JS .slice() 切断 emoji 代理对 → 所有请求被 400 拒绝，且错误文案无法定位根因
• Session permanently poisoned after a tool-dispatch crash: dangling `tool_calls` make every later request fail with 400 "insufficient tool messages" #571 [General] Session permanently poisoned after a tool-dispatch crash: dangling tool_calls make every later request fail with 400 "insufficient tool messages"
• Bug: Web UI multi-turn sessions drop reasoning blocks — 400 "reasoning_text must be passed back" (openai-responses custom provider) #231 [General] Bug: Web UI multi-turn sessions drop reasoning blocks — 400 "reasoning_text must be passed back" (openai-responses custom provider)
• [Bug] 思考模式下工具调用返回 400 INVALID_REQUEST — reasoning_content 未回传 #739 / ds你自己都不在源码上支持切换思维等级。本轮运行失败The `reasoning_content` in the thinking mode must be passed back to the API. INVALID_REQUEST #906 / 【BUG反馈】pi-ai DeepSeek 路由在回传跨 provider 历史消息时丢失 reasoning_content #1146 [General] 思考模式下 reasoning_content 未回传 → 400 INVALID_REQUEST

共同点：provider 适配层往上游回传历史块时形状不合法，且因为块已固化在会话历史里，失败是会话级不可恢复的。本条的 tool_addition 是这一族里的新的一块（触发点是会话中途工具/技能目录变化）。

[argszero]

Thanks for the request ids and the "still failing on the third turn" evidence — that is what made this diagnosable. I re-derived the mechanism from the shipped 0.2.1-rc.2 packages rather than from the report alone, and one part of the diagnosis needs correcting.

The harness has no step that downgrades these blocks to a user/assistant message. Both serializers that can emit them refuse instead of relocating them: @deepseek-ai/dsh-llm-pi-ai throws UNSUPPORTED_CONTENT when a non-developer message carries one (lib/index.js:1215), and @deepseek-ai/dsh-llm-deepseek throws UNSUPPORTED_CONTENT for "tool-change blocks outside developer messages" in its serializer. The {type:'tool_addition', tool:{type:'tool_definition', …}} shape you quoted, together with return { role: 'system', content }, comes from the bundled @earendil-works/pi-ai library, not from the harness: the harness hands that library a neutral IR (toolsAdded / toolsRemoved on a system entry, dsh-llm-pi-ai lib/index.js:1307-1330) and the library builds the wire body. So a tool_addition sitting in a non-system message at messages.340 is not a role the harness wrote.

What the harness does do is decide whether to send these blocks at all from the model entry, not from the endpoint it points at. conversationUpdates() derives toolUpdate: 'in-history' from the entry's compat.supportsMidConvoToolChanges (dsh-llm-pi-ai lib/index.js:789), and the projection that consumes it (projectToolUpdates, packages/llm/llm/src/content.ts:424) runs on the declared value alone. Point a declaring entry at an endpoint that cannot carry mid-conversation tool changes and every later request keeps carrying the blocks. You observed exactly that: the same session is fine on your own endpoint and permanently broken on the official one, with messages.340 never moving, because the blocks are durable history and each request resent them.

Two consequences follow, and they are both worth knowing before burning more turns on retries. Retrying cannot recover the session — only the outgoing request can be changed. And a fix aimed at "restore the system role" would not help: whether the official endpoint accepts the block turns on the mid-conversation-tool-changes-2026-07-01 beta opt-in travelling with the request. dsh-llm-deepseek adds that header itself whenever the body carries such a block; the pi-ai path only reshapes the request when every declared tool is deferred (dsh-llm-pi-ai lib/index.js:1949), so a mixed tool table reaches the wire by a different route.

Containment, available now. I packaged the projection as a plugin for the routes an operator names:

https://github.com/argszero/dsh-tool-update-route-guard (commit 54ecf0e, v0.1.0)

npm install github:argszero/dsh-tool-update-route-guard

Mounting it is one patch entry; config.routes lists the provider/model globs whose endpoint cannot carry these blocks, and audit: true reports without changing anything. For each matching route it re-dispatches the request with the core's own unsupported-route projection, so the outgoing body is exactly what the harness already sends to a route declaring nothing. Durable history is untouched, the session stops failing, and the guard can be removed again.

The evidence is wire-level, not object-level: driving the published @deepseek-ai/dsh-llm-deepseek adapter with a capturing fetch shows the unguarded request going out as role: user, system with a tool_addition block and anthropic-beta: mid-conversation-tool-changes-2026-07-01, and the guarded request going out with neither — while the credential headers, the user turn and the tool declarations survive. 33 tests, 31 injected defects all caught, and a mount smoke on the published cordis.

What this does not fix, plainly: the plugin contains the symptom only on routes an operator names. The defect is that a capability describing an endpoint is declared on a model entry, and the real fix belongs in the core — either resolving the capability from the endpoint, or letting a route lose the declaration once its endpoint rejects the blocks. Until then this is a workaround, and I would rather say so than imply the report is closed.

Two things from you would settle the remaining ambiguity: did the failing request carry that beta header, and does a turn with no tool-catalogue change succeed on the official endpoint? I could not test against the official API myself.