企业官网建设流程全解析

当我们在说"AI 网关"的时候，到底在说什么？本文从架构设计的角度，拆解一次大模型调用背后的完整链路。

前言

最近在技术社区看到不少关于"AI 网关"的讨论。有人觉得它就是个 API 转发代理，有人觉得它是套了壳的 NewAPI。说实话，我一开始也是这么想的。

直到认真研究了几款企业级 AI 网关产品的架构设计，才发现事情没那么简单。一个真正的企业级 AI 网关，远不止"转发请求"这么简单——它要处理协议适配、路由调度、身份鉴权、配额管控、安全过滤、成本核算、日志审计……每一个环节都有设计上的考量。

这篇文章我以魔芋 MAI Gateway 为例，拆解它的四层架构设计。它的架构文档比较完整，适合做分析样本。文中的架构思路对于理解同类产品同样适用。

MaiGateway-企业级大模型API网关|多模型统一调度与AI流量治理平台MaiGateway企业级LLM API网关，统一兼容国内外大模型，提供智能路由、密钥管控、限流熔断、Token计费、数据脱敏、全链路审计，私有化部署，解决企业多模型接入混乱、成本失控、数据安全合规难题。https://mai.moyu.cn

一、先说清楚：AI 网关不是什么

在拆架构之前，先排除几个常见误解：

误解 1：AI 网关 = API 代理

API 代理只做请求转发，不关心请求内容。AI 网关需要理解请求的结构（模型、Token、消息体），并根据内容做路由决策、成本计算和安全检查。

误解 2：AI 网关 = 聚合网关

市面上有不少开源聚合网关（如 NewAPI、OneAPI），它们的核心能力是"把多个模型供应商的接口聚合到一个入口"。这在个人开发者场景下够用，但企业场景还需要组织架构同步、项目隔离、预算管控、安全合规等能力，这些聚合网关基本不具备。

误解 3：AI 网关 = MLOps 平台

MLOps 平台管的是模型训练、部署、版本管理和推理调度。AI 网关不管模型训练，它管的是"模型已经部署好之后，企业内部如何安全、可控、可核算地调用这些模型"。

搞清楚边界后，我们来看架构。

二、四层架构总览

MAI Gateway 的架构从上到下分为四层：

┌─────────────────────────────────────────────┐

│ 应用层 (Application) │

│ 智能体 / AI编程 / 知识库 / 客服 / 内容生成 │

├─────────────────────────────────────────────┤

│ 分发与管理层 (Management) │

│ 组织 / 角色 / 项目 / 令牌 / 配额 / 预算 │

├─────────────────────────────────────────────┤

│ 智能调度层 (Scheduling) │

│ 协议转换 / 路由选择 / 负载分配 / 限流 / 缓存 │

├─────────────────────────────────────────────┤

│ 模型与算力接入层 (Integration) │

│ 公共API / 私有模型 / 云端算力 / 本地GPU │

└─────────────────────────────────────────────┘

三、应用层：统一的调用入口

应用层是离业务最近的。包括智能体平台、AI 编程工具、知识库与 RAG 系统、智能客服、办公助手、内容生成工具等。

这些应用通过统一接口向网关发请求，携带包括受控令牌和模型标识等重要信息。

设计要点：接口兼容性

MAI Gateway 对外暴露的接口兼容 OpenAI 协议。这是一个很务实的选择——市面上绝大多数 AI 应用和 SDK 都支持 OpenAI 接口规范，兼容它意味着应用侧的改造成本极低，通常只需要替换 Base URL 和 API Key。

但这里有个细节值得注意：兼容 OpenAI 协议不等于只支持 OpenAI 协议。对于供应商专有参数（如某些多模态接口、文件上传接口），网关需要做协议适配和参数映射。

四、分发与管理层：治理的核心

这一层是我认为企业级 AI 网关和普通聚合网关差距最大的地方。它管的是"谁能用什么模型、花多少钱、归到哪个项目"。

4.1 组织与角色

MAI Gateway 支持与钉钉、飞书、企业微信、AD 等组织目录对接，同步部门和人员信息。这意味着不需要在网关里手动建组织架构，企业已有的组织体系可以直接复用。

角色体系分为多级：

超级管理员

├── 部门/项目管理员

│ ├── 运维人员

│ ├── 财务审计人员

│ ├── 安全人员

│ └── 普通用户

每个角色的权限边界清晰：

• 超级管理员：平台初始化、全局策略配置
• 部门/项目管理员：成员管理、模型范围分配、预算设定
• 运维人员：链路监控、告警处理、容量查看
• 财务审计人员：账单查看、费用归集、日志审计
• 普通用户：在授权范围内使用模型、创建个人令牌

设计要点：项目作为管理单元

这里有个设计思路值得说说。MAI Gateway 把"项目"作为连接业务和资源的核心单元。一个项目可以绑定负责人、成员、可用模型、令牌、配额、预算和报表。

这样做的好处是：所有模型调用都能归属到具体的业务场景。不再是"某个人用了某个模型"，而是"某个项目的某个业务场景用了某个模型，花了多少钱"。这对于成本归因非常重要。

4.2 令牌全生命周期管理

令牌是企业应用访问网关的凭证。MAI Gateway 对令牌的管理覆盖了完整生命周期：

创建 → 绑定（关联责任人/部门/项目）→ 授权（设置模型范围、有效期、IP白名单）

→ 使用 → 轮换 → 撤销/失效

几个关键设计：

• 令牌与供应商 Key 解耦：应用侧拿到的是网关令牌，不是供应商的 API Key。供应商 Key 只在网关后台保管，应用侧永远接触不到。
• 可设置有效期和模型范围：某个令牌只能调用指定模型，过期自动失效。
• 支持 IP 黑白名单：即使令牌泄露，非授信 IP 也无法调用。
• 强制轮换：定期轮换缩短密钥泄露的风险窗口。
• 操作记录入审计日志：令牌的创建、变更、撤销全过程可追溯。

这个设计解决了一个实际问题：以前 API Key 散落在代码和配置里，人员离职或项目结束后 Key 还在用，没人管。现在令牌绑定了责任人和项目，人员离职时直接撤销相关令牌就行。

4.3 配额与流量控制

配额可以按企业、组织、部门、项目、用户、令牌或模型设置，周期可按日/周/月计算，控制指标包括金额、Token 数量、请求频率（RPM）和并发数。

配额层级：

企业总额 → 部门配额 → 项目配额 → 用户/令牌配额 → 模型配额

接近阈值时触发告警，超限后按规则执行限速、阻断或模型降级。

设计要点：针对智能体的流控

自动化智能体是 Token 消耗的"重灾区"。一个有 Bug 的 Agent 可能陷入循环调用，短时间内消耗大量 Token。MAI Gateway 支持为智能体单独配置 RPM、TPM 和最大费用，一旦触发熔断，毫秒级切断调用。

这个能力在实际使用中非常关键。没有它，一个 Agent 的 Bug 可能在一夜之间烧掉几万块的 Token 费用。

五、智能调度层

这一层处理协议转换、路由选择、负载分配、限流、缓存和故障切换。

5.1 路由策略

MAI Gateway 支持多种路由模式：

智能路由是最有意思的一个。它的思路是：不是所有请求都需要最贵的模型。简单的 FAQ 问答用低成本模型就够了，复杂推理才需要高端模型。网关根据请求内容判断复杂度，自动路由到合适的模型。

5.2 故障转移

网关定期检查各模型链路的健康状态。检测指标包括延迟、错误率和可用性：

健康检查流程：

定期探测 → 连续报错? → 临时下线该链路 → 流量切到备用链路

↓

原链路恢复? → 重新加入路由

关键设计点：故障切换对应用侧透明。应用侧看到的是一个稳定的接口地址，底层切了哪个供应商它不需要知道。

5.3 缓存与上下文优化

网关支持语义缓存——对于重复或高度相似的请求，直接从缓存返回结果，不再调用上游模型。这能显著减少 Token 消耗。

上下文压缩也是一个降本手段。对于长上下文请求，在不影响语义的前提下压缩 prompt，减少输入 Token 数。

注意：缓存和上下文压缩都有适用边界。对实时性要求高、上下文经常变化的场景，缓存可能不适用。上下文压缩可能在极端情况下影响模型理解。是否启用需要结合业务场景判断。

六、模型与算力接入层：连接一切

最底层负责连接各种模型来源：

• 公共大模型 API：OpenAI、Anthropic、通义千问、MiniMax 等
• 企业私有模型：自建的 DeepSeek、Qwen 等
• 云端算力：云上的 GPU 推理服务
• 本地 GPU：企业自有的 GPU 服务器

网关为每个模型记录供应商、模型名称、接口协议、计费单价、启用状态和可用范围。这些数据是路由决策、费用核算和权限判断的基础。

设计要点：混合部署的路由

在混合部署场景下，普通任务可以调用公共模型（按 Token 计费），涉及敏感数据的任务路由到本地私有模型（固定算力成本）。路由条件由企业根据数据类型、模型效果、成本和可用性设置。

这种设计让企业在"用公共模型省事"和"用本地模型保安全"之间找到平衡点。

七、一次请求的完整链路

把四层串起来，一次模型调用的完整链路是这样的：

1. 应用发送请求（携带网关令牌）

↓

2. 【分发与管理层】身份校验 → 令牌是否有效？模型是否在授权范围？

↓

3. 【分发与管理层】配额检查 → 预算是否超限？是否触发限流？

↓

4. 【智能调度层】安全处理 → 提示词注入检测？PII 脱敏？内容过滤？

↓

5. 【智能调度层】路由选择 → 根据策略选择上游链路（权重/成本/智能）

↓

6. 【模型接入层】上游请求 → 协议转换，调用真实模型供应商

↓

7. 【智能调度层】结果处理 → 响应内容检测？缓存写入？

↓

8. 【分发与管理层】费用记录 → 计算 Token 消耗和费用，归属到项目

↓

9. 【分发与管理层】日志留存 → 记录请求链路、响应状态、耗时等

↓

10. 返回结果给应用

注意步骤 4 的安全处理——这是在请求到达模型供应商之前执行的。也就是说，敏感信息在离开企业内网之前就已经被脱敏了。这个位置很重要，如果放在模型返回之后再处理，数据已经出去了。

八、与通用聚合网关的对比

最后聊聊大家都关心的问题：企业级 AI 网关和开源聚合网关到底差在哪？

简单说：聚合网关解决的是"能不能用"的问题，企业级网关解决的是"用得好不好、管得住管不住、花得清不清楚"的问题。

如果你的场景是个人开发或小团队内部使用，聚合网关够用。如果是企业级场景，涉及多部门、多项目、预算管控和安全合规，那企业级网关的这些能力就不是"锦上添花"，而是"必需品"。

九、写在最后

拆完整个架构，我最大的感受是：企业级 AI 网关的本质，不是技术问题，而是治理问题。

转发请求不难，难的是在转发的过程中，把身份、权限、成本、安全、审计这些治理逻辑编织进去，而且不能影响性能和可用性。

MAI Gateway 的四层架构设计，本质上是在回答一个问题：当大模型成为企业的基础设施后，如何让它的使用像用水用电一样安全、可控、可计量。

这个问题不会只有一种答案，但理解现有的架构设计思路，有助于我们在选型和使用时做出更明智的判断。