端云协同模型路由方案

开篇：现状与难度

现状一句话

现在在做的，是「用大模型给 query 打难度 tag，再按 tag 把请求分给不同档位的模型」。 主线是 Qclaw 端云协同（L1-L8 难度分级）。

贯穿全文的主线

路由的收益来自「把简单请求给便宜模型」，但 cache 复用已经把单价压到了 0.1x。 所以任何路由决策必须先回答一个问题：省下的钱，有没有超过丢掉的 cache？

三条路线（三个方案）总览

全篇其实是三条路线在比，最后收敛成一个。下表是三者的定位与取舍对照。

三者的关系不是三选一，是演进 + 合并：

方案 A（现有主力，语义强但贵、有延迟）
        ＋
方案 B（本地快、零成本、已处理 cache）
        ↓  合并
方案 C = 维度3（定规则：什么时候允许切）
        ＋ 维度4（学选择：窗口内切给谁）

为什么 C 不是简单二选一：A 的均分略高但极差大（0.220），B 的极差最小（0.185）。 两者正好互补 —— 用 B 的快判定兜日常，用 A 的语义能力啃难题， 再用维度 3 的规则守住 cache，用维度 4 把「切给谁」从配置升级成学习。

维度 1：现有的「大模型打 tag 难度 → 路由」方案

机制链路

数据清洗 → GT标注（大模型打标，人工抽检）→ 模型PE → SFT微调 → 部署

链条很长：清洗 → 标注 → 人工 check 定 baseline → 小模型摸底 → 微调 → 部署测试， 每一步都要等上一步出结果，且重新打标就得重跑整条链。

当前实测效果

分类器准确率（1.7B）

H20 部署压测（qps=5）

服务映射：L1-L3 本地小模型 / L4-L5 云端小模型 / L6-L8 云端大模型 输出示例：{"level":"L4","task":"short_code_task","modality":["code","text"]}

优

• 端到端可控、可解释（打的是离散 tag，出错能复盘）
• 已经上线跑通，有真实压测数据
• modality/caps 能挡住硬错（视觉任务不会路由到纯文本模型）
• SFT 这一步收益极大：level 75.09% → 91.09%（+16pp），不能省

劣

• 准确率天花板已现（caps 不升反降）
• 无置信度输出，护栏无信号
• 判定本身 280ms+ 的开销
• 标注依赖大模型，成本高、规模小（3000 条）
• 只解决「判难度」，不解决「什么时候允许换模型」

判断

这条链路继续保留并作为 L1 层，但要做三处补强：加 confidence 字段、加缓存边界判定、加切换预算帽。 它的问题不是「该不该做」，而是「只做它不够」。

维度 2：OpenSquilla（本地、时延小）

详细版见 OpenSquilla-详细介绍.md（含完整输入输出契约），本节为汇报用精简版。

机制：四层路由栈（README 的「length/language/code」是简化说法，论文里远不止）

前三层是确定性过滤器 + 轻量分类器，第四层才是 LightGBM。 论文原话：「LightGBM is the cold-start matching engine, not the market itself」——它只是冷启动引擎，不是终局。

两个视角：论文版（C0-C3）vs 源码实现（R0-R3）

这里有一点需要先说清：

两者不矛盾：论文讲路由的架构思想，源码讲工程落地。 档位名不同是版本演进；模型映射不同恰恰证明了它的三层解耦有效 —— 换模型只改 YAML，档位定义不动，分类器不重训。

源码实现的三个关键（论文里没写，但决定了它能不能用）

1. 双流特征：390 维稀疏异构特征喂 LightGBM，1536 维 BGE 稠密向量喂 ONNX MLP，per-class α 融合。 其中 hist 通道把上一轮的路由决策也当特征 —— 天然防抖动。
2. 3-Head：Main(LightGBM 分类) + MLP(语义) + Aux(判断该不该升降档)。Aux 头是关键，它让「换不换模型」成为一个独立可学的决策。
3. 8 步后处理：模型输出只是起点，之后 8 步规则修正。Step 1/3/4/5/6 全是单向向上，唯一向下的 Step 2 默认关闭。 Step 7 是 KV-cache 防抖（默认关闭，待重训）。

输入（三层）

① 模型输入 x_t = (q, h_t) h_t 十项：当前观测、压缩+原始上下文、上下文压力、控制循环状态、可用动作、产物状态、工具历史、恢复状态、验证信号、最近路由决策 四类信号：路由决策信号（含 confidence、ranking margin）／工具调用信号（成功、错误、重试、恢复路径）／上下文管理信号（长度、压缩触发、丢弃证据）／验证与运行时信号（测试结果、judge、成本、延迟）

② 配置输入：default_tier=c1、confidence_threshold=0.5、kv_cache_anti_downgrade_enabled、 complaint_upgrade_enabled、upgrade_to_c3_compaction_enabled、provider_routing 绑定表

③ 反馈输入：router.feedback.submit { decisionId, rating: up|down|neutral }

输出（三种形态）

① 分档输出 C0-C3 + image_model

② 两种形态：k=1 输出单个模型；k>1 输出 proposer set P_t + 聚合策略 a_t B5 阵容 = deepseek-v4-pro + glm-5.2 + kimi-k2.7-code + qwen3.7-max，glm-5.2 聚合，quorum 3-of-4

③ 会话级三模式：direct / router / ensemble，CAS 写入（需 expectedRevision）， appliesTo: "next_accepted_turn" —— 变更下一轮才生效，不在中途改

实测

• README 口径（PinchBench 1.2.1，25 任务总量）：$0.688 vs $6.233（约 1/9），分数 0.9251 vs 0.9255
• 论文口径（per-task）：PinchBench 93.14 @ $0.0204，质量保留 99.77%，成本降约 90%； DRACO 52.33 @ $0.3729，质量保留 99.94%，成本降 43.15%
• 多模型：DRACO(Brave) 64.09 @ $0.1218，比最强单模型 Fable 5 质量 +2.03、成本 -90.8%

⚠️ 重大修正：它已经处理了 cache 问题

之前我们批评它「每轮切会打散 prompt cache」，这个批评过时了。配置里有两个字段：

kv_cache_anti_downgrade_enabled = true
kv_cache_anti_downgrade_window_seconds = 600   # 10分钟内禁止降级
upgrade_to_c3_compaction_enabled = true        # 压缩后允许升C3

即：每轮评估 + cache 感知闸。我们用「只在边界切」规避，它用「时间窗口内禁止降级」规避，目的一致。 加上 appliesTo: next_accepted_turn，它其实是 cache 友好的。

亮点

1. 纯本地跑，提示词不出机器 —— 隐私 + 零 API 成本 + 零网络延迟
2. 路由决策本身不消耗 token —— 传统 ML 分类器，不是再调一次大模型
3. 只在最高档开 ensemble —— 成本分层极干净
4. complaint_upgrade：用户抱怨一次自动升一档（限 1 档、限 160 字符）——用真实反馈在线纠偏

与维度 1 的对比

劣

• 便宜优先无质量门控 —— 候选全不够格时的行为论文没说清
• 多模型模式 token 涨 5.6x、p50 延迟涨 3x，只适合离线批处理
• benchmark 全是 agentic 任务，我们的知识库/报告场景需自测，且无中文评测
• 依赖 ONNX Runtime + LightGBM 原生库（macOS 要 libomp），加载失败会静默降级为直连单模型——你可能不知道它已经不路由了

判断

价值不在分类精度（维度1 语义更强），而在于三点： ① 路由决策可以不花 token 钱、不外传、不加延迟；② 输入应该看 harness state 而不只是 query； ③ cache 保护和用户抱怨兜底这两个工程细节，我们直接抄。

建议直接吸收：kv_cache_anti_downgrade 时间窗口（与我们边界切叠加：边界切决定何时能改， 时间窗口决定改的方向不能是降级）、complaint_upgrade、分档决定是否值得开 ensemble。

关键实测：双方案端到端对抗（维度 1 vs 维度 2）

这是目前唯一一组两条路线直接对抗的数据。四个模式同跑同一测试集，10/10 全部完成。 评估维度：relevance / correctness / completeness / usefulness。

原始结果

有一点必须诚实：均分前三名的差异在噪声内，不能当结论用

• 大模型方案 vs router 差 0.012（相对 -2.9%）
• 以极差 0.22 粗估 sd≈0.055、n=10 的标准误≈0.017，这个 0.012 只有 0.69 个标准误
• 也就是说：0.409 / 0.397 / 0.385 这三个数在统计上分不开
• router 比 baseline-glm5.2 高 0.012，同样是噪声量级

唯一够得上显著的信号是 baseline-flash：0.355，比前三低 7.8%~13.2%， 且极差 0.275 全场最大 —— 全用小模型确实明显更差，也更不稳。

更稳妥的结论是：「两个路由方案都『不劣于』全用强模型，而成本更低」， 而不是「大模型方案赢了」。前者站得住，后者会被人一问就穿。

但方向上的信息是真的，而且比均分更有价值

① 「越大越好」不成立 —— 强模型在简单题上是负资产

这条由失分分析给出，比均分可靠得多。上限模型失分集中在三类：

这三条是同一个病：模型越强，越倾向于「多做一点」和「给确定答案」。 而在需要克制、需要先答通用核心的题上，这恰恰是减分项。

→ 结论：在当前评估体系里，更小或更对口的模型反而更好。

② 路由第一次拿到了质量侧的论据，不只是成本侧

之前我们讲路由，卖点一直是省钱。现在可以多一条： router 用更低的成本，拿到了不低于全用强模型的分数（0.397 vs 0.385）。 即「降本 + 不降质」同时成立。这个论据比以前硬。

③ 极差是比均分更实的指标 —— router 最稳

• router 极差 0.185，比大模型方案（0.220）小 15.9%，比 baseline-flash（0.275）小 32.7%
• router 甚至比全用强模型（0.191）还稳
• 原因很可能是：路由按难度分配后，简单题不会被强模型过度发挥搞砸，输出更可控

→ 建议：把极差（稳定性）列为第二主指标，跟均分并列。 以前我们只看均分，这条漏了。

对主方案的四条影响

1. 简单题主动降级，从成本策略升级为质量策略。 以前降级是为了省钱、要小心掉质量；现在有实测支持：简单题交给小模型，分可能更高。

2. 给强模型加「克制」约束。 三类失分都指向过度发挥。提示词层面可以显式要求：先答通用核心、 不做未经证实的承诺、不确定时说不确定。这比换模型便宜。

3. 评估体系要补「克制」维度。 现在四个维度（relevance / correctness / completeness / usefulness）全是正向的「多给」， 没有任何一项惩罚「给多了」。实测里强模型因话太多失分，说明评测方其实在惩罚， 但这个信号被均分掩盖了。建议显式加一项 conciseness / 过度回答惩罚。

4. 两个方案合并的必要性被数据支持了。 大模型方案均分略高但极差大，非大模型方案极差小但均分略低 —— 正好互补。 维度 3 的合并思路（用非大模型的分类器做快判定、用大模型的语义能力做难判定） 在数据上有依据，不只是理论推演。

必须标注的两个不确定性

• 样本量 n=10 太小，且自述多轮测试集存在不稳定性。结论只能当方向，不能当定论
• 难度分布未知：如果这 10 题里简单题占比高，结果天然偏向小模型。 换一个难度分布，结论可能反转 → 需要按难度分层看结果（这条已进待确认）

维度 3：合并推荐方案（缓存边界切 + 场景级兜底）

为什么是这两个

• 缓存边界切：只在 cache 本来就要丢的时点重路由，其余沿用。保住 82%-98% 的命中率。
• 场景级兜底：场景整体切换时由 sub-agent 承接，新 sub-agent 天然无 cache，切换成本为零。

零成本切换窗口（三个）

1. 会话首轮
2. 上下文压缩（session compaction）后
3. 场景切换（新 sub-agent 独立上下文）

成本算账（核心论据）

同一个 10 轮会话，每轮 +4K 上下文，全价 30 元/百万、缓存价 3 元/百万（0.1x）：

为什么每轮切和不路由一样贵？ 小模型价格是大模型的 0.1x，命中缓存的价格也正好是 0.1x。 所以「贵模型+命中缓存」和「小模型+缓存全失效」成本完全相同，但前者质量高得多。 每轮切成小模型，等于拿质量换了一个本来就存在的折扣 —— 白换。

五层架构

L0 安全前置      → 凭证/越狱/停止指令，最高优先级，直接短路
L1 难度分级      → L1-L8（复用维度1的分类器，只判定不执行）
L2 场景路由      → 决定是否派生 sub-agent
L3 能力画像选型  → F0-F6 加权打分选模型
L4 服务路由      → 同模型多供应商，按健康/成本/延迟切换（新增层）
护栏             → 置信度阈值 + 级联兜底 + 切换次数预算帽

关键设计参数

• 切换预算帽：单会话 ≤3 次（紧急升配豁免）
• 迟滞区间：升级 +2 / 降级 -3（防抖动）
• 上下文自适应：<8K 跨 1 档即切；8K-32K 跨 2 档；>32K 仅场景切换
• 默认动作是「不动」，不是「重新评估」

与维度 1/2/4 的关系

• 复用维度 1 的分类器（不重新训练）
• 吸收维度 2 的本地化思想（简单判定不上语义模型）
• 补上两者都缺的「什么时候允许换」
• 与维度 4 是接力关系不是竞争：本层定「什么时候允许切」的规则， 维度 4（DeleGate）在被允许的窗口里把「切给谁」从静态配置变成可学习组件。 即维度 3 管闸门，维度 4 管闸门内的选择质量。

维度 4：DeleGate —— 端到端 RL 训练 model router

沿用内部代号 DeleGate（强控制器 + 可学习委派接口）。 汇报只讲三块：主张 / 三样能立刻抄的 / 落地路径。 架构、协议、训练配方等细节挪到 4.5 备查，被追问时再翻，不主动讲。

4.1 主张：强控制器 + 可学习委派接口

一句话：把握全局的应当是强模型。

让 frontier 模型当 controller 做任务分解、上下文封装、质量把关、最终合成； 把「为某个子任务选哪个执行模型」封装成一个可调用的工具接口， 接口内部由一个轻量可学习 selector 完成选择。

判断力密集的环节（分解、封装、验收、合成）留给强模型； 适合统计学习的环节（能力与价格的匹配）交给 selector。

为什么不是另外两条路：

• 基于固定 MAS 结构做模型分配不现实 —— 编排工作流预先固定，搜索空间就被锁死， 路由退化成「给既定 role 分配模型」。但真实任务的分解方式因请求而异。
• 让弱模型统领全局不行 —— 判断「这个子任务是否超出便宜模型的能力」， 要求评判者的能力天花板高于被评判的任务，弱模型系统性做不好这件事。

定位为原语：model selection 是 orchestration-agnostic 的原语。 编排方案（单 agent 循环 / subagent 树 / 图式 MAS）可以随生态演化， 但「给定任务决定哪个模型来做」永远存在。

4.2 与维度 3 的关系：两级接力（不是竞争）

        ┌───────────────── 维度 3：闸门层 ─────────────────┐
        │  决定「什么时候允许换模型」                        │
        │  依据：缓存边界（首轮 / 压缩后 / 场景切换）        │
        │  输出：允许 or 不允许                              │
        └────────────────────┬─────────────────────────────┘
                             │ 允许切换的窗口
                             ▼
        ┌───────────────── 维度 4：选择层 ─────────────────┐
        │  决定「在这个窗口里选谁」                          │
        │  依据：DeleGate selector（可学习）                │
        │  输出：具体 worker（档位）                         │
        └──────────────────────────────────────────────────┘

一句话讲清关系：维度 3 管能不能切，维度 4 管切给谁。 维度 3 用规则守住 cache 不丢，维度 4 在守住的窗口里把「选谁」从静态配置升级成学习。

为什么 DeleGate 不违反维度 3 的 cache 约束（这是上一版我判错的地方，必须讲清）：

委派发生时，worker 拿到的是 controller 封装的独立上下文， 换 worker 根本不碰 controller 主对话的 KV cache。 它的路由单位是「每次委派」，而委派本身就落在维度 3 的第三个零成本窗口里 （新上下文，本来就没有 cache 可丢）。

→ 所以它不是「每轮切」，是踩在允许切换的窗口上切。

它还是维度 3「场景级兜底」那条线的学习化升级： 我们场景级 sub-agent 的模型选择是静态配置；DeleGate 把它变成可学习。 文档自己写明：与 Claude Code subagents 形态相同，本方案是其自然的学习化升级。

适用前提（要诚实）：只在 agentic 场景成立——必须存在「强 controller 分解 + 委派」结构。 单轮问答、纯 chat 没有委派，用不上。它是 Qclaw/QClawX 这类场景的演进方向，不是通用路由的全部。

4.3 完整流程图 + 举例

流程（七步）

①  用户请求
      ↓
②  Controller（强模型）推理，遇到适合外包的子任务
      ↓
③  调 delegate(spec, context, requires, constraints)
      ↓
④  Pool card 做可行性过滤 → 候选 worker 集
      ↓
⑤  Selector 双塔打分：效用 = 预估质量 - λ × 预估成本
      ↓
⑥  选中 worker 执行（信息不足可 ask-back 回问，上限 1-2 轮）
      ↓
⑦  结果 + 元信息回到 Controller → 验收 / 重试 / 接管 → 合成最终答案
      ↓
   全过程落盘 → 训练日志 → 反哺 selector

举例：一次销售数据分析

用户：「帮我分析这三个月的销售数据，找出下滑原因，写一份给管理层的汇报。」

Controller（强模型）接手后自己不干细活，拆成三个子任务分别委派：

成本对比：全用 C3 要付三份溢价；路由后只有子任务 ③ 付高价。 质量对比：子任务 ① 交给强模型反而可能失分——实测里「简单题话太多、 自加误导承诺 + 幻觉虚构」正是上限模型的三类失分之一。这题给小模型，分可能更高。

ask-back 举例：

子任务 ① 的 worker 只拿到了 CSV 表头和前几行（部分上下文原则）， 发现没有月份字段，于是返回 need_context("需要日期列或月份标识") 而不是硬算。 Controller 补上正确的日期列，worker 继续，一轮解决（上限 1-2 轮）。

这一步的价值：把「上下文封装错了」从必须事前做对降级成事前给初值、事后可修。 而且 ask-back 率本身就是指标——某个 spec 模式老是回问，说明 controller 的封装 prompt 该修了。

4.4 三样能立刻抄的（不依赖 RL，现在就能做）

① 只暴露档位，不暴露型号

• 做法：委派接口只告诉 controller「这是 C2 档、擅长多步编码、价格档中」，不告诉它具体型号
• 为什么：保住 pool 可热替换——controller 不知道型号，换模型时不需要改 prompt
• 佐证：DecisionBench 观察到 orchestrator 以 1.5 至 3.7 倍于随机的比例偏向同厂商模型 （一旦 controller 知道型号，就会形成品牌捷径）

② worker card 文本编码做冷启动

• 做法：新模型上线时，用它的能力描述文本过一遍编码器，直接得到先验向量
• 为什么：新模型不用等数据积累就能参与路由
• 配套：在线更新时冻结编码器，只更新那 M 个 worker 向量 → 自由度极小，便宜且不会灾难性遗忘

③ ask-back 协议 + ask-back 率监控

• 做法：worker 信息不足时返回 need_context 而不是硬输出，硬上限 1-2 轮
• 为什么：把「封装错了」从致命错误变成可修复的小错
• 附加收益：ask-back 率是一个零成本的可观测指标，直接反映 controller 封装质量

另有一条兜底原则，可直接写进维度 3 的护栏层： 低置信时升档，而不是赌便宜档 —— 把误判成本封死在「多花钱」一侧。 这与维度 3 护栏层的方向完全一致（正确性支配成本）。

4.5 落地路径（三步，每步独立可评测）

为什么现在不上 V2：不是杀鸡用牛刀，而是 V2 的前提是 V1 那笔全矩阵开销 （N 个 spec × M 个 worker 全跑一遍），在模型池定型前花不值。

建议顺序：先做 MVP 的日志管道（这一步零风险，且早晚必须做） → 模型池与 controller 稳定后再上 V1 → 最后才谈 V2。

4.6 技术细节备查（Q&A 用，不主动讲）

delegate(
  task_spec:   str,          # controller 撰写的自包含子任务描述
  context:     list[Item],   # controller 挑选的上下文片段
  requires:    list[enum],   # 能力需求标志，用于可行性过滤
  constraints: {budget_usd, latency_s, output_schema}
) -> {
  result, cost_usd, n_askbacks,
  meta: {worker_tier, exec_stats}   # 只暴露价格档位，不暴露型号
}

select(task_spec, context_view, requires, constraints, catalog)
-> { choice: worker_id | ABSTAIN, q_hat, c_hat{p50,p90}, propensity, alternatives }

学术侧对照（与本方案不同路线）

Router-R1（UIUC，arXiv:2506.09033） —— router 本身是一个 LLM - 交替执行 think（内部推理）和 route（调用模型），把每次响应整合进演进的上下文 - 三段式奖励：format + final outcome + cost reward（惩罚过度使用贵模型） - 只靠模型描述符就能路由到训练时没见过的第 11 个模型，无需重训 - 效果：7 个 QA 基准超所有基线；EM 0.409(Llama) / 0.416(Qwen)；α=0.6 是较好的平衡点 - 多跳 QA 上平均调用次数显著高于普通 QA —— 说明它学会了判断任务难度

DialRouter（arXiv:2604.12385，2026.04） —— 针对多轮对话的 myopic 问题 - MCTS + 用户模拟器探索对话分支，用 reward model 评估累积回报，再 Behavior Cloning 蒸馏成轻量 policy - 配检索式未来状态近似，实现推理时无需再搜索 - 把 KV cache 复用写进了奖励函数 - 效果：成本降约 80%，成功率降到 88.69%

与 DeleGate 的路线差异：Router-R1 是「router 即 LLM（生成式）」， DeleGate 是「selector 即 encoder（表征 + 打分，非生成）」，并明确把 LLM 判断式降级为对照基线。 DeleGate 选后者的理由是可时延、可在线更新、可处理未见目录条目。

维度 5：前沿方法详解（精选 5 个）+ 示例

选这 5 个的理由：它们不在同一层，是五个粒度，可以摞起来用

按路由粒度从细到粗排，正好对应前面四章已经出现的四个层级。 这个顺序说明的是「不是五选一，是五层串联」。

5.1 FrugalGPT   query 级 · 级联        ← 最经典，也是我们的反面教材
5.2 RouteLLM    query 级 · 学习型       ← 数据驱动的代表
5.3 CASTER      sub-task 级 · 双信号    ← 对应维度 4 的委派粒度
5.4 HyDRA       会话级 · 缓存边界       ← 对应维度 3 的主线依据
5.5 腾讯云       服务级 · 网关          ← 对应 L4 服务路由层

5.1 FrugalGPT（Stanford, 2023）—— query 级级联，最经典也最容易踩坑

• 机制：小模型先答，打分器判合格就收，不合格逐级往上抬
• 亮点：思路最简单、工程最好落地，是绝大多数团队第一个想到的方案
• 效果：98% 的成本下匹配 GPT-4 性能
• 示例：用户问「帮我写个快排」→ GPT-3.5 先答 → 打分器判不合格 → 升 GPT-4 重答
• 为什么重点讲它：因为它是我们的对照组。讲清楚它为什么不够，才能说明维度 3、4 的价值
• 三个坑： 1. double billing —— 失败那次的钱已经花了，省不回来 2. 错误的中间步骤会污染共享上下文，误导后面所有 agent（CASTER 的批评，在 MAS 场景是硬伤） 3. reactive 试错 vs proactive 预测：预测付一次钱直接给对模型，级联要付两次且错误已进共享状态
• 结论：单轮、无共享上下文、无工具链的场景可以用；agentic 场景必须限制在 sub-agent 内部、污染不外溢

5.2 RouteLLM（LMSys, 2024）—— 把人类偏好变成可训练信号

• 机制：4 种 router（MF / SVM / BERT / Causal LLM），用 Chatbot Arena 的人类偏好数据训练
• 亮点：不需要人标注「这个 query 该给谁」，只需要「两个答案你更喜欢哪个」—— 后者便宜得多
• 示例：Arena 上同一问题两个模型的答案，人类选了 A → 这条偏好直接变成一条训练样本
• 效果：大模型调用降 40-75%，质量基本无损
• 坑：偏好数据是为单轮主观对话设计的，agentic 多步推理要的是客观精确性，不是「更喜欢哪个」
• 对我们的用处：它的思路可以迁移 —— 线上 A/B 里「用户采纳了哪个答案」就是免费偏好信号，比人工标注便宜

5.3 CASTER（arXiv:2601.19793, 2026.01）—— sub-task 级双信号

• 全名：Context-Aware Strategy for Task Efficient Routing
• 机制：MAS 图结构中每个子任务独立分模型。双信号 router = 文本分支（embedding 语义）+ 结构分支（agent 角色、图位置等元特征）
• 关键洞察（建议作为本节的记忆点）：

  同一个 prompt 在「最终汇总」节点和「中间格式整理」节点的重要性完全不同 —— 前者错了全盘皆输，后者下轮还能改。 纯语义看不出这个差别，必须把结构信号喂进 router。

• 效果：成本降 72.4%，成功率持平全 GPT-4o；软件工程域比 FrugalGPT 还省 48%
• 反直觉发现（我认为这是全篇最值钱的一条之一）：
• naive 随机探索会污染训练数据 —— 随便把任务分给弱模型，它做砸了你就贴个「难」的标签， 但可能是弱模型太弱、不是任务难
• 后果：训出来的 router 系统性高估难度，最后把所有任务都发给强模型，路由等于白做
• 正解：用 performance divergence（强弱模型的表现差异） 标注难度 —— 强对弱错才算真难
• 对我们的用处：直接写进数据飞轮的标注规范（8.4 节）；路由输入建议补 agent_role / graph_position 字段
• 另一条批评要记住：简短但重逻辑的 prompt 往往比一段长摘要更需要推理力，按长度判难度是肤浅指标

5.4 Copilot HyDRA（2026.06）—— 缓存边界 + 先筛后选（维度 3 的直接依据）

• 双信号：实时模型健康（可用性/利用率/速度/错误率/成本）+ 任务意图（推理深度/代码复杂度/调试难度/工具编排需求）
• 核心机制「先筛后选」：先筛出能满足质量要求的候选集，再在候选集里挑最便宜的
• 与 OpenSquilla「便宜优先」的本质分歧：候选集里没一个够格时， HyDRA 选最强的（宁可贵），便宜优先会继续选最便宜的（质量崩）
• 这一条是我们护栏层设计原则的直接来源
• 可调运行点（训的是一条帕累托前沿而不是固定策略，换阈值就服务不同用户群）：

  运行点	成本节省	质量
  Peak 峰值	12.9%	超过 Sonnet
  Cons. 保守	省 3.3x	SWE-bench 70.8%，与 OpenRouter Auto 持平
  Agg. 激进	72.5%	质量与性能平衡

• 配套 harness（收益不比路由本身小）：prompt caching 在 VS Code 达 ~94% 命中； deferred tool loading 让中位数用户 token 降 ~18%（工具越多省得越多）
• 示例：一个挂了 40 个 MCP 工具的会话，每轮只加载真正用到的 2 个 schema → token 直接降 18% —— 这提醒我们：少塞上下文可能比路由本身更省钱
• 对我们的用处：维度 3 主策略的直接依据；帕累托前沿这个设计可以直接抄

5.5 腾讯云 AI 网关（2026.06）—— 工程视角，我们 L4 层的现实参照

• 视角差异（一句话点破）：学术方案默认「你有一个应用要加路由」； 腾讯云面对的是「一个企业 20 个 Agent、6 家厂商、5 个团队，怎么统一管」
• 五大策略：权重 / 模型名（逻辑名解耦）/ 语义（阈值默认 0.75）/ 延迟优先 / Token 长度
• 最值得抄的一条：语义路由用独立子请求调意图识别，识别服务挂了主链路照常跑 → 解决了所有智能路由共有的「路由器自己成为单点故障」隐患
• 延迟路由的细节：容量有限时用随机二选一（power-of-two-choices）而不是选当前最快的 —— 否则所有请求会涌向同一个节点，把它打成最慢
• 三层高可用：L1 配额感知预切换（余量 <10% 主动切，覆盖「健康检查全绿但 GPU 已满载」的软故障， 这是传统健康检查的盲区）→ L2 服务内切换 → L3 跨服务切换
• 局限：是服务水平路由不是推理质量路由，只有 5 类粗粒度意图，无难度分级无能力画像
• 对我们的用处：三份企微文档都缺这一层，L4 服务路由层直接参照它设计

其余 5 个：一句话速览（不展开，留作 Q&A 备用）

若被追问「还有别的方法吗」，这张表可作补充，既显完整又不占篇幅。

维度 5 的收口（一句话）

这五个不是竞争关系，是五个粒度： - FrugalGPT / RouteLLM 管「单个 query 给谁」 - CASTER 管「MAS 里每个子任务给谁」 - HyDRA 管「一个会话什么时候允许换」 - 腾讯云管「流量怎么分、故障怎么兜」

它们可以同时上，各管一层。 这也解释了为什么前面维度 3 和维度 4 不冲突。

实现规划路线

前面五章回答「选什么」，这一章回答「怎么一步步做出来」。 排序原则只有一条：风险递增、每期独立可验收、任何一期停在这里都不亏。

设计路线时的四个前提（先说清楚，否则排序不成立）

1. 先观测后动手。所有路由方案的成本收益都建立在「cache 命中率」和「难度分布」两个数上， 现在这两个数没有。在算不清账之前改路由，等于闭眼调参。
2. 先建闸门后选模型。维度 3 的规则层（什么时候允许切）不依赖任何模型选型， 且它是后续所有策略的安全边界。闸门没建就切模型，出事无法归因。
3. 按风险递增排序：服务路由（零质量风险）→ 规则降级 → 学习型选择 → RL。 反过来做，任何一步出错都会连带推翻前面。
4. 标注规范必须 P0 就定死。数据一旦按错误方式采，后面全会系统性跑偏 （CASTER 实证：naive 探索会污染标签，导致路由器高估难度，最终把所有任务都发给强模型，路由白做）。

五期路线总览

关键路径：P0 → P1 → P2 → P3 → P4（串行） 可并行：评测体系修复（全程）、数据集扩充（P0 起）、模型池梳理（P0-P1）

P0 · 可观测与基线（约 2-3 周）

为什么排第一：这是全案唯一「零风险且不做就永远做不成」的一步。 现在回答不了「一次会话多少钱」「cache 命中率多少」「简单题占几成」， 那么 P2 之后所有降幅承诺都是拍脑袋。

做什么

1. 调用日志管道（最重要，其他都能等） 每条请求必须落这些字段，缺一不可：

session_id / turn_index        → 会话位置（判断是否处于 cache 边界）
scene_tag / agent_role         → 场景与角色（维度 3 的 L2 用）
model / provider / endpoint    → 实际走的模型与供应商
prompt_tokens / completion_tokens
cache_read_tokens              ← 必须单独采，没有它成本模型是空的
cache_creation_tokens
latency_p50 / latency_total
cost_estimate                  → 按当前单价折算
safety_flag                    → L0 命中情况

cache_read_tokens 是这一期的命门。OpenSquilla 实测 cache 命中率 98.1%， Qclaw H20 压测 82%-98%，我们的真实值是多少现在是黑箱。 拿不到这个数，第 3 章那笔「每轮切 ¥6.60 vs 缓存边界切 ¥1.74」的账就永远是纸面推演。

2. 成本基线看板 单次会话成本中位数 / P90、按场景拆分、按难度拆分（如果有标注）、cache 命中率趋势。

3. 评测集 从真实日志分层采样（不要随机采，随机采会被高频简单题淹没）， 规模建议 300-500 条起步，覆盖：短指令、长上下文、多轮追问、工具调用、开放推理五类。

4. 标注规范（与数据采集同步定，不能等） 正确做法是用强弱模型表现差异（performance divergence）标注难度： 同一个 query 让强模型和弱模型各跑一次，强对弱错才算真难。 不能只看弱模型的绝对表现——它做砸了可能是它自己太弱，不是任务难。

5. 评测维度补一项 当前是 relevance / correctness / completeness / usefulness 四项，全是正向的「多给」， 没有任何一项惩罚「给多了」。而实测里强模型恰恰因话太多失分（自加误导承诺、幻觉虚构）。 建议显式加 conciseness / 过度回答惩罚，否则这个信号会一直被均分掩盖。

出口判据（Gate 0）

• [ ] 能回答：单次会话成本中位数、cache 命中率、难度分布、场景分布
• [ ] 评测集 ≥300 条且分层覆盖五类
• [ ] 标注规范文档已定稿并完成一轮一致性抽检
• [ ] 日志字段完整率 ≥99%（缺字段的日志等于没有）

风险与不做清单

• 不做任何路由改动，纯观测，线上零影响
• 风险：日志量导致的存储成本（建议采样 + 冷热分层）
• 常见坑：只记录「调了哪个模型」不记录「为什么调」，后期无法复盘

P1 · 闸门与护栏（约 3-4 周）

为什么排第二：维度 3 的规则层不依赖任何模型选型， 而且它是后续所有策略的安全边界。闸门没建就切模型，出 badcase 无法归因、无法回滚。

做什么

1. L0 安全前置（最高优先级，直接短路） 凭证/越狱/停止指令识别，命中即短路，不进路由逻辑。

2. L4 服务路由（本期的性价比之王） 同模型多供应商切换：按健康、成本、延迟选 endpoint。

这是全案风险最低、见效最快的一步，理由是： 它换的是同一个模型的不同供应商，不改变模型能力， 所以对质量零影响，但直接带来可用性提升和单价优化。

抄腾讯云的三层高可用： - L1 配额感知预切换：余量 <10% 主动切，专门抓「健康检查全绿但 GPU 已满载」的软故障 - L2 服务内切换 / L3 跨服务切换 - 延迟路由用随机二选一（power-of-two-choices）而不是选当前最快， 避免所有请求涌向同一节点把它打成最慢

抄腾讯云最关键的一条：语义路由用独立子请求调意图识别，识别服务挂了主链路照常跑。 路由器自己绝不能成为单点故障。

3. 护栏层 - 切换预算帽：单会话 ≤3 次（紧急升配豁免） - 迟滞区间：升级 +2 / 降级 -3（防抖动） - 上下文自适应：<8K 跨 1 档即切；8K-32K 跨 2 档；>32K 仅场景切换 - 置信度低于阈值 → 升档而不是赌便宜档（把误判成本封在「多花钱」一侧） - 默认动作是「不动」，不是「重新评估」

4. 影子模式（shadow mode） 路由决策只记录不下发，与线上实际结果对比。这是 P2 灰度前的必过环节。

出口判据（Gate 1）

• [ ] 影子模式跑满 2 周，决策日志完整
• [ ] 护栏触发率在预期区间（触发过多说明阈值太敏感，过少说明形同虚设）
• [ ] L4 服务路由已实切，无 P0/P1 事故
• [ ] 一键回滚开关可用且演练过

风险与不做清单

• 不做任何模型降级（本期只建闸门，不切档位）
• 风险：护栏阈值初始拍脑袋，需 P2 灰度中校准
• 常见坑：影子模式只记决策不记「如果真下发会怎样」，等于没影子

P2 · 分级路由上线（约 4-6 周）

为什么排第三：闸门和护栏就绪，才有条件动模型档位。 本期复用维度 1 已有的分类器（不重新训练），成本最低。

做什么

1. 分类器接入 维度 1 分类器输出 level/task/modality，映射 L1-L8 → 三档服务。 注意实测教训：level 从多数投票 75.09% 涨到 6-level 91.09%， 但 caps 从 85.88% 反而降到 85.34%——继续细分等级精度不涨， 所以不要在这一期追求更细的分级，先跑通链路。

2. 只在零成本窗口切 会话首轮 / 上下文压缩后 / 场景切换，这三个时点 cache 本来就要丢。

3. 抄 OpenSquilla 的三条 cache 感知设计 - kv_cache_anti_downgrade：时间窗口（600s）内禁止把已建立 cache 的对话降级到更弱模型。 与我们的边界切叠加——边界切决定何时能改，时间窗口决定改的方向不能是降级。 - appliesTo: "next_accepted_turn"：路由变更下一轮才生效，不在中途改。 - complaint_upgrade：用户抱怨一次自动升一档，限一档、限 160 字符。 用真实反馈在线纠偏，成本几乎为零，比离线调阈值快一个数量级。

4. 灰度节奏 5% → 20% → 50% → 100%，每档至少观察一个完整业务周期，看质量分与成本双指标。

出口判据（Gate 2）

• [ ] 成本降幅达标（建议先设保守目标 ≥15%）
• [ ] 质量分不劣于基线（注意：实测前三名差异在噪声内， 所以判据应写「不低于基线减一个标准误」，不要写「优于基线」）
• [ ] 切换预算帽触发率 <5%
• [ ] 灰度全量后无 P0/P1 事故

风险与不做清单

• 不做每轮切（这是全案最大的反模式，见第 3 章算账）
• 不做级联降级（FrugalGPT 式）——除非能限制在 sub-agent 内部、污染不外溢
• 风险：分类器在中文场景的准确率基线未知，需先看影子模式数据
• 回滚：一键回退全强模型，开关已在 P1 备好

P3 · 本地化 + 场景兜底（约 6-8 周）

为什么排第四：P2 跑通后，路由决策本身的成本和延迟才会成为瓶颈 （维度 1 分类器判定时延 280-725ms）。本期把它变成毫秒级、零 token 成本。

做什么

1. 方案 B（OpenSquilla 式本地分类器）上线 LightGBM + ONNX，特征取 token 复杂度、语言、代码密度、上下文压力、工具历史等。 只管简单判定——能确定是 trivial 的直接给 C0/C1 档，不进语义模型。

2. 两级判定

本地快判定（毫秒级、零 token）  → 能确定 → 直接走
        ↓ 不能确定
语义慢判定（维度 1 分类器）      → 出 level + caps + confidence
        ↓ 置信度不足
默认安全档（升档，不赌便宜档）

3. 场景级 sub-agent 静态档位 各场景预设模型档位（对应 DeleGate 的 pool tier），兜住本地和语义都判不准的情况。

4. 抄 OpenSquilla 的 risk pricing 思路 第三层把上下文压力、工具失败、验证结果、恢复状态、动作不可逆性、下游纠正风险算进去。 这正好补上「按长度判难度是肤浅指标」的批评——简短但重逻辑的 prompt 比长摘要更需要推理力。

出口判据（Gate 3）

• [ ] 路由决策 P50 时延 <50ms（从 280-725ms 降下来）
• [ ] 路由本身零 token 成本
• [ ] 本地分类器覆盖率 ≥60%（即六成请求不进语义模型）
• [ ] 端到端质量分仍不劣于 P2 基线

风险与不做清单

• 不做多模型 ensemble 路由（OpenSquilla 实测：token 涨 5.6 倍、延迟涨 3 倍，只适合离线批处理，交互式开不得）
• 风险：ONNX Runtime / LightGBM 原生库依赖（macOS 需 libomp）， 加载失败会静默降级成直连单模型，你可能根本不知道它已经不路由了 → 必须加启动自检 + 运行期心跳告警
• 风险：无中文评测数据，本地分类器在中文场景表现未知 → 先影子模式

P4 · DeleGate 学习化（约 8-12 周起，建议立项验证）

为什么排最后：V1 的前提是「N 个 spec × M 个 worker 全跑一遍」这笔全矩阵开销， 在模型池定型前花不值。而且此时 P0-P3 已经把成本大头拿走了， 这一期争的是剩余部分的选择质量，属于精加工。

三步（每步独立可评测）

三样不依赖 RL、P4 之前就能抄的

1. 只暴露档位不暴露型号 —— 佐证：DecisionBench 观察到 orchestrator 以 1.5-3.7 倍于随机的比例偏向同厂商模型。若 controller 知道具体型号会形成品牌捷径， 模型池也就热替换不了了。这条建议 P1 就做。
2. worker card 文本编码冷启动 —— 新模型上线用能力描述文本过编码器就有先验向量， 不用等数据。在线更新时冻结编码器、只更新 M 个 worker 向量，自由度极小、不会灾难性遗忘。
3. ask-back 协议 —— worker 信息不足返回 need_context 而不是硬着头皮输出，上限 1-2 轮。 把「上下文封装错了」从必须事前做对，降级成事前给初值、事后可修复。 ask-back 率本身就是指标：某个 spec 模式问得多，说明 controller 的封装 prompt 该修了。

出口判据（Gate 4）

• [ ] MVP 阶段 spec 日志积累 ≥ 设计阈值
• [ ] V1 对比静态配置基线有统计显著增益（不是噪声内的差异）
• [ ] pool 热替换 30% 压力测试：应在 O(百次) 委派内恢复（静态方案需重训）
• [ ] 低置信时默认升档的行为已验证

风险（诚实列出）

• 标签天花板：以「与强参考模型一致」定义成功，参考模型的错误会注入标签
• 委派开销倒挂：小任务被接口往返吃掉收益
• spec 分布漂移：controller 静默升级导致
• 责任边界不干净：封装错还是选错，归因不清会污染信号

依赖关系（哪些必须串行，哪些可以并行）

                 ┌─────────────────────────────────────┐
                 │  并行轨道（不阻塞主链路）            │
                 │  · 评测体系修复（加 conciseness）    │
                 │  · 评测集扩充与标注                  │
                 │  · 模型池梳理与单价/配额摸底         │
                 └─────────────────────────────────────┘
                              ‖
  P0 观测基线 ──→ P1 闸门护栏 ──→ P2 分级路由 ──→ P3 本地化 ──→ P4 DeleGate
   零风险        极低风险         中风险          中风险        高风险
  看清现状       建安全边界       成本兑现        决策免费      选择质量
     │              │               │              │             │
   Gate0          Gate1           Gate2          Gate3         Gate4

关键路径说明：P0-P4 必须串行，因为后一期的出口判据依赖前一期的产出数据。 但并行轨道全程不阻塞，且评测体系修复越早越好——它决定了所有 Gate 的质量判据是否可信。

明确不做清单（避免范围蔓延）

里程碑与检查点

需要提前备好的资源（不备会卡住某一期）