AI 大模型中转站：正在重演的 HTTP 明文时代

Fri, 31 Jul 2026 10:20:00 +0800

现在用 AI 的人，尤其是开发者，基本都绕不开"中转站"这个东西。new-api、one-api、各种自建聚合网关、还有五花八门的反代，本质上都是同一类东西：你把自己的 API Key 和请求交给它，它帮你转发到真正的模型厂商那边，顺便帮你省点钱、聚合好几个模型、或者绕一些区域限制。

用起来确实方便。但方便是有代价的，而且这个代价比大多数人意识到的要大。

你发出去的每一条 prompt，你完整的上下文，你喂给模型的代码片段、公司内部逻辑、甚至系统提示词，在中转站那里，全是明文。

这话听着耳熟。对，就是 HTTP 时代那种耳熟。

中转站就是当年那条明线

HTTP 时代的问题很简单：你的请求在网络上裸奔。路由器能看到、运营商能看到、任何中间节点都能看到。后来大家实在受不了了，才搞出 TLS，也就是 HTTPS——把传输内容加密，中间节点只负责转发，不知道你传了什么。

现在的 AI 中转站，位置恰好就是当年的那个中间节点。而且情况比 HTTP 时代更微妙：

HTTP 明文时代，你至少是被动被看。中转站是你主动把东西交过去的。你注册、填 Key、把请求导流过去，等于亲手把明文递到别人手里。

更要命的是内容性质。HTTP 时代被看到的是网页内容和流量特征；AI 时代被看到的，是你整个思维过程的外化——prompt 里带着需求、代码、隐私、业务逻辑。这东西泄露的杀伤力，比当年泄露几个 HTTP 包大得多。

为什么大家还是忍了

因为中转站给的好处太实在了：

便宜。官方 API 原价算，中转站走量、囤额度、搞活动，一个 token 能差出好几倍
聚合。一个 Key 通吃各家模型
方便。不用维护 N 个厂商的账号、计费、限流
反代需求。绕区域限制、接非官方渠道的模型

你算一笔账：自建一个 one-api，自己当中转站，至少流量和 Key 都是自己的。但绝大多数人不会自建，直接用别人的站——因为你信任它，或者你懒得想这事。

信任这个东西，在协议设计里是最靠不住的假设。

怎么解：两条路

我认为要往两个方向使劲，缺一不可。

第一条：客户端防范

既然中转站不可信，那就让"能暴露的东西"在客户端就降到最低。

比如：

敏感内容本地化。prompt 里要带的公司内部文档、个人隐私，先在本地脱敏或摘要，不把原文发出去
上下文瘦身。能压缩的压缩，能不带的不带，减少被看的面
客户端加密。如果模型厂商配合，客户端直接对 prompt 加密，中转站只看到密文
别把主 Key 交出去。给中转站用子 Key、限量的临时 Key，而不是厂商账号的主 Key

这一条现实可行，现在就能做。它的思路是：我管不了中转站，但我可以减少给它看的东西。

第二条：制定协议，让中转站只转发

这一条治本，但需要生态一起动。可以叫它 AI Secure Transport Protocol（ASTP），定位就是当年 TLS 的角色。

ASTP 的核心诉求一句话：

中转站只负责路由和计费，不接触内容。

技术上大致拆这么几块：

1. 内容端到端加密

请求体里的业务部分（prompt、上下文、工具定义）用加密保护，只有客户端和目标模型方持有密钥。中转站拿到的，是"目标模型是谁 + 一串密文"。

2. 路由与内容分离

中转站能看到的最小信息集，应该只有：

目标模型 ID（它得知道往哪转发）
用量（它得靠这个计费）
也许还有来源标识（做限流）

至于你问了什么、上下文是什么，它不需要知道。

3. 可信计量

这是最难的一块。中转站按 token 计费，可 token 数在密文里，它怎么数？

几条路：

客户端自报用量并签名，中转站按声明计费（信任但可审计）
用量由模型方在响应里返回，加密带回来，中转站只转发计费凭据
更远的：TEE 机密计算，让计量逻辑跑在硬件可信环境里，“看得见"的是代码不是人

4. TEE 作为兜底

如果盲转发纯软件做不干净，就用硬件：中转站跑在可信执行环境里，路由和计量逻辑可被远程验证，操作者本人也看不到明文。这是把"信任一个站"变成"信任一段可验证的代码”。

这玩意会落地吗

回看历史：HTTP 到 HTTPS，不是一天推成的。靠的是浏览器厂商带头、CA 体系成型、搜索引擎用排名逼你上 HTTPS、最后证书免费化。从"裸奔是常态"到"裸奔会被警告"，花了很多年。

ASTP 要落地，逻辑上差不多：

模型厂商先动。谁先支持客户端加密加盲转发标准，谁就拿到安全敏感客户（企业、开发者）的信任
中转站生态竞争。当"只看得到密文"成为卖点，那些明文站会被逐渐挤掉
SDK 默认开。各家的客户端库默认启用，用户无感

我判断前两步短期内难，但第三步一旦有人做，扩散会很快。因为用户不需要理解协议，只需要"默认安全"。

个人现在能做的

在协议落地之前，务实一点：

重要对话走官方直连，或者走自己完全可控的自建网关
把 Key 最小化：给中转站的永远是最小权限、最小额度的 Key
敏感内容不上公网中转：公司代码、隐私数据，本地先处理
优先用支持端到端加密的客户端和 SDK

一句话总结我的态度：

中转站是便利，不应该是信任的默认选项。协议没落地之前，客户端就是最后一道防线。

当年 HTTP 明文是技术无奈，今天的中转站明文是设计懒惰。技术无奈我们忍了，设计懒惰不该忍。

API on lategege 的技术博客