路由DSL：组合一个模型面板，其思考方式类似Fable 5

对于"更多智能"的剧本，两年来一直是"等待下一个模型"。我们认为这是错误的进步单位。前沿不是一个单一的检查点——而是一个专家团。给三个好模型同一个难题，让它们各抒己见，然后仲裁答案，这个专家团会胜过任何一个成员。通常它能胜过价格表上更贵的下一个模型。

该 路由 DSL是你构建那个面板的方式。这是一个可编程的路由策略 — YAML + CEL — 它把你的 OrcaRouter 端点变成一个推理图：按难度路由，按任务路由，同时分发到多个模型，判断或投票它们的输出，当信心低时回退，并根据成本、延迟或质量调整整个系统。你编写规则；网关在每次请求上编译并运行它们，大约5 ms。

这篇文章是工程指南：语法、可分支的变量、四个仲裁器、级联，以及最后的完整生产规则集。

结果优先

两个说明性基准测试。（数字仅为说明性质——它们旨在展示效果的形态，而非作为官方分数引用。）

前沿比较 — 基于难度路由的DSL端点与单独前沿的比较：

融合面板 vs. 单独模型 — 在100个任务（来自OpenRouter）中的93个上得分：

三件值得注视的事物：

每个融合面板都击败了其自身的每一个成员。 Opus 4.8 + GPT-5.5 （约67.5%）以7-9分的优势击败了单独的Opus（约58.5%）和单独的GPT-5.5（约60%）。分歧即为信号；仲裁对其进行利用。

融合达到了下一个级别。 三个不同的面板交叉 Fable 5 solo（~65.5%） 仅使用模型 下面 它。

你不需要昂贵的会员。 Opus + Opus 自融合（~65.5%）只需一个模型和一个采样器就匹配了 Fable 5。一组 廉价 模型——Gemini 3 Flash + Kimi K2.6 + DeepSeek V4 Pro（~64.5%）——以每 token 成本的一小部分就能略低于 Fable 5。这就是整个论点：用拓扑结构购买智能，而不是用下一个价格层级。

路由 DSL 是一个控制面，让你只在有价值的地方投入拓扑——简单80%用廉价模型，难啃的尾巴用融合面板。

30秒语法

规则集由版本、规则列表和必需的默认值组成。规则被评估自上而下；第一个为真的 when: 获胜。 没有 when: 表示“always match”。

版本: 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 judge 读取所有候选者并对它们进行排序。这是来自表B的 Opus + GPT-5.5 → judge 配置。优化 质量 在开放式工作上；如果 judge 出错，则回退到第一个成功的。

tests_pass — execution-grounded: 为那些补丁确实使测试套件通过的候选者服务。没有裁判猜测——由测试框架决定。这是代码/智能体工作的最强仲裁者。验证器位于网关之外（通过 VerifierProvider 连接）；如果没有连接，则降级为第一个成功的。

{{1}}max_latency_ms（1000–600000，默认120000）限制扇出，使得一个慢分支不会阻塞响应——落后请求会被丢弃。{{/1}}{{2}}在lint阶段会拒绝在`parallel`内部嵌套`parallel`；面板特意只支持一层深度。{{/2}}

可用性说明： N 路扇出运行时受服务器标志控制 ROUTING_DSL_ENSEMBLE_RUNTIME 而逐项计费在预发布环境中得到强化——这就是为什么融合是 预览版，而非正式版。如果关闭该标志，则 parallel: 规则会干净地服务于其第一个分支，因此您现在可以编写和影子测试您的面板，并在融合功能在您的区域上线时将其启用。

原语 3 — 回退与置信度级联

扇出预先花费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 (差异无法通过 git apply --check 验证), self_doubt (一个模糊限制短语的正则表达式集), low_logprob (平均 token logprob 低于阈值，如果提供者暴露该值), 以及 next_turn_test_failed (一个跨回合锁存器——当前回合的提示携带了上一回合失败测试的形状). Cascades 设计上是深度1。将它们与 agent_state.models_tried 配对以获得 diversity on retry — 永远不要将修复发送给刚刚失败的模型。

调节刻度：成本、延迟、质量

同一个DSL表达了所有三个目标；你可以根据规则选择：

成本 — 委托：最便宜的，将廉价模型保留在简单尾部，并为难度 > 0.7 的任务保留扇出。表 B 的廉价面板（约 64.5% ≈ Fable 5 单刷）是存在性证明：小模型的融合可以用每 token 成本的一小部分取代前沿模型。但要清醒地看到——融合使用了"为每条腿计费" 模型：一个三腿 best_of_n 面板对三个候选者加评判者进行计费。其经济性在于，你（a）只对少数困难请求进行扇出，并且（b）融合更便宜的 成员，比你正在取代的前沿模型。

延迟 — arbiter: { strategy: first } 加上一个严格的 max_latency_ms 参数，可在硬性上限内提供 N 个选项中最快的结果。

质量 — 开放工作中使用 best_of_n，有测试套件时依据 tests_pass。samples 和 thinking_budget_tokens 可在单次推理中获取更多。

在不破坏生产环境的情况下操作它。

路由更改令人担忧，因此该领域特定语言内置了站点可靠性工程师所期望的安全护栏：

每次保存时进行 lint — 包括 schema、CEL 类型检查（每个 when: 必须计算为 bool）、引用解析、旋钮范围、头部/参数黑名单。错误返回格式为 {line, column, message, rule}，并在编辑器中显示为沟槽标记。

空运行 — 发送一个合成请求（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

那个端点位于表A的顶部——不是因为它找到了更好的模型，而是因为它将正确的模型分配给正确的请求，并在面板胜出的地方精确地融合面板。

开始撰写

能力的下一次跃升不必等待下一个检查点。它是一个你今天下午就可以编写的图谱：按难度路由，在困难尾部展开，判断或测试输出，当信心下降时级联。

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

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

前沿是一块面板。去打造属于你的吧。