你花 5 倍钱用 Claude Opus，结果在算法题上被 GLM-5 吊打 86%：NUS+阿里提出 Agent-as-a-Router，让 AI 自己学会"选将"

核心直觉：你以为订阅了最贵的 Claude Opus 4.6 就能通吃所有编程任务？数据显示，在算法设计题上 GLM-5 比 Opus 高 86%；在测试用例生成上 Qwen3-Max 比 Opus 高 111%。没有一个大模型是全能的——但现有 coding agent（Claude Code、Codex）却固执地只用单一模型。NUS、阿里达摩院、伯克利等联合提出的 Agent-as-a-Router（ACRouter）框架，把"路由哪个模型干活"本身做成一个智能体，通过 Context-Action-Feedback 循环在线学习，在 10 个 coding 维度上达到最低累积 regret，而且比一直用 Opus 省了 3 倍钱。

一、残酷真相：最强模型也有"死穴"

先看一组数据（来自论文 Figure 4，8 个 frontier LLM 在 9 个 coding 维度上的表现）：

Claude Opus 4.6 平均最强（42.9%），但在5 个不同维度上被 5 个不同模型超越。一直用 Opus 的代价是什么？

• 性能损失：在算法题上你只发挥了最佳模型 53% 的水平
• 成本爆炸：Opus 的总成本是 Kimi-K2.5 的 12 倍
• 机会成本：你花大价钱订阅的 GLM-5、Qwen3-Max 等模型，根本没用上

这引出一个核心问题：如果模型各有所长，为什么 coding agent 不自动切换？

二、现有路由器的盲区：不是推理差，是信息少

2.1 实验诊断：为什么 LLM-as-a-Router 表现差？

论文做了一个精妙的 ablation：用 Claude Sonnet 4.6 当 router，只改变给它的信息，看路由性能变化。

关键发现：

1. 告诉 router "这是算法设计题"（+Dimension）几乎没帮助——从 41.41 降到 41.18
2. 但告诉它 "算法设计题上 GLM-5 平均 47.2%、Opus 25.4%"（+Perf stats），性能飙升 15.3%
3. 有性能统计后，LLM router 甚至超过了基于同样信息的启发式 DimensionBest（47.74 vs 47.50）

结论：路由器的瓶颈不是推理能力（Claude Sonnet 4.6 足够聪明），而是信息缺失——它不知道每个模型在每个维度上到底表现如何。

2.2 静态路由器的根本缺陷

现有路由方法（RouteLLM、FrugalGPT 等）都是静态的：

• 训练时学一个分类器，部署时冻住
• 信息状态是固定的，看不到实时执行结果
• 无法积累"这个模型在这类任务上到底行不行"的经验

这就像让一个医生根据课本知识开药，但从不跟踪病人吃完后的反应——永远活在训练集的知识里。

三、Agent-as-a-Router：把路由做成智能体

3.1 C-A-F 循环：Context → Action → Feedback

论文的核心创新是把路由形式化为一个智能体循环：

┌─────────────────────────────────────────────────────────┐
│                    C-A-F 循环                            │
├─────────────────────────────────────────────────────────┤
│                                                         │
│   Context c_i ──→ Decide ──→ Action a_i ──→ Execute   │
│      ↑                                              │
│      └────────────── Feedback f_i ←── Verify ───────┘  │
│                                                         │
│   c_i = (任务 prompt, 元数据, 历史记忆)                │
│   a_i = 选哪个模型（从 8 个候选中）                     │
│   f_i = (执行得分, 花费成本)                            │
│                                                         │
└─────────────────────────────────────────────────────────┘

每个循环的验证结果（Feedback）会被写回记忆，让下一个循环的上下文（Context）更聪明。这和传统静态路由的根本区别：

3.2 ACRouter 的三模块架构

① Orchestrator（指挥者）—— 做决策

输入信号有三路：

• DimensionBest prior：各维度上历史最优模型（粗粒度先验）
• Memory kNN：从在线记忆中检索 top-10 个最相似的历史任务及其结果（细粒度经验）
• 任务元数据：维度、难度、语言等

核心策略：一个 fine-tuned 的 Qwen3.5-0.8B（对，就是 0.8B 参数的小模型）做主要决策，加上启发式规则做加权投票。

为什么用小模型当指挥者？ 因为 router 本身需要被频繁调用（每个任务一次），用 0.8B 模型在 H100 上自托管，每百万 token 成本仅 ＄0.054——比调一次 Claude API 便宜两个数量级。

② Verifier（验证者）—— 产信息

Verifier 是 ACRouter 的信息引擎。它不只返回"对/错"，而是综合多个信号生成一个统一分数 u_i ∈ [0,1]：

不同任务类型（dimension）有不同验证工具组合，权重也不同。比如算法设计题主要 sandbox 执行，代码理解题主要 LLM-as-Judge。

关键洞察：Verifier 产生的不是" ground truth 标签"（很多任务没有标准答案），而是执行层面的置信度信号——这正是 static router 缺失的信息来源。

③ Memory（记忆）—— 累经验

Memory 是一个在线向量数据库：

• Key：任务 embedding（用 voyage-code-3 或 BGE-large 编码 prompt）
• Value：选了哪个模型、执行得分、花费成本、Verifier 的完整验证 trace
• 检索：cosine kNN，top-10，相似度阈值 0.5
• 容量：FIFO 20K 条目，超出时淘汰最早的

Memory 的设计哲学：让 Orchestrator 在做新决策时，能看到"类似任务过去发生了什么"。这比静态的"维度最优模型"更细粒度——因为即使在同一个维度（如"算法设计"），简单题和难题的最优模型可能不同。

四、CodeRouterBench：为 router 量身定做的考场

现有 benchmark 无法评估 streaming router，因为：

• 大多数 benchmark 只测"单次准确率"，不测累积 regret
• 没有 pre-collected 的 per-task per-model 结果矩阵，无法计算 oracle 上限

4.1 Benchmark 构造

CodeRouterBench 包含 ~10K 任务，10 个 coding 维度：

数据划分：

• Probing set（7,080 任务）：用于开发 router——训练分类器、校准 DimensionBest、warm-start Memory
• ID Test（2,919 任务）：同分布的 held-out 测试
• OOD Test（176 任务）：完全不同的任务类型——多步规划、文件导航、迭代调试的 agentic 编程任务，router 在开发时完全没见过

4.2 模型池：8 个 frontier LLM

五、实验结果：ACRouter 全面领先

5.1 In-Distribution（同分布测试）

关键观察：

• ACRouter 是唯一 AvgPerf > 49% 的 router，比 DimensionBest 高 2.48%
• CumReg（累积 regret）最低：205.5，比次优的 DimensionBest 低 26%
• Perf/＄ 3.79，比一直用 Opus 的 1.29 高 3 倍——花更少钱，做更好决策
• 静态 fine-tuned 模型（Qwen3.5-FT）Perf/＄ 很高（6.82），但看 OOD 会出事

5.2 OOD（Agentic Programming，真正考验）

这是论文最震撼的结果：

静态 router（RouteLLM-BERT、LogReg、TF-IDF+MLP）在 ID 上还能接近 DimensionBest（差距 < 1.3%），但在 OOD 上全面崩溃——最低只有 8.93%，甚至低于 Random（31.25%）。

原因：这些 router 严重过拟合到训练分布。Agentic programming 任务和 9 个单轮 coding 维度根本不同（多步规划、文件导航、迭代调试），静态模型完全无法适应。

而 ACRouter：

• OOD AvgPerf 62.50%，超过 Always-Opus（57.14%）
• CumReg 仅 17.0，比 Always-Opus 的 26.7 低 36%
• Perf/＄ 1.18，比 Opus 的 0.64 高 84%

这意味着：即使面对完全没见过的任务类型，ACRouter 不仅能自适应，还能比一直用最强单模型更省钱、效果更好。

5.3 Cumulative Regret 曲线（Figure 5）

论文画了 regret 随任务流累积的曲线：

• 静态 router：regret 线性增长，最终很高（284-317）
• Bandit (LinUCB/LinTS)：regret 增长稍慢，但线性趋势仍在（297-307）
• ACRouter：regret 增长明显更慢，最终最低（205.5）——因为 Memory 不断积累，决策越来越准

在 OOD 上，静态 router 的 regret 曲线直接"起飞"，而 ACRouter 保持相对平稳。

5.4 Pareto 前沿（Figure 6）

在 AvgPerf vs Cost 的 Pareto 图上：

• ACRouter 在 ID 和 OOD 上都位于最上方——性能最高
• 成本比 Always-Opus 低，Perf/＄ 更高
• 静态 router 虽然便宜（高 Perf/＄），但性能太低，不在有效前沿上

六、核心设计洞见

6.1 为什么小模型能当好指挥者？

ACRouter 的 Orchestrator 用 Qwen3.5-0.8B——一个不到 1B 参数的小模型。它能超越 Claude Sonnet 4.6 当 router 吗？

能。因为 router 的任务不是"写出完美代码"，而是"从 8 个模型里选一个"。这是一个低维分类问题（8 类），不需要 175B 参数的世界知识。0.8B 模型足够学习"算法设计 → GLM-5"、"测试生成 → Qwen3-Max"这类映射。

更重要的是，router 需要频繁调用（每个任务一次），用 0.8B 自托管的成本是 ＄0.054/M tokens，比 Claude API 便宜 100 倍。如果 router 本身就很贵，省下的模型成本会被 router 成本吃掉。

6.2 为什么信息缺失比推理缺失更致命？

论文的核心发现是：给 Claude Sonnet 4.6 加上 per-dimension 性能统计，Router 性能提升 15.3%，直接超过基于同样信息的启发式方法。

这意味着：

• 推理能力不是瓶颈：Claude 足够聪明，能看懂性能统计并做出合理决策
• 信息获取是瓶颈：router 不知道每个模型在每个维度上的真实表现，只能瞎猜
• 信息需要执行验证：静态统计不够，需要运行时 sandbox 执行产生真实反馈

这和人类决策很像：一个聪明的经理如果不知道每个员工的实际产出，决策也不会好。ACRouter 的 Verifier 就是这个"绩效追踪系统"。

6.3 Memory 的 FIFO 设计：为什么只保留 20K？

Memory 是 FIFO 20K 条目，不是无限增长。为什么？

• 任务分布漂移：coding 任务的类型和难度会随时间变化（比如新语言、新框架），过旧的经验可能误导
• 检索效率：20K 条向量检索在延迟和精度之间平衡
• 在线学习：FIFO 保证 router 始终基于近期经验做决策，适应分布变化

这比传统"训练一次、部署永久"的 router 更 robust。

七、对开发者的实践启示

7.1 多模型策略不是"备选项"，是"必选项"

如果你还在用单一模型做 coding agent：

• 你大概率在某些任务上严重浪费钱（用 Opus 做 Kimi 就能做好的事）
• 你大概率在某些任务上严重损失性能（Opus 做算法设计不如 GLM-5）

建议：至少订阅 2-3 个不同层级的模型（如 premium + mid + low），让 router 根据任务动态选择。

7.2 Router 不要冻住，要让它"活"着

静态 router（训练一个分类器就部署）的问题：

• 模型版本更新（GPT-5.4 发布）→ 需要重新训练
• 新任务类型出现（agentic programming）→ 直接崩溃
• 模型价格变化（促销、降价）→ 无法自适应

ACRouter 的解法：

• 在线 Memory 积累实时执行结果
• Verifier 产生 grounded 信号，不依赖模型自评
• 新模型加入 pool 时，只需跑 probing set 即可自动校准

7.3 自建 Router 的成本可以很低

论文算了一笔账：

• Qwen3.5-0.8B 在 H100 上自托管：＄0.054/M tokens
• Claude Sonnet 4.6 API：＄3/＄15 per M tokens
• 一个 routing 调用大约 2000 input + 96 output tokens
• 每次 routing 成本：~＄0.0001（自托管） vs ~＄0.007（Claude API）

70 倍成本差距。如果你每天路由 1000 次任务，自建 router 一年能省数万美元。

7.4 局限性

论文也坦诚了局限：

• 提供商缓存不可见：实际 API 调用可能有缓存折扣，论文按公开定价计算，成本估算偏保守
• Agentic 评估用 40 步限制：标准 SWE-bench 是 250 步，论文压缩到 40 步控制预算，但 router 相对排序不受影响
• Memory 是简单的 kNN：更先进的参数级记忆（如 neural memory）待探索

八、形式化：C-A-F 是 Contextual Bandit

论文把 C-A-F 循环形式化为上下文多臂老虎机（Contextual Multi-Armed Bandit）：

• 臂（Arms）：M 个候选模型
• 上下文（Context）：c_i = (prompt, 元数据, 历史记忆)
• 拉动（Pull）：选择模型 a_i
• 奖励（Reward）：r_i = s_i - 0.1 × κ_i（得分减去 10% 成本惩罚）
• 累积后悔（CumReg）：与 per-task oracle 的累积差距

这个形式化的意义：

1. 它让 router 优化有理论保证（bandit 有收敛界）
2. 它定义了自然评估指标（CumReg 比单次准确率更适合 streaming 场景）
3. 它连接了现有算法（LinUCB、LinTS 是 C-A-F 的简化版——只有 parametric Memory，没有 LLM Orchestrator 和 sandbox Verifier）

结语：从"选模型"到"模型自己会选"

Agent-as-a-Router 的核心思想是：路由不应该是一个静态分类问题，而应该是一个持续学习的决策问题。

当 coding agent 面对一个任务时：

• 静态路由："根据训练数据，这类任务通常用模型 X"
• ACRouter："让我看看过去 100 个类似任务上各个模型表现如何，结合当前任务的特征，选一个在相似任务上验证过的模型"

后者的决策基于执行验证过的经验，而不是训练集里的统计关联。这在面对 OOD 任务时，差距是巨大的——论文中 static router 在 OOD 上从 47% 崩溃到 8-21%，而 ACRouter 保持在 62.5%。

对于正在构建 coding agent 的开发者来说，ACRouter 提供了一个立即可用的蓝图：

1. 接入 3-8 个不同模型（覆盖不同成本和性能层级）
2. 用小模型（0.8-7B）做 router，自托管极低成本
3. 用 sandbox 执行验证结果，积累在线 Memory
4. 让 router 在任务流中持续学习，越用越准

最终，你花更少的钱，得到更好的结果——而且你的 agent 会越来越聪明。

参考来源：

• Zhou, P., Tang, Z., Ma, Y., et al. (2026). "Agent-as-a-Router: Agentic Model Routing for Coding Tasks." arXiv:2606.22902.
• NUS, DAMO Academy (Alibaba), Hupan Lab, UC Berkeley, Zhejiang University, HKUST
• 代码与基准：https://github.com/LanceZPF/agent-as-a-router
• 8 个评估模型：Claude Opus/Sonnet 4.6, GPT-5.4, Qwen3-Max/3.5-Plus, GLM-5, Kimi-K2.5, MiniMax-M2.7

#论文解读 #AI #LLM #模型路由 #CodingAgent #ACRouter #ContextualBandit #多模型 #NUS #阿里达摩院 #小凯