上篇讲了怎么用网关一行代码切换模型。这一篇聊聊更根本的问题：当你的团队从"偶尔用用大模型"变成"业务跑在模型上"，为什么网关会从"可选项"变成"必需品"。
一条凌晨三点发到你手机上的消息
想象一下这个场景。
凌晨三点，你的手机震了一下。不是闹钟。是财务同事在企业微信上发来的消息："这个月的 DeepSeek 余额归零了，全组 API 调用都断了，怎么回事？"
你爬起来查日志，发现一个内部测试用的 Agent 在半夜触发了循环逻辑——它反复调用推理模型分析同一段用户输入，每次消耗一万多个 Token，连跑了四个小时。
没有告警。没有熔断。没有人在意。
Agent 不会累，但你的账户余额会。
这种事不是"如果"，而是"什么时候"。当调用方从人变成 Agent，"有人盯着用"变成了"没人看着自动跑"。你把钥匙交给了一台 24 小时不会累的机器，却没有给它装上刹车。
LLM 网关到底是个什么东西
上一篇文章我们演示了用网关切换模型——改一个 Header 参数，DeepSeek 变通义，通义变智谱。很多人看完后的第一反应是："哦，这不就是个 API 代理嘛。"
不只是。
如果把 LLM 调用比作开车，那一个简单的 API 代理只是帮你换了一条路——从国道换到高速。而一个完整的 LLM 网关，是给你装上了仪表盘、刹车、行车记录仪和限速器。
更准确地说，LLM 网关在你的应用和所有大模型之间充当了控制平面（Control Plane）：
┌─────────────┐
│ │
你的应用 ──────→ │ LLM 网关 │ ──→ DeepSeek
│ │ ──→ 通义千问
│ (控制平面) │ ──→ 智谱 GLM
│ │ ──→ Claude
│ │ ──→ ...
└──────┬──────┘
│
┌──────┴──────┐
│ 谁在调？ │
│ 花了多少？ │
│ 有没有超预算？│
│ 要不要熔断？ │
└─────────────┘
它不只是把请求"转发"出去，而是在转发的同时做四件事：身份验证、成本记录、预算控制、安全审计。这四件事，是"个人用大模型"和"团队跑大模型"之间的分界线。
从"一个人用"到"一个团队用"，问题完全不一样
一个人用大模型的时候，需求很简单：有个 Key，能调就行。Key 存在 .env 里，花了多少钱月底看一眼余额，不够了再充。
一个团队用大模型的时候，情况就变了：
第一，权限问题。 三个项目、五个同事、七个模型厂商——谁的 Key 给谁用？新同事来了怎么给他配 Key？老同事离职了怎么确保他不会带走 Key 继续用？
第二，成本问题。 老板问："这个月 AI 调用花了三千块，哪个项目花的？谁花的？值不值？"你看着散落在各家后台的账单，答不上来。
第三，合规问题。 如果你在金融、医疗、政务行业，你的 AI 调用链路必须可追溯。谁在什么时候调了什么模型、输入了什么、输出了什么——监管来查的时候，你手上得有一份不可篡改的完整记录。
这三个问题，靠"一个 Key 一个 .env"解决不了。靠各家厂商的后台额度限制也解决不了——因为那是管一个模型的，管不了跨模型的统一视图。
市面上的方案，为什么还不够
我调研过目前国内开发者用得最多的方案，结论是：对个人够用，对团队不够。
One API / New API，GitHub 上加起来近 70,000 个 Star，Go 单二进制部署，10 分钟就能跑起来。它是中国开源社区在 LLM 网关领域的标杆——但它的设计原点是为"个人开发者管理多个 API Key"而生的，不是为"企业团队管理 AI 基础设施"而生的。
没有多租户隔离——所有人共用一个视图。没有预算熔断——超量了不会自动切断。没有不可变审计日志——管理操作不可追溯。没有 AES-256 加密存储——Key 的安全性依赖部署环境本身。
这些问题对个人开发者来说不是问题。但对一个 10 人以上的团队、对一个有合规要求的公司、对一个 Agent 正在自动跑着的系统来说，这些事情不是"锦上添花"，是"没它不行"。
Portkey（美国，被 Palo Alto Networks 以 1.2-1.4 亿美元收购）在这些方面做到了企业级——但它面向的是美国和印度市场，国产模型的适配浅，中文支持少，中国部署网络延迟高。
这就是为什么我做了 OneLLM。
OneLLM 在代理层之上加了什么
OneLLM 在网关核心里面内置了四层管控能力，这四层恰好对应了前面说的四个问题：
第一层：虚拟 Key 体系。 你不再需要把 DeepSeek、通义、智谱的原始 API Key 分发到各个项目里。在管理后台把各家 Key 录入（AES-256 加密存储），生成一个 aihub_sk_ 开头的虚拟 Key，把它绑给所有厂商。同事离职？在后台一键吊销，不用去各家跑一遍轮换 Key。
第二层：Workspace 多租户 + RBAC。 不同的项目、不同的团队，创建不同的 Workspace，彼此完全隔离。Owner、Admin、Member、Viewer 四个角色，谁能看什么、谁能改什么，一清二楚。
第三层：预算熔断。 给每个 Workspace 设置月预算和日预算。花费到 70% 发告警，到 85% 限速，到 100% 硬切断。Agent 跑飞了？到线自动停，不会烧穿底。
第四层：不可变审计日志。 所有管理操作——谁创建了 Key、谁修改了权限、谁删除了 Workspace——全部追加写入审计表，不可修改、不可删除。不是"记一下"，是"法律级的证据链"。
这四层能力，在 One API 的生态位里不存在，在 Portkey 的生态位里存在但在中国用不了。 OneLLM 要填补的就是这个空白。
为什么现在就应该考虑这件事
2026 年的 AI 调用和 2024 年已经完全不是一个概念了。
2024 年，大模型调用是人在做——开发者手动写 Prompt、点发送、看结果。调用频率以"次/小时"为单位。
2026 年，大模型调用越来越多地是 Agent 在做——自动触发、高频调用、无人看管。调用频率以"次/秒"为单位。MCP 协议让 Agent 能直接调工具、A2A 协议让 Agent 之间能互相通信。
调用方从"人"变成了"程序"，管控就必须从"手动"变成"自动"。
这不是在贩卖焦虑。你看看周围——Dify、扣子、LangChain、CrewAI，更不用提个各种“小龙虾”、“爱马仕”了，越来越多的团队正在把大模型嵌入业务流程。每多一个 Agent，就多了一条可能失控的调用链路。每多一条链路，就多了一份需要管理的成本和安全风险。
网关层在现在加，叫"基础设施建设"。等出了事再加，叫"救火"。
现在就可以开始
OneLLM 是开源的，MIT 协议。你可以现在就用三条命令跑起来：
git clone https://github.com/EmilyLi2026/OneLLM.git
cd OneLLM/gateway-core && npm install && npm run dev:node
启动管理后台后，录入你的模型 Key、创建虚拟 Key、设置预算——十分钟搞定。
它不是大厂产品，没有 99.99% 的 SLA 承诺，还在快速迭代中。但它解决的是一个真实存在的问题：当你的团队开始在 AI 上花钱——而且花得越来越多——谁来帮你管住这笔钱？
One API 管模型，OneLLM 管 Agent。
如果你也在经历 Key 管理的混乱、账单的不可见、Agent 调用的不可控——欢迎来 GitHub 看看。
Demo 环境：http://59.110.62.203:18080/
有任何想法，直接提 Issue，或者扫码加微信聊。
扫码添加，备注"OneLLM"。不一定秒回，但每条都会看。
下一篇预告：《5 分钟自建 LLM 统一 API 入口——Docker 部署完整教程》。点关注，不错过。
