OctaFuse Gateway 2.2.0：让每一层路由都有自己的策略

OctaFuse Gateway 2.2.0 正式发布。 这次升级聚焦一件事：让路由配置更贴近真实的生产流量。

当一个模型同时接入多个账号、多个供应商或多条备用链路时，"先走谁、同层怎么选、失败后往哪里切"不应该是一组藏在代码里的隐含规则。2.2.0 把这些决策继续下沉到 Route Pool 的 priority 层，同时统一 Gemini 的流式与非流式路由语义，让配置、执行与日志看到的是同一套结构。

一句话看懂 2.2.0：一套 Gemini 路由，同时服务流式与非流式请求；一个 Route Pool，可以为不同 priority 层选择不同策略。

本次版本还统一了路由策略名称，升级了 Admin 的可视化策略编辑，并重新设计 Agent Tools Provider 的配置入口，让凭证、启用状态与三账本定价更容易核对。

01｜Gemini 路由：从两套配置收敛为一套

过去，Gemini 的 generateContent 与 streamGenerateContent 会以两个 operation 出现在路由配置中。它们在客户端侧确实是两个 action，但从网关治理视角看，通常属于同一个能力、共享同一组上游和故障转移策略。

Gemini 流式与非流式请求统一配置为 models.generate，实际 action 仍由 Proxy 根据请求生成。

2.2.0 将公开 Surface 与上游 Target 的配置统一为：

text 复制代码

models.generate

现在，一次 Surface / Pool 配置即可同时服务流式与非流式请求。Proxy 仍会根据客户端请求生成真实的上游 action：

这意味着路由配置更少、流式与非流式行为更一致，也减少了两套 Pool 长期漂移的风险。客户端 URL 保持不变，现有 Gemini SDK 与调用方式无需调整。

Route Pool 原本已经支持 priority 分层：高优先级上游全部失败后，才会进入下一层。但在 2.2.0 之前，一个 Pool 内的所有层共享同一套路由策略。

同一个模型可以拥有多个 Route group；每个 Pool 内按 priority 组织首选层与备用层。

现在，你可以为每个 priority 层分别选择排序方式：

策略选择器会说明适用场景、取舍、生效来源，并在保存前展示当前层的实际排序效果。

例如，同一个 Route Pool 可以这样组织：

如果某一层没有单独设置策略，它会继续继承 Pool、模型或全局配置。你可以只覆盖真正需要差异化的层，不必重复维护整套规则。

本次版本将策略 ID 统一为更明确的 canonical 名称：

新名称直接表达策略行为，也为 Admin、API、数据库与运行时建立了统一契约。

需要特别注意：2.2.0 不再接受三个旧 ID。 数据库迁移会改写已持久化的配置；如果你有外部自动化直接调用 Admin API 或写入配置，也必须同步使用新名称。

Routes 页面同步升级了策略编辑体验：

我们的目标不是把更多配置项塞进页面，而是让运维人员在修改前就能回答：这层现在按什么顺序走？配置从哪里继承？失败后会切到哪里？

2.2.0 也重新设计了 Agent Tools Provider 卡片。现在可以通过卡片与右侧抽屉集中维护：

Web Search、Web Fetch、Deep Search 与 AI Detection 的 Active Provider、凭证状态和三账本价格集中呈现。

对于 Web Search、Web Fetch、Deep Search、AI Detection 这类按调用量计费的 Agent 能力，配置是否完整、售价是否覆盖成本、当前 Provider 是否真正启用，都可以在同一处完成核对。

如果此前的路由策略全部继承自全局配置，可以平滑升级到 2.2.0。
如果存在模型、Pool 或 priority 层的独立策略配置，升级期间可能短暂出现因新旧数据不一致导致的请求错误。建议在同一维护窗口内完成数据库迁移，并同步升级 Proxy 与 Admin。

OctaFuse 是一个可自托管的开源 AI 能力网关与运营控制面。它把模型、图片、语音与 Agent Tools 接入统一入口，并提供路由、密钥、预算、计费、日志和审计能力。

如果你正在管理多个模型供应商、多个账号或复杂的主备链路，欢迎升级到 2.2.0，也欢迎在 GitHub Issues 分享你的使用场景与反馈。

最后，如果您觉得这个项目不错，顺手给个 Star 支持一下，您的支持是持续更新的动力～