结论先说： 黑盒 API 无法通过一次请求百分百证明底层模型身份。可行目标是寻找“声明、协议和行为是否一致”的证据，识别需要进一步核实的套壳、模型替换或路由漂移风险。
你可以先用中转站检测工具检查任意符合协议范围的公开 HTTPS 端点。工具不会把高分包装成“官方模型认证”。
套壳、别名和路由替换不是一回事
| 情况 | 可能表现 | 是否一定有问题 |
|---|---|---|
| 模型别名 | 请求名与上游正式名不同 | 不一定，需看服务商是否公开映射 |
| 网关改写 | model、请求 ID 或系统提示被统一处理 |
不一定，但会降低可追踪性 |
| 自动降级路由 | 高峰期切换到备用模型 | 若未告知用户，存在质量与计费风险 |
| 套壳或虚假声明 | 声称模型与实际能力长期不符 | 需要多项证据和基线进一步确认 |
因此，“名称不同”只能触发核实，不能直接下结论。真正值得关注的是多项信号持续相互矛盾。
六类黑盒风险信号
1. 请求模型与响应模型不一致
比较请求中的 model 和响应中的 model。若持续不同，先确认是否存在公开别名或版本映射。即使二者完全一致，也只能说明返回字段一致，不能证明字段没有被网关改写。
2. 元数据过度简化
持续缺少 id、object、created、请求 ID 或 usage，说明接口与标准结构存在差异。字段缺失可能只是兼容层实现不完整，但会削弱排错、计费核对和请求追踪能力。
3. Token 数据不可信
检查输入、输出和总 Token 是否非负、完整且算术一致。Token 统计方式可能因分词器和网关而不同，因此小幅差异不等于造假；长期缺失或明显矛盾才是更强风险信号。
4. 动态能力题持续失败
服务端随机生成参数和 nonce，可以降低固定题被提前适配的影响。应使用多种任务，而不是把一道数学题当作模型身份证。
5. 声称支持的协议能力不可用
如果页面宣称支持 SSE 或工具调用，但标准请求持续失败，需要区分模型本身不支持、模型 ID 映射错误和网关兼容缺陷。无论内部原因是什么，都意味着该入口不适合依赖这些能力的业务。
6. 同一模型在不同时段明显漂移
固定参数和题集后，比较模型声明、结构化字段、延迟、Token 与业务结果。高峰期持续退化而低峰期恢复，可能与限流或动态路由有关，仍需服务商日志才能确认原因。
推荐的证据优先级
从强到弱可以这样排列：
- 可重复的协议或关键能力失败。
- 模型声明、请求 ID、Token 与能力结果之间的交叉矛盾。
- 多时段、同参数、同题集下的持续漂移。
- 单次输出风格、模型自述身份和知识 cutoff。
第四类信号最容易受提示词、随机性和网关改写影响，只适合作为线索。
常见误判
/models被限制访问，不等于套壳。- 模型自称“我是某模型”，不等于身份得到验证。
- 一次动态题失败，可能是格式、随机性或输出截断。
- 输出风格变化，可能来自系统提示和温度参数。
- 工具调用失败，可能是接口协议不匹配，而不是模型能力不足。
如何做公平对照
为每个端点使用独立临时 Key，但保持模型系列、请求参数、题集、测试时间窗口和网络环境尽量一致。至少重复三轮，并保留每项证据，而不是只记录总分。
如果服务商公开模型别名、上游版本和自动降级规则，应将这些信息加入报告。透明的路由说明本身也是选择服务商的重要依据。
下一步
运行标准模型检测后，按照检测报告判读指南区分兼容问题与身份风险。若只看到 model 字段一致，请继续阅读这个字段究竟能证明什么。