1. 企业大模型网关到底解决什么问题

1.1 从一个真实的翻车现场说起

去年帮一家做 SaaS 的团队做架构评审，他们内部已经有 6 个业务线在调用大模型能力，结果我一看账单和日志，头皮发麻。市场部用 A 家的接口做文案生成，客服团队用 B 家的接口做意图识别，研发自己又搭了一套 C 家的调用封装，三套密钥散落在不同的配置文件里，有的甚至硬编码在前端。更离谱的是，某条业务线因为没做限流，一次批量任务把当月预算烧掉了四成，等到财务对账才发现。

这不是个例。任何一家把大模型真正用起来的公司，走到一定阶段都会撞上同一堵墙：调用入口太散、密钥管理失控、成本不可见、模型切换成本高、合规审计无从下手。企业大模型网关就是在这个背景下被推上台面的东西。

说白了，网关就是所有大模型调用的统一收口层。业务方不再直接对接 OpenAI、Anthropic 或者国内各家厂商的 API，而是统一打到网关，由网关负责鉴权、路由、限流、计费、日志、缓存、降级。它跟你熟悉的 API Gateway 在思路上是一脉相承的，只不过处理的是 token 流、模型路由和 prompt 治理这些新问题。

1.2 网关的核心能力清单

我把一个合格的企业级大模型网关应该具备的能力拆成下面几块，你可以拿这个清单去对照市面上的方案：

这张表里，统一接入和密钥托管是地基，路由调度和限流配额是省钱和保命的关键，可观测是后面一切优化的前提。很多团队一上来就想做智能路由、做语义缓存，结果连基础的日志都没打通，纯属空中楼阁。

1.3 为什么是现在，为什么必须做

有人会问，我业务量不大，直接调官方 API 不香吗？短期确实香，但你要想清楚两件事。

第一，模型迭代速度已经超过了业务代码的迭代速度。今天 GPT 系列性价比高，明天可能某个开源模型在特定任务上更划算，后天某家厂商降价一半。如果你的业务代码里到处是openai.ChatCompletion.create，每次换模型都是一次伤筋动骨的改造。网关把这层变化隔离掉了，业务方只认网关的虚拟模型名，背后换谁用户无感。

第二，成本必须被度量才能被优化。我见过太多团队，问他们一个月大模型花了多少钱，答不上来；问哪个功能最烧钱，也答不上来。网关的 token 统计和成本归因能力，是精细化运营的起点。没有度量，所有的降本都是拍脑袋。

所以我的判断是：只要你的公司有超过 2 个业务线在用大模型，或者月调用量超过百万 token，就该认真考虑网关这件事了。再晚，技术债会以你想象不到的速度累积。

2. 网关架构设计与技术选型拆解

2.1 整体分层架构

我推荐的分层是这样的，从上到下依次是接入层、治理层、适配层、上游层：

接入层负责协议转换和鉴权。对外统一暴露 OpenAI 兼容的/v1/chat/completions、/v1/embeddings这些端点，业务方用任何 OpenAI SDK 都能直接对接，迁移成本几乎为零。鉴权用网关自己签发的虚拟 key，格式可以设计成sk-gw-前缀，方便识别和审计。

治理层是网关的大脑，包含路由、限流、缓存、计费、审计这些模块。这一层是纯业务逻辑，跟具体哪家模型无关，所以可以做得非常通用。

适配层负责把统一的内部请求格式翻译成各家上游的格式。OpenAI 的格式基本成了事实标准，所以适配层主要是处理那些不完全兼容的厂商，比如某些厂商的 function calling 参数名不一样，或者流式返回的 chunk 结构有差异。

上游层就是各家模型服务，包括公有云 API、私有化部署的推理服务、以及自建的模型集群。

这个分层的好处是每一层可以独立演进。接入层要支持新的鉴权方式，不影响治理逻辑；治理层要加一个新的路由策略，不用动适配代码；上游要接一家新厂商，只写一个 adapter 就行。

2.2 技术栈选型：别一上来就上重型框架

选型这块我踩过坑，说点实在的。市面上有 Portkey、LiteLLM、One API 这些现成方案，也有团队选择自研。我的建议是分阶段：

第一阶段（验证期），直接用 LiteLLM 或者 One API 这类开源方案快速搭起来。它们已经覆盖了 100+ 模型的适配，OpenAI 兼容协议也做得不错，一周内就能跑通。这个阶段的目标是先让调用收口，别追求完美。

第二阶段（成长期），业务量上来了，开源方案开始不够用，比如你需要自定义的路由策略、需要对接内部计费系统、需要特殊的审计规则。这时候可以在开源方案外面包一层自己的治理服务，或者基于它的插件机制做扩展。

第三阶段（成熟期），如果调用量到了亿级 token/月，性能和安全要求都很高，可以考虑用 Go 或 Rust 重写核心链路。我见过用 Rust 写的网关，单机 QPS 能到几万，P99 延迟控制在个位数毫秒，这个量级用 Python 是很难达到的。

提示：不要为了技术先进性而自研。网关这东西，稳定性和生态适配比性能重要得多。开源方案能覆盖 80% 的需求，剩下 20% 再自己补，性价比最高。

2.3 路由策略的设计逻辑

路由是网关最有技术含量的部分，我把它拆成几个维度：

按成本路由：给每个模型维护一个每千 token 的价格表，请求进来时根据 prompt 长度和预期输出长度估算成本，优先选便宜的。这个策略适合对延迟不敏感、对成本敏感的批处理任务。

按延迟路由：维护每个上游的实时延迟指标（P50/P95），优先选快的。适合交互式场景，比如客服对话。

按能力路由：有些任务需要 function calling，有些需要长上下文，有些需要多模态。给模型打上能力标签，请求里声明需要的能力，路由到匹配的模型。

按可用性路由：实时监控各上游的健康状态，某个上游错误率超过阈值就自动摘除，流量切到备用。这是保命策略，必须有。

实际生产里通常是多策略加权。比如先按能力过滤出候选集，再在候选集里按成本和延迟加权打分，选最高分的。权重可以配置，不同业务线用不同的权重。

2.4 缓存策略：省钱的隐藏大招

大模型调用里，有相当比例的请求是重复或高度相似的。比如同一个 FAQ 被不同用户问了几十遍，或者系统 prompt 完全一样只是用户输入略有差异。

精确缓存最简单，把请求的 hash 作为 key，命中直接返回。适合完全相同的请求，命中率不高但实现简单。

语义缓存更高级，把 prompt 做 embedding，在向量库里找相似度超过阈值的缓存结果。这个能显著提升命中率，但要注意阈值调优，太低会返回不相关的答案，太高又命中不了。我一般从 0.95 开始试，根据业务反馈调整。

Prompt 前缀缓存是另一条路。很多厂商（比如 OpenAI）对相同前缀的请求有折扣，网关可以把系统 prompt 统一管理，确保前缀一致，享受这个折扣。这个不需要额外存储，纯配置就能省一笔。

3. 自动化编程与 Agent 的落地实践

3.1 Agent 到底是什么，跟传统脚本有什么区别

热词里 agent 出现频率极高，但很多人对它的理解还停留在"会调工具的 ChatGPT"。我用一句话说清楚：Agent 是一个能自主决定下一步做什么、并且能根据执行结果调整后续动作的程序。

传统脚本是你把步骤写死，A 完了 B，B 完了 C。Agent 是你给它一个目标，它自己规划步骤，执行一步看结果，再决定下一步。这个"看结果再决定"的循环，就是 Agent 的核心。

跟 Agent 容易混淆的是harness。Harness 是"脚手架"，指的是给模型提供工具、上下文、执行环境的这套框架。Agent 是跑在 harness 上的那个决策逻辑。打个比方，harness 是厨房和厨具，Agent 是厨师。同一个厨房，不同的厨师能做出不同的菜。

3.2 CLI 类 Agent 工具的使用要点

最近 codex cli、zcode cli 这类命令行 Agent 工具很火，它们的价值在于把 Agent 能力直接嵌进开发者的终端工作流。你不用切到网页，在终端里就能让 Agent 帮你改代码、跑测试、查文档。

以 codex cli 为例，安装通常是通过 npm：

npm install -g @openai/codex

装完之后配置 API key，一般是通过环境变量：

export OPENAI_API_KEY="sk-..."

然后就能在项目目录里直接唤起。常用的几个命令我列一下：

这里有个坑要提醒：安装时如果报missing optional dependency @openai/codex-win32-x64这类错误，通常是平台相关的二进制包没装上。解决办法是先卸载再重装，或者手动指定平台包。Windows 上尤其容易遇到，因为 npm 的可选依赖机制在某些网络环境下会静默失败。

注意：CLI Agent 会读取你当前目录的文件，也会执行命令。在敏感项目里用之前，务必确认它的权限边界，最好在独立的沙盒目录里跑。

3.3 用网关给 Agent 做统一出口

Agent 场景对网关的需求比普通调用更强烈，原因有三个：

第一，Agent 的调用量不可预测。一个复杂任务可能触发几十次模型调用，如果每个 Agent 实例都直连上游，很容易触发限流。网关可以做全局配额，把 Agent 的突发流量平滑掉。

第二，Agent 需要多模型协作。规划用强模型，执行用便宜模型，判断用快模型。网关的路由能力让 Agent 可以按角色请求不同的虚拟模型名，背后自动映射到最合适的实际模型。

第三，Agent 的成本必须可控。一个失控的 Agent 循环能在几分钟内烧掉几十美元。网关的限流和熔断能在检测到异常调用模式时自动切断，这是保命机制。

我一般的做法是给每个 Agent 项目分配一个独立的虚拟 key，设置日配额和单次会话的 token 上限。超过就拒绝，让 Agent 自己处理这个错误。这样即使 Agent 逻辑有 bug，损失也是可控的。

3.4 Agent 并发扛不住的排查思路

"AI Agent 怎么扛并发"是高频问题，我分享一套排查方法。

先看瓶颈在哪一层。模型调用层的瓶颈通常是上游的 rate limit，这个只能靠多 key 轮询或者多上游分流解决。Agent 逻辑层的瓶颈往往是同步阻塞，比如 Agent 在等一个工具返回时把整个线程占住了，这时候要改成异步。存储层的瓶颈常见于对话历史，每次都全量读写数据库，量一大就崩，要改成增量存储加缓存。

我实测下来，一个设计良好的 Agent 服务，单实例扛几百并发是没问题的，前提是模型调用必须异步、工具调用必须有超时、对话历史必须分页。这三点做到了，剩下的就是水平扩容的事。

4. 从零搭建的完整实操流程

4.1 环境准备与依赖安装

假设我们用 LiteLLM 作为网关底座，先搭一个最小可用版本。环境要求 Python 3.9 以上，建议用虚拟环境隔离：

python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate pip install 'litellm[proxy]'

装完之后，核心是一个配置文件config.yaml，定义模型列表和路由规则：

model_list: - model_name: gpt-4o litellm_params: model: openai/gpt-4o api_key: os.environ/OPENAI_API_KEY - model_name: gpt-4o-mini litellm_params: model: openai/gpt-4o-mini api_key: os.environ/OPENAI_API_KEY router_settings: routing_strategy: usage-based-routing num_retries: 3 timeout: 30

启动命令：

litellm --config config.yaml --port 4000

启动后，业务方就可以用 OpenAI SDK 打到http://localhost:4000，模型名填gpt-4o或gpt-4o-mini，网关会自动路由。

4.2 虚拟 Key 与配额配置

生产环境必须给每个业务方发独立的虚拟 key。在配置里加上：

general_settings: master_key: sk-master-xxx database_url: postgresql://... key_management: - key: sk-team-marketing models: [gpt-4o-mini] max_budget: 100 budget_duration: 30d rpm_limit: 500

这段配置的意思是：市场部只能用gpt-4o-mini，30 天预算 100 美元，每分钟最多 500 次请求。超了直接拒绝，不会影响其他团队。

提示：master_key是管理密钥，权限最大，绝对不能下发给业务方。业务方只拿sk-team-开头的虚拟 key。

4.3 接入自动化编程工具

把 CLI Agent 指向网关，只需要改环境变量：

export OPENAI_BASE_URL="http://gateway.internal:4000" export OPENAI_API_KEY="sk-team-dev"

这样 Agent 的所有调用都走网关，配额、日志、成本统计全部自动生效。我实测下来，codex cli 这类工具对 base_url 的支持都很好，改一个环境变量就行，不用改任何代码。

如果 Agent 需要多模型协作，可以在网关里定义几个虚拟模型名，比如planner、executor、judge，分别映射到不同的实际模型。Agent 代码里按角色请求对应的虚拟名，路由策略在网关侧统一管理，业务代码完全不用关心背后是谁。

4.4 可观测性配置

日志和指标是网关的眼睛。LiteLLM 支持把日志推到多种后端，我一般用 Postgres 存结构化日志，用 Prometheus 暴露指标：

litellm_settings: success_callback: ["postgres"] failure_callback: ["postgres"] cache: true cache_params: type: redis host: redis.internal port: 6379

关键指标要盯这几个：每模型的请求量、token 消耗、P95 延迟、错误率、缓存命中率。这几个指标一上监控大盘，很多问题会自己浮出来。比如某个模型的错误率突然飙升，多半是上游出问题了；缓存命中率突然下降，可能是 prompt 变了导致缓存失效。

5. 常见问题与排查技巧实录

5.1 高频问题速查表

5.2 几个我踩过的坑

坑一：缓存把不该缓存的请求缓存了。有些请求带随机数或者时间戳，本来就不该命中缓存，结果因为 key 设计不当，反而污染了缓存。解决办法是在缓存 key 里排除这些字段，或者对这类请求直接跳过缓存。

坑二：重试放大了故障。上游抖动时，网关自动重试，结果重试的流量把上游压得更死。后来我把重试策略改成指数退避加熔断，连续失败到阈值就停止重试，直接返回降级结果。

坑三：日志把敏感信息记下来了。用户的 prompt 里可能有手机号、身份证号，直接落库是合规风险。后来在网关里加了一层脱敏，正则匹配敏感字段做掩码，才敢开全量日志。

坑四：虚拟 key 没有轮换机制。有个团队的虚拟 key 泄露了，因为从来没轮换过，被人薅了半个月才发现。现在我的做法是虚拟 key 强制 90 天轮换，快到期时自动通知业务方更新。

5.3 性能调优的几个实操技巧

连接池要调大。网关到上游是 HTTP 长连接，默认连接池往往不够用，高并发时会排队。我一般把连接池调到 200 以上，具体看并发量。

异步要彻底。Python 网关如果用同步框架，并发上不去。用 FastAPI 这类异步框架，配合 httpx 的异步客户端，单机能扛的并发能翻好几倍。

缓存要分层。本地内存缓存挡第一层，Redis 挡第二层，数据库兜底。本地缓存命中时延迟几乎为零，能挡掉大量重复请求。

批量请求要合并。有些场景是短时间内大量小请求，可以攒一批一起发，减少往返次数。这个对 embedding 场景特别有效。

6. 安全与合规的底线

6.1 Agent 安全的三条红线

Agent 能执行命令、能读写文件，安全边界必须划清楚。我的三条红线是：

第一，最小权限。Agent 能访问的目录、能调用的工具，都要显式声明，默认拒绝。不要给它整个文件系统的读写权限。

第二，操作审计。Agent 的每一次工具调用都要记录，包括调了什么、参数是什么、结果是什么。出问题能追溯。

第三，危险操作二次确认。删除文件、执行 shell 命令、访问网络这些操作，要么禁止，要么需要人工确认。我见过 Agent 误删生产数据库的案例，血的教训。

6.2 数据合规的注意事项

大模型调用涉及数据出境、隐私保护这些合规问题，网关是天然的管控点。我的做法是：

• 数据分级：把请求按敏感程度分级，高敏感数据只允许走私有化部署的模型，不允许出境。
• 脱敏前置：在网关入口做脱敏，敏感字段掩码后再发给上游。
• 审计留痕：所有请求的元数据（谁、什么时候、调了什么模型、多少 token）必须留存，保留期按合规要求设置。
• 供应商评估：接入任何上游之前，确认它的数据处理条款符合你的合规要求。

这些不是技术问题，是流程问题，但必须在网关设计阶段就考虑进去，事后补很痛苦。

7. 我个人的一些实践体会

搭网关这件事，我最大的体会是别追求一步到位。我见过太多团队，一开始就想做一个大而全的平台，结果半年过去了还在设计阶段，业务方等不及又各自直连了，最后网关成了摆设。

正确的节奏是：先用开源方案一周内把调用收口，让业务方感受到统一入口的便利；然后逐步加限流、加日志、加缓存，每加一个能力都让业务方看到实实在在的好处（比如账单降了、故障少了）；最后再考虑智能路由、语义缓存这些高级能力。

还有一个体会是网关的运维比开发更重要。网关是所有调用的必经之路，它挂了全线都挂。所以高可用、监控告警、灰度发布这些运维能力，要在设计阶段就当成一等公民，而不是上线后再补。

最后分享一个小技巧：给网关加一个影子模式。新路由策略上线前，先让流量同时走新旧两条路，对比结果和成本，确认没问题再切。这个能避免很多线上事故，我每次改路由策略都会用。

这套东西后续还能往几个方向扩展：一是接入更多类型的模型，比如语音、图像、视频；二是把 Agent 的编排能力也收进网关，做成统一的 Agent 运行时；三是和内部的成本中心打通，做到实时的成本归因和预算预警。每一步都不难，难的是坚持把基础打牢。