从 Beego 到 TokenHub：一路开源，这次我想做一个企业真正需要的 AI 网关

从 Beego 到 TokenHub 微信公众号海报

TokenHub 开源之后，我收到最多的一个问题，不是怎么部署，也不是支持哪些模型，而是：

已经有 Sub2API、New API、LiteLLM、Portkey、Higress 这些项目了，为什么还要再做一个开源 AI 网关？

这个问题很合理。

因为在 TokenHub 之前，很多人认识我，是因为另一个开源项目：Beego。

从 Beego 到 TokenHub，中间隔着很多年，也跨过了完全不同的技术周期。一个属于 Go 和 Web 应用快速发展的时代，另一个诞生在 AI 进入企业生产环境的今天。

看起来，它们没有多少关系。

但对我来说，Beego 和 TokenHub 其实来自同一种冲动：当一种技术开始被越来越多人使用，复杂度也随之出现时，能不能做一套开放、可靠的基础设施，把复杂的部分收进去，让更多人更简单地使用它？

今天的 AI 网关赛道并不缺项目。有人解决多模型接入，有人擅长 API 中转和计费，有人把订阅账号转换成接口，也有人从云原生流量治理切入。如果只是为了“再写一套模型转发代码”，确实没有必要重新造一个轮子。

但 TokenHub 从一开始想解决的，就不只是转发请求。

我真正想做的，是一个企业可以长期拥有、放心商用、自由二开，并且能把员工身份、项目 Key、供应商账号、模型路由、Token 成本和审计日志放在一起管理的开源 AI 网关。

这既是 TokenHub 的产品定位，也是做完 Beego 这么多年后，我仍然愿意在 AI 时代再出发一次的原因。

在 TokenHub 之前，我最重要的开源经历是 Beego

我从大学开始接触开源，一路走到今天。

在我过去做过的开源项目里，最被大家熟悉的应该是 Beego。

Beego 是一个使用 Go 语言快速开发企业应用的开源框架。它把路由、MVC、ORM、Session、日志、配置、缓存和开发工具等能力组织在一起，让开发者可以更快地构建 RESTful API、Web 应用和后端服务。

今天回头看，Beego 真正带给我的，并不只是一个流行框架的经历。

它让我第一次完整地感受到，一个开源项目是怎样从个人代码变成公共基础设施的。

最开始，你可能只是想解决自己的问题。后来，越来越多人开始使用它，提出不同的需求，遇到你从未遇到过的环境，甚至把它放进真正重要的生产系统里。

这时，代码的意义就变了。

它不再只是作者觉得“能跑就行”的作品，而是别人愿意投入信任的工具。

这种信任，是开源最让人兴奋的地方，也是最沉的一份责任。

Beego 教会我的，不只是如何写一个框架

做 Beego 的过程中，我逐渐形成了自己对开源的理解。

第一，代码发布只是开始，不是结束。

一个项目放到 GitHub 上，只能说明仓库公开了。真正的开源，要有人使用，有文档可以阅读，有问题能够讨论，也要允许其他人提交完全不同的想法。

维护一个开源项目，很多时候并不是继续写最有趣的新功能，而是处理兼容性、修复边缘问题、补齐文档，或者耐心回答一个已经被问过很多次的问题。

这些事情不一定耀眼，却决定了一个项目能不能被长期信任。

第二，技术选择最终会变成对用户的承诺。

当别人把项目用于生产环境，作者的一个接口调整、一次版本升级、甚至文档里一句不够清楚的说明，都可能影响真实业务。

开源带来的不只是自由，也意味着克制。你要考虑升级路径、兼容边界和用户已经建立起来的使用习惯，而不能永远按照个人喜好重写一切。

第三，一个真正成长起来的开源项目，最终一定会大于作者本人。

有人贡献代码，有人维护文档，有人创建社区，也有人在原项目基础上发展出新的实践。作者需要接受项目不再完全按照自己的想象成长，也需要学会把舞台留给更多参与者。

Beego 让我明白，开源不是把代码送出去之后就失去什么。恰恰相反，正因为代码被交给了社区，它才可能走到一个人无法抵达的地方。

从 Web 时代到 AI 时代，我又看到了熟悉的问题

Beego 出现时，Web 开发正在快速普及。

开发者需要处理路由、配置、数据库、Session、日志和应用结构。每一项都能单独实现，但如果所有团队都从头拼装一次，大量精力就会消耗在重复的基础设施工作上。

Beego 做的事情，是把这些分散的复杂度组织起来，给开发者一个更完整、更容易开始的入口。

今天，AI 正在经历相似的过程。

一开始，大家只关心模型能不能调用。很快，企业就会同时面对多个供应商、多个订阅账号、不同模型、不同项目和大量员工。API Key 开始散落，Token 成本开始增长，安全与审计问题也随之出现。

每一项能力都可以单独开发，但如果身份、Key、Provider、路由、额度、成本和日志彼此分离，企业依然无法真正管理 AI。

TokenHub 想做的，就是在 AI 时代把这些新的复杂度重新组织起来。

Beego 降低的是开发 Web 应用的门槛；TokenHub 降低的是企业安全、稳定、可控地使用 AI 的门槛。

它们不是同一种产品，却延续着同一种工程思路：让基础设施承担复杂度，让使用者获得一个简单、可靠、可以长期掌控的入口。

开源对我来说，已经不是一个技术选项

这些年，技术栈换过很多轮，互联网热点也换过很多次。但有一件事始终没有变化：每当我做出一个真正有价值的技术项目，我首先想到的还是，能不能把它开放出来，让更多人使用、修改和一起完善。

对我来说，开源不是产品做完之后增加的一个宣传标签，也不是商业化之前用来积累用户的获客手段。

开源本身就是我相信的一种技术协作方式。

我一直很享受这种感觉：一个人写下最初的代码，另一个人发现问题并提交修复；有人补充文档，有人适配新的环境，还有人把项目用到了作者从未设想过的地方。

代码一旦真正进入社区，它就不再只属于最初的作者，而会在一次次使用和贡献中获得新的生命。Beego 让我亲眼见证过这个过程，也让我更相信这件事值得继续做。

如果只是为了赚钱，完全可以把 TokenHub 做成一个闭源 SaaS，按账号、调用量或者高级功能收费。这条路可能更直接，商业边界也更容易控制。

但我还是选择把它开源。

因为我希望把一个技术人对开源的热爱继续做到底。

为什么选择 Apache 2.0

聊到开源，就绕不开许可证。

Beego 采用的是 Apache 2.0。多年之后做 TokenHub，我依然选择了同一个协议。

这不是为了保持形式上的一致，而是因为经历过一个开源项目的长期发展后，我更确定自己希望代码以什么方式进入社区和企业。

我个人更喜欢宽松、清晰、对商业使用友好的开源协议。因此 TokenHub 从一开始就选择了 Apache License 2.0。

企业可以下载、部署、修改和商用，也可以围绕自己的业务做闭源集成和内部二次开发。只要遵守协议要求，就不需要因为使用了 TokenHub，而被迫把自己的全部业务代码一起公开。

这对企业级基础设施尤其重要。

AI 网关往往要接入公司的身份体系、权限系统、成本中心、内部模型、审计平台和业务应用。这些集成天然会触碰企业自己的核心系统。如果许可证边界不够清楚，技术团队即使认可项目，法务和管理层也可能不敢真正采用。

我也想把一个容易引发争论的问题说清楚：GPL、AGPL 和 LGPL 同样是正式、重要的开源协议。Copyleft 的出发点，是确保修改和再分发仍然回馈开源社区，它并不等于“假开源”，许可证本身也不能用来判断一个作者是不是只想赚钱。

但站在企业采用者的角度，强 Copyleft、网络分发义务、双许可证模式，或者 README 中额外出现的商业限制，确实会提高闭源集成、SaaS 交付和商业部署的评估成本。

我自己不希望 TokenHub 的用户先花大量时间猜测“这样用会不会触发开源义务”，也不希望开源版本成为一个只能体验、真正商用还必须换许可的入口。

所以我选择 Apache 2.0。

不是因为其他协议没有价值，而是因为我希望企业拿到 TokenHub 时，第一反应是“可以放心部署和二开”，而不是先去开一场许可证风险评审会。

有了 Sub2API 和 New API，TokenHub 还有什么不同

TokenHub 开源后，被问得最多的两个名字就是 Sub2API 和 New API。

它们都解决了真实需求，也有各自非常清晰的使用场景。

Sub2API 更关注把 Claude、Codex、Gemini CLI 等订阅资源转换成 API，方便团队共享和调用。对于希望把已有订阅能力池化的团队，它提供了一条直接路径。

TokenHub 也支持接入可用的 Codex 订阅账号资源，但这只是企业资源池中的一种 Provider 能力，而不是整个平台的最终定位。TokenHub 更关心的是：这些账号由谁管理、员工通过什么身份使用、请求属于哪个项目、消耗如何归因、出了问题能不能审计，以及企业能否把这套入口长期掌握在自己手里。

New API 则更接近大家熟悉的多供应商中转和计费管理平台。它的中文社区活跃，多模型和渠道接入丰富，适合需要快速搭建中转服务、额度计费和运营体系的场景。

TokenHub 不准备成为另一个面对互联网售卖 Token 的中转站。它的服务对象首先是企业内部员工、团队负责人、平台管理员、安全部门和财务部门。它要解决的不是“如何把额度卖给更多用户”，而是“企业如何把 AI 变成一项可治理的内部能力”。

这就是两种产品方向的根本区别。

一个更偏向中转与运营，一个更偏向企业内部基础设施。它们可能会有相似的模型接口和 Provider 管理，但产品最终要服务的人、组织关系和治理目标并不相同。

和其他开源 AI 网关相比，我们给自己找到了什么位置

为了回答“为什么还需要 TokenHub”，我也认真梳理了目前几个有代表性的开源项目。

图片

LiteLLM 很适合开发者团队快速接入多种模型，SDK 生态、协议适配和故障转移能力很强。TokenHub 在此之外，更强调企业统一工作台：员工身份、项目 Key、成本中心、请求日志和角色治理要出现在同一个系统里。

Portkey 的企业特性、可观测性和缓存能力比较完整，也有成熟的托管与商业服务。TokenHub 选择的路线是 Apache 2.0、开源和私有化优先，希望企业能够按照自己的合规边界长期维护和二开。

Higress 是成熟的云原生 API Gateway，基于 Istio 和 Envoy，在 Kubernetes、Ingress、微服务流量治理、MCP 和 Wasm 插件等方向有深厚积累。TokenHub 不想替代这样的通用流量网关，而是把重点放在更轻量的企业内部 AI Token 平台上。

至于 OneAPI / New API 和 Sub2API，它们分别在多供应商中转、计费运营和订阅资源 API 化上形成了鲜明定位。TokenHub 的差异并不在于“也能转发一个请求”，而在于它希望把转发背后的企业关系建立起来。

需要说明的是，图中的许可证和产品信息来自写作时各项目公开仓库及文档。开源项目一直在快速演进，实际选型时仍应查看最新版本，并由企业结合自身使用方式进行技术和法务评估。

企业级 AI 网关，不能只有一条 /v1 接口

如果只看最底层，所有 AI 网关做的事情都很相似：接收请求，选择上游，再把模型结果返回给客户端。

但对企业来说，真正复杂的问题都发生在接口之外。

谁有权使用模型？

普通员工、团队负责人和平台管理员应该看到相同的后台吗？

一个项目创建的 Key，能不能限制模型、额度、并发和来源？

多个供应商和订阅账号之间，如何配置权重、优先级、健康检查、失败冷却和故障回退？

每次调用用了多少输入和输出 Token，成本应该归到哪个人、团队、项目和成本中心？

安全部门需要追溯时，能不能看到请求日志、路由命中和管理员的策略变更？

员工入职、转岗和离职时，权限能不能跟着组织关系一起变化？

这些问题，才是 TokenHub 所理解的“企业级”。

因此，TokenHub 从一开始就不是围绕单一管理员页面设计，而是区分普通用户、团队负责人和平台管理员的工作台；不是只维护一个上游 Key，而是管理 Provider、账号资源、模型目录和路由策略；不是只显示供应商总账单，而是把使用量和成本归因到项目、团队与成本中心。

它支持企业 SSO、OAuth/OIDC、RBAC、项目 Key、配额与并发控制、请求日志、后台审计和私有化部署。模型可以来自 OpenAI、Anthropic、Gemini、国内供应商或企业本地模型，但身份、入口、成本和证据链应该留在企业自己的平台里。

这就是 TokenHub 给自己找到的位置：

一个 Apache 2.0 开源、私有化优先、面向企业内部治理的 AI API 网关。

我们不需要证明别人做错了

做一个新的开源项目，最容易掉进的陷阱，是一定要证明现有项目哪里不行。

但开源世界不是一道只能有一个正确答案的选择题。

不同项目往往来自不同作者亲身遇到的问题。有人需要快速适配上百个模型，有人需要运营 API 中转服务，有人需要把订阅账号转成团队接口，有人需要治理 Kubernetes 中的 AI 流量。把自己的问题解决好，本身就有价值。

TokenHub 也不需要通过贬低其他项目来证明自己存在的合理性。

我们只需要把自己的选择说清楚：为什么采用 Apache 2.0，为什么坚持私有化优先，为什么把身份、项目、成本和审计放在转发能力之前，为什么更愿意服务企业内部平台，而不是成为另一个 Token 售卖系统。

定位清楚之后，很多比较就不再是谁“功能更多”，而是谁更适合当前场景。

如果你只是想快速调用多个模型，LiteLLM 可能很合适；如果你已经在 Kubernetes 中运行大规模云原生基础设施，Higress 值得认真评估；如果你要搭建多渠道中转和计费运营，New API 有成熟的社区积累；如果你关注订阅资源 API 化，Sub2API 的方向更直接。

如果你想搭建的是企业自己的 AI 统一入口，希望账号可控、调用可追溯、费用可归因、权限能回收，并且希望代码可以长期商用和自由二开，那么 TokenHub 想成为这个选项。

从 Beego 到 TokenHub，把技术人的热爱继续做到底

开源项目不会因为发布到 GitHub 就自动成功。

它需要持续写代码、补文档、修问题、回复 Issue，也需要接受不同意见，甚至接受别人拿走代码，做出与原作者完全不同的东西。

但这恰恰是开源最有魅力的地方。

从大学到今天，我从开源社区获得了很多。知识、工具、合作伙伴，以及一次次把想法变成现实的机会。

Beego 是我在 Web 时代交给开源社区的一份作品。它让我知道，一段代码真的可以跨越个人能力和时间边界，被无数开发者使用、讨论和继续完善。

TokenHub 则是我在 AI 时代交出的下一份作品。

从 Beego 到 TokenHub，变化的是技术问题：过去是如何更快地开发企业应用，今天是如何让企业更安全、更稳定、更可控地使用 AI。

没有变化的，是我对开源的理解：协议应该足够开放，使用者应该拥有自主权，真正有价值的基础设施应该允许更多人参与建设。

我不知道它最终会长成多大的项目，但我知道自己希望它沿着什么方向成长：协议足够开放，部署足够自主，企业能力足够扎实，技术讨论足够坦诚。

不是为了再造一个看起来相似的轮子。

而是因为还有一个我真正想解决的问题，也还有一份不想放下的开源热爱。

所以，在已经有这么多 AI 网关项目的今天，我仍然选择开发并开源 TokenHub。

这不是从 Beego 转向了另一个毫无关系的热点。

而是一个做了一路开源的人，在 AI 时代又遇到了一个值得长期解决的问题。

TokenHub 采用 Apache 2.0 协议，支持私有化部署。

GitHub：https://github.com/astaxie/TokenHub