为什么我们做了 OctaFuse：聚合散落的 Token 资源
发布于
做 OctaFuse 的起点并不复杂：我们的 AI 资源越来越多，但使用体验却越来越碎片化。
购买的 Coding Plan、Token Plan，以及官方模型账号、第三方兼容端点和自托管模型，各自提供基础地址（Base URL）、API 密钥（API Key）、额度和价格。每增加一个客户端或业务系统，就要重新维护一遍连接信息和切换逻辑。
我们需要的不是又一层简单转发，而是一个真正属于自己的统一入口。
两个最初的使用场景
Section titled “两个最初的使用场景”个人资源聚合
Section titled “个人资源聚合”个人开发者可以把不同供应商和订阅计划统一维护在网关中，再向 Cursor、CLI、脚本和各种智能体（Agent）客户端提供一个网关地址（Gateway URL）与用户 API 密钥。
上游更换地址、轮换密钥或发生故障时，只需修改网关配置，不必逐个更新所有客户端。
团队与产品的 AI 基础服务
Section titled “团队与产品的 AI 基础服务”AI 产品同样需要消费多个上游的 Token。除了统一接入，还必须解决：
- 如何为不同用户和项目签发独立 API 密钥
- 如何设置预算周期与额度
- 如何记录供应成本、目录价和用户实际计费
- 如何审计配置变更与调用链路
- 如何在上游失败时自动切换
OctaFuse 把这些共性能力放在网关层，业务系统只处理自身业务，不必重复实现密钥存储、扣费、路由和日志服务。
为什么选择自己做一个网关
Section titled “为什么选择自己做一个网关”现有方案通常在两个方向上做取舍：
- 托管平台开箱即用，但接入范围和运行环境受平台限制。
- 开源网关更加灵活，但部署、配置和运营体验可能过于复杂。
OctaFuse 希望同时保留三件事：
- 开放接入：官方供应商、聚合平台、兼容端点和自托管服务都能接入。
- 可自托管：支持 Cloudflare Workers + D1，也支持 Docker + PostgreSQL / MySQL。
- 完整治理：不仅转发请求，还管理路由、故障转移、用户 API 密钥、预算、计费、日志和审计。
一个稳定入口，背后可以持续变化
Section titled “一个稳定入口，背后可以持续变化”对客户端而言，OctaFuse 始终提供稳定的网关地址、用户 API 密钥和模型 ID。背后的供应商、账号、价格与主备关系可以由运营人员独立调整。
这层解耦带来几个直接收益：
- 供应商密钥不会分散到每个客户端。
- 业务代码无需感知供应商切换。
- 多账号和多供应商可以统一分流与故障转移。
- 每一次调用都能归集到用户、密钥、模型、供应商和成本口径。
- 个人资源与团队资源可以使用同一套治理方式。
从聚合 Token 开始，但不止于模型
Section titled “从聚合 Token 开始，但不止于模型”OctaFuse 最初解决的是多模型 Token 资源聚合。随着智能体开始调用搜索、抓取和更多外部能力，网关也在继续扩展：图片生成、语音转写与智能体工具（Agent Tools）都可以共享同一套鉴权、预算、计费与日志体系。
我们希望它最终成为一个可自托管的 AI 能力总控服务：上游能力可以不断增加，但客户端入口与治理方式保持稳定。
如果 OctaFuse 对你的项目有帮助，欢迎在 GitHub 上点一个 Star。你的关注和反馈，会帮助这个开源项目持续成长。