第三方模型设置思考强度报错

[xdwjc]

在配置settings.yaml配置了reasoningEfforts字段
llm-pi-ai:
providers:
positec:
displayName: ××××
apiKeyEnv: ××××××
api: openai-completions
baseURL: ×××××××
models:
- id: deepseek-v4-flash
contextWindow: 1000000
maxTokens: 256000
reasoningEfforts:
off:
high: high
max: max
- id: deepseek-v4-pro
contextWindow: 1000000
maxTokens: 256000

        界面出现了可以选择的思考强度，但是实际聊天报错：
        400: {"message":"Failed to deserialize the JSON body into the target type: messages[0].role: unknown variant `developer`, expected one of `system`, `user`, `assistant`, `tool`, `latest_reminder` at line 1 column 60","type":"invalid_request_error","param":"","code":"invalid_request_error"}

[XIXIKA-123]

我可以的，你这个配置有问题吧

[yangwuan55]

我没找到在什么地方设置思考强度怎么

[Luca4Don3]

声明 reasoningEfforts 后模型被视为推理模型，system prompt 会以 developer role 发送，而第三方 OpenAI 兼容端点（positec 等）只认 system，所以 400。临时方案是去掉模型条目的 reasoningEfforts（或设 false），代价是思考强度不可用。
也可以改用 OpenCode 官方网关（我本地就是这么跑的）
DeepSeek 官方提供 OpenCode Zen / OpenCode Go 网关（opencode.ai），它兼容 developer role 和 reasoning_effort 参数，所以思考强度（low/high/max）能正常用，不会报 400。我的配置：

llm-pi-ai:
  providers:
    opencode-go:
      displayName: OpenCode Go
      apiKeyEnv: OCG_API_KEY      # 环境变量里配 opencode.ai 的 API key
agent-default-model:
  provider: opencode-go
  model: deepseek-v4-flash
  reasoningEffort: max

模型走 openai-completions 协议，deepseek-v4-flash 支持 low/high/max 三档思考强度，请求直接发 reasoning_effort: max。

[wenheguo2]

rang让DSH给你搞个委派路由并能设置思考模式就行了 不仅主代理可以子代理也可以用自己的思考强度。再牛逼点让主代理可以根据任务强度自动分配思考强度

[weijiafu14]

你这里不是 reasoningEfforts 写错了：声明它以后模型被识别成 reasoning model，但私有网关又被误判为支持 developer，而 DSH settings 不能把 supportsDeveloperRole: false 传下去。

不禁用思考档位的绕法是使用带 transport 的 Pi provider route：

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

pi2dsh 会把它注册进 DSH 原生模型选择器，同时保留 provider 的 compat 和 thinking level map。我们抓过实际请求：选 High 后 effort 真进入请求，system prompt 使用 system 而不是 developer。

如果网关入口是 LiteLLM，可直接用 pi-provider-litellm。

[wenheguo2]

感谢这份非常专业的分析！逐点核对后，你的机制分析完全正确，我们也分别在 pi-ai 源码和真实端点上做了实证，把结论同步一下： 一、机制确认 pi-ai openai-completions.js:787 的判定我们核实了：const useDeveloperRole = model.reasoning &amp;&amp; compat.supportsDeveloperRole; 自定义网关 provider（如 CodeBuddy 的 copilot.tencent.com）确实不在 isNonStandard 名单（名单只有 nvidia/cerebras/xai/together/deepseek.com/zai/moonshot 等），默认 supportsDeveloperRole=true → reasoning 模型发 developer role → 腾讯网关 content-audit 拒绝。compat 配置面确实没有 supportsDeveloperRole 开关（compatProfile schema 只有 thinkingFormat 和 supportsReasoningEffort 两项）——这个缺口值得给 pi-ai 上游提个 issue。 二、官方端点实测：强度传递全部有效 对三个官方 provider 各发两遍同一问题（强度关 vs 高），实测： - DeepSeek 官方（OpenAI · reasoning_effort）：强度高 → HTTP 200，reasoning_tokens = 42，思考真实发生；强度关 → pi-ai 按 thinkingLevelMap off→null 正确省略字段。✅ 生效 - Kimi K3 coding plan（Anthropic · thinking budget）：强度关 → thinking_tokens = 46；强度高 → thinking_tokens = 67，budget 调节可见。✅ 生效（K3 恒思考是网关特性，budget 仍起作用） - ZAI GLM bigmodel coding（OpenAI · thinking 参数）：thinking disabled → reasoning_content = 0 字符；enabled → 310 字符。✅ 生效，开关灵 role 形态：DeepSeek / ZAI 在 pi-ai 内置目录均为 supportsDeveloperRole: false（发送 system role）；Kimi 走 Anthropic 协议（无 developer 概念）。三家官方端点的 role 和强度都没有问题。 三、CodeBuddy 网关：两条实测结论 1. developer role：我们目前的解法是本地 60 行 Node 转发器（127.0.0.1:8790，developer→system 改写后原样透传含 reasoning_effort 的完整请求体），settings.yaml 的 baseURL 指向它。工作稳定，缺点是依赖本机进程——你说的 pi2dsh 路线确实更通用，认可。 2. thinking 参数：腾讯网关忽略 thinking 参数（我们 8/14 抓包结论：GLM 在该网关恒定思考）——字段正确送达但档位无效，属网关侧行为，客户端无解。 四、插件本身零网关依赖 dsh-delegation-suite 的默认路由表用 deepseek-official 官方模型，开箱即用；上述网关行为是「用户自配私有网关 provider」场景下的 DSH/pi-ai 通用行为（与本插件无关，不装插件同样存在）。插件 README 的 FAQ 已写清这三种情况（官方端点生效 / 网关忽略参数 / developer role 被拒的解法），避免后续用户踩坑。 再次感谢反馈，pi2dsh + LiteLLM 的建议很有价值，README 里也引用了这个方向。 原始邮件 发件人：weijiafu14 ***@***.***&gt; 发件时间：2026年8月19日 01:03 收件人：deepseek-ai/deepseek-harness ***@***.***&gt; 抄送：wenheguo2 ***@***.***&gt;, Comment ***@***.***&gt; 主题：Re: [deepseek-ai/deepseek-harness] 第三方模型设置思考强度报错 (Discussion #636) 你这里不是 reasoningEfforts&nbsp;写错了：声明它以后模型被识别成 reasoning model，但私有网关又被误判为支持 developer，而 DSH settings 不能把 supportsDeveloperRole: false&nbsp;传下去。 不禁用思考档位的绕法是使用带 transport 的 Pi provider route： dsh plugin --profile web add pi2dsh dsh plugin --profile web add <对应网关的 Pi provider 包&gt; pi2dsh&nbsp;会把它注册进 DSH 原生模型选择器，同时保留 provider 的 compat&nbsp;和 thinking level map。我们抓过实际请求：选 High 后 effort 真进入请求，system prompt 使用 system&nbsp;而不是 developer。 如果网关入口是 LiteLLM，可直接用 pi-provider-litellm。 — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS&nbsp;and Android. Download it today! You are receiving this because you commented.