先把“中转”还原成一条真实链路#

很多人把 AI 中转理解成“官方 API 的便宜代理”：客户端把 base_url 改掉，继续使用熟悉的 OpenAI 兼容接口，模型名称也许只需要换一个字符串。这个理解只描述了调用方式，没有描述信任边界。

最简单的直接调用链路是：

1
你的应用 → 官方 API 网关 → 模型服务 → 返回结果

中转之后通常变成：

1
你的应用 → 中转站入口 → 中转站日志/计费层 → 第三方模型 API → 返回结果

如果中转站还叠加了模型路由、缓存、内容审核、重试和账号池，链路可能进一步变成：

1
客户端 → 兼容层 → 路由器 → 账户池/代理网络 → 模型厂商 → 路由器 → 客户端

这里增加的不只是一个网络跳转，而是一个能够接触完整请求上下文的中间系统。Prompt、系统指令、代码片段、检索结果、工具调用参数和模型输出，都可能在兼容层或日志层出现。社区材料 S7 提到，部分调查关注的正是“用户请求是否被实时转发给第三方模型”以及中转站是否可能截留、保存或再次利用请求；材料同时明确指出，具体企业归因仍属于调查结论，不能直接等同于司法认定。这一区分很重要：风险模型可以先建立，事实判断却不能越过证据等级。

因此，“便宜”至少对应四种不同的成本转移：服务商把模型调用成本转移给账号池，把合规成本转移给用户，把日志风险转移给请求内容的所有者，把故障和封禁风险转移给调用方。只看每百万 Token 的价格，会漏掉真正昂贵的部分。

API 兼容不等于信任兼容#

OpenAI 兼容接口解决的是协议适配，不是数据治理。一个中转站可以正确返回 choices、流式输出和错误码，却仍然没有回答以下问题：

1. 请求最终发送给哪个模型厂商和哪个地区？
2. 中转站是否保存原始 Prompt、输出、IP、账号标识和请求时间？
3. 保存多久，谁可以访问，是否用于训练、调试或人工审核？
4. 工具调用是否会被修改、重放或注入额外参数？
5. 中转站停止服务、账号池被封或上游变更时，谁负责解释和迁移？

应用商店的披露可以帮助我们理解“声明”与“证明”的差别。S3 中的 VPN 应用页面同时展示了开发者对隐私、加密传输、数据收集和第三方共享的说明，并提示数据安全实践可能因地区和年龄而变化。这类页面是可核验的一手公开声明，但它不是独立审计报告，也不能自动证明所有运行时行为。把这个原则迁移到 AI 中转：服务商写着“不记录日志”，只能证明它做过这样的声明；要证明声明成立，还需要隐私政策、数据保留配置、访问审计、独立测试或可复现的技术证据。

同理，“加密传输”只说明某一段链路使用了加密，不能推出中转站无法读取内容。TLS 通常保护客户端到中转入口、或中转入口到上游的传输过程，但中转服务器为了转发 JSON，往往需要在应用层解析请求。真正要问的是：谁在 TLS 终点解密，解密后的数据是否进入日志，是否经过缓存，是否被异步任务复制。

接入前：先做一份最小信任清单#

不要从“能不能注册”开始，而应从“最坏情况下会泄露什么”开始。可以把请求分为三类：公开资料、内部代码、身份与业务数据。公开资料适合用于功能验证；内部代码必须经过脱敏和最小上下文裁剪；密钥、客户数据、未公开漏洞、生产日志和个人信息不应直接交给无法审计的中转站。

接入前至少完成以下检查：

1
curl -sS -D /tmp/headers.txt \
2
  -H 'Authorization: Bearer REDACTED' \
3
  -H 'Content-Type: application/json' \
4
  https://example.invalid/v1/models \
5
  -o /tmp/models.json
6

7
sed -n '1,30p' /tmp/headers.txt
8
jq 'keys' /tmp/models.json

1
curl -sS -L -o /dev/null \
2
  -w 'final=%{url_effective}\nremote=%{remote_ip}\nssl=%{ssl_verify_result}\n' \
3
  https://example.invalid/v1/models
4

5
openssl s_client -connect example.invalid:443 \
6
  -servername example.invalid </dev/null 2>/dev/null \
7
  | openssl x509 -noout -subject -issuer -dates

运行中：让日志证明“少知道一点”#

工程上最有效的做法不是要求中转站“绝对可信”，而是让它即使不可信，也尽量拿不到完整资产。

第一，使用独立的中转专用密钥，不与官方控制台、生产服务或个人账号复用。第二，把敏感配置放在本地网关：由本地网关完成密钥注入、字段过滤和内容脱敏，外部中转只接收经过裁剪的请求。第三，关闭不必要的请求体日志，保留请求时间、延迟、状态码、模型标识和费用估算等运营指标；如果必须记录调试样本，应使用短期、加密、可审计的采样存储。

一个简单的脱敏边界可以是：

1
业务系统 → 本地策略网关 → 中转 API
2
                 ├─ 删除 Authorization 之外的内部头
3
                 ├─ 移除邮箱、手机号、客户编号
4
                 ├─ 截断超长上下文
5
                 ├─ 禁止生产工具调用
6
                 └─ 记录哈希、状态码、延迟，不记录原文

工具调用尤其需要单独处理。让模型通过中转站直接获得文件写入、Shell、DNS、支付或生产部署能力，相当于把“文本泄露风险”和“执行风险”叠加。即便中转站本身没有恶意，异常重试、错误路由、提示词注入或响应污染，也可能诱导本地 Agent 执行危险操作。安全默认值应是：中转只负责文本推理；工具由本地策略层执行；每个工具有独立 allowlist、参数校验、超时和人工确认。

如何验证“没有偷偷保存”这种难以证明的承诺#

负面承诺最难验证。你无法仅凭一次 curl 证明服务商没有保存请求，但可以设计分层证据，缩小未知范围。

先发送唯一的、无敏感意义的 canary 字符串，例如随机生成的标记，并在服务商隐私政策、控制台导出、删除请求和后续支持回复中寻找一致性。不要把真实秘密当作测试数据。再观察响应头、错误页面、计费记录和管理后台是否回显完整 Prompt。若服务商支持数据删除，提交删除请求并保存时间、范围和结果；若不支持，应把“无法验证删除”记录为风险，而不是默认视为没有日志。

同时在本地建立请求审计：保存请求哈希、模型、状态码、延迟、重试次数和出站目标，不保存原文。这样至少可以发现模型路由漂移、异常重试、跨地区切换和未经批准的域名变化。对关键业务，可以周期性用同一组公开测试样本比较输出差异，区分模型升级、参数改写和服务降级。

验证的结论要写成分级语言：

• 已观察到：入口证书、返回模型、重定向、状态码和本地网关行为。
• 服务商声明：隐私政策、日志承诺、数据删除承诺和上游说明。
• 尚未证明：后台是否复制请求、员工是否可访问、上游是否进一步留存。
• 高风险推断：没有透明政策、域名频繁变化、要求上传长期密钥或禁止任何审计的服务。

这种分级比“安全/不安全”二元判断更适合持续运营。

失败边界：什么时候必须绕开中转#

以下场景不应把低价中转作为默认路径：涉及客户合同约束的数据、受监管的个人信息、未公开源代码、生产凭据、漏洞利用细节、内部安全事件和需要可追责模型版本的决策流程。即便服务商价格极低、响应速度很快，也不能抵消数据控制权和审计责任的缺失。

中转也可能在非安全层面失败：上游模型被封导致批量错误，账号池触发限流导致延迟抖动，模型别名漂移导致输出格式变化，流式连接被截断导致 JSON 不完整，计费口径不透明导致预算失控。客户端应对这些情况设置超时、指数退避、幂等请求标识和明确的降级模型，但不要自动把敏感请求切换到未知的备用站点。

更稳妥的架构是把中转当作可替换的非核心依赖：官方 API、已审计的企业网关和中转服务分别配置独立适配器；业务代码只依赖内部统一接口；每次切换都经过公开样本回归、数据分类检查和费用上限验证。这样即使中转消失，也只是供应商切换，而不是整个应用失去控制。

原创结论：便宜 API 的核心问题是“谁拥有解释权”#

AI 中转的关键风险并不在“是否经过代理”这一事实本身。合法的 API 聚合、区域接入和统一计费都可能需要代理层；真正决定风险的是，用户是否知道请求去了哪里，是否知道谁能看到它，是否能够删除、迁移、追责和停止使用。

因此，评估一个中转站不应只问“每元能买多少 Token”，而应计算一项更完整的工程成本：数据暴露面、供应商替换成本、故障回滚成本、审计成本和责任追踪成本。只要服务商无法给出清晰的上游、日志、保留期、删除路径和变更通知，价格优势就只能被视为未经定价的风险折扣。

最终的工程原则可以压缩为一句话：把中转当作不完全可信的网络依赖，把敏感数据和工具权限留在自己能审计的边界内。

参考资料#

• Anthropic：发现中国 AI 公司大规模调用 Claude
• play.google.com