直连、聚合平台、本地网关：三种 AI API 接入方式怎么选
数据截至 2026-07，价格与限额以各官网为准。
这三条路不是”初级、中级、高级”的递进关系，而是三种不同的责任分配方式：直连是你自己扛全部（每家单独开户、单独管 key、单独接故障），聚合平台是把这些托管给一个第三方（省事，但账单链路和数据链路都多一跳），本地网关是把”聚合”这件事搬到自己机器上（凭证不出本机，但运维和排障归你）。先想清楚你愿意把哪部分交出去，选型基本就定了，纠结哪个技术更先进意义不大。
有个挺常见的误解得先说破：不少人把”聚合平台”和”本地网关”当成一回事，觉得都是”多接一层转发”。它们在协议层面确实很像——都是 OpenAI 兼容端点，都是改一个 base_url 的事——但在你最该在意的两件事上完全相反：密钥放在谁那里，和出问题时找谁。这篇就围绕这两条线把三种方式拆开讲。
三条路各是什么形态
厂商直连：你的代码直接请求某一家的官方 API 端点，密钥是你在那家控制台自己申请的，账单也在那家结算。链路最短，一跳都不多。
托管聚合平台：你在一个第三方平台开一个账号、拿一把 key，平台后端替你连各家模型。你的请求先到平台服务器，再由平台转发给上游厂商。你只需要维护一套凭证。
本地网关：在自己的机器（开发机或内网服务器）上跑一个进程，它对外暴露一个本地端点，各个 AI IDE、CLI、脚本统一指向它，由它负责把请求分发到你配置的各家上游。凭证存在你自己的机器上，不经过别人的服务器。
第三条路这两年变得容易了很多，因为出现了几个成熟的开源实现。下面拿 OmniRoute 做具体样本，它是一个 MIT 协议的开源 AI 网关，起源上是从 9router fork 而来，同时也是 Go 项目 CLIProxyAPI 的 TypeScript 移植版本。选它当例子不是推荐，是因为它的形态足够典型，讲清一个就能类推其他。
本地网关到底长什么样
抽象说”跑个进程”不太有画面感，看几条实际命令就懂了。OmniRoute 的启动方式是：
npx omniroute@latest
或者用 Docker：
docker run -p 20128:20128 diegosouzapw/omniroute
跑起来之后浏览器打开 http://localhost:20128 就是它的管理面板，而所有工具要填的 API 地址是 http://localhost:20128/v1。这一处就是全部——Claude Code、Codex、Cursor、OpenCode、Cline、Copilot 这些工具，各自的配置里把端点指向这个地址，之后你换上游、加供应商、调整回退顺序，全在网关这一层改，IDE 那边一行都不用动。
它还带几条常用命令：omniroute setup 是首次运行向导，omniroute doctor 做自检，omniroute chat 是个交互式 TUI 聊天窗口，omniroute models --search <关键词> 用来查某个模型当前有没有可用来源（也可以走 GET /api/models/catalog 接口）。仓库自述有 80 多条命令，日常大概率就用得上这几条。
加供应商的路径是面板左侧 Providers → + Add Provider → 搜索点选 → 连接 → 用 Test Connection 验证一下。认证方式分四类，这四类的差别值得单独记一下，因为它直接决定你要交出什么：
- OAuth：由网关代管登录流程，你不用手工填 API key；
- web cookie：拿浏览器会话凭证接入；
- API key：填你自己申请的密钥，属于付费类型（部分带免费额度）；
- Local：接本机跑的 Ollama、LM Studio、vLLM 这类本地推理服务。
最后这一类是本地网关相对聚合平台的一个结构性优势——你可以把云端模型和本机模型放进同一个端点、同一套回退链路里，聚合平台做不到这件事。
免费额度：可以试，但别当承诺
本地网关这条路这两年被讨论得多，很大一部分动力来自”免费”。OmniRoute 的目录自述覆盖 290 多个供应商、500 多个模型，其中 90 多个有免费档、40 多个是永久免费；免费选项里包括 Kiro、OpenCode Free、Pollinations，文档建议新手从 Kiro AI 起步，理由是免费、不需要 API key、并且能用到 Claude 系模型。仓库还给过一个零成本组合的示例链路：gemini-cli/gemini-3-flash-preview（每月 180K 免费额度）打头，回退到 if/kimi-k2，再回退到 qw/qwen3-coder-plus。
这里必须泼一盆冷水，而且这盆水是本文最该记住的一句话之一：**免费额度类信息变动极快，上面这些数字只能当”仓库文档当前版本是这么写的”来看，不构成任何持续可用的承诺。**供应商数量的口径本身在不同来源就对不上（有写 268+ 的，也有写 290+ 的），星标数之类的更是各说各话。真实情况通常是：某个免费档今天还能跑，下周上游一调策略就没了。所以如果你打算认真用，务必接多个免费供应商把自动回退启用起来，别把一条链路押死在单一免费来源上——这也是网关这类工具真正的价值点，它的配额感知自动回退就是为这种场景设计的。
对应地，生产环境不建议靠免费档撑。免费额度适合的是个人学习、试模型、跑一次性脚本这类”断了也无所谓”的场景。
模型 ID 和 auto 路由的小坑
多上游的架构会带来一个新问题：模型名该怎么写。OmniRoute 的做法是模型 ID 沿用各供应商的原生格式，仓库里举的例子形如 claude-opus-4-8、gpt-5.5、glm-5.1、kimi-k2.5。有的版本号里带点号看着奇怪，但那是上游 API 本来就要求的写法，不是网关自己发明的，照抄就行。
如果不想操心具体填哪个，把模型字段写成 "auto"，由网关按可用性自己挑。auto 适合”随便哪个能跑就行”的探索阶段；一旦你的输出质量对模型敏感（比如代码生成、结构化 JSON 抽取），还是显式指定为好，不然今天和明天跑出来的东西不一样，你会以为是自己 prompt 写崩了。
其他一些能力顺带提一句：它支持 MCP 和 A2A，有 Desktop 和 PWA 客户端，还带一个叫 RTK+Caveman 的上下文压缩，仓库称能省 15%-95% 的 token——这个区间跨度这么大，说明效果高度依赖具体内容，别按上限去做成本测算。想逐个工具照着配的话，仓库里 docs/reference/CLI-TOOLS.md 收了 33 个工具的配置方法，OpenCode 那边则是走一个叫 @omniroute/opencode-provider 的插件。
三条路怎么选：按你的处境对号入座
只固定用一两家模型、上了生产的项目 → 直连。多一跳就多一处故障源和一处责任模糊地带，出问题时你希望能直接看厂商的状态页，而不是猜是不是中间层挂了。计费和数据流向也最容易向合规同事解释清楚。
要横向试很多模型、又不想为每家单独开户 → 聚合平台或本地网关都行，差别在你介不介意凭证托管。介意就自己跑网关，不介意就选托管的，省下那点运维时间。
主力是 AI IDE / CLI 编程工具、手里已经攒了好几把 key → 本地网关的收益最明显。它解决的核心痛点其实不是”接更多模型”，而是”每个工具各配一套 key”这件事本身太碎，收敛成一处配置之后维护成本降一个量级。
团队要统一账单、审计和限额 → 别用开发机上的本地网关，那是单人工具。要么走厂商的企业账号直连，要么把开源网关部署到内网服务器上做成团队服务，两条路都行，但要有人负责运维。
做的是给外部用户提供服务的产品 → 优先直连，或者部署在自己可控基础设施上的网关。把用户数据经过一个你无法审计的第三方转发层，这个决定需要合规上说得过去。
必须说清楚的两个风险
**第一是凭证。**本地网关意味着你把各家的 API key、OAuth 令牌、甚至 web cookie 集中交给一个本地代理进程保管。这个模型比”交给某个第三方服务器”要好，但也不是零风险：开源不等于你审过代码，本机中招同样会一锅端。实际做法上建议——给网关用的 key 尽量单独申请、和生产 key 分开，能设消费上限的就设上；不要在共享机器或公共网络环境下暴露那个端口；定期看一眼各家控制台的用量有没有异常。
**第二是合规和条款。**用第三方渠道、web cookie 之类的方式间接接入某些模型，很可能不符合上游厂商的服务条款，这不是技术问题，风险要你自己评估和承担。本文不背书任何具体供应商。
顺带把最容易被误解的一点说明白：**这三条路都不会改变”某些海外厂商官方不支持中国大陆直连”这个事实。**OpenAI、Google Gemini、Anthropic 这类服务的准入限制是政策层面的，不是网络快慢问题，网关和聚合平台都不是”官方开通了大陆访问”的证明。市面上确实存在第三方中转服务声称能解决访问问题，客观上它们存在，但计费是否透明、数据怎么处理、会不会触发上游封禁，都需要你自己核实并承担后果——本文不推荐任何具体渠道，也不建议把这类链路放进生产环境的技术选型。
小结
三种接入方式的差别不在技术含量，在责任边界：直连责任最清晰、链路最短，适合生产和固定用量；聚合平台省事，代价是账单和数据都多一跳第三方；本地网关把凭证留在自己机器上、把多工具配置收敛成一处，适合个人开发者和重度使用 AI 编程工具的人，代价是排障归你自己。免费额度是本地网关这条路最吸引人的部分，也是最不可靠的部分，接多家做回退、别押单点、别拿它撑生产。选之前先回答一句话：这套东西出问题的时候，你希望找谁？答案会告诉你选哪条。