模型名称没变，后端行为为什么会漂移

模型字符串不一定固定模型版本

请求里的 model 可能是固定版本，也可能是会移动的别名。两者看起来都只是一段字符串，稳定性承诺却不同。

Anthropic 的模型 ID 与版本文档区分得很细：Claude 4.6 及后续的无日期 ID 是固定版本；更早型号的短别名，例如 claude-sonnet-4-5，会解析到该小版本最新的日期快照。Anthropic 的 GET /v1/models/{model_id} 还能解析别名并返回模型信息。

OpenAI 的部分模型同时提供别名和日期快照。以 GPT-4o 模型页为例，文档明确把快照用于锁定具体版本；OpenAI 的请求调试文档也提醒，不同快照之间的提示行为可能变化，生产应用应固定版本并做评测。

Gemini 把命名阶段写进了模型文档：stable 型号通常不变，preview 可能调整，latest 别名会在新版本发布时切换。名称带有 latest，行为变化本来就在这个接口约定内。

所以，排查第一项是确认这个字符串属于固定 ID、稳定型号、预览型号还是移动别名。字符串是否变化不能代替版本规则。

固定版本也可能出现小幅变化

固定模型 ID 通常约束模型权重或发布快照，不会冻结它周围的全部服务。Anthropic 同一份版本文档写明，请求路由、安全分类器与采样逻辑等服务基础设施可能更新，固定 ID 的可观察行为因此会有小幅差异。

模型输出本身也有随机性。固定 prompt、固定参数并不保证每次逐字相同。温度、采样参数、推理强度、工具可用性、输出上限或安全策略中的任一项变化，都可能改变输出长度、终止原因和延迟。OpenAI 因此建议用固定版本配合评测，而非拿单个答案当版本证明。

单次回答「变笨」不能定位来源。要观察分布：固定任务的通过率、stop_reason 构成、输出 token、TTFT、工具调用结构是否在一段时间内一起移动。

协议探针与任务评测各管一层

只测一道问答题，答错可能来自采样；只看协议字段，又可能漏掉模型完成任务的能力变化。监控配置需要把两类观察分开。

协议探针检查可明确判定的结果，例如输入 token 是否稳定、结构化输出能否通过 JSON Schema 校验、工具调用是否包含必填参数、故意压低输出上限时终止原因是否符合文档。这类探针适合定位参数过滤、请求改写和响应重组。

任务评测使用固定题集与固定评分规则，观察一段时间内的通过率。评分条件要能复查，例如「返回的代码通过哪些测试」「抽取结果是否包含指定字段」，少用「回答看起来更聪明」这样的主观尺度。题集与生产任务差得太远时，评测稳定也不能代表业务没有受影响。

两类结果一起变化，排查模型版本、参数与路由；协议稳定而任务通过率下降，扩大任务样本并检查模型服务变化；任务稳定而字段结构变化，优先处理兼容性和计费风险。它们提供的是定位方向，仍不等于模型身份结论。

中转站还多了一层名称映射

请求到达中转站后，公开的模型字符串可以被映射到内部渠道、云厂商区域、账号池或另一套模型名称。后台改了映射，客户端仍会发送原来的 model；中转站也可以把响应里的 model 改回原值。

这层映射通常无法从响应中的一个字段直接验证。响应头、错误类型、缓存行为和延迟分布只能提供线索。关于不同渠道可能留下哪些痕迹，可参考中转站渠道类型；模型自述为什么不可靠，见Claude 降智怎么判断。

还有一种容易漏掉的来源：中转站没有换模型，却开始过滤参数、截断上下文或插入系统提示。此时模型身份可能没变，任务行为照样会明显偏移。把所有变化叫作「掉包」，会让排查提前走错方向。

按请求经过的顺序排查

1. 确认发出去的内容有没有变

保存脱敏后的请求体、端点、协议版本、SDK 版本、模型字符串、prompt 版本和参数。对 JSON 做稳定排序后计算哈希，可以快速确认两次探针是否同一份配置。工具定义、系统提示和历史消息也属于输入，不能只比末尾那条用户消息。

若请求哈希已经变化，先解释客户端改动。此时继续猜中转站换了什么，证据不够。

2. 查模型名称的版本规则

到厂商模型页确认名称类型，再查发布记录与弃用记录。使用 Anthropic 旧型号别名时，可以通过 Models API 看它当前解析到哪个 ID；使用 Gemini latest 时，要把别名切换日期与变化开始时间放在一起比较。

中转站自己的模型目录只能说明它声称如何映射，不能代替厂商文档，也不能证明请求最终去了哪里。

3. 用官方直连做同期对照

同一份固定探针，在相近时间分别请求官方端点和中转站。官方与中转站同时出现相似变化，优先检查厂商版本、公共服务变化或探针本身；只有中转站偏离，才把注意力放到中转路由与请求改写。

对照需要保持模型版本与协议一致。拿官方固定快照去对比中转站的移动别名，或者拿 OpenAI Chat Completions 去对比另一边的 Responses API，结论会混入接口差异。

4. 看哪些信号一起变化

组合信号帮助安排排查顺序。要指认具体后端，还需要可复现的模型指纹、服务方日志或其他独立证据；四类学术方法及其误判边界整理在学术界怎么审计中转站掉包模型。

把版本变化与异常变化分开记录

计划内迁移也会打断旧基线。模型别名切换、固定版本升级、SDK 改版或 prompt 变更时，记下变更时间和新配置，从该时点建立新基线。未知变化则保留旧基线，继续收集相邻样本，确认它持续多久、影响哪些探针。

一条完善的记录应能回答：哪份请求发生了什么差异、差异从何时开始、官方对照是否同步、有哪些原始字段支持判断。建立方式见怎样建立中转站行为基线，记录的阅读顺序见如何读懂一条 LinkyMonitor 变化记录。