一、先别填表，先看路：请求处理流程一眼看完
每个模型的路由配置，现在都会被转换成清晰的「请求处理流程」：从左到右展示的，就是一次真实请求的完整路径：
客户端请求 → 匹配模型 → 策略与故障转移 → 上游供应商
所有可配置项，都会直接挂在它「真正生效」的那个环节上。不需要先记一堆概念再去猜页面含义，而是做到：页面本身就是说明书，流程本身就是配置入口。
过去你需要在脑子里先画完整的请求路由流程图，现在后台已经帮你把这件事可视化了，只需要在需要额外配置的节点点击设置即可，路由管理会轻松很多。
二、策略不用背单词：点卡片，还能预览效果
同一优先级下应该如何选择上游？2.0 提供了四套常用路由策略，全部可以直接在路由页面通过卡片方式选择：
| 策略 | 人话版 |
|---|---|
| affinity（默认） | 同类请求尽量走同一家供应商，更有利于 Prompt Cache 命中 |
| weighted_random | 按照权重随机分流，适合做成本控制和流量配比 |
| strict | 高权重目标始终优先，主备关系非常明确 |
| round_robin | 轮询分配，请求依次分摊给各个上游 |
另外，选完策略之后还能查看「策略效果预览」：系统会基于当前启用的 Target，说明谁会最先被调用、谁会作为故障回退层，而且不会发出真实请求。在修改路由策略之前，先把运行时结果预演一遍，这种体验过去通常只能在运维文档或架构图里看到。
全局默认策略同样支持配置；模型和路由池也可以单独覆盖，继承关系在页面中展示得非常清晰：当前池 → 模型规则 → 全局 → 系统默认。这样你不必再反复确认“当前实际生效的到底是哪条路由规则”。
三、Priority 权重：主备和分流，在一张图上讲清楚
在流程图中，你可以直接看到：
- 首选层 / 回退层：Priority 更高的目标会优先请求；当前层全部失败后，才会进入下一层
- 权重 weight：同一层里的流量怎么分配、谁承担更多请求、谁作为备用，直接用数字表达
- 启用 / 停用：如果某个供应商或路由已经关闭，预览中会被直接排除，避免出现“明明配置了却根本没生效”的情况
一句话总结这个版本的路由调度逻辑：
Priority 决定先走谁，策略决定怎么选，权重决定更偏向谁。
而这三个核心概念，现在都直接展示在路由页面上。
四、Provider 也变简单了：一把 Key 管一个供应商
2.0 还顺手把 Provider 配置做了单键化：一个 Provider 只对应一把 API Key。如果你有多个账号，直接创建多个 Provider 即可，这和路由页中「多个上游目标」的使用逻辑是完全一致的。
API 密钥不再散落在冗长的 Key 列表里来回查找；你在路由页面看到的「上游供应商」，就是你实际要管理的那个账号实体。整个配置链路更短、更直观，也更适合日常运维和多供应商管理。
五、配置路径可以很「懒」——也仍然专业
推荐一条适合大多数用户的「懒人正确路径」：
- 打开路由配置，先通过流程图看清请求路径
- 给模型添加几个上游 Target（不同供应商 / 不同权重 / 不同优先级）
- 打开策略设置，默认先使用 affinity（更适合缓存命中）
- 如果需要做流量分流，就切换为 weighted_random；如果需要明确主备，就选择 strict
- 最后看一眼效果预览，确认无误后保存即可
写在最后
Octafuse Gateway 2.0 这次升级为 major 版本，重点对底层数据结构进行了较大调整，从而带来了更高的路由配置灵活性。后续也会基于这套能力，继续提供更多 AI 网关、模型路由和多供应商调度场景下的解决方案。
