结论先说： “降智”不是一个可以通过单道题直接确认的技术状态。更可靠的做法是固定模型、参数和题集，在不同时段重复采样，并把协议字段、Token、动态能力题、流式输出、工具调用和真实业务结果放在一起比较。
打开大模型 API 中转站检测工具，可以先生成一份分项报告，再按本文方法补充业务题集。
先定义什么叫“降智”
用户感受到的“变笨了”，可能来自多个环节：模型路由发生变化、网关追加系统提示、上下文被截断、工具调用不兼容、请求参数被过滤、高峰期限流，或者模型本身的随机输出波动。黑盒检测只能发现结果与声明不一致，不能仅凭现象确定内部原因。
因此建议把问题拆成三层：
| 层级 | 需要回答的问题 | 主要证据 |
|---|---|---|
| 协议层 | 接口有没有按声明返回标准结构 | 状态码、model、usage、流式事件 |
| 能力层 | 关键任务是否稳定完成 | 动态题、工具调用、结构化输出、业务题集 |
| 时间层 | 同一配置是否发生持续漂移 | 多时段报告、延迟、错误率、Token 与结果变化 |
可重复的检测步骤
1. 固定请求条件
记录 Base URL、模型 ID、temperature、最大输出长度、系统提示和测试时间。比较两个中转站时，除了 API Key 和地址，其余条件应保持一致。否则结果差异无法归因。
2. 先检查结构化信号
优先检查认证、HTTP 状态、响应 model、请求 ID、usage 和 Token 算术。结构化字段异常不等于模型一定被替换，但能较快暴露网关兼容、计费透明度或路由声明问题。
需要特别注意：/models 不开放或返回 401、403、429，可能只是权限与限流策略，不能单独当成造假证据。
3. 再验证关键能力
至少覆盖以下三类：
- 服务端随机生成的动态题，避免供应商针对固定题预设答案。
- SSE 流式输出，检查事件格式、增量内容和结束标记。
- 工具调用，检查工具名、JSON 参数和随机 nonce 是否原样返回。
如果业务依赖代码、长文本、检索或结构化 JSON，还应加入自己的脱敏样本。通用动态题只能检查部分能力，不能代替生产任务。
4. 在不同时间复测
建议低峰和高峰各运行一次，并在次日复测。一次失败可能来自网络、限流或上游波动；多项关键能力持续下降，且同一条件下能够重复，才值得升级为高风险信号。
哪些现象值得重点排查
- 请求模型与响应
model长期不一致，且服务商无法解释别名映射。 usage持续缺失或 Token 算术明显不一致。- 原本可用的工具调用、流式输出或结构化结果持续失败。
- 同一业务题集的约束遵循率明显下降，而请求参数没有变化。
- 高峰期与低峰期的模型声明、能力结果或输出结构出现系统性差异。
这些信号说明“需要排查”，并不等于已经证明套壳或降智。网关升级、模型版本变更和客户端差异也可能产生类似现象。
不要只看总分
检测工具中的综合分衡量协议与关键能力的兼容程度，不是模型智力分，也不是厂商认证分。应先看失败项是否影响你的业务，再看多轮结果是否一致。
例如，工具调用失败对普通文本摘要影响有限，但对 Agent 任务可能是阻断问题；知识 cutoff 自述与输出风格属于弱信号，只适合长期对照，不应单独判定真假。
建议保存的对比记录
time, base_url, requested_model, response_model,
status, latency_ms, input_tokens, output_tokens,
dynamic_probe, sse, tool_call, business_suite, notes记录时不要保存完整 API Key、用户隐私或未脱敏提示词。出现异常后，使用同一题集复测并向服务商提供请求时间和脱敏请求 ID，比只说“模型变笨了”更容易定位。
下一步
先运行一次标准模型检测，再阅读检测报告判读方法。如果主要异常是请求模型与响应模型不一致，继续查看套壳与路由替换风险排查。