AI中转站全景拆解:从灰色生意到可信基础设施

壹 / 三堵墙与一条链

中转站为什么会出现

2026年2月，中国大模型的Token调用量首次超过美国。但绝大多数开发者和企业，依然无法直连OpenAI、Anthropic、Google的官方API。

网络不通，支付不了，价格也扛不住。三堵墙横在中间，催生出一门野蛮生长的生意——AI中转站。它用比官方低得多的价格，把GPT、Claude、Gemini的API包装成国内可直接调用的接口。

但低价的背后，是一整条灰色产业链。薅羊毛、盗刷信用卡、偷换模型、虚报Token用量、倒卖用户数据、卷款跑路，你能想到的灰产套路，在这个行业里几乎都有人干。今年6月8日，国家安全部发布安全提示，点名AI中转站的数据安全风险。上海一名站长被刑事拘留37天。央视做了专题报道。清朗专项行动关停了数百个违规站点。

三重墙

海外模型官方API在中国大陆面临三重障碍。

网络层面，OpenAI、Anthropic、Google的API服务器都在境外，国内直连要么超时要么不稳定。企业要解决，得自建VPN或租海外服务器做转发，成本和技术门槛都不低。

支付层面，官方API用美元计价，需要海外信用卡或PayPal支付。国内大多数开发者和中小企业没有海外支付渠道。即便有，汇率波动和手续费也增加了使用成本。

定价层面，以OpenAI为例，GPT-5.5的输入定价是每百万Token 5美元，输出30美元。对于重度用户，一个月的API费用可能上千美元。而中转站声称能以官方价格的3折甚至1折提供同样的服务。

三堵墙叠加，官方渠道走不通，低价替代方案自然有人买单。

三级产业链

中转站不是孤立的生意，它背后有一条三级产业链。

上游是卡商和号商。卡商提供海外信用卡，有的是盗刷来的"料卡"，有的是批量注册的虚拟卡。号商提供海外手机号、邮箱账号，用于批量注册各大模型平台的开发者账号。他们批量获取免费额度或开通订阅套餐，然后以极低价格转卖给中转站。

中游是中转站运营者。他们从上游进货，搭建一个API转发平台，把多个模型的接口聚合在一起，对下游统一售卖。入行门槛极低，一个开源的API转发程序（如OneAPI、NewAPI），一台服务器，几百块钱就能开张。这也是整个行业鱼龙混杂的根源：开张太容易，跑路也太容易。

下游是开发者、中小企业和科研机构。他们需要用海外模型，但走不通官方渠道，或者承受不了官方价格。中转站成了唯一可行的选择。有些用户知道自己用的是灰色服务，有些则完全不知情，尤其是通过某些"AI助手"产品间接使用中转站API的普通用户。

五种业务模式

不是所有中转站都在做灰产。按合规程度从高到低，大致可以分出五种模式。

最正规的是官方授权聚合，获得多家模型厂商的正式授权，合规转售API。这类平台凤毛麟角，因为OpenAI等厂商在中国大陆没有正式的授权转售渠道。

往下走一层是灰色采购加合规包装。通过非官方渠道获取API额度（比如批量注册账号薅免费额度），但在前端包装成正规服务，做ICP备案、甚至挂出隐私协议。这是目前大多数中转站的形态。

再往下是纯转发套利，不做任何包装，纯粹低价进、高价出，赚差价。这类站点通常不持久，货源断了就关站。

更灰色的是网页逆向，不走API，直接逆向ChatGPT等产品的网页接口，把网页版的功能包装成API对外提供。技术上更复杂，合规上更危险。

最混乱的是混合模式，以上几种混着来。官方额度用完了掺开源模型，API走不通了走网页逆向，哪个赚钱用哪个。

从第一种到第五种，风险逐级递增。但用户很难分辨自己用的是哪一种。中转站不会告诉你它的货源从哪来，模型到底跑的是哪个版本。

贰 / 低价的代价

八大灰色手法

中转站的低价不是天上掉下来的。把官方价格打到3折甚至1折，要么是货源本身有问题，要么是靠别的手段补利润。以下八种手法，在目前的行业中普遍存在，且往往不是单独出现。一个中转站可能同时用好几种。

叁 / 信任模型的崩塌

为什么"靠人品"必然失灵

明文代理的三种权力

前面在拆解灰色手法时，已经分别提到了中转站能看明文、能换模型、能改计费。把这三种能力放在一起看，才能看清问题的结构性本质。

中转站是一个明文代理。在TLS加密链路中，它扮演"中间人"的角色：用户的请求先发给中转站，中转站解密后看到明文，再用自己的凭证向下游模型平台发起请求，拿到响应后再转发给用户。

这意味着中转站同时握着三种权力。它能看明文，所有经过的请求和响应对运营者完全可见，TLS加密在这里中断，明文在这里暴露。它能定路由，决定用户的请求最终发给哪个模型，用户指定了GPT-5.5，中转站可以在后端转发给任何模型。它能改结果，可以截断内容、注入广告、插入恶意代码，甚至替换整个响应。UCSB团队发现的9个主动注入恶意代码的中转站，行使的就是这种权力。

当中转站连的不只是大模型

如果中转站转发的只是聊天请求，风险还相对可控。但AI Agent的兴起让情况发生了质变。

现在的Agent应用不再只是调用大模型做文本生成，而是通过中转站连接邮箱、数据库、企业内部系统、云服务平台。Agent的API请求里可能包含数据库查询语句、邮件内容、企业内部文档、云服务操作指令。

当中转站成为Agent与外部服务之间的必经之路，它掌握的就不再只是"聊天记录"，而是企业系统的操作权限。数据泄露从"内容暴露"升级为"权限滥用"，风险从"隐私问题"升级为"业务流程失控"。

UCSB团队发现的99组被窃的云凭证、17个尝试窃取AWS凭证的中转站，说明这个升级已经在发生。中转站不再只是一个被动的转发节点，它有能力主动利用截获的凭证，冒充用户身份访问云资源。

现有安全机制为什么挡不住

有人会说，不是有各种安全机制吗？我们逐一来看。

OAuth解决的是授权问题，用户不把密码给第三方，而是给一个有限权限的Token。但OAuth保护的是凭证，不是运行时数据。当Agent通过中转站调用API时，OAuth保证的是"中转站有权调用"，但中转站调用过程中看到的所有明文数据，OAuth管不了。

PII替换在发送请求前用占位符替换掉敏感信息（如姓名、身份证号），到响应阶段再还原。这保护了提示词中的部分隐私字段，但保护不了模型返回的响应内容。而且PII替换只能处理已知的敏感字段模式，对于代码片段、业务逻辑、API密钥等非结构化敏感信息无能为力。

服务端扫描在模型平台侧部署内容审核，检测违规请求和响应。这是启发式方法，依赖规则匹配和模型分类，无法提供密码学级别的保证。而且服务端扫描的视角是模型平台，不是中转站，它看不到中转站在转发过程中做了什么手脚。

运行时监控在用户侧部署检测，发现中转站的行为异常。同样是启发式方法，且需要用户自己部署和维护，门槛高，覆盖率低。这些机制各有用处，但有一个共同的局限：它们都无法解决"中转站同时握着三种权力"这个结构性问题。只要中转站能看到明文、能决定路由、能修改结果，任何外挂式的安全机制都只是打补丁。

一个真实的翻车案例

2025年，开发者社区广泛讨论了一个案例。一款月活数百万的AI编程工具被曝出在"无限续杯"模式下，通过自签CA证书拦截用户的HTTPS流量。

具体做法是：该工具在用户设备上安装一个自签的根证书，然后以这个证书为信任锚，对用户到模型平台之间的HTTPS连接做中间人拦截。用户的API请求和响应全部被解密、存储、分析。高峰期时，该工具还会把用户的请求从高端模型悄悄路由到更廉价的模型上，以控制成本。

用户以为自己在直连模型平台，实际上所有流量都经过了一个自己不知情的中间人。这个案例完整演示了明文代理的三种权力如何被滥用：拦截HTTPS是看明文，降级模型是定路由，响应替换是改结果。

合规视角：走不通的，和走得通的

从合规角度看，中转站能不能合法做下去，第一刀要切在"你接的是什么模型"上。

转售境外未备案模型（ChatGPT、Claude、Gemini），在现行法律框架下几乎不存在完整的合规路径。原因有三：截至2026年4月30日，国家网信办累计公示868款大模型备案、530款大模型登记，合计1398款，但没有任何一家海外大模型厂商在列，你转售的等于监管不认可的东西。OpenAI、Anthropic、Google的服务条款都明确禁止转售、禁止凭证共享、禁止绕过地区限制。你即便主动想备案也无从备起，上游模型本身不被监管体系接纳。

但转售境内已备案模型（DeepSeek、Qwen、GLM等），合规路径是清晰的。国产主流模型几乎都已在国家网信办完成备案或登记。接入这些模型的中转站，按部就班把证办齐就能合法运营。

具体要办哪些证？四张。

算法备案是基础。根据《生成式人工智能服务管理暂行办法》第十七条，具有舆论属性或社会动员能力的生成式AI服务必须开展安全评估并履行算法备案。中转站以"服务技术支持者"身份备案，比做完整的大模型备案投入更少、更容易通过。办理周期约2到3个月。

大模型登记和备案是两回事，别搞混。纯调用已备案模型、没有微调训练行为的，做"大模型登记"即可，审核相对轻。做了自研、二次开发或微调的，才需要走更重的"大模型备案"流程，涉及模型安全评估和语料审核。

ICP许可证是硬门槛。只要向用户收费，就是经营性互联网信息服务，必须取得ICP许可证。很多人把ICP备案和ICP许可证搞混，备案只是域名备案，许可证是经营资质。没有ICP许可证擅自从事经营性互联网信息服务，可处违法所得3到5倍罚款，没有违法所得或不足5万元的，处10万至100万元罚款，情节严重的责令关闭网站。申请ICP许可证要求主体是注册资本100万以上的中国大陆公司，有至少3名员工（含技术人员）的社保证明，法定审核期限为60日，实际办理周期因地区而异。

数据出境合规是最容易被忽视的。中转站的技术架构决定了用户请求必然经过你的服务器，把境内用户数据路由到境外模型服务器，这个动作本身就构成数据出境。目前有三条路：签订标准合同、通过网信部门安全评估、通过个人信息保护认证。一般规模走标准合同即可，处理个人信息达到100万人以上或涉及重要数据的，必须申报安全评估。据业内观察，目前几乎没有一家民间中转站真正完成过数据出境安全评估。

监管能做的是关停违法者，但无法凭空创造出一条合规路径。对于接境内模型的平台，合规路径已经摆在桌面上。对于接境外模型的平台，只要三堵墙还在，需求还在，灰色地带就会存在。要真正解决这部分的问题，需要的是一套让中转站"想作恶也做不到"的技术方案。

肆 / 从"可用中转"到"可信中转"

TrustedARI的技术路径

思路转换：不消灭中转站，改造它

前面的分析指向一个结论：中转站的三种权力是问题的根源。那直接消灭中转站行不行？

做不到。三堵墙短期内不会消失，开发者对聚合API的需求也不会消失。中转站提供的路由、适配、计费等基础设施功能，本身是有价值的。问题不在于中转站这个角色，而在于它行使权力的方式不受约束、不可验证。

清华大学的研究团队在2026年6月发表了一篇论文《TrustedARI: Towards Trust-Native Agentic Routing Infrastructure for Agentic AI》（arXiv:2606.15822），提出了TrustedARI方案。核心思路是：不取消中转站，把"默认可信"变成"协议可验证"。

具体怎么做到的？TrustedARI把Agent和中转站（论文里叫ARI）通过安全多方计算组成一个"虚拟客户端"，由这个虚拟客户端与下游服务方建立标准的TLS连接。服务方看到的还是一个正常的TLS请求，不需要做任何改造。但在这个虚拟客户端内部，Agent和ARI各持有一部分密钥，谁也看不到对方的隐私数据，谁也无法单独伪造或篡改请求。

在这个架构上，TrustedARI设计了三把锁，分别约束中转站的三种权力。

威胁模型：半诚实但好奇

在讲三把锁之前，需要先说清楚TrustedARI的威胁模型。

论文没有把ARI和Agent都假设为纯恶意实体，而是建模为"半诚实但好奇"（semi-honest but curious）。双方会遵守协议规则，但会尝试从协议执行过程中推断对方的隐私信息。

这个假设是务实的。中转站要维持业务运营，不太可能公然破坏协议，那样会被立即发现并抛弃，但它有强烈的动机去窥探用户数据、推断用户的API Key。Agent侧同理，它会遵守协议，但可能尝试少报Token用量来少付钱。

所以TrustedARI的信任设计是双向的：Agent验证ARI的路由行为（你确实把我的请求发给了正确的服务方），ARI验证Agent的计费申报（你报的Token用量确实是真的）。论文第8节也讨论了向更强的恶意安全模型扩展的路径，目前还没有完整实现，但架构上留了空间。

第一把锁：身份锁

让中转站没法偷换路由

中转站偷换模型的前提，是它能控制请求的路由目标。用户以为请求发给了OpenAI，实际被转发给了别处。要约束这种权力，需要让Agent能独立验证"请求到底发给了谁"。

标准TLS是两方的：客户端和服务器做握手，建立加密通道。但在中转站场景下有三方：Agent、ARI、服务方。如果用标准TLS，要么ARI和服务方握手（Agent无法验证服务方身份），要么Agent和服务方握手（ARI无法参与转发）。两难。

TrustedARI的方案是三方TLS握手。Agent和ARI通过多方安全计算组成"虚拟客户端"，与服务方完成标准TLS 1.3握手。关键在于握手过程中密钥的分阶段分配。

握手分四个阶段。密钥交换阶段，Agent和ARI共同生成握手密钥，但密钥被拆成两半，各自持有一半。ARI把自己那一半的握手密钥交给Agent，Agent把两半拼起来就能在本地验证服务方的身份证书。但ARI永远拿不到完整的服务端握手密钥，所以它无法伪造服务方的身份。

这意味着什么？Agent虽然不直接与服务方通信，但它能独立确认"我的请求确实发给了正确的服务方"。ARI负责转发，但如果它偷偷把请求路由到别的服务器，Agent在握手阶段就能发现身份不匹配，直接中止连接。

握手是一次性的成本。建连完成后，TLS通道可以复用，后续的请求不需要重新握手。如果Agent需要同时连接多个服务方，这些握手可以并行执行。实验数据显示，相比现有的三方TLS方案（DiStefano），TrustedARI的握手通信开销降低了39.34%，端到端建连延迟最高降低50.47%。在最差的网络环境下，在线握手时间也不超过10秒，在TLS连接建立的实用超时范围内。

第二把锁：数据锁

让中转站看不到明文

身份锁解决了"请求发给谁"的问题，但更核心的问题是：请求和响应的明文内容，中转站能不能看到？

标准方案下，中转站必须看到明文。它要用自己的API Key向服务方发起请求，就必须知道请求的完整内容。但用户的提示词是隐私，中转站的API Key也是隐私。双方都不想让对方看到自己的敏感信息。

TrustedARI的方案叫"安全模板实例化"。用论文里的一个实际例子来说明。

假设一个Agent要通过ARI调用一个电商结账服务。HTTP请求里有这些字段：buyer（买家姓名）、addr（收货地址）、item（商品编号）是Agent的隐私；Authorization头里的API Key、coupon（优惠券码）是ARI的隐私；HTTP方法、Host、Content-Length这些是公开的协议语法。

Agent和ARI事先约定一个公开的模板，模板定义了请求的结构（有哪些字段、每个字段的最大长度），但不包含任何具体的隐私内容。然后双方通过多方安全计算，各自把自己的隐私输入填进模板，拼装出完整的HTTP请求。

这个拼装过程有两个关键设计。第一是内容隐藏。每个隐私字段都被填充到公开的最大长度，真实内容藏在里面。比如buyer字段最大长度设为20字节，"Bob"只有3字节，剩下17字节用空字节填充。双方各自持有填充后内容的一半份额，拼在一起才能还原，但任何一方单独都看不到对方的明文。

第二是结构隐藏。这是更精妙的部分。即使字段内容被加密了，字段的实际长度本身也会泄露信息。如果ARI看到buyer字段虽然最大20字节，但每次都只用了3字节，它就能推断出这个用户的买家姓名很短，甚至通过长度变化模式推断用户行为。TrustedARI的结构隐藏拼接协议（SHC）不仅隐藏字段内容，还隐藏字段的真实长度。ARI连"这个字段实际用了几个字节"都看不出来。

拼装完成后，双方用共享的客户端密钥（两方各持一半，必须协作才能加密）对请求做TLS加密。加密后的请求是一个标准的TLS记录，ARI把它转发给服务方。服务方解密后看到完整的请求内容，但ARI只看到密文。

响应方向更直接。服务端密钥在握手阶段只分配给了Agent，ARI拿不到。所以服务方返回的加密响应，只有Agent能解密。ARI转发密文，但看不到明文。实验数据：在GitHub、Google、OpenAI等10个真实API上，隐私请求构造的平均计算时延为1.32秒。其中结构隐藏（SHC）只额外增加0.19秒和0.58MB，占总开销的14%和1.3%。对于大多数API调用场景，1到2秒的额外延迟是可以接受的。

第三把锁：账单锁

让计费可以被独立验证

前两把锁解决了"发给谁"和"看到什么"的问题，但计费的问题更微妙。

在TrustedARI的架构下，只有Agent能解密响应明文，ARI看不到响应内容。但计费信息（比如LLM返回的token_usage字段）就藏在响应里。ARI要按Token收费，却看不到Token用量，只能靠Agent自己报。一个想省钱的Agent完全可以少报用量。

所以账单锁的信任方向跟前两把锁是反的：不是ARI向Agent证明什么，而是Agent向ARI证明"我报的Token用量是真的"。

TrustedARI用零知识证明来解决这个问题。Agent从响应明文中提取计费字段（比如token_usage: 1500），然后生成一个零知识证明，证明这个数字确实是从服务方返回的TLS加密响应中正确提取的。ARI验证这个证明，但看不到响应的其他内容。

这里有一个关键的性能优化。大模型API的响应可能很长，如果对整个响应做零知识证明，计算开销会爆炸。TrustedARI的方案是局部解析电路：只对包含计费字段的那一小段响应做证明，不需要处理整个响应包。

具体怎么做？大模型API的响应通常是JSON格式，计费字段（usage）往往在JSON的某个位置。TrustedARI从JSON的开头或末尾取更近的那一侧来定位计费字段，只解密和解析这一小段窗口。比如计费字段在JSON末尾附近，就从末尾往前解析，只需要处理几个AES加密块，而不是整个响应。

实验数据：计费证明的平均生成时间为3.50秒，比基线方案（DECO+ZKMB）快28.20倍。约束数量从平均2062万减少到62万，减少了33.26倍。验证时间只有3.44毫秒。而且Agent可以收集多个响应后批量生成证明，不会阻塞正在进行的API调用。

三把锁合在一起：双向验证的信任闭环

把三把锁放在一起看，TrustedARI建立的是一个双向验证的信任闭环。

Agent侧的验证：通过身份锁，确认请求发给了正确的服务方，ARI没法偷换路由。通过数据锁，确认请求和响应的明文只有自己能看到，ARI没法窥探数据。

ARI侧的验证：通过账单锁，确认Agent申报的Token用量是真实的，Agent没法少报省钱。

与现有方案的差异

在TrustedARI之前，学术界已经有TLS-oracle这类方案，通过TLS握手来证明数据来源的真实性。DECO和Coral是两个代表性工作。

但TLS-oracle解决的是"证明数据来自某个服务器"的问题，假设客户端是诚实的、服务器是诚实的，只有第三方验证者需要被说服。ARI场景比这复杂得多：双方都有隐私输入，只有一方能拿到响应明文，还需要按量计费。这三个特征是传统TLS-oracle不支持的。DECO假设客户端可以独立完成TLS握手，但在ARI场景中Agent没有API Key，无法独立完成。Coral支持多方参与TLS，但不支持隐私保护请求构造和可验证计费。TrustedARI没有发明新的密码学算法，它的价值在于把三方TLS握手、多方安全计算、零知识证明这三项已有技术组合起来，针对中转站场景做了专门优化。

落地：到底怎么用，谁来改

一个技术方案再好，如果要求所有参与方都改造系统，落地就无从谈起。TrustedARI的落地路径是这样的。

服务方（OpenAI、Google、GitHub等）零改造。三把锁的全部操作都在Agent和ARI之间完成，服务方看到的仍然是标准的TLS连接和HTTP请求，不需要做任何适配。这是最重要的兼容性保证：你不需要等OpenAI支持这个协议，今天就能用。

Agent侧加载一个Skill。论文里提到的实现方式是给Agent装一个适配器（以Anthropic的Agent Skills形式），这个适配器把Agent的输入映射成TrustedARI兼容的请求格式。论文用Gemini-3-Flash、GPT-5.2、Claude-Sonnet-4.5三个模型测试了Agent生成兼容请求的准确率，最大下降仅0.45个百分点。换句话说，现有的大模型Agent几乎不需要额外训练就能适配。

ARI侧需要部署协议库。这是唯一需要主动改造的一方。中转站需要集成TrustedARI的协议库，支持三方TLS握手、安全模板实例化、零知识计费证明。论文的实现大约是9000行C++加3000行Go代码，基于EMP-toolkit和BoringSSL构建。

论文还提到了一个更进一步的落地方向：与X402托管支付协议集成。Agent先向智能合约托管账户存入预付款，API调用完成后，Agent提交零知识计费证明，合约自动验证并按实际用量结算，剩余款项退回。这样连支付环节都不需要信任ARI。

还有什么问题

性能开销方面，握手是一次性的，建连后可复用。日常调用的额外开销主要在请求构造（约1.3秒）和计费证明生成（约3.5秒）。对于实时聊天场景，这个延迟体感明显。但对于批处理、后台任务、非实时分析等场景，完全可接受。随着密码学协议的优化和硬件加速（如TEE可信执行环境），这些数字还有下降空间。

威胁模型的局限方面，半诚实假设意味着，如果中转站真的恶意破坏协议（而不是只偷看），TrustedARI的保证会打折扣。论文第8节讨论了向恶意安全模型扩展的路径，但还没有完整实现。不过论文也指出，即使在半诚实假设下，恶意攻击者能获得的优势也很有限：篡改请求主要导致请求失败或服务拒绝，而不是泄露隐私数据。

生态推动力方面，TrustedARI需要中转站主动部署。在当前环境下，大多数中转站靠的就是"看明文"和"定路由"来赚灰色利润，让它们主动放弃这两种权力，动力不足。推动力可能来自三个方向：一是监管要求，如果监管把"部署可验证计费和隐私保护"作为中转站合规的必要条件；二是用户需求，如果企业用户把"支持TrustedARI"作为选择中转站的硬性标准；三是平台推动，如果模型平台在API层面支持或要求可信中转协议。