中转站准入清单：通过、继续观察还是淘汰

先定义三种结果

准入测试不需要给站点打一个笼统分数。每个分组、模型和用途分别做判断：

「通过」只表示当前条件下可以使用，不代表以后不会换上游或修改配置。准入结束后仍要复跑同一组请求。

第一步：确认谁在提供服务

充值前保存站点名称、域名、运营主体、联系方式、服务条款、退款规则和当时的套餐页面。页面以后可以修改，截图要带时间和完整网址。

继续观察的典型情况是：服务可以小额试用，但主体、退款路径或故障响应时间写得不清楚。此时不宜预存大额余额，也不适合承载必须按时完成的任务。

如果收款对象、服务主体和联系方式都无法对应，或对方要求先大额充值才允许测试，可以直接淘汰。这里判断的是追索和止损条件，不推断运营方是否会关停。

第二步：把数据和凭据隔离开

中转站作为 HTTPS 连接的接收端，可以读取发给它的请求头、Prompt、工具参数和模型响应。准入前要先划定允许经过这条通道的数据：

• 使用中转站签发的独立 Key；若必须自带上游 Key，为中转用途创建独立项目或工作区，并设置额度和告警。
• 测试使用合成 Prompt，不复制客户对话、内部代码、数据库凭据或未发布文档。
• Agent 的文件、Shell、浏览器和云操作采用最小权限；带外部副作用的动作要求本地确认。
• 记录中只保存排查需要的字段；需要保存正文时，另行规定脱敏方式和保留期限。

涉及受监管数据、生产凭据或无法撤回的自动操作，而服务方又不能提供满足要求的数据条款与安全材料，应淘汰。完整边界见中转站能看到哪些数据。

第三步：冻结站方声明

测试前把可变条件写进一张记录：

社区里的「官转」「号池」「逆向」没有统一定义。把它们当作站方声明保存，不要直接当作渠道证据；各类标签和核验边界见中转站渠道类型。

第四步：跑最小验收集

验收集应来自计划承载的任务。只测一句普通问答，覆盖不了长上下文、工具调用和流式结束等接口条件。

1. 基础请求：保存原始状态码、响应头、请求 ID、响应体、Usage 和实际扣费。错误体的排查方法见 AI API 错误排查。
2. 流式与终止：确认事件顺序完整、正文能够拼接、终止原因与协议相符，断流时客户端能识别失败。OpenAI 兼容接口可按兼容性分层逐项检查。
3. 业务必需能力：按实际用途测试工具调用、结构化输出、缓存或长上下文。用不到的能力不必为了清单完整而测试。
4. 用量与扣费：固定 Prompt 和参数，在可比的官方端点与中转站分别运行，核对输入 Token、Usage 分项和账户扣费。步骤见 Token 对账。

一次超时或单个答案不理想可以继续观察；同一项在排除客户端配置后稳定复现，并影响业务要求，应判为淘汰。模型回答「自己是谁」不能代替模型身份验证。

第五步：保存准入基线

通过测试后，保存完整请求版本、脱敏后的原始响应、发送时间、分组、模型字符串、生成参数、Usage、终止原因、响应头、请求 ID、首 Token 延迟与扣费记录。给请求体计算版本标识，后续修改 Prompt、工具定义或参数时另起基线。

测试用 Key、分组和运行时段要尽量覆盖准备上线的路径。只测专用测试账号，无法说明生产账号是否被分到同一资源池。

上线后怎样复查

准入题要留在生产周期里继续跑。发现时间要求决定复查频率；采样时间应覆盖实际业务时段，并保留少量抖动。具体方法见准入通过后，模型还会不会换。

出现偏离时按下面的状态处理：

• 继续观察：单次异常、官方同期也在变化，或本地请求版本已经改变。保留样本，修正对照条件后再测。
• 暂停新增流量：固定请求连续异常，或只在某个分组、账号、时段出现偏离。先冻结相关记录，再联系服务方核对。
• 淘汰：安全边界被破坏、扣费持续无法自洽、关键能力长期不符合声明，或服务方无法给出可复查的处理结果。作废凭据，迁移流量并处理余额。

准入清单负责降低接入风险，持续记录负责发现接入后的变化。两者缺一项，结论都只覆盖很短的时间。