做 AI 应用开发的人现在面临的局面很微妙：模型越来越多，每个都要对接，每个的 API 格式、计费方式、限流策略都不一样。项目中同时接了三四个大模型 API，光管理这些接入就够写一个模块了。
Google Cloud 最新的一篇文章讲的是 Apigee AI Gateway——用 API 网关统一管理大模型流量。说实话，这个思路不新，但 Google Cloud 的实现方式有点意思。
多模型管理的痛苦
先说说为什么需要这个东西。
一个典型的企业 AI 应用，背后可能接了好几个模型：ChatGPT 做对话、Claude 做代码分析、Gemini 做多模态理解、外加一个自部署的开源模型做敏感数据处理。每个模型都有自己的 API endpoint、认证方式、速率限制。
以前的做法是什么？要么在应用代码里写一个 Router，根据请求类型动态选择模型。要么在每个模型前面加一个薄代理层。
翻了下原文，发现了一个有意思的细节：Google Cloud 观察到，很多企业实际上花在"对接模型"上的时间比"用模型解决问题"的时间还多。
怎么说呢，模型本身已经不是瓶颈了，管理模型的成本才是。
Apigee AI Gateway 的做法
Apigee AI Gateway 的核心思路是把 AI 模型当成 API 来治理。什么意思呢？就是通过一个统一的网关入口，让所有模型请求走同一个通道，然后在这个通道上做鉴权、限流、监控、计费。
具体的实现方式是这样的：
你在 Apigee 上配置一个 AI Gateway 代理，指定后端模型（可以是 Gemini、Claude、GPT，也可以是私有部署的模型）。客户端只需要调用这一个地址，Apigee 负责把请求转发到正确的模型，并把响应返回。
Gateway 层面可以做几件事：
一个是统一鉴权 。不用在每个模型各自管理 API Key 了，Gateway 层面统一做身份认证和授权。用户调用 Gateway 的 API Key，Gateway 自动映射到后端模型的凭证。
一个是速率控制 。不同模型的价格差很多——Claude Opus 和 Gemini Flash 的价格能差十倍。Gateway 可以根据用户角色或应用类型，设置不同的调用频率和预算上限。
一个是统一监控和审计 。所有模型的调用记录都在 Gateway 层面统一收集，包括响应时间、Token 消耗、错误率。做成本分析和性能调优的时候，不用去各个模型的后台分别查。
真正麻烦的是治理
API 网关做统一的请求入口，这件事本身不新鲜。真正的问题在后面。
大模型 API 和传统 API 有个本质区别：传统 API 的入参是结构化的，请求什么就返回什么。大模型 API 的入参是自然语言，同一个 prompt 给不同模型，返回的内容可能完全不一样。怎么做治理？
Apigee 的方案是通过 Model Armor——一个专门给 LLM API 做的安全层。它可以在 Gateway 层面检测 prompt injection、检查输出是否符合规范、阻止敏感数据泄露。这些检查是在请求到达模型之前和响应返回客户端之前完成的。
这里容易被忽略的是，Model Armor 本身也是一个 AI 模型在做检测——一个 AI 保护另一个 AI。在这种架构下，每次调用实际走了两遍推理：一遍是 Model Armor 检测，一遍是目标模型推理。延迟会不会受影响？
从文档看，Model Armor 用的是轻量级模型，检测延迟在几十毫秒级别。对大多数对话场景影响不大，但对实时性要求高的场景（比如语音对话），这个额外延迟可能是不能接受的。
MCP 的集成
还有一个值得注意的点：Apigee 最近正式支持了 MCP（Model Context Protocol）。
MCP 是由 Anthropic 提出的开放协议，目的是让 AI agent 发现和调用外部工具时有统一的接口。Apigee 现在原生支持把 API 发布为 MCP 工具，agent 可以直接通过 MCP 协议发现和调用 Gateway 管理的 API。
这个组合很有意思。API 网关做治理和安全，MCP 做工具发现和调用。以前 agent 要调用企业内部 API，要么写死 endpoint，要么搞一套自定义的服务发现。现在通过 MCP registry，agent 可以动态发现可用的 API，而不用知道 API 的具体地址——调用入口统一走 Apigee，治理和安全都在 Gateway 层完成。
对开发者的影响
对个人开发者来说，Apigee AI Gateway 太重了。一套 API 网关的维护成本远高于直接写几行代码调用模型 API。但对企业团队，这东西可以省掉不少维护成本。
主要省的地方：
一个是不需要自己写模型路由 。Gateway 已经内置了模型选择、fallback、负载均衡的逻辑。加一个新模型，改一下配置就行，不用改代码。
一个是成本控制 。在 Gateway 层面可以设置预算上限和告警。某个团队这个月模型调用费用异常增长，第一时间就能发现。以前是等账单出来了才后悔。
一个是合规 。数据不会直接送到模型厂商的服务器——Gateway 层面可以配置数据脱敏、审计日志、访问控制。对金融、医疗这些行业来说，这是硬需求。
几个边界问题
但事情没有这么简单。看完文档，有几个点还没搞清楚。一个是 Gateway 本身的高可用怎么做——如果 Gateway 挂了，所有模型调用都断了，这比某个模型不可用要严重得多。另一个是 Gateway 对不同模型的原生特性支持——Claude 的 thinking token、Gemini 的多模态输入，这些特性在 Gateway 层能不能透传？
从目前的信息看，Google Cloud 在这个方向的投入是认真的。统一 API 治理的思路对中大型团队的价值很明显——但能不能解决上述边界问题，决定了它到底是个实用工具还是个控制台上的展示品。
关于维基框架
维基框架关注企业应用开发中的长期维护问题。在实际项目中，业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素，因此我们希望提供一套更容易扩展和维护的基础框架。
官网：framewiki.com
Gitee：gitee.com/wiki-framework
GitHub：github.com/wiki-framework
示例项目：gitee.com/cdkjframework/framewiki-example
📄 许可证：MulanPSL-2.0（木兰宽松许可证，第2版）
