兼容端点要防 SDK 注入非标准字段

更新于 2026-07-28

**OpenAI 兼容层通常会按「对面就是真 OpenAI」往请求体里塞字段，而严格校验的兼容端点会直接 400。** 报错看起来像「接口坏了」，其实多出来的是一个 SDK 自己加的字段。

实测形态：store:false 让 Gemini 兼容层拒收

探测结果
chat/completions 干净请求200 ✅
同上 + store:false400 ❌ Unknown name "store": Cannot find field
流式干净请求200 ✅
流式 + store:false400 ❌
openai/embeddings（对照）200 ✅
  • 字段不是业务代码写的，是 Pi SDK 的 openai-completions 适配器自动注入的。
  • 自定义 relay 域名不在 SDK 的「非标准端点」白名单里，所以每个文本请求都会被塞进去。
  • 路由、key 轮换、模型 id 全部正常 —— relay 没坏，是请求体多了一个字段。

为什么「本地能用」掩盖了它

本地 .env.local 没配 GEMINI_BASE_URL → fallback 到 Google 原生地址 → 走 SDK 内置的原生 provider，根本不经过会注入 store 的 OpenAI 适配器。生产配了 relay，对话和 summary 走同一条 openai-completions 路径，于是生产上所有文本请求大概率都 400。本地好 ≠ 生产好，因为两者走的是不同协议路径。

可迁移的判断

  • 兼容层报「Unknown name / Cannot find field」时，先 dump 出实际请求体，比对干净请求，找多出来的字段，而不是先怀疑网关。
  • 接入自建/第三方兼容端点时，要主动处理三件事：把域名加入 SDK 的非标准端点白名单、在适配层剥离非标准字段、或改走原生协议端点。
  • 排查「本地正常生产异常」时，第一问是「两边是不是同一条协议路径」，而不是「代码是不是同一份」。

相关