同一中转站两次检测结果为什么不同？先排查这 7 个变量

中转不是一根固定水管

很多用户第一次检测得 90 分，第二次只有 70 分，就认为工具不稳定。实际上，中转网关常在多个上游账号、区域、模型版本和负载策略之间路由。同样的地址、Key 和模型名，不保证每次走同一条链路。

判断结果变化前，先检查下面七个变量。

变量一：上游路由池

中转可能按权重轮询多个渠道，也可能在失败后自动切换。不同上游对协议字段、thinking、工具调用和多模态的支持不完全一致。最明显的信号是：响应头、错误格式或流式事件在连续请求中出现两套稳定模式。

复测时连续运行三次并记录时间。如果结果呈现 A/B 两组而不是随机小波动，多路由的可能性很高。

变量二：模型版本或别名

服务商可能让一个别名指向“当前最新版”，上游更新后实际模型发生变化，但 API model 字符串不变。也有中转在高峰期把旗舰别名临时映射到便宜版本。

尽量使用精确模型 ID，并记录服务商模型列表的更新时间。若只能使用别名，就把版本漂移纳入风险。

变量三：生成随机性

即使底层模型完全相同，开放式回答也会变化。temperature、top_p、系统提示和上下文都影响结果。依赖文风或某一道谜题判断身份，很容易把随机性当成偷换。

复测应固定参数，使用可客观验证的结构化任务，并关注协议和能力是否通过，而不是答案是否逐字相同。

变量四：缓存和请求改写

部分网关会缓存常见提示，或在请求前后添加系统指令。缓存命中时延迟异常低、回答高度一致；未命中时又恢复正常。请求改写还可能影响模型自我介绍和拒答行为。

可以加入不会影响任务的随机标识，观察响应是否仍机械重复；同时检查 usage 是否与输入变化相符。

变量五：限流与降级

探针并发时，某些上游会返回 429 或暂时关闭高成本能力。检测工具会把请求错误与能力失败区分，但错误项增多仍会让报告证据减少。高峰期复测和低峰期复测出现差异，往往说明容量或账户额度不足。

不要在收到 429 后立即连续重跑。等待限流窗口结束，再以相同参数复测。

变量六：网络和流式断开

代理、Nginx、CDN 或客户端网络可能在流式响应完成前断开。此时模型本身可能正常，但流结构、usage 或最终事件缺失。检查 HTTP 499/502、读取超时和 SSE 结束标志，可以区分能力问题与传输问题。

变量七：检测输入发生变化

模型名、协议选项、Base URL 尾部路径甚至语言设置不同，都会改变请求。比较两份报告前先核对请求摘要，不要把不同配置当成同一实验。

标准复测流程

1. 固定地址、Key、模型、协议和参数；
2. 第一次检测后等待至少五分钟；
3. 同一时段连续测三次，记录 request ID；
4. 换一个时段再重复三次；
5. 对比分项状态、HTTP 错误和协议，而不是只比总分；
6. 若结果分成稳定的两组，重点检查路由池；
7. 若仅开放式行为项轻微变化，优先考虑生成随机性。

什么变化值得警惕

单项从通过变成警告不一定严重；更值得警惕的是实际模型字段跨模型族变化、签名与协议结构同时消失、工具和结构化输出持续失败、或者错误集中在固定高峰。

如果报告变化伴随价格、速度和回答质量同时下降，应保存脱敏证据并联系服务商。描述“哪几项、什么时间、重复几次”比只发一个总分更容易定位。

正确使用检测结果

检测是某个时间点的取证，不是永久证书。购买前用它筛掉明显异常渠道，使用中用低频复测发现路由变化，出现争议时用 request ID 和分项证据沟通。把单次结果与长期可用率结合，才能形成可靠判断。