引子
2025 年企业 AI 的行业叙事，被一组庞大的数字占据。
黄仁勋在 GTC 上喊"再加几千亿"，Altman 抛出 5000 亿美元的 Stargate 计划，阿里云宣布三年投入 3800 亿做 AI 基建。
算力成了叙事中心，所有叙事都在暗示同一件事：买得多，赢得快。
然而 BCG 在 2025 年的企业 AI 研究中，则给出了完全不同的数字。成功的 AI 落地，资源分配的权重是 70% 人和流程、20% 技术栈（含算力在内）、10% 算法本身——把预算全砸在买卡上，最多覆盖 20% 的权重。
Menlo Ventures 的报告则显示，企业 GenAI 支出里基础设施层捕获了 180 亿美元，占总支出的一半，同比翻倍。这 180 亿里其中一部分没花在买卡上，花在了"治理"——也就是网关及其周边组件。
对照之下，AI在企业中落地的问题并不在算力够不够，而是在算力进入企业之后，谁来管它的流向。
这道关，就是内部 AI 网关。
为什么 网关是 AI落地 企业 的第一站
企业大规模推行 AI 时，所有员工都会以不同程度访问外部 AI 推理服务。问题在于，员工的访问路径通常是分散的。有人用公司统一采购的账号，有人用自己在淘宝、闲鱼买的低价 API 中转站，有人直接用 ChatGPT、Claude 的官方订阅。分散访问带来的风险结构，是企业 AI 落地最容易被低估的早期问题。
第一组风险是数据外泄。
淘宝、闲鱼上的低价 API 中转站运营方有完整的技术能力从缓存里还原用户的对话内容。员工以为自己在省钱，实际上把公司代码、客户数据、内部文档以明文形式递给了中转站运营方。这种绕过公司管控私自接外部 AI 服务的连接，业内通常称为"野连接"。
第二组风险是成本失控。
员工分散使用提供的AI服务时，公司无法统计真实的 token 用量、无法跟供应商对账、无法做预算管控。一旦 AI 编程工具的渗透率起来，token 消耗会以非线性速度增长。
在笔者与客户的一次讨论中，对方展示了公司内部 AI 编程agent token用量的真实曲线：前3个月，公司范围内Top10用户日均 token 用量均未超过 1 亿，于是公司采取了 tokenmaxxing策略，"token不限量，鼓励使用"；连续在接下来3个月的推广后，部分员工开始使用 agent loop 框架（如 Hermes、小龙虾）执行定时自动化任务，甚至是自主开发工作，于是个人agent的单日 token量就 飙到 8~20 亿，甚至出现单个 agent 三小时token用量就超过 2000 元的情况。
第三组风险是审计缺失。
当公司需要回溯"某段代码是不是 AI 生成的""某次客户数据外泄是不是通过 AI 渠道完成的"时，分散访问根本无法追溯。受监管行业（金融、医疗、法律）的合规要求会直接卡在这一层。
网关服务（Gateway）是这三组风险的统一解决方案。它部署在公司内网与外网推理服务之间，作为统一流量入口——所有 AI 调用必须经过网关，由网关统一对外、统一认证、统一审计。员工没有"绕开"的必要，因为公司提供的更快、更稳，通常也比淘宝中转站更便宜。
这一思路与近年来几份行业研究的判断一致。
麦肯锡《State of AI 2025》的判断："所有人都采用了 AI，几乎没人重设计组织来用它。"重设计组织的第一步，不是改架构图，是改流量出口。Menlo Ventures 2025 企业 GenAI 报告显示，基础设施层捕获了 180 亿美元，占 GenAI 总支出的一半（同比翻倍）——这笔钱里其中一部分花在了"治理"，也就是网关及其周边组件上。
企业 AI 落地的第一笔钱，不应该花在买卡、买推理服务上，而是应该花在网关这道流量管控设施上。
AI网关的核心功能：一份企业 内部 AI 基建的能力清单
把企业的 AI 网关拆开看，里面装着的不是单一功能，而是 5-7 个相互关联的子系统。这套子系统恰好是一份完整的"企业 AI 内部基建清单"。
统一账号体系与认证。
员工使用 AI agent 时不再直接对接外部供应商账号，由公司网关统一发放账号、统一验证身份。这一层背后是企业 SSO、IAM、RBAC 等身份基础设施。网关在身份层做的是把"员工身份"翻译成"AI 服务身份"，让供应商看到的是公司账号而不是个人账号。
流量计算与对账。
所有 token 用量按模型、按上行下行、按缓存命中分维度统计，月底跟供应商对账。这一层对应的是计费系统、成本中心、AP（Accounts Payable）流程。糊涂账是企业 AI 第一个失血点——一旦供应商报的数和公司自己统计的对不上，谈判和预算都失去依据。
连接池管理。
网关维护多个 API key（来自不同供应商），放进池子里统一调度，削峰填谷，控制并发数。同样的算力预算能撑住更多员工同时使用。这一层背后是流量调度、负载均衡、断路器等通用基建组件。
模型 智能 适配。
根据 prompt 复杂度自动选择模型——简单任务路由到便宜模型，复杂任务才上贵模型。这是降本效果最显著的一层，也是工程难度最大的一层。它背后需要的是评估体系、A/B 测试框架、模型质量监控。
数字身份证与可追溯性。
识别员工是否使用了未经公司认证的 AI 服务（如私人中转站），通过数字身份证在防火墙上拦截未经验证的连接。这一层对应的是零信任架构、设备指纹、网络访问控制（NAC）。
可观测性。
企业中纷繁复杂、高频发生的agent信息流是AI原生组织的常态，每条agent信息流去了哪、什么时候、出了什么问题——全有日志和监控。这一层背后是 CloudWatch、Prometheus、Grafana、ELK 等可观测性栈，以及 SOC 2 / ISO 27001 等审计要求。
内容审查。
在网关之上叠加一层 LLM，专门审查 prompt 和返回内容，识别敏感字段、可疑意图、潜在数据外带。这一层是"用模型审模型"，是 AI 时代内容安全的核心，也是成本最高的一层。
参考 AWS、Azure、阿里云的官方参考架构，企业级AI网关服务的架构思路已然清晰。
AWS 的 Multi-Provider GenAI Gateway 参考架构以 LiteLLM Proxy 为核心，外面套 Amazon API Gateway 做认证限流，后面接 DynamoDB 做 token 缓存，CloudWatch 做可观测性，IAM 做细粒度访问控制。Azure 的 AI Foundry Gateway 背靠 API Management，提供限流、缓存、token 管理、负载均衡、可观测性。阿里云有 AI 网关加开源的 Higress。
这三家云厂商的企业级AI基建架构组件清单内容几乎一致，把他们作为行业标杆可以窥见一个企业级AI落地需要的架构考量。
从客户端到 LLM 端点，token流量要经过如下层级：
客户端是多种来源——IDE 插件、Coding Agent、普通客户端——但都要汇聚到同一道网关。网关内部从入口到端点，五层依次串接，每一层都对应企业内部一段基建账：身份基建、计费系统、流量调度、存储、可观测性栈、供应商管理。搭一个网关的过程，就是把这些基建挨个补一遍的过程。
失控的成本曲线与标杆案例
企业 AI 落地有一条几乎所有人都重走的曲线。
曲线的前半段往往是温情脉脉的：AI 编程工具刚铺开，员工试一试，每天几百万 token，账单看起来友好。之后的某个时间节点，部分员工发现 agent loop 框架可以跑定时自动化任务，曲线开始指数化飙升。
agent loop 干的事情很简单——让 AI agent 反复执行某个任务直到完成。但"反复"两个字在人那里是几十次，在 agent 那里是几千次几万次。每一次循环都在烧 token，每一次烧的都是公司的钱。
Uber 是这条失控曲线的典型样本——因按量计费模式和任务复杂度上升，Uber 在 4 个月内即耗尽全年 AI 预算。马斯克把 AI 订阅费天花板推到了 300 美元/月——企业要么接受这个量级的支出，要么自己分流到便宜模型。
三星电子是另一类内容风险样本。
2023 年初引入 ChatGPT 不到 20 天，三星电子就发生了三起半导体机密外泄事件——员工把半导体设备测量数据、源代码、生产瑕疵信息直接输入 ChatGPT 寻求优化建议。三星紧急全面禁用 ChatGPT 和 Bard。三年后剧情反转——三星从"全面封杀"转为"All-in"，成为 OpenAI 最大企业客户之一。这条 U 型曲线本身是企业 AI 落地的一个完整剧本：仓促上马 → 撞墙 → 全面禁用 → 思考治理 → 建闸 → 放开使用。
Air Canada 是 AI 客服虚假承诺造成实际商业后果的标志案例。
客服机器人给乘客虚假承诺，公司被告上法庭。媒体系统梳理的 54 起 AI 失控事件核心结论：如果企业自身数据没有打通、缺乏清晰流程，盲目引入 Agent 只会将"混乱"自动化；由于缺乏可靠的输出验证机制，大多数企业最终只能无奈退回原点，重新依赖人工。
国内头部金融机构则更像是是这条曲线的"成年期"样本。
招商银行 2025 年大模型日均 token 调用 260 亿，同比增长 10.1 倍；自研"研发智能体 DevAgent"基于多轮交互模式；通过"云+AI+中台"科技底座建立完整大模型技术能力体系，跨境金融业务流程压缩至原来的 1/3。工商银行 金融科技投入 285 亿元，业务领域落地 500+ AI 应用，风险模型超 100 个。
JPMorgan Chase 是把原本可能失控的成本曲线走成利润的标杆。
自研的 LLM Suite 不是单一模型，而是多模型门户——首发集成 OpenAI，后续接入多家第三方供应商。规模上覆盖 450+ 个 GenAI 用例，2026 年目标扩展到 1000+；用例涵盖欺诈检测、信贷建模、交易研究、客户个性化、后台自动化、软件开发（工程团队效率提升 10-20%）、财富顾问生产力等。ROI 上，AI 年化业务价值 15 亿美元，年化 ROI 增长 30-40%，节省人工小时数 360,000+。LLM Suite 用户规模 200,000+，约半数为高频用户。
JPMC 的关键不是接了多强的模型——它接的是 OpenAI 和第三方模型，跟好多公司一样——而是把治理放在了第一位。LLM Suite 的治理结构包括：AI 治理委员会（处理算法偏见、网络安全、数据安全）、董事会风险委员会（审批主要风险政策，审查 AI/模型风险框架）、模型风险管理团队（专门负责 AI 系统的模型风险）、AI 合规职能（作为第三方/SaaS 和托管 AI 平台的独立挑战者）、数据出口控制（禁止公共生成式 AI 工具，所有访问通过受控 LLM Suite 门户）。LLM Suite 获得 American Banker 2025 年度"创新奖"。
同一条曲线，结局完全不同。
大型企业之间的AI成本差距不在曲线本身，在曲线之外——企业有没有网关、有没有配额、有没有模型适配策略、有没有内容审查、有没有治理委员会。
开源方案 vs 商业产品
网关这道流量管控设施，立的方式有两种：自己搭，或者买现成。
听上去是个二选一的选择题，实际是个伪装成选择题的算账题——算的是钱、时间、坑、人四样东西。
主流开源 AI 网关对比
网关方案 模型支持 核心优势 部署方式 适用场景
LiteLLM 100+ 模型 Python 生态、SDK 强、故障转移 Docker / pip 开发者团队、快速接入
Portkey 200+ 模型 企业特性、可观测性、缓存 Docker + license key 中大型企业、需数据本地化
OneAPI 25+ 供应商 中文社区活跃、管理界面完善 Docker 私有化 国内团队、中小型企业
New API OneAPI 超集 多模态（MJ/Suno/TTS）、灵活计费 Docker 私有化 需要多模态 + 计费体系
APIPark 多模型 Apache 2.0 免费商用、API 开发平台 Docker / K8s 需 API 全生命周期管理
Sub2API Claude / Codex / Gemini CLI 订阅 订阅资源转 API、池化共享 Docker / 自托管 团队共享订阅、合规边缘场景
国内企业自建的网关解决方案中，OneAPI 与 LiteLLM 加起来占开源大模型聚合网关 82% 的部署份额，基本成为了行业 事实标准。
OneAPI 在 GitHub 上有 35K+ Star、6.7K Fork，用 Go 语言写成，单文件即可运行。New API 是 OneAPI 的超集，补充了 Midjourney、Suno、Rerank、TTS 等多模态和灵活计费。
Sub2API 走的是另一条路——聚合对象不是 API 供应商而是订阅资源（Claude Pro、Codex、Gemini CLI），合规上有边缘风险，但成本上对小团队极有吸引力。
中小公司常在多个中转站注册账号，催生了多站点聚合方案：MetAPI 把分散的 New API / One API / Sub2API 站点汇聚成一个 API Key、一个入口，通过自动发现模型、智能路由、实现成本最优解的目标。
Portkey 的部署模式比较特别——Docker 镜像本地运行加 license key 解锁企业特性，兼顾"数据不出机房"和企业级支持。
在AI网关的商业版产品方面，也有很多选择。
国内有深信服、阿里云 AI 网关、腾讯云 AI 网关、华为云；国外主流商业 AI 网关包括 Kong AI Gateway、Solo.io Gloo、Traefik Hub、Cloudflare；以及云厂商方案 AWS Multi-Provider GenAI Gateway 与 Azure AI Foundry Gateway。
商业产品的好处是内容审查、意图分析、SLA、技术支持都有；坏处是贵，而且通常和厂商自家云服务绑定，迁移成本高。
开源方案的"隐形深坑"在于：可观测性、安全性、企业级治理（如智能模型适配、内容审查）需要大量自建——这是商业产品的生存空间。
决策的关键不是"哪个更好"，是公司规模和工程能力。
30 人以下的团队，搭开源就够用，先把流量出口收口；100-500 人的中型公司，搭加局部买——网关用开源，内容审查模块买商业产品，这是性价比最高的组合；500 人以上的大公司，买——除非有 JPMC 那样的工程能力自建 LLM Suite，否则商业产品的总成本更低，因为治理、合规、SLA 的隐性成本很高。
中小企业的CIO, CTO们可以根据自身条件综合选择网关方案。
AI网关的选型决策也不是一次性的，随着组织增长可以有自己的发展路径。
30 人时搭开源，跑通；100 人时补一个商业内容审查模块；500 人时整体迁到商业产品。这条路径——开源起步、商业接力——是大部分公司的真实路径。
阿里云的 Higress 从开源走到商业，AWS 的参考架构核心也是开源 LiteLLM——开源和商业不是对立的两条路，是同一条路上的不同阶段。
安全：90% 防御与三道网关
企业 AI 落地的安全风险，90% 可以用两件事挡住——
建立公司内部 AI 网关；
做好出方向防火墙白名单
出方向防火墙白名单管的是网络层——公司内网到外网的连接，必须有白名单，不在白名单上的域名、IP、端口，一律拒绝。员工想用某个淘宝中转站，根本连不上——因为那个中转站的域名不在白名单里。两道防御一里一外，企业内的AI野连接基本可以被堵死，这就消解了可能90%的潜在风险。
剩下 10% 才是真问题——内容层的问题。
举一个具体场景的例子：员工合规地通过公司网关调用 GPT-5，输入了一段 prompt，里面带了客户数据库的字段名。GPT-5 的回答没问题，但 prompt 本身已经把客户字段名泄露给了模型供应商。或者员工给 AI agent 写了一段 prompt，让它定期抓取公司销售数据，分析后发到外部邮箱。从流量上看都是合规调用，但意图是数据外带。
传统杀毒软件的范式在这里失效。杀毒靠特征库——已知病毒的哈希、已知钓鱼的 URL、已知木马的签名。AI agent 时代的内容意图是上下文相关的——同一段 prompt，在这个上下文里是正常工作，在另一个上下文里是数据外带。意图没有固定特征。
要挡住这 10%，需要在网关之上叠加一层内容审查——再跑一个 LLM 来审 prompt 和返回内容。
这一层也有行业解决方案。
拿英伟达作为标杆来讲的话，软件层有 NeMo Guardrails 未代表的开源组件——它本身是 Python 库而非网关，需要与商业 AI 网关（Solo.io Gloo、Traefik Hub、Kong 等）集成后部署在企业流量出口；硬件层英伟达的 BlueField DPU 也提供 GPU peer-to-peer DMA 通道，能让审查模型审每个 HTTP 请求而 host CPU 不参与。
这套解决方案本质都是在网关路径上再部署一个 LLM 专门做内容审核——它能识别 prompt 里的敏感字段、可疑意图、潜在数据外带。
只是内容审查这一层并不便宜。
模型审模型意味着每次调用都要再跑一次推理——多消耗 token、多消耗 GPU。简单任务用小模型审（成本低但能力弱），复杂任务用大模型审（能力强但成本高）。如果选大模型审，企业 AI 的 token 成本可能要翻 1.5-2 倍。这是一笔反向成本——企业想挡住失控，挡的本身也在烧钱。
JPMC、Goldman Sachs 这类受监管企业，AI 投入里"治理"是独立预算。JPMC 在它近 170 亿美元的年技术预算里给"内容治理"留了一块独立位置。
更前瞻的视角是"三道网关"框架。
LinkedIn 上的高频被引文章《AI Security Requires Three Gateways》论点：AI 安全面需要三层网关——LLM 路由网关（流量层）、MCP（Model Context Protocol）网关（基础设施面）、数据/工具访问网关。多数企业只建了 1-2 层，留下重大安全空洞。
为什么是三层而不是两层？
因为 Agent 调工具是"动作"，工具访问数据是"后果"。两层网关能管动作，但管不住后果。举一个具体场景：一个 AI Agent 调用"发邮件"工具，第二层 MCP 网关能管这个调用是不是合规；但邮件里附带了客户数据库的导出——这件事第三层（数据/应用网关）才能发现。
所以完整的网关至少包括四层：
流量层（账号、对账、连接池、配额、限流，挡住粗放式失控）
网络层（出方向防火墙白名单，挡住绕开网关的私接）
内容层（用模型审模型，挡住合规流量里的不当内容）
审计层（日志、监控、追溯，让每一次调用都能回溯到人）
四层都立住，这 90% + 10%企业AI落地所需要解决的风控要求才算完整。
前瞻：MCP 网关与 CIO 的控制面
MCP（Model Context Protocol，模型上下文协议）是 Anthropic 在 2024 年末推出的开放标准，让 AI Agent / 客户端能标准化连接到外部数据源、工具、知识库。
以前 Agent 调一个 CRM、ERP、数据库，要写专门的适配——每接一个系统都是 N×N 的麻烦。MCP 把这件事标准化了：所有工具都按 MCP 协议暴露能力，Agent 按同一套协议调用，N×N 的问题变成 N+M。
但 MCP 普及之后，新的问题来了：谁来管 Agent 调了哪些工具、传了什么数据、有没有越权？
这就需要 MCP 网关。
业界共识是 MCP 网关正在成为独立的一层，位于 AI Agent 与 MCP Server 之间，核心定位是 Agentic AI 架构中的安全、治理、可观测性控制面。
它解决三个核心难题：可观测性（Agent 调了哪些工具、传了什么数据）、访问控制（哪个 Agent 能调哪个工具）、安全（防止工具被滥用、数据被外泄）。
Anthropic 自己内部已实现大规模 MCP Gateway 来管 LLM 集成基础设施——工程师 Karan Sampath 的演讲《Gateways are All You Need》是这一方向的代表论述。Gartner 报告显示 2025 年已部署 16,000+ 个 MCP Server，预测 2026 年 75% 的 API 网关厂商将具备 MCP 功能。7 家主流 MCP Gateway 厂商已经登场（Lunar.dev、MintMCP 等）。
CIO 视角下，整套体系对应的是"AI 控制面"（Control Plane）的概念。一个完整的治理层，从账号、对账、配额，到模型适配、内容审查、审计追溯，再到 Agent 工具治理、数据访问控制。企业 AI 风险的"控制面"正在从传统的"边界安全"（防火墙、堡垒机、DMZ、VPN）转向"流量治理"。
传统 IT 安全守了 30 年的边界，AI 把它绕开了。AI 流量不是"进出边界"，是"内网里跑的智能"——员工在内网里调 GPT-5，AI agent 在内网里访问 CRM——这些流量根本不经过传统边界。守边界守不住 AI，新的防线叫控制面。CIO 的角色从"看门人"变成"调度员"，网关是他的指挥台。
结论：先建闸，再放水
回到本文开头的判断：企业 AI 落地的第一笔钱，不应该花在买卡、买模型上，应该花在AI网关门口这道流量管控设施上。
AI网关不是一个产品，是一份企业 AI 内部基建清单的索引。从账号体系到对账系统，从连接池到模型适配，从可观测性到内容审查——搭一个网关的过程，就是把企业 AI 内部基建补一遍的过程。
最终总结一下今天的主题——企业的AI应用基建要如何打造。
对企业AI基建的决策者来说，具体的行动建议是：
第一，先识别企业当前在失控曲线上的位置。如果还在"鼓励用"阶段，紧急立网关；如果已经撞墙（成本失控或泄密事件），不要走全面禁用的老路，直接进入治理建设。
第二，按规模选方案。30 人以下搭开源，100-500 人搭加局部买，500 人以上买商业产品或自建。死守开源或死守商业都是教条。
第三，留出"治理"独立预算。开源方案能跑通基础流量，但内容审查、模型适配、可观测性这些企业级功能要花钱。受监管行业（金融、医疗、法律）尤其要把治理预算单列。
第四，把 CIO 的角色从"守边界"切到"管流量"。这是 30 年来企业 IT 范式最大的一次迁移。守边界是静态思维，管流量是动态思维——流量在变、模型在变、Agent 在变、风险在变。
第五，提前规划三道网关。LLM 网关（流量层）、MCP 网关（工具层）、数据/应用网关（资源层）。多数企业只立了第一层，AI Agent 时代要求三层都立。
企业 AI 落地的第一关，不仅是技术问题，也是组织问题。而AI网关正是AI组织重设计的物理载体。
参考来源
BCG – AI Transformation Is a Workforce Transformation（10-20-70 法则一手来源）: https://www.bcg.com/publications/2023/ai-transformation-is-a-workforce-transformation
McKinsey State of AI 2025: https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
Menlo Ventures 2025 企业 GenAI 报告（基建层 180 亿美元）: https://menlovc.com/perspective/2025-the-state-of-generative-ai-in-the-enterprise/
LLM Gateway Architecture: 2026 Engineering Reference: https://www.digitalapplied.com/blog/llm-gateway-architecture-2026-engineering-reference
Enterprise Reference Architecture for AI Applications at Scale: https://www.opsatscale.com/opsatscale-framework/enterprise-reference-architecture/
JPMC LLM Suite（HBS 案例）: https://www.hbs.edu/faculty/Pages/item.aspx?num=67230
Microsoft Azure AI Foundry Gateway（Microsoft Learn）: https://learn.microsoft.com/en-us/ai/playbook/solutions/genai-gateway/
Google Gemini Enterprise（Google Cloud）: https://cloud.google.com/gemini-enterprise
三星从封杀到 All-in（钛媒体）: https://www.tmtpost.com/agent/ai-article/18470
Uber 4 个月烧光全年 AI 预算（财联社）: https://www.cls.cn/detail/2081970
Air Canada AI 客服虚假承诺 / 54 起 AI 失控事件（腾讯新闻）: https://view.inews.qq.com/a/20260622A06DL200
证券时报：金融机构 AI 应用向深向实: https://stcn.com/article/detail/3733862.html
沙丘智库：22 家银行大模型应用实战: https://www.shaqiu.cn/article/yRoBL7xgVObE
深圳金融创新大赛：招行全栈自研大模型: https://jr.sz.gov.cn/sjrb/xxgk/gzdt/content/post_12637909.html
新华网：银行大模型应用"加速跑": http://www.news.cn/tech/20250910/a5091cbc53b94f7da05bd9dcbabbb710/c.html
阿里云 AI 网关（官方文档）: https://help.aliyun.com/zh/api-gateway/ai-gateway/
Higress 开源 AI 网关: https://higress.ai/blog/higress-gvr7dxawbbpbkeeoubp57qezvb1k/
腾讯云 AI 网关（官方文档）: https://intl.cloud.tencent.com/zh/document/product/1290/79460
国内三大厂 AI 战略对照（澎湃新闻）: https://m.thepaper.cn/newsDetailforward33474412
国内商业 AI 网关产品（深信服、英伟达中国企业版）：作者与客户讨论纪要（2026-06-30）
NVIDIA NeMo Guardrails（开源内容审查组件）: https://github.com/NVIDIA/nemo-guardrails
NVIDIA BlueField DPU（硬件层审查加速）: https://www.nvidia.com/en-us/networking/products/data-processing-unit/
企业级 LLM Gateway 选型 2026（Ofox.ai）: https://ofox.ai/zh/blog/enterprise-llm-gateway-litellm-portkey-helicone-ofox-comparison-2026/
开源 AI 网关选型实测：OneAPI 与 LiteLLM 核心差异（Starverse AI）: https://www.starverse-ai.com/guide/archives/7407
AI 网关对决：Higress 与 OneAPI 的功能对比（CSDN）: https://blog.csdn.net/cr7258/article/details/145621773
大模型网关 New API 详解（Quant67）: https://quant67.com/post/llm-infra/22-llm-gateway/22-llm-gateway.html
LiteLLM 统一大模型访问的开源网关（51CTO）: https://www.51cto.com/article/816676.html
one-api / new-api / Sub2API 对比（知乎）: https://zhuanlan.zhihu.com/p/2036783704245326926
Sub2API 自建教程（codepick.dev）: https://codepick.dev/zh/guides/sub2api-self-hosted-ai-relay/
GitHub: cita-777/metapi: https://github.com/cita-777/metapi
AWS Multi-Provider GenAI Gateway（AWS 官方文档）: https://docs.aws.amazon.com/solutions/multi-provider-generative-ai-gateway-on-aws/
LLM Gateway 标准定义（Axiom Studio）: https://axiomstudio.ai/learn/what-is-an-llm-gateway
AI 安全是三道网关（LinkedIn）: https://www.linkedin.com/pulse/ai-security-requires-three-gateways-most-enterprises-have-sinha-gxlte
LLM Gateways for Enterprise Risk（Medium）: https://medium.com/@adnanmasood/llm-gateways-for-enterprise-risk-building-an-ai-control-plane-e7bed1fdcd9c
Anthropic 实施 MCP Gateway（ZenML）: https://www.zenml.io/llmops-database/implementing-mcp-gateway-for-large-scale-llm-integration-infrastructure
Gateways are All You Need — Karan Sampath, Anthropic（YouTube）: https://www.youtube.com/watch?v=CD6R4Wf3jnY
Enterprise MCP Gateway: Key Considerations（Tyk）: https://tyk.io/learning-center/enterprise-mcp-gateway-key-considerations/
TrueFoundry: MCP Gateway Revolution (Gartner 2025): https://www.truefoundry.com/blog/truefoundry-and-the-mcp-gateway-revolution-insights-from-gartners-2025-report
Architecting Secure Enterprise AI Agents with MCP / IBM（AIGL Blog）: https://www.aigl.blog/architecting-secure-enterprise-ai-agents-with-mcp-ibm-oct-2025/
Enterprise-Grade Security for MCP（arXiv）: https://arxiv.org/pdf/2504.08623
AI 原生应用架构白皮书（SmartCity）: https://www.smartcity.team/cases/llms_cases/
