[Bug] DSH桌面版 0.1.0-rc.6 自定义中转站 DeepSeek V4 调用工具报 400 错误

[crazyboy5]

标题：DSH 使用自定义中转站时，DeepSeek V4 推理模型在工具调用轮次必现 400

环境

• DSH 版本：0.1.5-rc.2
• 操作系统：Windows 11
• 接入方式：自定义 OpenAI 兼容中转站（地址已脱敏）
• 协议：openai-completions
• 默认模型：gpt-5.6-terra（可用）
• 问题模型：deepseek-v4-flash、deepseek-v4.1-flash（必现 400）

复现步骤

1. 在 settings.yaml 中配置自定义中转站，api 设为 openai-completions。
2. 将默认模型切换为 deepseek-v4-flash 或 deepseek-v4.1-flash。
3. 新建会话，发送中文指令：“帮我列出当前目录的文件”。
4. 模型先输出 Think 思考内容，然后尝试调用 Pwsh 工具。
5. 工具调用轮次返回 400。

实际结果

本轮运行失败 400:
{"message":"Upstream error: 400","type":"invalid_request_error"}
代码：INVALID_REQUEST

对比测试

同一中转站、同一配置下，切换模型为 gpt-5.6-terra，工具调用正常。只有 DeepSeek V4 系列在开启思考模式并调用工具时必现 400。

推测原因

DSH 在序列化包含 tool_calls 的 assistant 历史消息时，可能丢弃了 reasoning_content 字段，导致中转站校验失败。非推理模型不受影响。

已尝试的兼容配置（均无效）

compat:
supportsDeveloperRole: false
requiresReasoningContentOnAssistantMessages: true
thinkingFormat: deepseek
supportsStrictMode: true
suppressReasoningContentReplay: false

附件

• session log（已脱敏，完整记录了 400 错误的触发过程和与 gpt-5.6-terra 的对比测试）
• settings.yaml（已脱敏）

[PerryLink]

先回答最关键的一点：你列的五个 key 里有一个不存在 —— suppressReasoningContentReplay 在整个仓库里没有任何命中，它既不在 schema 里（packages/llm/llm-pi-ai/src/config.ts:254-281），也不在 COMPLETIONS_COMPAT_GATE 里（packages/llm/llm-pi-ai/src/catalog.ts:231-258），我在安装的 pi-ai 0.85.1 里也没搜到。另外四个都存在，而且对 openai-completions 都是可配置的：

key	是否存在	依据
supportsDeveloperRole	是	config.ts:256、catalog.ts:233（offer）
requiresReasoningContentOnAssistantMessages	是	config.ts:264、catalog.ts:241（offer）
thinkingFormat	是，deepseek 是合法值	config.ts:265、catalog.ts:242；可选值见 catalog.ts:99-114，deepseek 在 catalog.ts:101
supportsStrictMode	是	config.ts:272、catalog.ts:248（offer）
suppressReasoningContentReplay	否	全仓库无命中

重要的是：未知的 compat key 不是被静默忽略的。catalog.ts:537-557 的 assertOfferedCompatFields 会把没被任何协议声明的键直接判错并点名，错误信息里还会列出真正可配的开关；值为空的键也一样被拒（catalog.ts:566-569）。这个校验对 route 级和 model 级都会跑（catalog.ts:879、catalog.ts:883）。所以如果那一行真的落在 compat: 下面，你的 profile 应该会被拒绝并报错，而不是"改了没用"。请先确认这一点：那行 suppressReasoningContentReplay 到底写在哪一层？如果它被别的 schema 吃掉了、根本没进 llm-pi-ai 的 compat，那么你后面那几次尝试的结论都要重来。

放置位置：compat 在 route 上和每个 model 上都合法（route：config.ts:329；model：config.ts:311 经 modelFields），model 逐字段覆盖 route（catalog.ts:342-343）。settings.yaml 里的段名是 llm-pi-ai（packages/llm/llm-pi-ai/src/index.ts:5-7），下面才是 providers.<你的路由名>。

关于你的推测（带 tool_calls 的 assistant 历史丢了 reasoning_content）：形状不对。回放时写哪个 reasoning 字段，取决于 thinking 块带的 thinkingSignature 是否落在 reasoning / reasoning_content / reasoning_text 里（pi-ai 0.85.1，dist/api/openai-completions.js:155 与 :1001-1007），而且 :999 在有 preservedReasoningDetails 时会整段跳过。tool_calls 的映射在 :1019-1041，在 reasoning 写入之后、且不参与那个判断 —— 所以"因为有 tool_calls 所以不写 reasoning_content"不是这段代码的行为。另外，requiresReasoningContentOnAssistantMessages: true 的语义是补一个空字符串，不是把真实 reasoning 补回去（:1045-1049：assistantMsg.reasoning_content = ""）。你把它设成 true 却没用，和"中转站要的是真实 reasoning 内容而不是空串"是相容的 —— 这一点是我的推断，未验证。

建议的下一步（一条就够）：把出站请求体抓下来。我没在仓库里找到 DSH 自带的"打印出站请求体"开关（搜了 DEBUG、DSH_DEBUG、DSH_LOG、logLevel 等均无命中；我只说"我没找到"，未能证明不存在）。可行的做法是把 baseURL 指向一个本机打印请求体的转发代理，再原样转发到中转站；或者直接找中转站要它的上游请求日志。

原因是你手上那条 400 的 body 没有信息量：{"message":"Upstream error: 400","type":"invalid_request_error"} 是中转站自己的通用包装，里面没有字段名。DSH 侧只是按文案把它归成 INVALID_REQUEST（packages/llm/llm-pi-ai/src/stream.ts:49 命中 400 / invalid request），而这个码不在默认可重试集合里（packages/llm/llm/src/retry-policy.ts:18-24），所以必现即终态。真正指出是哪个字段被拒的，只有中转站的上游错误原文 —— 拿到它才能定位，否则我们只是在猜。

顺带一个可能更省事的方向：不要手写路由，把路由名直接命名成 deepseek。按仓库自己的说明，pi-ai 在没有显式配置时会从 provider id 和 baseURL 推断这些兼容开关，而"私有网关的 URL 什么也说明不了：对不认识的端点，推断结果等同于它就是 OpenAI 本身，这对大多数 OpenAI 兼容网关都是错的"（catalog.ts:345-350）。手写路由正好落在这个坑里，而 catalog 路由会带上该厂商需要的开关（同样的取舍写在 catalog.ts:218-221 与 :553-554）。baseURL 是可以覆盖的（catalog.ts:893：request.baseURL ?? base?.baseUrl ?? providerBaseUrl），所以命名成 deepseek、把 baseURL 指向你的中转站是可行的形状；你的中转站是否真的按 DeepSeek 官方协议转发（尤其 reasoning_content 的收发语义），需要你自己确认，未验证。

[crazyboy5]

感谢您的指导。我通过本地 Fiddler 代理成功抓到了触发 400 错误的完整出站请求体，附件是脱敏后的 6_Request.json。

同时，我定位到了问题的根本原因并成功修复了它。

原来 DSH 在请求时默认发送了 max_completion_tokens 和 store 这两个字段，但我的中转站（以及可能其他 OpenAI 兼容网关）严格校验了这些字段，一旦发送就会返回 400。之前中文报错而英文 hello 不报错，大概率是因为中文上下文触发中转站更严格的格式检查。

修复方法：在 settings.yaml 的 llm-pi-ai.providers.s1.compat 配置下，加上这两行就完全解决了：

supportsMaxOutputTokens: false
supportsStore: false

附件
6_Request.json（脱敏后的出站请求体）

[argszero]

I could not reproduce this as a reasoning_content-dropping bug, and while measuring I found one item in your compat list that breaks every request on that route. Below is what I actually observed on the wire. All of it comes from a local OpenAI-compatible relay plus a route declared exactly like yours (api: openai-completions, own models list) driven through the real @deepseek-ai/dsh-llm-pi-ai adapter at 0.1.5-rc.2 (pi-ai 0.85.1).

1. The reasoning text does reach the wire

Two-turn replay: turn 1 the relay answers with thinking + a tool call; turn 2 is the round you say 400s. Recorded bodies:

• relay streams reasoning_content → turn 2 sends
  {"role":"assistant","content":null,"reasoning_content":"I should list the files.","tool_calls":[…]} — the full thinking text, as the provider's own field.
• relay streams structured reasoning_details → turn 2 sends …,"reasoning_details":[{"type":"reasoning.text","index":0,"text":"I should list the files."}] instead, with no reasoning_content (details are replay metadata for pi-ai, so it replays them in the shape it received).

So the durable thinking text is preserved in the request. What varies is which key carries it — and which key your relay insists on.

2. One entry in your compat list is not a real switch

suppressReasoningContentReplay does not exist in pi-ai 0.85.1. dsh accepts unknown compat keys when you write the configuration, then rejects them at dispatch, so every model call on that route fails before it reaches your relay:

llm-pi-ai: provider "<route>" route sets compat "suppressReasoningContentReplay", which no wire protocol declares;
the configurable switches are supportsStore, supportsDeveloperRole, supportsReasoningEffort, supportsUsageInStreaming,
supportsFinishReason, maxTokensField, requiresToolResultName, requiresAssistantAfterToolResult, requiresThinkingAsText,
requiresReasoningContentOnAssistantMessages, thinkingFormat, chatTemplateKwargs, chatTemplateArgs,
supportsThinkingTokenBudget, thinkingTokenBudgetField, vllmPriority, supportsStrictMode, cacheControlFormat,
supportsLongCacheRetention, supportsMaxOutputTokens, supportsEagerToolInputStreaming, supportsCacheControlOnTools,
supportsTemperature, forceAdaptiveThinking, allowEmptySignature, supportsStrictTools
code: INVALID_CONFIG

Remove that key first, then re-test — it makes the whole compat block untrustworthy, because with it present none of the other four switches was ever being exercised. (I checked it on your own version; the installed @deepseek-ai/dsh@0.1.5-rc.2 pins pi-ai ^0.85.1, and 0.85.1 is what resolves.)

3. requiresReasoningContentOnAssistantMessages is inert on a custom route

Inside pi-ai that switch is gated on the model being a reasoning model as well:

if (compat.requiresReasoningContentOnAssistantMessages && model.reasoning && assistantMsg.reasoning_content === undefined)
    assistantMsg.reasoning_content = ""

On a route the installed catalog does not describe, model.reasoning is false unless the model entry declares reasoningEfforts — dsh resolves it as base?.reasoning ?? false, and there is no catalog entry under your custom provider key. I reproduced exactly your "the compat settings had no effect": with the switch set true and no reasoningEfforts, the request goes out with no reasoning_content key at all; with reasoningEfforts declared, the same switch produces "reasoning_content":"". This also explains why it could not have been the fix even if it applied — an empty string is not the thinking text.

4. My best hypothesis for your 400, and how to settle it in one look

If your relay reports reasoning as structured reasoning_details (OpenRouter-style) rather than a plain field, the replay carries the thinking under reasoning_details and never as reasoning_content — so a relay that requires a non-empty reasoning_content on tool-call assistant messages rejects every such round, while non-reasoning models (no thinking block at all) pass. That matches your comparison test exactly.

You can confirm it from the session log you already have. Open the first assistant message of the failing session and look at

source.replayState.blocks[0].thinkingSignature

• starts with [{"type":"reasoning → structured details; your relay is in the case above.
• equal to "reasoning_content" → plain field; then the field is being sent and the 400 is coming from something else in the payload (the same request also differs from the catalog route in other ways — I saw store, max_completion_tokens instead of max_tokens, and no thinking object unless thinkingFormat is set), and the response body of the failing call would be the thing to look at.

Either way, sending me the session log plus your settings.yaml will let me reproduce it exactly — the two files you attached are not visible from the discussion page.

Suggested fixes on the harness side

1. Refuse an unknown compat key where the configuration is written, not on the first request. A switch that cannot be applied should not be silently accepted and then fail a round with INVALID_CONFIG.
2. requiresReasoningContentOnAssistantMessages is a user statement about the endpoint; it should not also depend on the harness's own guess of whether the model reasons. As written, the explicit switch is the weaker of the two inputs.
3. When the provider reports reasoning only as structured reasoning_details, the durable assistant message keeps an empty reasoning block — the text survives only as an opaque signature. Worth deciding deliberately: it means the thinking is neither persisted nor visible, and is unrecoverable if that signature is ever dropped.

Thanks for the detailed report — the comparison test with a non-reasoning model on the same relay was the part that made this tractable.

[crazyboy5]

感谢你的回复！我通过 Fiddler 抓取出站请求体数据之后，让 DeepSeek 自己分析，已经成功解决了这个问题。

问题根源在于：DSH 默认发送了 max_completion_tokens 和 store 这两个字段，但部分 OpenAI 兼容中转站（比如我用的）会严格校验这些字段，一旦包含就返回 400。

解决方法是：在 settings.yaml 的 compat 配置中，加上以下两个参数（请直接复制到你的配置中）：

llm-pi-ai:
  providers:
    s1:
      displayName: 自定义中转站
      apiKeyEnv: YOUR_API_KEY_ENV
      api: openai-completions
      baseURL: https://<your-gateway>/v1
      compat:
        supportsDeveloperRole: false
        requiresReasoningContentOnAssistantMessages: true
        thinkingFormat: deepseek
        supportsStrictMode: true
        suppressReasoningContentReplay: false
        supportsMaxOutputTokens: false   # <-- 核心修复：阻止 DSH 发送 max_completion_tokens
        supportsStore: false             # <-- 核心修复：阻止 DSH 发送 store 字段
      models:
        - { id: deepseek-v4.1-flash, name: deepseek-v4.1-flash }
        # ... 其他模型保持不变

其中，supportsMaxOutputTokens: false 和 supportsStore: false 是解决问题的关键，加上这两行后，中文请求和工具调用就完全正常了。

另外提醒一下，我排查时还发现桌面版内置的 DSH 核心版本比较老（0.1.0-rc.6），可能与最新版存在差异，建议也检查一下版本。

希望能帮到你！