路由 DSL：組合一個像 Fable 5 那樣思考的模型面板

前兩年，「更多智能」的劇本一直是「等待下一個模型」。我們認為那是錯誤的進步單位。前沿不是一個單一的檢查點——它是一個小組。給三個好的模型同一個難題，讓它們意見不同，然後在答案之間進行仲裁，這個小組勝過其任何一個成員。通常它能勝過價格圖表上的下一個模型。

該路由 DSL就是您構建該面板的方式。它是一種可程式化的路由策略—YAML + CEL—可將您的 OrcaRouter 端點轉變為一個推理圖：按難度路由、按任務路由、同時分支到多個模型、對其輸出進行評判或投票、在信心不足時回退，並針對成本、延遲或質量調整整個系統。您編寫規則；網關在每次請求時編譯並執行這些規則，耗時約~5 ms。

這篇文章是工程導覽：文法、你可以分支的變數、四個仲裁者、串聯、以及最後一個完整的生產規則集。

結果優先

兩個說明性基準測試。（數字是說明性的——它們旨在顯示形狀的效果，而不是作為官方分數引用。）

前沿比較 — 難度路由的DSL端點 vs. 單獨前沿:

融合面板 vs. 单独模型 — 基于 OpenRouter 在 100 项任务中的 93 项得分：

三件值得凝視的事物：

每個融合面板都勝過其自身的每一個成員。 Opus 4.8 + GPT-5.5（約67.5%）以7到9分的優勢同時超越Opus單獨（約58.5%）和GPT-5.5單獨（約60%）。分歧即是信號；仲裁從中收穫。

Fusion 達到下一個層級。 三個不同的面板跨越 Fable 5 solo (~65.5%) 使用僅那些模型 之下 它。

您不需要昂貴的成員。 Opus + Opus 自融合 (~65.5%) 匹配 Fable 5，使用一個模型和一個取樣器。一組廉價的模型 — Gemini 3 Flash + Kimi K2.6 + DeepSeek V4 Pro (~64.5%) — 略低於 Fable 5，而每個 token 的成本僅為其一小部分。這就是整個論點：用拓撲結構購買智能，而不是用下一個價格等級。

Routing DSL 是一個控制面，讓你能夠只在有回報的地方使用該拓撲——在簡單的80%上使用廉價模型，在困難的尾部使用融合面板。

30秒文法

一個 規則集 是 版本、 一個 列表 的 規則、 和 一個 必需的 預設值。 規則 被評估 上 到 下; 該 第一 when: 那是 真 獲勝。 無 when: 表示 "總是 匹配."

版本：1

rules:
  - id: only_rule
    use: { model: "claude-sonnet-4-6" }
default:
  delegate: balanced

「when:」是一個CEL 布林表達式 — 沙盒化、僅限 RE2 正則表達式、無迴圈、無 I/O、微秒級評估，並在整個規則集內共用一個 5 毫秒的截止時間。「use:」是效果：請求的去向以及如何調整。限制故意設定得很小（≤30 條規則、≤16 KiB 原始碼、每個 when: 最多 200 字元），以便規則集保持可稽核性。

原始1 — 按難度和任務規劃路線

分發器在路由之前對每個請求進行分類，並將特徵暴露給 CEL。你可以直接根據它們進行分支：

版本：1

rules:
  - id: hard_reasoning
    when: difficulty > 0.8
    use:
      model: "claude-opus-4-8"
      reasoning_effort: "high"
      thinking_budget_tokens: 32000


  - id: code_path
    when: task_class == "code" && code_keyword_density > 0.5
    use: { model: "gpt-5.5" }


  - id: cheap_chat
    when: difficulty < 0.3
    use: { model: "gemini-3-flash" }


default:
  delegate: balanced

您可以在 when: 中讀取的變量：（縮寫——請參閱文檔中的完整參考）：

群組範例

請求形狀

request.input_tokens, request.output_max_tokens, request.stream, request.vision, request.message_count, request.has_tools

分類

task_class (chat/code/agent/vision/audio/rag/creative), difficulty (0.0–1.0), code_keyword_density, reasoning_cue_count, log_prompt_tokens, tool_count

工作階段 

agent_state.turn, agent_state.tools_used, agent_state.has_edited, agent_state.last_test_failed, agent_state.consecutive_errors, agent_state.models_tried

上下文

headers["x-…"], user.group, token.name, time.hour, workspace.id
…plus six macros for the things regex-over-payload is good at: system_prompt_matches(re), user_message_matches(re), tool_definitions_include(name), tool_calls_present_any([…]), tool_results_from_any([…]), header_matches(name, re).

任何目的地都可以承載 每次呼叫的旋鈕，經由中繼適配器轉換為每個提供者的原生參數：reasoning_effort（低/中/高）、thinking_budget_tokens（1024–64000）、samples（1–16）、temperature（0.0–2.0），以及受拒絕清單保護的 param_override / header_override。這已足以構建表 A 中的按難度路由的端點：簡單尾部使用低成本模型，困難尾部則使用帶思考預算的 Opus。

原始圖形2 — 展開至面板（融合）

這是基準提升的來源。一個並行：效果將請求分派到 2–5條路徑同時，然後一個 仲裁者決定客戶實際看到的內容：

- id: hard_tail_panel
  when: difficulty > 0.7 && task_class == "agent"
  use:
    parallel:
      - { model: "anthropic/claude-opus-4-8", reasoning_effort: "high" }
      - { model: "openai/gpt-5.5", thinking_budget_tokens: 16000 }
      - { model: "google/gemini-3.1-pro", temperature: 0.3 }
    arbiter:
      strategy: best_of_n
      model: "anthropic/claude-sonnet-4-6"      # the judge
      template: judge_code
    max_latency_ms: 120000
    on_disagreement:                  # majority-only escape hatch
      model: "anthropic/claude-opus-4-8"
      reasoning_effort: "high"

四種仲裁策略，每一種都是對「誰的輸出勝出？」的不同回答：

首先— 賽跑腿部，服務首次成功，取消失敗者。優化延遲（你獲得最快的N個）。

大多數——跨分支輸出的結構化投票，無需額外的模型調用。當分支之間無嚴格多數時，可選的 on_disagreement: 分支會重新分派一個新的、更強的嘗試，而非提供平局解決方案。最佳化穩健性於具有標準答案的任務上。

best_of_n — 一個 LLM 評判器讀取所有候選者並對它們進行排名。這是表 B 中的 Opus + GPT-5.5 → judge 配置。在 品質上優化開放式任務；若評判器出錯，則回退到第一個成功的結果。

測試通過 — 執行驅動：服務於其修補程式真正使測試套件通過的候選者。沒有評判猜測——由測試框架決定。這是程式碼/代理工作最強的仲裁者。驗證器存在於閘道之外（通過 VerifierProvider 連接）；若無連接，則降級為第一個成功的。

max_latency_ms（1000–600000，預設為120000）限制了扇出，因此一個慢速分支無法延遲回應 — 落後者會被丟棄。在平行內部巢狀平行會在 lint 階段被拒絕；該面板刻意只有一層深度。

可用性说明： the N-way fan-out 运行时的使用受服务器标志控制 ROUTING_DSL_ENSEMBLE_RUNTIME 而在暂存环境中，逐项计费功能已得到强化，这就是融合功能之所以是 预览版，而非正式发布版. 关闭该标志后，parallel: 规则可正常服务于其第一条路线，因此你现在即可编写和预览你的面板，待融合功能在你的区域上线后即可启用。

原始型 3 — 備用方案與信心級聯

扇出（Fan-out）預先花費 N 倍。一個 串聯 額外花費 僅在第一次答案看起來錯誤時。回應後，on_low_confidence 會評估信號，如果觸發，則重新派遣至更強的目標：

- id: agent_with_safety_net
  when: task_class == "agent"
  use:
    pool: "@pool:fast"
  on_low_confidence:
    signals: [patch_invalid, self_doubt, next_turn_test_failed]
    threshold: { low_logprob: -1.5 }
    use:
      model: "claude-opus-4-8"
      reasoning_effort: "high"

訊號： patch_invalid（diff 失敗於 git apply --check）， self_doubt（一個迴避性短語的正則表達式集合）， low_logprob（平均 token logprob 低於閾值，且提供者會暴露此資訊），以及 next_turn_test_failed（一個跨回合鎖存器 — 本回合的提示承載了上一回合失敗測試的形狀）。 Cascades 設計為深度為1。將它們與 agent_state.models_tried 配對以獲取 重試時的多樣性 —絕不將修復發送給剛剛失敗的模型。

調整刻度：成本、延遲、品質

相同的DSL表達了所有三個目標；您可以根據規則選擇：

成本 — 策略：使用最便宜的模型，将廉价模型保留在容易的尾部，并为難度 > 0.7 的请求保留扇出。表B的廉价面板（約64.5% ≈ Fable 5 单独）是存在的证据：小模型的融合可以取代前沿模型，且每代币成本仅为其一小部分。不过要清醒地认识到——融合使用了 「按每条腿计费」模式：一个三腿的 best_of_n 面板对三个候选者加上评审者收费。经济性之所以成立，是因为你 (a) 仅在困难的少数请求上进行扇出，并且 (b) 融合 更便宜的成员，比你正在取代的前沿模型。

延遲 — arbiter: { strategy: first } 加上緊湊的 max_latency_ms 可讓您從 N 個選項中獲得最快的結果，並有嚴格的最高上限。

品質 — best_of_n 用於開放式工作，當有測試套件可依託時使用 tests_pass。在單次迭代中，samples 和 thinking_budget_tokens 能換取更多成果。

在不影響生產環境的情況下操作

路由變更令人畏懼，因此該DSL提供了SRE所期望的安全護欄：

每次保存时进行代码检查schema（模式）、CEL 类型检查（每个 when: 必须求值为布尔类型）、引用解析、旋钮范围、头部/参数黑名单。错误以 {行, 列, 消息, 规则} 的形式返回，并在编辑器中显示为边栏标记。

試運行 — 發送一個模擬請求（task_class、difficulty、agent_state……），並返回匹配的規則、解析的效果以及任何內容發布前的評估時間。

影子模式 — 在首次儲存後的24小時內，DSL會 被評估但未使用；影子日誌記錄了可能選擇的項目，而主控台顯示差異（路線變更百分比、預測每日成本差異、每規則觸發次數）。

Canary — 一個 0–100 的流量滑桿。逐步增加 5 → 25 → 50 → 100，同時觀察每個分片的指標；滑回 0 即可回滾。

稽核+回滾 — 每次儲存/回滾都會在同一交易中寫入一筆稽核記錄；並行編輯將收到一個帶有當前版本的409錯誤，因此您需要根據最新狀態重試。

測試案例、追蹤重播，以及一個 AI「解釋此規則集」檢視完善了整體功能。你可以在儀表板中的路由 → 策略 → DSL.

完整的規則集

便宜的在容易上，中等在中間，一個被評判的融合面板在困難的代理尾巴上，下面有一個信心級聯：

版本：1

rules:
  - id: trivial
    when: difficulty < 0.3 && !has_tools
    use: { model: "gemini-3-flash" }


  - id: standard
    when: difficulty < 0.7
    use:
      model: "gpt-5.5"
    on_low_confidence:
      signals: [self_doubt, low_logprob]
      use: { model: "claude-opus-4-8", reasoning_effort: "high" }


  - id: hard_agent_panel
    when: difficulty >= 0.7 && task_class == "agent"
    use:
      parallel:
        - { model: "anthropic/claude-opus-4-8", reasoning_effort: "high" }
        - { model: "openai/gpt-5.5", thinking_budget_tokens: 16000 }
        - { model: "google/gemini-3.1-pro" }
      arbiter:
        strategy: tests_pass        # execution-grounded; judged fallback if no harness
      max_latency_ms: 180000
      on_disagreement:
        model: "claude-opus-4-8"
        reasoning_effort: "high"


default:
  delegate: balanced

那個端點位於Table A的頂部——並非因為它找到了更好的模型，而是因為它將正確的模型用於正確的請求，並在面板勝出的地方精確地融合了一個面板。

開始撰寫

能力的下一次飛躍不必等待下一個檢查點。{{1}}這是一個你可以在今天下午編寫的圖表：按難度路由，在困難尾部扇出，判斷或測試輸出，信心下降時級聯。{{/1}}

文件： https://docs.orcarouter.ai/routing/routing-dsl

UI: 路由 → 创建路由器 -> 路由策略 → DSL（专家）

前沿是一塊面板。去打造你的專屬。