AI 网关和请求转发有什么区别？六个判别维度

先给结论：AI 网关和「把请求原样转发出去」的区别，不在功能列表，在六个可以自己动手验证的判别点——模型保真、计费粒度、失败处理、可观测性、协议兼容、上下文完整性。两者都能让你「跑起来」，差异要到项目复杂之后才暴露，所以选型阶段必须靠验证而不是靠宣传。这篇不讲哪家好，只讲怎么判断：判别标准比推荐名单有用，名单会过期，标准不会。

先说清楚这个品类是什么

在开发者和模型厂商之间加一层统一接入，这类产品的通称是 AI 网关（AI Gateway），国际上比较有代表性的是 OpenRouter。它要解决的问题是真实存在的：官方订阅需要境外支付方式、按消息条数限流且用量不可查、多家模型要分别注册分别对接协议。网关把这些差异吃掉，对上暴露统一接口。

但「加一层」这件事，做深和做浅差别巨大。 最浅的做法是配一个反向代理把请求转出去，按 token 加价转售；最深的要处理协议兼容、额度核算、多节点调度、缓存透传、错误语义保持。两者都能让 curl 返回 200，区别在你的项目变复杂之后。

六个判别维度

下面逐条展开验证方法。

1. 模型保真：你选的模型，真的被调用了吗

这是大家最关心也最难验证的一点。风险有两种：替换（你选 Opus，实际调用更便宜的模型）和削减（模型对，但最大输出、思考预算被压低）。

方法一：固定题目双渠道比对。 准备三到五道有标准答案的题——算法题、有明确解的数学题都行——在官方渠道和待测渠道各跑一遍，对比答案质量和推理风格。题目必须够难：被换成低配模型时，复杂推理题上的差异很明显，简单题则看不出来。

方法二：看额度触顶时的行为。 这是区分度最高的信号。额度用尽时，正规实现会明确报错并告诉你窗口何时重置；不正规的实现会静默改用另一个更便宜的模型继续返回内容——质量下降了，你完全无感。刻意把额度跑到触顶，看它报错还是继续输出，几分钟就能测完。

方法三：追问自报身份。 让模型自己说它是哪个版本。这个方法只能参考，不能作为证据——模型对自身版本的认知本来就不可靠，且容易被系统提示词覆盖。只有当自报结果和你选的差了一整个档位时，才值得顺着查下去。

2. 计费粒度：服务方的利益方向朝哪

这一条决定了服务方和你的利益是否一致：

• 按 token 转售加价：你用得越多，对方赚得越多。这个模式下，服务方没有动机帮你省 token，也没有动机优化缓存命中率——恰恰相反。
• 订阅制包月：收入与你的实际用量解耦。你少用一点它不少赚，你多用一点它不多赚，没有多跑 token 的动机。

按量计费在 AI 编程场景下对用户本身也不友好：你没法预算。写代码不像调 API，你不知道这次重构会读多少文件、来回几轮，一周高强度重构就可能烧完一个月的预算。

验证很简单：看定价页有没有清晰的 token 单价表，或者直接问「额度怎么算、能不能实时查」。答不上来的，通常是因为后面根本没有额度核算层。

3. 失败处理：错误信息是原样透出还是被吞掉

这一条平时用不到，出事时决定你排查多久。

简单转发的典型症状是把上游的错误吃掉，统一返回一个自造的 500 或者一个空响应。你看到的是「请求失败」，看不出究竟是超出上下文长度、参数不被支持、还是触发了内容策略——三种情况的处理方式完全不同。

验证方法：故意发一个必然失败的请求，比如带上一个已被弃用的参数（Claude 5 家族已弃用 temperature，带上会直接返回 400）。然后看返回体：

• 拿到上游原始的错误码和 error.type、error.message → 错误语义被保住了
• 拿到一句含糊的「服务异常，请稍后重试」 → 中间层把信息吞了

顺带还能测出重试策略：观察一次失败请求实际发出去几次。无限重试会在额度告急时加速消耗，而你看不到。

4. 可观测性：能不能实时查到自己用了多少

这条最能筛掉不认真的服务，因为它需要真的做一层额度核算，骗不了。

有意思的是，官方订阅在这一点上反而是弱项——按消息条数限流、用量不可查，你只能撞到墙才知道。所以一个网关如果能把用量透明化，那是比官方更好的体验，而不只是追平。该有的三样：

1. 当前窗口已用额度
2. 当前窗口剩余额度与重置时间
3. 逐条请求日志（时间、模型、消耗）

验证方法：连续跑 10 次请求，然后刷新控制台，看数字动没动、请求记录对不对得上。做不到，说明它只是转发，没做核算。

5. 协议兼容：高级功能还在不在

这是最容易被忽略、也最能暴露技术深度的一条。

Claude Code、Codex CLI 这类工具依赖大量高级特性：Prompt Caching、工具调用、MCP 连接器、推理链回传、长上下文、流式响应。只覆盖基础对话请求的实现，这些一用就出问题：

• 「能聊天但工具调不动」——工具调用的请求/响应结构没有正确转换
• 「MCP 连上了但没反应」——连接器相关的字段被过滤掉了
• 「长会话跑一半崩」——流式响应的分帧处理有问题

验证方法：不要用 curl 发一句「你好」来测。跑一个真实项目，让它读十几个文件做一次跨文件改动，中途调用几个 MCP 工具，看能不能一次做完。五分钟，能筛掉大部分只做了基础转发的实现。

6. 上下文完整性：长会话里信息有没有丢

最后一个隐蔽的问题：中间层有没有动你的上下文。有些实现为了省成本会在转发前裁掉历史消息，或重排消息顺序以提高自己那侧的缓存命中。结果是模型「忘事」——你在第 5 轮定的命名规范，第 40 轮它不认了。

验证方法一：长会话回溯。 连续对话四五十轮之后，问它「我们最开始约定的命名规范是什么」。答不上来，要么是上下文被裁了，要么是被重排了。

验证方法二：看缓存命中率。 重复读同一批文件时，正常实现的 Prompt Caching 命中率应该稳定在较高水平。命中率异常低意味着上下文每轮都在变。这不只是慢和贵的问题——它说明你发出去的东西，和你以为发出去的东西，不是一回事。

三个 30 秒能做完的快速检查

不想逐条验证的话，问这三个问题就能筛掉大部分：

三个都是「是」，才具备网关的基本特征。任何一个是「否」，就要多问几句。

第三条还有一层容易被忽略的意义：用官方原生客户端意味着你随时能切走，改两行环境变量就换服务方。一个愿意让你零成本切走的服务，是对自己产品有信心的信号。

对照：Code2AI 在六个维度上的做法

按同一套标准自我披露一次，方便横向比对。Code2AI（code2ai.codes） 的实现是：

产品结构上也做了拆分：Claude 控制台、Codex 站、多模型网关是独立产品线、单独订阅——一个池子混着卖的结构，往往意味着后端调度是黑盒，你不知道请求最终去了哪。要把 AI 能力集成进自己的产品，则走 聚合 API，OpenAI 协议兼容，存量代码改一个 base URL 即可。

上面这六项都可以用本文的方法自己验，判别标准应该一视同仁。

为什么值得花这半小时

这六个维度有个共同特点：在简单场景下完全看不出来。用 curl 发一句「你好」，简单转发和真网关的返回一模一样；等项目上了生产才发现问题，迁移成本已经不是零。而且这半小时的成果可以复用——标准建立之后，评估下一家只需要五分钟。

常见问题

AI 网关到底是什么？

开发者和模型厂商之间的统一接入层。它对下屏蔽各家模型在协议、鉴权、计费上的差异，对上暴露一套统一接口，同时承担额度核算、多节点调度、错误处理等职责。OpenRouter 是国际上比较有代表性的一个。

怎么判断一个服务是真网关还是简单转发？

问三个问题最快：能不能实时查到自己用了多少？计费跟用量是不是解耦的？用的是不是官方原生客户端？三个都是「是」才具备网关的基本特征。要更严格的话，按本文六个维度逐条验证，全部跑完约半小时。

怎么自测模型有没有被替换？

两个可靠办法。一是准备三到五道有标准答案的难题，在官方渠道和待测渠道各跑一遍对比推理质量——题目必须够难，简单题看不出差异。二是刻意把额度跑到触顶，看它是明确报错还是继续静默输出，后者说明它换了模型。追问模型自报版本只能参考，不能作为证据。

为什么订阅制比按 token 计费好？

两个原因。一是利益方向：按 token 转售加价的模式下，你用得越多服务方赚得越多，它没有动机帮你省 token 或优化缓存命中率。二是可预算性：AI 编程场景下你事先无法估算用量，按量计费意味着账单不可预测。

上下文被裁剪了会有什么表现？

典型表现是模型「忘事」——长会话跑到四五十轮后，它不记得前面约定过的规范。另一个信号是 Prompt Caching 命中率异常低，说明上下文每轮都在变。

为什么强调要用官方原生客户端？

两层意义。安全上，要求你装专有客户端或魔改版，意味着你的代码要经过一个来路不明的程序。迁移上，官方客户端意味着换服务方只需改两个环境变量——这既是你的退路，也是服务方对自己产品有信心的信号。