llm-pi-ai 的 compat schema 丢弃了 pi-ai OpenAICompletionsCompat 大部分字段（如 supportsDeveloperRole），导致手写 provider 不可用

[royzhrxy-glitch]

摘要

自定义（手写声明）provider 无法通过 llm-pi-ai 设置表达 pi-ai 的大部分兼容性开关。settings 的 schema 只接受 thinkingFormat 和 supportsReasoningEffort 两个字段，pi-ai OpenAICompletionsCompat 中的其余字段——包括 supportsDeveloperRole、maxTokensField、supportsStore——会被静默丢弃。对于 pi-ai URL 自动探测不认识的端点（如火山方舟 ark.cn-beijing.volces.com、Kimi Coding api.kimi.com），这会导致支持推理（reasoning）的自定义路由完全不可用。

环境

• dsh 0.1.0-rc.6（npx @deepseek-ai/dsh web）
• Linux x86_64
• 自定义 provider 声明在 ~/.dsh/settings.yaml 的 llm-pi-ai.providers 下

复现步骤

1. 声明一个指向火山方舟的自定义路由：

llm-pi-ai:
  providers:
    ark-coding:
      api: openai-completions
      baseURL: https://ark.cn-beijing.volces.com/api/coding/v3
      apiKeyEnv: ARK_CODING_API_KEY
      displayName: Volcano Ark Coding Plan
      models:
        - id: deepseek-v4-pro
          contextWindow: 1048000
          reasoningEfforts: { low: low, high: high, max: max }
      compat:
        thinkingFormat: deepseek
        supportsReasoningEffort: true

2. 用该 provider 中任意声明了 reasoningEfforts 的模型开启会话。
3. 发送消息。

实际表现

上游返回 HTTP 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`."}

根因

packages/llm/llm-pi-ai 中 settings 的 compat schema 只有两个字段：

const compatProfile = z.object({
  thinkingFormat: z.union(SUPPORTED_THINKING_FORMATS),
  supportsReasoningEffort: z.boolean()
});

而 pi-ai 请求时使用的 OpenAICompletionsCompat 约有 20 个字段，其 URL 自动探测（detectCompat）对不在已知名单（deepseek.com、opencode.ai、api.x.ai、api.z.ai、api.moonshot.* 等）内的端点，supportsDeveloperRole 默认按 true 处理。ark.cn-beijing.volces.com 和 api.kimi.com 不在名单内。

因果链：

1. 手写模型一旦声明 reasoningEfforts，reasoning 变为 true（这是好的——力度选择生效了）。
2. openai-completions.js 计算 useDeveloperRole = model.reasoning && compat.supportsDeveloperRole。
3. 由于 settings schema 丢弃了 supportsDeveloperRole: false，探测默认 true，系统提示以 developer 角色发送。
4. 国产端点拒绝该角色（只接受 system / assistant / user / tool）。

注意：这同时意味着这些端点上未声明推理的模型能"碰巧"正常工作（reasoning 为 false 时角色回落到 system）——故障恰好在你启用推理功能时出现，非常具有迷惑性。

当前使用的绕过方案

本地微型代理把 role: developer 改写为 system（并剥离 store 字段）后转发。能用，但不应该需要这样做。

请求

1. 让 llm-pi-ai settings 的 compat（路由级与模型级）透传 pi-ai OpenAICompletionsCompat 的完整字段——至少 supportsDeveloperRole，最好还有 maxTokensField / supportsStore / requiresAssistantAfterToolResult——而不是静默丢弃未知键。静默丢弃让错误配置无法被诊断。
2. 考虑扩充 pi-ai 的 URL 自动探测，覆盖常见国产兼容端点（火山方舟 *.volces.com、Kimi api.kimi.com、阿里百炼 *.aliyuncs.com），或者至少在自定义路由的 compat 完全依赖 URL 猜测时输出警告日志。

谢谢！

[weijiafu14]

这份根因分析是对的。补一个不需要改 node_modules 或自建 rewrite proxy 的现成绕法：通过 pi2dsh 使用对应的 Pi provider 插件。

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

provider 自带 transport 时会经 DSH 官方 llm.registerAdapter 注册为原生 route；请求读取 provider 自己模型描述上的完整 compat，不经过手写 llm-pi-ai profile 的字段白名单。

线上录制已经确认 supportsDeveloperRole: false 发出 system，provider 的 maxTokensField 和 thinking level map 也能到请求。边界是原 settings 路径仍未修，这是一条可安装的替代 route。