Degraded response generation and poor compatibility with Gemini models

[yakushevhk]

Description

Running deepseek-harness with Gemini models (or proxy endpoints forwarding to Gemini) exhibits poor response quality and instability.

Symptoms

• Responses stall, fail to parse correctly, or return malformed outputs.
• Inconsistent streaming behavior and token handling during model execution.
• Tool-calling integration and schema parsing degrade significantly when hooked up to Gemini endpoints.

[PerryLink]

先说清 DSH 对模型端点的要求，再说"Gemini 这一路"最可能卡在哪

1. 本仓只适配两类协议，而且没有 Gemini 专用适配器

packages/llm/ 下与模型接入有关的就是 llm-deepseek 与 llm-pi-ai（外加 llm-retry、token-meter 这类横切件）。自定义 provider 走的是"按 base URL + 协议 + 模型声明"的路径，界面里可选协议只有三种（ui-settings-models 的文案）：

protocolOpenAiCompletions : OpenAI Chat Completions
protocolOpenAiResponses   : OpenAI Responses
protocolAnthropicMessages : Anthropic Messages

没有 Gemini 原生协议。 所以你必然是"Gemini 直连"或"某个 OpenAI 兼容中转"，而这两条路都会在下面几处与预期不同。

2. 具体会在哪里退化（你说的三个症状都能对上）

• 流式分片：DSH 按协议的 SSE 帧形状解析，并对协议违规明确失败（错误码族里有 STREAM_CLOSED、MALFORMED_RESPONSE）。中转层把 Gemini 的流"翻译"成 OpenAI 帧时，最容易出问题的就是帧边界与结束原因——表现就是"卡住 / 解析失败 / 输出畸形"。
• 工具调用：DSH 从 delta 里拼装工具调用的参数（分片到达，需要正确 join）。Gemini 的工具调用结构与 OpenAI 的 tool_calls 不同，中转如果只是把 JSON 塞进 content 或分片切得不合法，就会出现你说的"tool-calling 与 schema 解析显著退化"。
• 思考字段：思考与最终答案是不同块类型（DeepSeek 侧是 native.thinking → reasoning 块）。若中转把模型的 reasoning 放进了非标准字段，DSH 要么看不到它、要么把它当普通文本——这会让"响应质量"看起来变差。
• 工具 schema 的严格性：DSH 把工具的 parameters 原样透传给 provider。如果中转/端点在 schema 上更挑（或反过来更宽松），工具调用就会失败或走形。

3. "空响应"这条也值得知道

有一个已知的漏网路径：DSH 会把"正常结束但一个内容块都没有"的响应当成可重试的 EMPTY_RESPONSE，但那个兜底只在结束原因是 stop 时生效。所以零内容块 + max-tokens 结束会漏过去，落成一条"有回合、没内容"的消息——如果你看到过这种情况，它属于已知缺口。

4. 请补这几样，才能定位到具体一层

1. 你用的协议（上面三个里哪个）+ base URL（域名可以保留，路径可以打码）；
2. 出错回合的 turn/end.reason（尤其 code：MALFORMED_RESPONSE / STREAM_CLOSED / EMPTY_RESPONSE / TIMEOUT）；
3. 是否直连 Gemini 还是经中转，中转是什么（自建？某服务？）；
4. 一两段原始响应的开头（如果有办法从中转侧抓到）。

有了 1 和 2，基本就能判断是"协议翻译错了"还是"模型行为如此"。我不建议在没看到这两个之前就把它当成 DSH 的 bug——因为这条路本身不在本仓适配范围内，而症状又高度符合"中转层的协议翻译不完整"。