Skip to main content

ACRouter：把每次执行结果回流成下一次的路由经验

Paper Info​

Overview​

  1. 核心问题：用户手头有多个 LLM，没有模型在所有代码维度都占优，但现有路由器把模型路由当成一次性静态分类，部署后即冻结，无法利用每次任务的真实执行结果。

  2. 诊断结论：瓶颈在信息缺失，不在推理能力——给零样本路由器补上维度级历史性能统计，平均性能从 41.41% 升到 47.74%，相对提升 15.3%，并超过编码同样信息的启发式路由。

  3. 方法框架：路由被形式化为 Context → Action → Feedback 循环；路由器读上下文选模型，沙箱验证分数和成本写回上下文，等价于上下文多臂老虎机，用累计遗憾衡量与逐任务最优选择的总差距。

  4. 系统实现：ACRouter 由 Orchestrator、Verifier、Memory 组成：Orchestrator 综合微调小模型、维度先验和记忆近邻投票选模型；Verifier 用 AST 解析 + 沙箱执行打分；Memory 用任务向量检索十条最相似历史经验。

  5. 评测环境：CodeRouterBench 汇总十五个以上代码基准，共 10111 个任务、十类代码维度、八个前沿模型，并提供逐任务逐模型的验证分数矩阵，支持基于累计遗憾的流式对比。

  6. 主要结果：分布内 2919 个任务上 ACRouter 平均性能 49.98%、累计遗憾 205.5，优于拥有完整维度先验的 DimensionBest（47.50% / 277.4）；分布外智能体编程任务上达到 62.50%，超过永远用 Claude Opus 4.6 的 57.14%。

  7. 成本效率：ACRouter 每美元性能 3.79，永远调用 Opus 4.6 的基线是 1.29，路由带来的成本效率提升显著高于固定用最强模型。

  8. 反直觉发现：静态轻量分类器在分布内接近维度先验，到了分布外全部崩到随机水平以下；编码能力不等于路由能力，最强的 Opus 4.6 当路由器反而垫底（39.27%）；路由器参数从 0.8B 加到 27B 收益不到一个点。

  9. 系列定位：相比 AgentSwing 在执行前预测、FOREAGENT 在执行前预测候选、AHE 自动化 agent 外层 harness，ACRouter 补的是模型选择层的执行反馈闭环，与预测路线形成互补。

  10. 意义与边界：论文重新定位多模型系统的瓶颈——上限取决于能否从每次调用中学习；成本数字因厂商缓存不可观测只作相对参考，分布外评测用了四十步上限，C-A-F 还有更多实例化方式未探索。

核心内容解读​

问题：手上多个模型，到底给谁​

做 AI 应用的人基本都遇到过这件事：手上同时挂着好几个 LLM，一个写代码的需求进来，到底应该派给谁。直觉上"用最贵的那个"听起来对，但论文的实测结果很反直觉——就算每个任务都直接调用 Claude Opus 4.6，离"每个任务都选对模型"还差得很远。

论文在八个前沿模型上覆盖九类代码维度，没有发现任何模型全面占优。Opus 4.6 平均分最高，但算法设计输给 GLM 5，测试生成输给 Qwen3-Max，数据科学输给 KIMI K2.5。九个维度里五个有不同的"维度冠军"。这种细粒度差异，写死的静态规则根本覆盖不了。

现有的路由器做法有两种：

  • 写死规则：数据处理类任务固定派给模型 A，代码生成派给模型 B。
  • 训练一个分类器：读任务描述，直接输出模型名。

这两种做法有一个共同特点——部署之后信息状态就冻结。任务真实跑出来的结果永远不会回流到路由决策里。

冻结带来的后果有两个：

  1. 零样本路由和逐任务最优之间的差距很大；
  2. 换一个任务分布，路由器就会失灵。

诊断：瓶颈在信息缺失，不在推理能力​

论文做了一个非常直接的消融来回答"瓶颈在哪"——用同一个 Claude Sonnet 4.6 当路由器：

配置平均性能
零样本41.41%
+ 任务维度标签41.18%（几乎没变）
+ 维度级历史性能统计47.74%（相对提升 15.3%）

关键是最后一档——同样的零样本 LLM，同样的推理能力，只多了一组历史统计信息，立刻提升 15.3%，而且超过了编码同样信息的启发式路由。论文给出的结论很干脆：模型没换、推理能力没变，只是信息多了 6.33 个百分点。瓶颈在信息缺失，不在推理能力。

这个结论把后续方法的取舍空间缩小了：与其花大力气训练更"聪明"的路由器，不如把信息源想办法打通。

方法：C-A-F 循环​

既然瓶颈是信息缺失，那信息从哪来？总不能每次都靠人工统计。论文把路由流程改成一个持续运行的循环：

Context（任务 + 历史经验）
  → Action（选模型）
    → Feedback（沙箱验证分数 + 成本）
      → 写回 Context

作者把它叫 C-A-F 循环——Context → Action → Feedback → 回到 Context。每处理完一个任务，路由器都会用沙箱验证这一次的实际得分与成本，并把结果写回一个在线经验库。下一轮任务来的时候，路由器看到的就是更丰富的上下文。

这个循环对应到强化学习的视角就是上下文多臂老虎机：

  • 每个模型是一条 arm；
  • 当前任务是 context；
  • 执行结果是 reward，reward 里除了任务得分，还扣掉一小笔美元成本；
  • 衡量路由器好坏的自然指标是累计遗憾——逐任务最优选择的奖励减去实际选择的奖励，逐轮累加。

这把"路由器好不好"从单点平均分换成了时序指标——不止看平均结果，还持续惩罚每一次选错。

系统实现：Orchestrator + Verifier + Memory​

ACRouter 把决策拆给三个模块协同：

Orchestrator（决策器）：每轮综合三类信号投票——

  1. 一个在探测集上微调过的 Qwen3.5-0.8B 小模型（按任务维度查表选模型）；
  2. 维度先验（同一维度上历史最优模型）；
  3. 从经验库里检索出的十条最相似历史任务及其对应的模型选择。

三类信号加权打分，得分最高的模型被派出。

Verifier（验证器）：当任务没有标准答案时，需要一个能落地的评分机制。Verifier 是沙箱原生的——先做 AST 语法解析，再在沙箱里真实运行代码，并从任务提示里抽出内嵌的测试用例。这些信号按任务类型加权合成一个 0~1 之间的分数。关键是它不需要标准答案，全靠可执行的检查，所以部署时也能稳定拿到反馈。

Memory（经验库）：一个在线向量库。每个任务用代码专用的 embedding 模型转成向量作为键，向量库里同时记录了"当时选了哪个模型 / 得分多少 / 花了多少钱 / 验证轨迹是什么"。新任务来了就按余弦相似度找最像的十条历史经验，交给 Orchestrator。库容量上限 2 万条，FIFO；每轮决策完立刻写入经验，和最新任务分布保持同步。

这套机制有一个具体例子：一次修 bug 的任务进来，0.8B 小模型投票给 MiniMax-M2.7，逻辑回归分类器投给 GLM 5，但记忆检索出的相似历史任务普遍支持 KIMI K2.5——加权之后 K2.5 拿到 1.47 分明显高于另两个候选，于是被派出。它修好代码，沙箱重跑通过，这个成功又写回记忆，下次类似的修复任务就更有把握。

评测：CodeRouterBench + 累计遗憾指标​

为了让不同路由器之间的对比有意义，论文新搭了 CodeRouterBench：

  • 15 个以上常用代码基准；
  • 共 1 万 1 千 1 十一 个任务；
  • 覆盖代码生成、算法设计、缺陷修复、数据科学、测试生成等十类维度；
  • 八个候选模型各自把所有任务跑一遍，用沙箱执行或 LLM 评审打出分数。

有了这张"逐任务、逐模型"的完整成绩单，才能算出每个路由器相对逐任务最优的遗憾。这比单纯比较平均分严格得多。

主要结果​

分布内测试（2919 个单轮任务）：

路由器平均性能累计遗憾
ACRouter49.98%205.5
DimensionBest（手握完整维度先验）47.50%277.4
微调小模型路由较低较高
逐任务最优（理论上限）57%0

ACRouter 平均性能最高、累计遗憾最低，而且赢过手握完整维度先验的 DimensionBest——这意味着 C-A-F 循环从在线执行中学到的细粒度经验，能超过任何静态先验。

成本效率上，ACRouter 每美元性能 3.79，永远调用 Opus 的基线只有 1.29。

分布外测试（176 个智能体编程任务，来自 SWE-bench Verified 等真实仓库场景，路由器事先没见过这类数据）：

路由器平均性能
ACRouter62.50%
永远用 Opus 4.657.14%
微调小模型路由55.36%
静态分类器（逻辑回归 / 决策树等）9% ~ 21%

最刺眼的是静态分类器——在分布内还能接近维度先验，到了分布外全部崩到 9%~21%，连随机选择的 31.25% 都不如。

崩盘的根因是：它们学到的只是训练分布里的浅层对应关系，分布一换对应关系失效，又没有记忆可以在线修正。

三个反直觉发现​

第一，静态分类器在分布外全部崩盘。原因如上。

第二，编码能力不等于路由能力。论文让八个模型轮流当零样本路由器，编码最强的 Opus 4.6 当路由器反而垫底（平均 39.27%）——很可能因为 Opus 倾向于自己尝试复杂推理，没有"快速判断该派给谁"的路由习惯。路由模型需要的不是"会做事"，是"会看人做事"。

第三，路由器参数规模收益很快饱和。微调的 Qwen3.5 从 0.8B 加到 27B，平均分只涨约 0.5 个点。用 0.8B 的小模型当路由策略完全够用——这再次呼应了"信息比推理更关键"的诊断。

在 agent 系统视野里的定位​

把 ACRouter 和最近几期 agent 相关播客的工作摆在一起：

  • FORECAST / AgentSwing：在执行前预测任务该走哪条策略；
  • FOREAGENT：在执行前预测哪个候选值得运行，省执行预算；
  • AHE：自动化 agent 外层的 harness 组件；
  • ACRouter：承认执行信息不可替代，把每次执行结果存进记忆，模型选择层做执行反馈闭环。

ACRouter 跟前面三个不太在同一条线上——它是事后学习型，不预测也不在执行前筛候选，而是把执行结果回流进路由决策本身。和预测路线形成互补：先用预测筛出 2~3 个候选，再把执行结果沉淀下来供下次做更好的选择。

落到多模型系统的工程含义​

论文重新定位了多模型系统的瓶颈——路由器的上限取决于系统能不能从每次调用里留下可复用的经验，而不取决于分类器本身多聪明。工程上拆成三件事：

  1. 执行结果要验证——没有验证就没有可信信号；
  2. 验证结果要存下来——存不下来的信号留不下经验；
  3. 存下来的经验在下次决策时要能被检索到——检索不到的信号等于没存。

缺了任何一环，路由器就退化成静态猜测。

边界和待验证的部分​

论文自己列了几条限制：

  • 成本数字按公开 token 价格估算，厂商缓存命中率不可观测，所以只适合相对比较；
  • 分布外评测为了控制预算用了 40 步上限（标准是 250 步），绝对性能可能偏低估；
  • C-A-F 框架目前只用 LLM 策略 + 向量检索这一种实例化，其他实现（如基于规则、基于结构化日志、基于在线学习算法）没探索；
  • 附录里更新的 GPT 5.4 单独跑分布外能解 75%——后端模型进步很快，路由器的领先优势需要持续重新验证。

最后一句留给系统建设的同行：模型路由这道题，离线训练一个更聪明的分类器走不远。ACRouter 给出的答案是——让每次模型调用的真实结果，回流到下一次选择里。多模型系统的竞争，正从"谁的分类器好"转向"谁的闭环转得快"。

Resources​

Last updated on by Kimi Gao