AI 基础设施选型：网关、工作流、协议层怎么搭
数据截至 2026-07，价格与限额以各官网为准。
大多数人不需要”搭一套 AI 基础设施”，需要的是把三件具体的事分开：模型入口统一到一个地方（网关层）、多步任务有个地方编排（工作流层）、工具能被模型稳定调用（协议层）。这三层的成熟度、上手成本、被替换的风险完全不同，混在一起选型，结果通常是花最多力气搭了最容易被淘汰的那一层。
先承认一个常见误解：很多人以为基础设施要从下往上搭，先把网关、编排、监控铺齐，再开始写业务。实际情况恰恰相反——个人和小团队在 AI 这条线上，业务形态每两三个月就会变一次，先铺底座往往是把还没验证的假设固化成代码。更可行的顺序是：先用最简单的方式跑通业务，等某个痛点真的开始反复出现，再把那一层单独抽出来。这篇按三层拆开讲，每层都说清楚”什么时候该上、什么时候不该上”。
第一层：网关层解决什么问题
网关层要解决的痛点很具体，你可以对照一下自己有没有踩到：
- 手上有三四家模型的 key，每换一个工具就要重新填一遍 base_url 和密钥；
- 某一家今天限流了，手动改配置切到另一家，改完还得重启一堆东西；
- 想知道这个月各家分别花了多少钱，只能挨个登控制台看账单；
- 团队里有人把 key 写进了仓库，你想统一收口但不知道从哪下手。
只要上面命中两条以上，网关层就值得上。如果一条都没命中——比如你只用一家模型、只在一个工具里用——那加一层网关纯属给自己找事，它引入的调试复杂度比省下的配置成本高。
网关层的核心价值只有一句话：把”哪家模型”这个决定从业务代码里搬出去。业务代码只认一个本地端点和一个模型名，换供应商、加回退、做统计都在网关里改，不用动上层。
用 OmniRoute 做一个可跑的网关层
具体到工具选择，开源方案里 OmniRoute 是个可以直接上手的样本，用它举例是因为部署路径足够短，而不是说它一定比别的方案好。
按仓库说明，它是 MIT 协议的免费 AI 网关，一个端点可以接 290+ 供应商（其中 90+ 有免费档）、500+ 模型，覆盖 Kimi、Claude、GPT、OpenAI、Gemini、GLM、DeepSeek、MiniMax 这些常见家族。来路上它由 9router fork 而来，是 Go 项目 CLIProxyAPI 的 TypeScript 移植——知道这个来路有用，说明它的路由逻辑不是从零写的，但也意味着两个项目的功能会各自漂移，遇到问题别拿另一个项目的文档对着排查。
最短的启动方式是：
npx omniroute@latest
或者用 Docker：
docker run -p 20128:20128 diegosouzapw/omniroute
起来之后打开 http://localhost:20128 就是面板。给上层工具配置时统一填 http://localhost:20128/v1 这一个地址，Claude Code、Codex、Cursor、OpenCode、Cline、Copilot 这类工具都能对接，仓库另外还列了 Kiro、Command Code、Antigravity、Windsurf、AMP 以及任意 OpenAI 兼容工具，逐个工具的配置写法集中在仓库的 docs/reference/CLI-TOOLS.md 里（仓库称覆盖 33 个工具），OpenCode 走的是 @omniroute/opencode-provider 这个插件。
几条会经常用到的命令：
omniroute setup—— 首次运行的向导，第一次别跳过；omniroute doctor—— 自检，连不上先跑它而不是先怀疑上层工具；omniroute models --search <term>—— 查某个模型现在能不能用，也可以走GET /api/models/catalog；omniroute chat—— 交互式 TUI，验证链路通不通比打开 IDE 快。
加供应商在面板左侧 Providers → + Add Provider，搜索点选之后，免费供应商无需凭证直接 Connect，接完记得点 Test Connection 验一下，别等业务跑起来才发现没通。认证方式一共四类：OAuth（由网关代管登录、不用自己拿 key）、web cookie、API key（付费类，有的带免费额度）、Local（Ollama、LM Studio、vLLM 这类本地推理）。这四类的运维成本差别很大，OAuth 和 cookie 类依赖登录态，掉线要重新授权；API key 类最稳定但要花钱；Local 类不花钱但吃你自己的显存。
免费档能用到什么程度，边界在哪
这是最容易被夸大的部分，得说清楚。
按目录口径，290 个供应商里 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（同样标称无限免费）。
但这里必须泼一盆冷水，免费额度类信息变动极快，上面这些只应被当作”仓库文档某个版本里的示例”，不是承诺。所谓”无限免费”更是要打问号——它可能是当前阶段的推广策略，也可能随时加限速、加登录门槛或者直接下线。把生产任务押在免费档上，本质是把服务可用性交给一个你无法约束的第三方。合理用法是：日常探索、写玩具项目、跑批量的低价值任务走免费档；一旦这条链路承载了别人在等结果的事情，就该换成付费档，或者至少把付费档配成兜底的最后一跳。
模型 ID 这块有两个坑要提前知道。一是模型名可以填 "auto"，让网关自己挑，省事但不可控，做对比测试时别用；二是显式指定时用供应商原生格式，仓库示例里像 claude-opus-4-8、gpt-5.5、glm-5.1、kimi-k2.5 这种带点号版本号的写法看着别扭，但那是上游 API 本身的要求，网关只是透传，别自作主张改成下划线或去掉点号。哪些名字当前真的可用，用 omniroute models --search 现查，别抄几个月前的文章。
网关层的风险，得自己认
这类聚合网关有一个绕不开的性质：你把各家的凭证都交给了一个本地代理进程。这意味着几件事——
第一，凭证集中了，风险也集中了。原来一把 key 泄露只影响一家，现在网关的配置目录一旦被别人读到，等于全套都漏。放配置的目录别丢进有同步盘的路径，别提交进仓库，团队共用时更要想清楚谁有机器的访问权。
第二，OAuth 和 web cookie 这两类认证方式，本质是用你的登录态去调用面向个人用户的服务。这类用法是不是符合对应厂商的服务条款，需要你自己去看条款原文判断，不同厂商写法差别很大，这篇不替任何一家下结论。
第三，涉及海外厂商就必然要面对准入问题：这几家官方并未把中国大陆列为受支持地区，注册、控制台与 API 端点都在境外，其中 Anthropic 官方受支持地区列表不含中国大陆（anthropic.com/supported-countries）。网关能帮你统一入口，但改变不了准入这件事——它是政策层面的前提，不是”配置正确就能解决”的技术问题。以各厂商官方公布的受支持地区为准；本文不提供也不背书任何第三方中转渠道。
另外，网关自述的一些能力也要理性看待。比如它带 RTK+Caveman 压缩，仓库称能省 15-95% token——这个区间宽到几乎不构成承诺，实际省多少完全取决于你的请求长什么样，重复前缀多的场景省得多，一次性长文本几乎省不到。想知道自己这边省多少，只能开着跑一段时间对账，别拿区间上限做预算。至于社区热度，第三方资料称 23k+ stars、500+ 贡献者，供应商数量各来源口径也不一致（268+ 到 290+ 都有），这类数字看个量级就行，不必当作选型的决定性依据。
第二层：工作流层，什么时候才该上
网关层解决”调用谁”，工作流层解决”按什么顺序调用、中间怎么存、失败怎么办”。
这一层的选择很多，可视化编排、代码编排、纯脚本都能做，具体产品的对比可以看站内已有的几篇：Dify、n8n、Coze 三者怎么选、n8n 入门。这里只讲一个判断标准。
如果你的任务能用一个脚本从头跑到尾，就别上工作流平台。 工作流平台真正开始产生价值，是在下面这些条件出现之后：任务需要被非技术同事触发或修改；步骤之间有人工审核环节；需要定时或被外部事件触发；某一步失败之后要能从断点续跑而不是整条重来。这些条件一条没有的时候，一个 Python 脚本加上 cron 比任何平台都好维护。
反过来说，一旦上了工作流平台，请把它和网关层的边界划清楚：工作流平台里所有的模型调用，统一指向网关的本地端点，不要在每个节点里各自填 key。这是三层架构里最值钱的一条纪律。做到了，换模型只改网关一处；做不到，你会在几十个节点里挨个改 key，而且永远漏掉一两个。
第三层：协议层，MCP 和它的定位
协议层解决的是”模型怎么调用外部工具”这件事的标准化。MCP 是目前这一层里讨论最多的方案，站内有基础介绍：MCP 协议是什么、MCP 配置教程。
从基础设施选型的角度看，协议层有两个特点。一是它比另外两层更”薄”——它规定的是接口形态，不规定你的业务逻辑，所以迁移成本相对低；二是它还在快速演进，规范版本变动会带来兼容问题，这也是站内单独有 MCP 版本兼容 这类话题的原因。
具体到网关这一层要不要管协议，OmniRoute 声称支持 MCP 和 A2A，另外提供 Desktop 和 PWA 形态。但要注意区分：网关支持 MCP，和你的客户端支持 MCP，是两件不同的事，能力最终由链路上最弱的一环决定。建议的做法是先在客户端侧把 MCP 跑通，确认工具调用行为符合预期，再考虑要不要让网关也参与这一层，而不是一开始就把两处都打开——一旦出问题，你分不清是谁的锅。
三层怎么组合：给两种典型情况的建议
个人开发者、只想省钱和少配置：只上网关层。跑起来 OmniRoute，接两三个免费供应商配好回退，把 IDE 和 CLI 全部指向 http://localhost:20128/v1。工作流层用脚本代替，协议层等确实需要模型访问本地工具时再说。这个组合的搭建时间大概是一个下午，收益是以后换模型不用再改十个地方。
小团队、有需要重复跑的业务流程：网关层 + 工作流层。网关放在一台大家都能访问的机器上，凭证统一在那儿管，个人机器上不再留 key；工作流平台负责编排，所有节点的模型调用指向网关。协议层同样往后放，等到确实有”模型需要读写公司内部系统”这种需求，再单独立项做，因为那时候安全边界的设计比协议本身更花时间。
两种情况的共同点是：协议层都排在最后。不是因为它不重要，而是它的价值依赖于前两层已经稳定，在业务形态还在变的时候投入协议层，返工概率最高。
诚实说局限
这篇讲的是个人和小团队规模的选型思路，几件事没覆盖，也不该被套用：
- 多租户、审计合规、SLA 承诺这类企业级需求，本地起一个开源网关是不够的，需要的是有责任主体的服务，选型逻辑完全不同。
- 成本核算的精度：网关能给你一个统一的用量视图，但和各家官方账单之间大概率对不上，流式调用的 token 统计口径本身就存在差异。要精确记账，还是以各家控制台的账单为准。
- 免费档的持续性：上文所有免费相关的说法都以仓库文档当前版本为准，几个月后大概率会变，别把这篇当作长期有效的配置清单。
- 具体产品的优劣：这篇拿 OmniRoute 举例是因为它路径短、便于说明网关层长什么样，不构成推荐；同类方案还有不少，对比可以看 OpenRouter 与 OmniRoute 的差异 和 AI 网关对比。
小结
第一，把 AI 基础设施拆成网关、工作流、协议三层来看，比笼统地说”搭一套”清楚得多，因为三层的成熟度和该上的时机完全不同。第二，网关层是三层里最值得先做的，它把”用哪家模型”从业务代码里搬走，一个下午就能落地，OmniRoute 这类开源方案的启动成本低到可以直接试。第三，免费档的价值在于多家串起来做回退，但任何”无限免费”的说法都别当承诺，承载正事的链路要留付费兜底。第四，工作流层等到出现人工审核、定时触发、断点续跑这类需求再上，上了就守住”所有模型调用走网关”这条纪律。第五，协议层放最后，也别忘了海外厂商的大陆准入是政策前提而非技术问题，具体以各官网当前地区政策为准。