OctaFuse 2.0：把复杂路由画成一条看得懂的链路

过去配置 AI 网关，很像在维修一台看不见内部结构的机器：供应商（Provider）密钥、优先级（priority）、权重（weight）和路由策略散落在不同字段中。即使完成配置，仍要在脑中推演“这次请求究竟会访问哪个上游”。

OctaFuse Gateway 2.0 的目标很直接：打开页面就能看懂请求怎么走，用可视化流程完成多供应商、分流与故障转移（Failover）配置。

先看请求怎么走，再决定在哪里配置

2.0 引入新的路由拓扑：

客户端请求
   ↓
Request Surface
   ↓
Route Pool
   ↓
Upstream Target
   ↓
Provider

请求入口（Request Surface）描述客户端通过哪种协议和操作进入网关；路由池（Route Pool）组织一组共享故障转移规则的上游；上游目标（Upstream Target）则对应实际尝试的供应商模型。

配置项直接出现在真正生效的环节。页面不再只是表单集合，而是请求处理过程本身。

优先级、策略和权重，各自只负责一件事

路由池中的调度可以用三句话解释：

优先级决定先走哪一层，策略决定同层如何排序，权重决定流量向谁倾斜。

• 优先级：当前层全部失败后，才会进入下一层。
• 策略：决定同一层的上游目标如何排列与选择。
• 权重：为同层分流提供比例或偏好信息。
• 状态：已停用的供应商或上游目标不会进入实际尝试计划。

这让“主力账号之间分流、低成本上游优先、昂贵服务最终保底”等组合，都能在一张拓扑图中表达。

路由策略不该只是一串内部 ID

2.0 首次提供四种可切换策略，并在管理后台（Admin）加入策略卡片和效果预览。无需发起真实请求，配置人员就能了解哪些上游目标会被优先尝试、哪些属于备用层，以及当前策略继承自路由池、模型还是全局配置。

策略名称已经更新

2.0 发布时使用 affinity、weighted_random、strict、round_robin。从 2.2.0 开始，规范 ID 改为 cache_affinity、weighted_random、fixed_order、weighted_round_robin。下表按照 2.2.0 时的名称描述相同能力。

2.2.0 策略	适合场景
cache_affinity	尽量稳定命中同一上游，提高提示词缓存命中率
weighted_random	按权重随机分流，适合灰度与容量配比
fixed_order	严格主备，始终按固定顺序尝试
weighted_round_robin	按权重轮转，让流量分配更均匀可预期

一个供应商配置，对应一个真实上游账号

2.0 同时将供应商配置调整为单密钥模型：一个供应商配置只维护一把上游 API Key。如果同一家供应商有多个账号，就分别创建多个供应商配置。

这种模型让配置对象与现实账号一一对应：路由页显示的上游实体，就是运维人员需要管理、启停和排障的账号。密钥不再隐藏在供应商配置下的二级列表中，路由与凭证使用同一套清晰的对应关系。

一条更简单的配置路径

1. 导入或创建供应商（Provider），并填写上游密钥。
2. 导入模型，创建对应路由（Route）。
3. 为路由设置优先级（priority）与权重（weight）。
4. 选择或继承路由策略。
5. 在拓扑和效果预览中确认尝试顺序。
6. 使用调试台（Playground）或模拟器（Simulator）验证真实链路。

2.0 不只是一次界面调整，而是对数据库结构、运行时调度和管理体验的同步重构。它建立的“请求入口 → 路由池 → 上游目标”基础，也成为后续 Gemini 路由统一和优先级分层策略的前提。

• GitHub Release v2.0.0

进一步了解 OctaFuse 或查看源码：

• OctaFuse 官网
• GitHub 仓库

如果 OctaFuse 对你的项目有帮助，欢迎在 GitHub 上点一个 Star。你的关注和反馈，会帮助我们继续完善路由与自托管体验。