OctaFuse 2.2.0：让每一层路由都有自己的策略
发布于
后续更新：v2.3.0 通过迁移 0021 将
cache_affinity/fixed_order改名为hash_affinity/weight_priority，且不保留旧 ID 别名。下文保留 2.2.0 发布时的历史语义；当前配置请参阅 2.3.0 发布说明。
OctaFuse Gateway 2.2.0 正式发布。
这次升级聚焦一件事：让路由配置更贴近真实的生产流量。
当一个模型同时接入多个账号、多个供应商（Provider）或多条备用链路时，“先走谁、同层怎么选、失败后切到哪里”不应该是一组隐藏在代码里的规则。2.2.0 将这些决策进一步下沉到路由池（Route Pool）的优先级（priority）层，同时统一 Gemini 流式与非流式请求的路由语义，让配置、执行和日志呈现同一套结构。
一句话看懂 2.2.0：
一套 Gemini 路由同时服务流式与非流式请求；一个路由池可以为不同优先级层选择不同策略。
本次版本还统一了路由策略名称，改进了管理后台（Admin）的可视化策略编辑，并重新设计了智能体工具（Agent Tools）的供应商配置入口，让凭证、启用状态和三账本定价更容易核对。
01｜Gemini 路由：从两套配置收敛为一套
Section titled “01｜Gemini 路由：从两套配置收敛为一套”过去，Gemini 的 generateContent 与 streamGenerateContent 会作为两个操作出现在路由配置中。它们在客户端侧确实是两个不同的请求动作，但从网关治理的角度看，通常属于同一项能力，并共享同一组上游和故障转移策略。
Gemini 流式与非流式请求统一配置为 models.generate，实际请求动作仍由代理根据客户端请求生成。
2.2.0 将对外请求入口（Request Surface）与上游目标（Upstream Target）的配置统一为：
models.generate现在，一套请求入口与路由池配置即可同时服务流式和非流式请求。代理（Proxy）仍会根据客户端请求生成真实的上游动作：
- 非流式请求使用
generateContent - 流式请求使用
streamGenerateContent - 实际动作写入
route_trace.gemini.action，排障时依然清晰可见
这意味着路由配置更少，流式与非流式行为更加一致，也降低了两套路由池配置长期产生差异的风险。客户端 URL 保持不变，现有 Gemini SDK 和调用方式无需调整。
02｜按优先级层配置策略
Section titled “02｜按优先级层配置策略”路由池原本已经支持优先级分层：只有高优先级上游全部失败后，才会进入下一层。但在 2.2.0 之前，同一路由池内的所有层只能共享同一套路由策略。
同一个模型可以拥有多个路由组；每个路由池按照优先级组织首选层和备用层。
现在，你可以为每个优先级层分别选择排序方式：
| 策略 | 适合场景 |
|---|---|
cache_affinity | 稳定命中首选上游，提高提示词缓存命中率 |
weighted_random | 按权重随机分配流量，适合灰度与容量分摊 |
fixed_order | 严格按固定顺序尝试，适合主备链路 |
weighted_round_robin | 按权重轮转，适合更均匀、可预期的流量分配 |
策略选择器会说明适用场景、取舍、生效来源，并在保存前展示当前层的实际排序效果。
例如，同一个路由池可以这样组织：
- P0 主力层：使用
weighted_round_robin，在多个稳定账号之间分摊流量 - P10 备用层：使用
fixed_order，优先低成本备用，再进入保底上游
如果某一层没有单独设置策略，它会继续继承路由池、模型或全局配置。你只需覆盖真正需要差异化的层，不必重复维护整套规则。
03｜策略名称统一，配置即语义
Section titled “03｜策略名称统一，配置即语义”本次版本将策略 ID 统一为含义更明确的规范名称：
| 旧 ID | 2.2.0 规范 ID |
|---|---|
affinity | cache_affinity |
strict | fixed_order |
round_robin | weighted_round_robin |
weighted_random | weighted_random |
新名称可以更直接地表达策略行为，也为管理后台、API、数据库和运行时建立了统一契约。
需要特别注意：2.2.0 不再接受三个旧 ID。 数据库迁移会改写已经持久化的配置；如果外部自动化会直接调用管理 API 或写入配置，也必须同步改用新名称。
04｜管理后台：看得见策略来源，也看得懂故障转移
Section titled “04｜管理后台：看得见策略来源，也看得懂故障转移”路由（Routes）页面同步升级了策略编辑体验：
- 全局、路由池与优先级层统一使用可视化策略选择器
- 每一层都能查看当前生效策略及其来源
- 故障转移规则可以在配置页面直接查看
- 新建 Gemini 供应商配置时，优先写入单一的
models.generateURL 模板 - 无法安全合并的历史 Gemini 双模板会被保留，并提示人工复核
我们的目标不是把更多配置项塞进页面，而是让运维人员在修改前就能回答：这层现在按什么顺序走？配置从哪里继承？失败后会切到哪里？
05｜智能体工具供应商：集中管理凭证、价格与启用状态
Section titled “05｜智能体工具供应商：集中管理凭证、价格与启用状态”2.2.0 还重新设计了智能体工具供应商卡片。现在可以通过卡片和右侧抽屉集中维护：
网页搜索（Web Search）、网页抓取（Web Fetch）、深度搜索（Web Deep Search）和 AI 率检测（AI Detection）的当前供应商、凭证状态与三账本价格集中呈现。
- 供应商凭证
- 供应成本（Metered）、目录标准价（Standard）和用户实付（Charged）三种账本单价
- “仅保存配置”或“保存并启用”
- 未保存、缺少凭证、服务不可用与亏损定价提示
对于网页搜索、网页抓取、深度搜索和 AI 率检测这类按调用量计费的智能体能力，配置是否完整、售价能否覆盖成本、当前供应商是否真正启用，都可以在同一处完成核对。
- 如果此前的路由策略全部继承自全局配置，可以平滑升级到 2.2.0。
- 如果模型、路由池或优先级层存在独立策略配置，升级期间可能因新旧数据不一致而短暂出现请求错误。建议在同一维护窗口内完成数据库迁移，并同步升级代理和管理后台。
获取 2.2.0
Section titled “获取 2.2.0”OctaFuse 是一个可自托管的开源 AI 能力网关与运营控制台。它为模型、图片、语音和智能体工具提供统一入口，并具备路由、密钥、预算、计费、日志与审计能力。
如果你正在管理多个模型供应商、多个账号或复杂的主备链路，欢迎升级到 2.2.0，也欢迎在 GitHub Issues 分享你的使用场景与反馈。
进一步了解 OctaFuse 或查看源码：
如果 OctaFuse 对你的项目有帮助，欢迎在 GitHub 上点一个 Star。你的关注和反馈，会帮助我们继续完善多供应商路由体验。