9Router v0.5 系列更新详解：Provider 扩展、Combo 智能路由与 RTK 令牌节省全解析-二趣网

9Router v0.5 系列更新详解：Provider 扩展、Combo 智能路由与 RTK 令牌节省全解析

【免费下载链接】9routerUnlimited FREE AI coding. Connect Claude Code, Codex, Cursor, Cline, Copilot, Antigravity to FREE Claude/GPT/Gemini via 40+ providers. Auto-fallback, RTK -40% tokens, never hit limits.项目地址: https://gitcode.com/GitHub_Trending/9r/9router

本文以 9Router 仓库 CHANGELOG.md 为骨架，系统梳理 v0.5.2 至 v0.5.45 版本的核心演进脉络，并结合仓库源码深入解析 Combo 路由策略、Fusion 融合模式、RTK 令牌压缩、Headroom 代理、Kiro 直连翻译等关键实现的底层原理。读完本文，你将理解 9Router 如何把 Claude Code、Codex、Cursor 等编码工具接入 40+ 免费/付费模型提供商，掌握自动回退、按能力自动切换模型、请求级令牌节省等机制的内部运作方式，并能据此更好地配置和使用 9Router。

一、版本概览：从 v0.4.46 到 v0.5.45 的演进主线

CHANGELOG 记录了从 v0.4.46（2026-05-15）到 v0.5.45（2026-07-30）共 20 余个版本，包内当前版本号为0.5.45（见 package.json）。整体演进可归纳为四条主线：

Provider 生态持续扩张：Poolside、api-airforce、baidu、bazaarlink、bluesminds、kilo-gateway、llm7、morph、sambanova、tencent、Venice、Kimchi、Qoder、xAI Grok、MiMo Free、Perplexity Agent、ClinePass 等先后加入；同期新增 zed / trae / windsurf 等 OAuth 提供商，并不断加固回调代理。
Combo 路由策略从「轮询」走向「策略化」：v0.5.2 引入 per-combo 策略选择器（fallback / round-robin / fusion / capacity），v0.5.2 的 Fusion 融合模式与 capacity 自动切换成为里程碑。
令牌节省（RTK / Headroom / Caveman / Ponytail / PXPipe）体系成型：从 v0.5.2 的 RTK 默认开启，到 v0.5.30 增加 PXPipe 多模态压缩与 Headroom 插件管理，再到 v0.5.35 的X-9Router-Token-Saver请求级开关。
稳定性与安全加固贯穿始终：Kiro 直连路由、Claude 429 冷却、Codex 流式超时兜底、SSRF 防护、刷新令牌轮换等大量修复。

二、Combo 路由策略：从 round-robin 到四策略并行的架构演进

v0.5.2 之前，Combo（模型组合）只有 round-robin 切换开关。v0.5.2 引入策略选择器，支持对每个 combo 独立选择四种策略：

策略	行为	适用场景
`fallback`	按顺序尝试，失败后回退到下一个模型	订阅额度不足时平滑降级到免费模型
`round-robin`	在组合模型之间轮询分配请求	多账号/多模型均衡负载
`fusion`	并行把请求发给所有成员模型，由 judge 模型合成最终答案	需要多模型交叉验证、追求答案质量
`capacity`	每次请求按能力重排模型，让支持图片/PDF 的模型优先	混合文本/多模态输入场景

2.1 round-robin 的粘性轮询实现

open-sse/services/combo.js 中的getRotatedModels展示了轮询的核心：每个 combo 在内存中维护{ index, consecutiveUseCount }状态，通过stickyLimit（粘性次数，默认 1）控制每个模型被连续使用几次后才切换到下一个，从而实现"请求亲和"——同一 combo 的连续请求不会频繁跳动模型。resetComboRotation在 combo 配置变更时重置状态，避免脏状态影响后续路由。

2.2 capacity 自动切换：按请求内容重排模型

capacity 策略的关键是 detectRequiredCapabilities 与 reorderByCapabilities：

能力检测：只扫描当前用户回合（trailingUserItems）中的内容块，识别image/input_image/inlineData等图片载体为vision需求、file/document/application/pdf为pdf需求。旧回合的历史媒体会被下游剥离并以占位符替代，避免把整个 combo 长期钉死在视觉模型上。
能力重排：reorderByCapabilities采用稳定排序，把模型分为三层——Tier 0 满足全部硬能力（vision/pdf/audioInput/videoInput）与软能力；Tier 1 仅满足硬能力；Tier 2 为其余。重排永不丢弃模型，回退链路始终完整。源码注释明确区分硬/软能力：硬能力缺失会直接导致请求数据（如图片）被剥离，必须优先满足。

对应测试见 tests/unit/combo-autoswitch.test.js（覆盖detectRequiredCapabilities与reorderByCapabilities）。

2.3 fallback 的智能回退与 503 语义

handleComboChat 实现了失败回退的完整链路：

对每个模型调用handleSingleModel，成功（2xx）立即返回；
失败时解析错误体、提取retryAfter，并记录所有成员模型中最早的 retryAfter；
通过checkFallbackError（见 open-sse/services/accountFallback.js）判断是否应回退；对 502/503/504 瞬时错误会先等待cooldownMs（≤5s）给上游恢复机会，避免"一抖就跳"；
全部失败时返回503 而非 406——源码注释解释：406 暗示请求本身非法，而此处是提供商不可用，503 语义更准确且可被客户端重试；若检测到no credentials也会返回 503。

三、Fusion 融合模式：并行面板 + Judge 合成

Fusion 是 v0.5.2 最具特色的策略，其实现集中在 handleFusionChat：

并行扇出：把请求体去掉 tools/tool_choice 并强制stream: false，通过flattenToolHistory（combo.js）把历史工具调用/工具结果展平为散文，保证面板模型拿到完整上下文却不会自己发起工具调用。
quorum-grace 收集：collectPanel只要凑够minPanel（默认 2）个成功响应，就开始 8 秒宽限期等待掉队者，同时受 90 秒硬超时兜底（见FUSION_DEFAULTS）。这样既避免最慢模型主导墙钟时间，又尽量收集完整面板。
优雅降级：0 个面板答案返回 503；恰好 1 个成功则直接转发该模型结果，不做无意义融合。
Judge 合成：buildJudgePrompt（combo.js）把各成员回答匿名化为[Source N]，要求 judge 先做共识/矛盾/局部覆盖/独到见解/盲区五维分析，再写出一份权威最终答案。来源匿名化让 judge 依据内容实质而非模型品牌声誉打分。judge 调用保留客户端原始 stream 标志与 tools，因此流式与后续工具使用不受影响。

测试见 tests/unit/combo-fusion.test.js 与 tests/unit/combo-routing.test.js（轮询路由）。

四、RTK 令牌节省与 token-saver 请求级开关

RTK（Request Token Killer）是 9Router 的令牌节省核心，默认压缩tool_result内容，宣称可省 20-40% 令牌（见 README.md）。

4.1 压缩管线

open-sse/rtk/index.js 的compressMessages在translateRequest顶部（任何格式翻译之前）注入，支持多种消息形态：

OpenAI tool 消息（{role:"tool", content:string}或 content 为文本块数组）；
OpenAI Responses 的function_call_output（字符串或input_text数组）；
Kiro 专用格式conversationState.history + conversationState.currentMessage（v0.4.52 引入，约 13.6% 节省）；
超出MIN_COMPRESS_SIZE阈值才压缩，避免对小文本产生无谓开销。

4.2 请求级旁路头

v0.5.35 新增X-9Router-Token-Saver请求头：客户端在单次请求中把该头设为off，即可绕过 token saver 管线。在 open-sse/handlers/chatCore.js 中，tokenSaverEnabled = clientRawRequest?.headers?.[TOKEN_SAVER_HEADER]?.toLowerCase() !== "off"，该开关统一控制 RTK 压缩、Headroom 代理、Caveman 与 Ponytail 的注入。对需要完整原始上下文（如精确检索、审计类请求）的调用，这是细粒度的逃生舱。

4.3 相邻的令牌节省组件

Caveman：v0.5.20 增加对齐上游的风格规则（见 open-sse/rtk/cavemanPrompts.js），v0.4.71 支持文言文级别。
Ponytail：极简代码生成指令注入（open-sse/rtk/ponytail.js），v0.5.6 首发。
PXPipe：v0.5.30 加入的多模态提示压缩器（open-sse/rtk/pxpipe.js）。
Headroom：独立压缩代理，支持 extras 检测/安装 UI（v0.5.30），v0.5.2 起在 dashboard 提供一键启停、状态探测与 claude↔openai 形状转换；v0.5.35 起以X-9Router-Token-Saver: off统一旁路。compressWithHeadroom（open-sse/rtk/headroom.js）是失败开放设计——任何错误返回 null，绝不因压缩代理故障阻断请求。

五、Provider 生态：新增提供商与 OAuth 加固

v0.5.45 的 registry（open-sse/providers/registry/index.js）已静态导入 100+ 提供商文件。v0.5 系列新增的提供商包括：

Chat/推理：Poolside、api-airforce、baidu、bazaarlink、bluesminds、kilo-gateway、llm7、morph、sambanova、tencent、Venice、Kimchi、Perplexity Agent、ClinePass、MiMo Free、Featherless（OpenAI 兼容预设）等；
编码工具 OAuth：Qoder（设备码流程 + COSY 签名 + WAF 绕过编码 + 实时模型目录，v0.4.66）、xAI Grok（OAuth/API key/图像，v0.4.58）、zed / trae / windsurf（v0.5.45）等；
关键模型更新：Gemini 3.6 Flash 分层路由 + 3.5 Flash Lite、Claude 默认 Opus 提升至claude-opus-5、Kiro 增加 Opus 5 / GPT-5.6 家族、Codex 增加 gpt-5.4-mini 等。

OAuth 方面，v0.5.45 强调"harden callback proxies"，结合 v0.5.2 的"hardened reverse-proxy local-access trust"与"SSRF hardening on web fetch"，说明回调代理与本地访问信任是持续安全投入点。

六、Kiro 直连路由：绕过有损的 OpenAI 两跳

v0.5.2 起 Kiro 支持无头 API-key 认证（ksk_）与直接 claude↔kiro 路由。在此之前 Claude 客户端访问 Kiro 需要经 OpenAI 格式中转（两跳转换有损）；直连路由保留原生消息结构，配合后续版本的功能持续完善：

v0.5.4：honor thinking effort budgets；
v0.5.15：剥离内容流中泄漏的<thinking>标签（tests/unit/kiro-thinking-strip.test.js）；
v0.5.20：原生传递 system prompt、增加 Opus 4.5/4.7/4.8、容忍 dash 版本 id；
v0.5.30：压缩 Kiro 会话状态、改进直接会话缓存复用；
v0.5.40：映射 GPT-5.6 推理力度字段、在输出前校验终端流；
v0.5.45：规范化工具历史并正确路由 API keys、归一化 dashboard 思考强度模型。

七、Claude 配额防抖与自动 ping：告别 429 风暴

v0.5.2 针对 Claude 429 做了系统性修复：

停止高频请求 OAuth 用量端点——缓存resetAt；
配额刷新节流至 3 分钟；
429 后进入冷却（chat 不受影响）；
Claude auto-ping：在 5 小时配额窗口重置后立即预热，使新窗口即刻开始计时（per-connection 开关）。

配合 v0.5.2 的"Claude 429 冷却"与 v0.4.66 的流式超时调优（35s→30s 更快检测挂起），形成了"检测-冷却-预热"的完整配额管理闭环。

八、流式传输健壮性：Codex 与通用流处理

多个版本持续加固流式传输：

v0.4.71：Codex 流式超时硬化为 60s（可 per-provider 配置），接受response.done事件，任何流关闭/停滞/中止前都发出终端response.failed+[DONE]，防止客户端挂起（issue #1648/#1680/#1688/#1618）；
v0.4.62：上游中途断流自动重试；
v0.5.12：防止非 JSON SSE 行与重复[DONE]破坏客户端（PR #2046）；
v0.5.15：处理response.done终端事件（#2142）、Gemini 抑制流结束哨兵。

九、安全、隧道与数据库加固

安全：DB 导出/导入重新鉴权（v0.4.80）、真实客户端 IP 限流与远程默认密码防护（v0.4.80）、反向代理本地访问信任加固与 web fetch SSRF 防护（v0.5.2/v0.4.80）。
隧道：v0.4.46 是 breaking change——公共隧道 URL 变更，旧链接失效需重连；v0.4.62 将隧道重构为独立的 Cloudflare / Tailscale 管理器模块（src/lib/tunnel），支持 Windows 状态修复、虚拟网卡跳过、cloudflared PID 继承（v0.5.45）、Docker 侧车代理（v0.5.8）。
数据库：v0.5.30 增加 schema 变更自动备份、MCP 子进程清理、Codex 模型与 usage providers OOM 修复；v0.5.40 解决 better-sqlite3 参数绑定崩溃（package.json 将 better-sqlite3 置于 optionalDependencies，无编译工具链时回退 sql.js）。

十、i18n 与社区贡献

v0.5 系列在 i18n 上投入显著：新增 Khmer（km，v0.5.40）、Farsi（fa，v0.5.20）、Thai（th，v0.5.35）等语言，zh-CN 于 v0.5.30 完成全部 UI 字符串翻译，v0.5.45 将 pt-BR 扩至 986 词条；README 同步提供中文、日文、俄文、泰文、波斯文、印尼文、越南文译本（见 i18n 目录）。CHANGELOG 中大量修复条目标注了社区贡献者（如 decolua、Sutarto Jordan Chrisfivo、Joseph Yaksich、Rex、Qin Li 等），且项目配有完善的测试门禁：__baseline__基线快照与 verify 脚本（tests/baseline）确保 Provider 注册表、别名、OAuth URL 无回归，translator 目录下的 golden/no-regression 测试（tests/translator）持续守护格式转换正确性。

结语

从 CHANGELOG 的演进可以看到，9Router 的核心竞争力在于「接入层无限扩展、路由层策略化、传输层令牌节省」三位一体：registry 式的 Provider 注册表让 40+ 提供商以统一 schema 共存（v0.5.2 的 ~40 提交大重构），Combo 四策略覆盖从省钱到高质量的完整诉求，RTK/Headroom/PXPipe 等组件在翻译管线前端完成无侵入压缩。如果你正被订阅额度浪费、限流中断或工具输出烧令牌困扰，沿着本文梳理的版本脉络，结合 README.md、open-sse/services/combo.js 与对应单元测试，即可快速定位并启用最适合自己的路由与节省策略。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析