[BUG]推理模型在仅支持 system role 的 OpenAI 兼容端点上请求失败

[zakahan]

使用 OpenAI Chat Completions 兼容接口时，为自定义模型开启 reasoning effort 后，DSH 会把 system prompt 以 developer role 发送。仅支持 system、assistant、user 和 tool 的供应商因此返回 400。

English summary: When reasoning is enabled for a custom OpenAI-compatible model, DSH sends the system prompt with the developer role. Providers that do not support this role reject the request. Reasoning effort and the system/developer role selection should be independently configurable.

复现、实际结果、预期结果与建议验收条件

复现

1. 配置一个使用 openai-completions（Chat Completions API）的自定义 OpenAI 兼容供应商。
2. 为模型配置 reasoningEfforts。
3. 选择一个 reasoning effort 并发送请求。

本次实测供应商为火山引擎 Ark。实际错误如下，请求 ID 已脱敏：

# test from volcengine-ark
400: {"code":"InvalidParameter","message":"The parameter `messages.role` specified in the request are not valid: invalid value: `developer`, supported values are: `system`, `assistant`, `user`, `tool`. Request id: 021786*************","param":"","type":"BadRequest"}

实际结果

启用 reasoning effort 后，原本的 system prompt 被序列化为 developer role。供应商不支持该角色，请求在模型推理前直接失败。

预期结果

reasoning effort 与 system/developer role 的选择应能独立配置。对于不支持 developer role 的 OpenAI 兼容供应商，应能继续发送 system role，同时保留 reasoning_effort。

期望可以配置：

compat:
  supportsDeveloperRole: false

上游 @earendil-works/pi-ai 已定义 supportsDeveloperRole?: boolean，但 DSH 当前的 PiAiCompatProfile 和配置 schema 只暴露 thinkingFormat 与 supportsReasoningEffort，因此无法从 DSH 配置传入该字段。

可能的影响范围

• openai-completions：已通过火山引擎 Ark 实际复现。
• openai-responses：尚未实际复现，但代码路径也会在 model.reasoning 为真且 supportsDeveloperRole 未设为 false 时选择 developer role，可能存在相同兼容性问题。

相关 DSH 代码：

• packages/llm/llm-pi-ai/src/catalog.ts：PiAiCompatProfile、模型 reasoning 配置和 compat 转换。
• packages/llm/llm-pi-ai/src/config.ts：compat 配置 schema。

环境

• @deepseek-ai/dsh-llm-pi-ai: 0.1.0-rc.5
• DeepSeek Harness commit: 47f943859b
• Node.js: v22.16.0
• Provider: Volcengine Ark
• API mode: openai-completions / Chat Completions

建议验收条件

1. DSH 暴露并转发 compat.supportsDeveloperRole: false。
2. openai-completions 设置该选项后仍发送 system role，并继续发送所选 reasoning_effort。
3. 检查并支持 openai-responses 的同一选项；保留 reasoning.effort，同时发送 system role。
4. 未设置该选项时保持现有默认行为。
5. 为两种 API 模式分别添加覆盖测试。

[Electricitysheep]

developer role 在仅支持 system 的 OpenAI 兼容端点上失败——经典网关方言问题，我们 FAQ 记录过同族（#280/#614）：配 compat.supportsDeveloperRole: false 让它退回 system role。

https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/faq.md

[zakahan]

感谢补充，个人认为这个问题应该被更直接的解决，没必要走第三方插件，至少dsh本体需要开放supportsDeveloperRole。

[Electricitysheep]

同意——supportsDeveloperRole 这类兼容开关应该在 dsh 本体开放，而不是靠第三方插件绕。第三方网关是刚需场景（不是小众），官方把它做成配置项是成本最低的正解。我们 FAQ 里也标了"等官方开放"：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/faq.md

[weijiafu14]

这个 400 可以用一条不修改 Harness 源码的 provider 路线绕开。手写 llm-pi-ai 配置会丢 supportsDeveloperRole；Pi provider 插件自己的模型描述不会。

dsh plugin --profile web add pi2dsh
dsh plugin --profile web add <对应网关的 Pi provider 包>

pi2dsh 把自带 transport 的 Pi provider 注册为 DSH 原生 LLM adapter。透传录制验证过：provider 声明 supportsDeveloperRole: false 后，请求第一条角色实际是 system，同时 DSH 选择器选中的推理档位也进入线上请求。

会话、重试、日志和子代理仍然是 DSH；只替换模型 route 的请求 adapter。复现探针在 examples/gateway-compat。