能力被环境差异静默改变

更新于 2026-09-22

能力被环境差异静默改变

# 能力被环境差异静默改变

「同一个请求 / 同一个开关 / 同一个模型名」都不保证「同一条执行路径」。 两侧都返回成功，而能力其实已经不同 —— 差异只在最末端的请求与响应里才看得见。判据一句话：观测点必须落在真正发出的那次调用上（实际模型 ID 与参数），而不是前端开关、请求别名或配置声明。

出处	你看到的	实际执行的	差异在哪
兼容端点要防SDK注入非标准字段	同一个模型、同一份代码	本地走 SDK 原生 provider；生产走 relay 兼容层	少一个 base URL 就换了整条路径
开关要映射到模型调用才算生效	前端开了「深度思考」、参数也透传了	真正发给 provider 的请求里有没有推理参数	观测里的 reasoning 为空
请求别名不等于实际模型ID	请求里的模型名	provider 响应 `model` 返回的实际 ID	别名与实体是两回事
多账号模型路由机制	同一个模型名	可能在国内版 / 国际版账号间混合调用	路由是 model-aware，不是账号轮询
模型ID是入口相关的	同一个模型名	各入口清单里注册的 ID 不同（裸名 vs `provider/` 前缀）	合法性由末端网关的模型表决定，不由「别处能跑」决定
同名provider冲突会让模型路由漂移	配置里写的是自己的自定义 provider	同名冲突下请求发给了内置后端	解析归属时名字压过了身份，且配置看起来没变
模型ID是入口相关的（第三例）	`config.toml` 里默认 `model = "gpt-6-astra"`	官方账号下该名字不存在（第三方模型名），请求必然 400	同一个名字在不同入口 / 账号下可用性不同（@09-23 21:41）

旁证：模型可见性按入口分批 —— 同一账号在网页端 / API / CLI 三个入口的模型可用性不同步，「我没有这个模型」不是操作错，而是灰度分批。

能力是一个「运行时事实」，不是「配置事实」。 配置里写了、请求里带了，都可能被中间的兼容层、路由层、灰度层改写或丢弃 —— 而且不报错。
验证必须落到最末端。 可用的证据只有两类：真正发出去的那次请求（含实际参数）、真正回来的那次响应（含实际模型 ID）。其余都是代理。
可迁移的动作：任何「开关 / 模型 / 能力是否生效」的判断，先问三句 —— 「真正执行的是哪一个实体？」「参数是在哪一层被消费的？」「响应里能证明它吗？」 三句都答得上，才算生效。
与本地能跑不等于环境里能跑是同一枚硬币的两面：那条讲两侧路径不同，本条讲同一侧内部也会因为名字与实体分离而不同。

单看每一页，都是某次模型 / 开关的排查。并排之后才看得出它们共享同一个判据错误：用名字与声明代替了末端事实。