怎么判断一个 AI API 中转有没有给你降智?六个可复现的探针(2026)
一次回答变差不能证明中转换了模型。模型 ID、客户端请求、上下文、协议转换、上游状态或 usage 口径都可能造成类似症状。这篇把这些可能拆成六类可复现检查。
1. 先定义故障,再选择检查方法
“降智”常被用来描述互不相同的问题。路由变化是请求到了不同模型或部署；上下文截断是预期输入没有完整到达；参数改写会改变输出上限、温度、reasoning effort 或工具行为；协议损失发生在格式转换无法表达某些源字段时；上游容量、安全策略或版本变化也可能在模型名不变时改变结果；客户端 bug 则可能让实际请求与界面显示不同。先把症状写具体:输出变短、中段内容忘记、工具缺失、token 计数变化、返回模型变化或错误率升高。一个检查只能针对其中一层,不能靠单一“指纹题”证明换模。
2. 检查一:响应元数据与实际端点
先发一笔短的非流式请求,保存原始响应头和 JSON。核对请求的模型 ID 是否存在于供应商当前模型目录、返回的 model 字段是否与该请求相容、实际端点是否正确。供应商若返回 request ID 就一并记录；若没有,记录自己的客户端 trace ID 并注明限制。把真实使用的每条路由分别测试,因为 OpenAI 兼容、Anthropic 兼容与本地路由器可能表现不同。这能发现错误别名、意外 fallback、过期配置或明显的返回改写,但仍只是第一层筛查:model 字段由服务端提供,可能被规范化或改写,不是底层模型身份的密码学证明。
curl -si https://cocodot.co/api/ai/v1/chat/completions \
-H "Authorization: Bearer 你的-key" -H "content-type: application/json" \
-d '{"model":"你的模型名","max_tokens":32,
"messages":[{"role":"user","content":"只回复:ok"}]}'
3. 检查二:审计 usage,但不要过度解释
把完全相同的序列化请求通过同一个端点和模型顺序发送多次,比较完整 usage,不要只盯一个总数。普通输入 token 在同一计费状态下应形成稳定基线;但第一次创建缓存、后续读取缓存时,普通输入、cache creation 和 cache read 的分类发生变化是正常现象。数字不同说明需要调查,可能来自客户端附加消息、路由模板、模型或 tokenizer 版本、缓存状态、流式 usage 配置或供应商计费口径,不能把它写成“有人注入提示词”的唯一证明。如果两个客户端结果不同,先抓它们实际发送的请求再比较。
4. 检查三:在长上下文多个位置测试完整性
生成一份合成的长文档,在大约 20%、45% 与 75% 的位置分别插入模型无法猜测的随机标签和数字,最后要求返回全部三项。重复测试,再用明显更短的文档做对照。若短对照成功、长版本中相同位置反复失败,应结合实际 usage 排查客户端 contextLength、网关限制、tokenizer 估算与服务端截断。不要把一次答错当成内容被移除的证明:即使所有 token 都到达,长上下文检索也不是每次完美。更强的证据是可重复的位置性失败,并且 usage 显著低于预期输入规模。
5. 检查四:完成工具调用的整个往返
工具调用是协议转换中最容易掉字段的地方,而且掉了通常不报错。分三个层次测。基础层:定义一个简单函数,看是否返回 tool_calls、参数是不是合法 JSON。并行层:定义两个函数,提一个同时需要两者的问题,看是否一次返回两个调用,有的转换层只保留第一个。复杂 schema 层:定义一个带嵌套对象、枚举和必填项的结构,看返回的参数是否满足枚举约束,这一层最能暴露"schema 被简化后转发"。最后别忘了把工具结果回传给模型,看它能不能接着往下走,很多问题恰恰出在回传这一半:请求方向的字段都在,回传方向的 tool_call_id 或角色字段被改坏了,表现就是模型开始胡说或者反复重试同一个工具。
6. 检查五和检查六:重复基线与缓存字段
探针五,确定性测试。temperature 设 0,发同一个有外部可核答案或严格结构的问题,重复多次并与自己保存的健康基线比较。温度 0 不保证逐字相同,所以看正确率与结构分布,不拿一次差异下结论。探针六,验证 Anthropic 缓存字段是否被保留。不要比较带与不带 cache_control 时 input_tokens 是否相同:在 Anthropic 口径里,input_tokens 不含单列的缓存创建和读取 token。准备达到最低可缓存长度的稳定前缀,把 cache_control 放在稳定部分末尾并顺序调用。第一个合格请求看 cache_creation_input_tokens,后续请求看 cache_read_input_tokens。两项都为 0 只是异常信号,还要排查前缀太短、模型或路由不支持、缓存边界丢失、TTL 或前缀变化;复现后才能判断字段是否被忽略。
7. 指纹题只能当旁证,应保存可重复基线
知识边界、长输出结构、模型自报身份和文风都只能当旁证,因为元数据、系统提示与随机性都可能改变结果。应把它们与响应元数据、完整 usage、上下文和工具往返等证据结合。probe.cocodot.co 可帮助组织可复现检查,但对任何第三方诊断工具都临时建一把额度很小的 key,不放进 URL、截图或公开配置,测完删除。保存端点、模型 id、带时区时间、完整 usage 和结果；供应商提供 request ID 时一并记录,否则使用自己的 trace ID。这样才能把可复现变化与随机波动区分开。
8. 测出异常之后怎么办,以及我们这一端
先区分上游能力边界、客户端或网关配置失误,以及可复现的路由或请求变化。正确顺序是先核对 contextLength、超时、准确模型 id 和客户端实际请求,再重复检查并运行有文档依据的对照路径,最后带着 usage、时间戳和供应商可用时的 request ID 去询问。不同产品的协议取舍可以不同,关键是把边界说清。cocodot 同样接受这套验证:OpenAI 兼容端点是 https://cocodot.co/api/ai/v1,供 Claude Code 使用的 Anthropic 兼容端点是 https://cocodot.co/api/ai。端点兼容不等于承诺所有字段在每个模型上都生效；模型、上下文、工具调用和缓存都应以实际响应、对照与重复测试为准。
一页自查清单:每接一个新供应商填一遍
| 检查 | 通过信号 | 异常可能指向 | 单项不能证明 |
|---|---|---|---|
| 响应元数据 | 请求模型、返回模型与端点一致；有 request ID 时记录 | 别名、路由或返回重写问题 | model 字段本身不能证明底层身份 |
| usage 可重复性 | 相同序列化请求形成稳定输入基线 | 客户端、模板、模型版本或计费口径变化 | 不能单独证明有人注入提示词 |
| 上下文完整性 | 多个位置的随机事实经重复测试可取回 | 客户端或网关截断,也可能是长上下文检索弱 | 一次漏答不能证明内容被移除 |
| 工具与 schema | 工具名、参数、ID、枚举和嵌套字段完成往返 | 协议转换或客户端兼容损失 | 一次随机未选工具不等于字段丢失 |
| 缓存字段 | 首次合格请求创建,后续顺序请求读取 | 字段被忽略、前缀变化、路由不支持或未达门槛 | input_tokens 前后变化不是有效证据 |
| 重复基线 | 正确率与结构处于已保存的参考分布 | 可复现的行为或基础设施变化 | temperature 0 也不保证逐字相同 |