企业官网建设流程全解析

OmniRoute Auto-Combo 引擎：多因子自适应评分、模式包权重与自修复路由机制

【免费下载链接】OmniRouteNever stop coding. Free MIT AI gateway: one endpoint, 352 providers (150+ free), 1200+ models Kimi, Claude, GPT, Gemini, GLM, DeepSeek, MiniMax. Works with Claude Code, Codex, Cursor, OpenCode, Cline & Copilot. Quota-aware auto-fallback, RTK+Caveman compression saves 15-95% tokens, MCP/A2A, Desktop/PWA. Built by 550+ contributors项目地址: https://gitcode.com/GitHub_Trending/om/OmniRoute

Auto-Combo 是 OmniRoute 中让模型链“自我管理”的路由引擎：每个请求到来时，它根据配额、健康度、成本、延迟、任务匹配度等因子对候选提供商动态打分，选出当前最优的 provider/model 组合，并通过临时排除、熔断感知和事件模式（Incident Mode）在故障发生时自动收缩探索、优先保稳。读完本文，你可以理解其评分函数与权重归一化的实现原理、各 Mode Pack 的完整权重配置、自修复冷却/探针机制的参数含义，以及通过 API 与auto/前缀消费 Auto-Combo 的具体方式。

一、核心原理：按请求动态评分选择最优 Provider/Model

Auto-Combo 引擎为每个请求动态选择最佳 provider/model，其基础是一套加权评分函数。官方文档最初定义了6 因子评分模型（见docs/i18n/pt-BR/docs/routing/AUTO-COMBO.md与docs/routing/AUTO-COMBO.md）：

从当前仓库源码看，这套模型已被扩展为16 因子评分，声明于 open-sse/services/autoCombo/scoring.ts 的DEFAULT_WEIGHTS（默认权重之和恰为1.0）。原始 6 因子全部保留（quota0.1429、health0.1605、costInv0.1429、latencyInv0.1143、taskFit0.0762、stability0.0476），新增因子包括：

• tierPriority（0.0476）：账户层级优先级，Ultra=1.0、Pro=0.67、Standard=0.33、Free=0.0；
• tierAffinity/specificityMatch/contextAffinity（各 0.0476）：候选模型层级与 manifest 推荐层级、请求特异性、上下文窗口的亲和度；
• sessionAvailability（0.0476）：OAuth 会话可用性，非 OAuth 连接记 1.0；
• connectionDensity（0.0476）：同一 provider 的连接密度，防止负载向单一连接集中；
• quality（0.03）：来自路由事件质量追踪器的反馈信号，无观测的冷候选取中性 0.5；
• cacheAffinity/resetWindowAffinity/reliability：默认权重为 0（声明但不参与默认投票），在 Mode Pack 中激活（见下文）。

1.1 因子的计算与归一化（源码细节）

open-sse/services/autoCombo/scoring.ts 中的calculateFactors()对每个因子统一clamp01到 [0,1]，关键公式：

• quota = quotaRemaining / 100（剩余配额百分比归一化）；
• health由熔断器状态直接映射：CLOSED → 1.0、HALF_OPEN → 0.5、OPEN → 0.0；
• costInv = 1 - costPer1MTokens / maxCost、latencyInv = 1 - p95LatencyMs / maxLatency、stability = 1 - latencyStdDev / maxStdDev，三者均相对整个候选池的最大值归一化。为避免逐候选重算池最大值（O(n²)），源码提供computePoolMaxima()一次性计算（源码注释明确提到过零配置auto组合把池扩展到上千目标时的 OOM 教训）。

最终得分由calculateScore()做加权和并clamp01，防止浮点漂移越界或单个 NaN 因子污染排序。用户自定义权重则先经过normalizeScoringWeights()清洗（非法/负值置 0，总和为 0 时回退默认权重）再重新归一化为概率分布，因此任意自定义权重都能安全生效。

二、Mode Packs：一套权重、一个优化目标

Mode Pack 是预置的权重画像，整表替换（而非合并）默认权重，把选择偏向单一目标。文档定义了 4 个核心 Pack：

当前 open-sse/services/autoCombo/modePacks.ts 已包含6 个 Pack（新增reliability-first与chaos-mode），各 Pack 主因子权重如下（每 Pack 均自行加和至 1.0，normalizeScoringWeights()无需再修正）：

各 Pack 的取舍很清晰：ship-fast压低 stability、把 latencyInv 提到 0.3048；cost-saver让 costInv 独占 0.3324；quality-first把 taskFit 拉到 0.3524 并配 0.1429 stability 与最高的 quality 权重 0.03；offline-friendly用 quota 0.3324 + health 0.2667 追求最大余量、taskFit 直接归零；reliability-first与chaos-mode则分别面向故障注入与高可用场景（health 0.3524 / 0.4000）。tierAffinity、specificityMatch、resetWindowAffinity在所有 Pack 中显式为 0。

三、Self-Healing：临时排除、熔断感知与事件模式

文档描述了四条自修复行为，其全部参数在 open-sse/services/autoCombo/selfHealing.ts 中有精确定义：

1. 临时排除（Temporary exclusion）：得分低于EXCLUSION_THRESHOLD = 0.2的 provider 被排除，初始冷却DEFAULT_COOLDOWN_MS = 5 分钟；重复触发时冷却时间倍增（cooldownMs * 2），上限MAX_COOLDOWN_MS = 30 分钟（渐进退避）。冷却到期且得分回升至REENTRY_THRESHOLD = 0.3以上时自动重新准入。
2. 熔断感知（Circuit breaker awareness）：熔断器OPEN→ 自动排除；HALF_OPEN→ 放行探针请求并计数。recordProbeResult()中连续3 次成功探针才完全恢复准入；任何一次探针失败则冷却再翻倍、探针计数清零。
3. 事件模式（Incident mode）：updateIncidentMode()统计所有候选熔断器状态，当OPEN占比超过INCIDENT_MODE_THRESHOLD = 0.5（>50%）时进入事件模式——禁用探索、最大化稳定性（引擎侧将探索率强制置 0）。
4. 冷却恢复（Cooldown recovery）：排除后的首个请求即探针，失败则加倍惩罚，构成“低成本试探、失败即退”的恢复闭环。

值得注意的兜底逻辑在 open-sse/services/autoCombo/engine.ts 的selectProvider()中：若排除过滤后候选池为空，引擎会回退到全量候选（pool.push(...candidates)），保证路由永不因排除逻辑而中断——这是一种 fail-open 设计。

四、Bandit Exploration：5% 探索与分层轮换

文档指出：5% 的请求（可配置）被随机路由到随机 provider 用于探索，事件模式下禁用。在engine.ts中对应config.explorationRate（默认0.05 = 5%）：

const incidentMode = healer.isInIncidentMode(); const effectiveExplorationRate = incidentMode ? 0 : config.explorationRate; const isExploration = Math.random() < effectiveExplorationRate && candidates_.length > 1; if (isExploration) { const idx = Math.floor(Math.random() * candidates_.length); selected = candidates_[idx]; }

非探索请求并不总是取第一名，而是经过ScoreTierRotator：按分差把候选分为 top/mid/rest 三层，若最优与最差分差 ≥CLEAR_WINNER_THRESHOLD = 0.1（明显赢家）则只在 top 层内轮换；否则按组合名对应的偏好做加权随机（如coding偏好 top:0.6、cheap偏好 rest:0.5、smart把探索权重提高），从而在同分附近保持轮换多样性，而不是钉死单一 provider。

此外，当taskType为default且提供了原始消息时，引擎会用classifyPromptIntent()对最后一条 user 消息做多语言意图分类（code/reasoning/simple/medium），再据此计算 taskFit——这让评分能感知请求的实际任务类型。

engine.ts还实现了预算上限（budget cap）：budgetCap按每请求美元计，估算成本costPer1MTokens / 1_000_000 × estimatedInputTokens（默认按 1000 token 估算）超过上限时优先在预算内候选重选；若所有候选都超限，budgetFallback: "strict"抛出BudgetExceededError（快速失败，避免静默超支），默认"cheapest"则退回到全局最便宜的候选。

五、API 与使用方式

5.1 文档记载的 Auto-Combo API

关联文档给出的接口示例：

# 创建 auto-combo curl -X POST http://localhost:20128/api/combos/auto \ -H "Content-Type: application/json" \ -d '{"id":"my-auto","name":"Auto Coder","candidatePool":["anthropic","google","openai"],"modePack":"ship-fast"}' # 列出 auto-combos curl http://localhost:20128/api/combos/auto

从当前仓库源码核实（src/app/api/combos/auto/route.ts），该路由现仅实现GET（且需管理鉴权requireManagementAuth）：列出auto及全部变体，每个变体带解析后的候选池、候选数量，以及context_length/max_output_tokens（取候选池窗口的MAX值，避免客户端因读到 0 而禁用自动压缩）。创建持久化 Auto-Combo 请走标准 combos 接口并指定strategy: "auto"：

curl -X POST http://localhost:20128/api/combos \ -H "Content-Type: application/json" \ -d '{"id":"my-auto","name":"Auto Coder","strategy":"auto","config":{"auto":{"candidatePool":["anthropic","google","openai"],"weights":{"quota":0.15,"health":0.3,"costInv":0.05,"latencyInv":0.35,"taskFit":0.1}}}}'

5.2 零配置auto/前缀

无需创建任何 combo，直接在model字段使用auto或auto/<variant>：

curl -X POST http://localhost:20128/v1/chat/completions \ -H "Authorization: Bearer <key>" \ -H "Content-Type: application/json" \ -d '{"model":"auto/coding","messages":[{"role":"user","content":"Hello"}]}'

可用变体（auto、auto/coding、auto/fast、auto/cheap、auto/offline、auto/smart、auto/lkgp）由open-sse/services/autoCombo/autoPrefix.ts解析；虚拟 combo 由open-sse/services/autoCombo/virtualFactory.ts按请求即时构建（活跃连接 → 凭据过滤 → 注册表模型/价格关联 → 16 因子评分），不落库。

5.3 逐请求控制头

通过 open-sse/services/autoCombo/requestControls.ts 解析的三个请求头，可以在不改动 combo 配置的前提下按请求覆盖modePack/budgetCap/budgetFallback：

curl -sS http://localhost:20128/v1/chat/completions \ -H "Content-Type: application/json" \ -H "X-OmniRoute-Mode: fast" \ -H "X-OmniRoute-Budget: 0.05" \ -H "X-OmniRoute-Budget-Fallback: strict" \ -d '{"model":"auto","messages":[{"role":"user","content":"hi"}]}'

六、Task Fitness：模型 × 任务类型匹配度

文档说明 TaskFit 因子覆盖 30+ 模型、6 种任务类型（coding、review、planning、analysis、debugging、documentation），并支持通配符模式（如*-coder→ 高 coding 得分）。open-sse/services/autoCombo/taskFitness.ts 的实际实现是一个多级解析链（优先级从高到低）：

1. 用户覆盖（DBmodel_intelligence，source=user_override）；
2. Arena ELO 实时榜单（source=arena_elo，ARENA_ELO_SYNC_ENABLED开启时生效，支持scoresAs继承）；
3. models.dev 能力层级（含厂商生命周期否决——已退役 id 不获得层级分）；
4. 静态FITNESS_TABLE（仅版本化模型 id 的手维护小表，如o3: 0.95、deepseek-coder: 0.9）；
5. 通配符加成（在 0.5 中性基线上做模式匹配加成；0.5 表示“无证据”而非“平庸”）。

七、相关文件一览

核心行为有单元测试覆盖，见 open-sse/services/autoCombo/__tests__/autoCombo.test.ts 及同目录下chaosEngine.test.ts、speedRanking.test.ts、taskFitness-pattern-order-8603.test.ts等用例；组合路由的端到端决策矩阵测试位于tests/integration/combo-matrix/。

小结：Auto-Combo 的核心价值在于“评分即策略”——16 因子加权和给出候选排序，Mode Pack 一键切换优化目标，self-healing 的 0.2/0.3 阈值、5 分钟起步（上限 30 分钟）的渐进退避与 3 探针恢复机制负责故障隔离，5% bandit 探索（事件模式下自动关闭）保证长期不陷入局部最优，而auto/零配置前缀让以上全部能力对客户端完全透明。

【免费下载链接】OmniRouteNever stop coding. Free MIT AI gateway: one endpoint, 352 providers (150+ free), 1200+ models Kimi, Claude, GPT, Gemini, GLM, DeepSeek, MiniMax. Works with Claude Code, Codex, Cursor, OpenCode, Cline & Copilot. Quota-aware auto-fallback, RTK+Caveman compression saves 15-95% tokens, MCP/A2A, Desktop/PWA. Built by 550+ contributors项目地址: https://gitcode.com/GitHub_Trending/om/OmniRoute