你花 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 | 差距 |
|---|---|---|---|---|
| 算法设计 | GLM-5 | 47.2% | 25.4% | GLM-5 高 86% |
| 测试生成 | Qwen3-Max | 82.7% | 39.2% | Qwen-Max 高 111% |
| 数据科学 | Kimi-K2.5 | 18.4% | 14.2% | Kimi 高 30% |
| 代码生成 | Claude Opus 4.6 | — | 最高 | — |
| Bug 修复 | Claude Opus 4.6 | — | 最高 | — |
- 性能损失：在算法题上你只发挥了最佳模型 53% 的水平
- 成本爆炸：Opus 的总成本是 Kimi-K2.5 的 12 倍
- 机会成本：你花大价钱订阅的 GLM-5、Qwen3-Max 等模型，根本没用上
---
二、现有路由器的盲区：不是推理差，是信息少
2.1 实验诊断：为什么 LLM-as-a-Router 表现差？
论文做了一个精妙的 ablation：用 Claude Sonnet 4.6 当 router，只改变给它的信息，看路由性能变化。
| Router 配置 | 信息给多少 | AvgPerf% | 相对提升 |
|---|---|---|---|
| Vanilla | 只有任务 prompt | 41.41 | 基线 |
| +Dimension | + 任务维度（如"算法设计"） | 41.18 | -0.6% |
| +Perf stats | + 各维度性能统计（probing set） | 47.74 | +15.3% |
| DimensionBest | 直接用维度最优模型（启发式） | 47.50 | — |
| Oracle | 每次都选该任务最优模型 | 57.00 | 上限 |
结论：路由器的瓶颈不是推理能力（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）更聪明。这和传统静态路由的根本区别：
| 静态路由 | Agent-as-a-Router | |
|---|---|---|
| 信息状态 | 冻结的训练知识 | 持续更新的执行经验 |
| 学习方式 | 离线训练，部署不动 | 在线部署，边用边学 |
| 适应性 | 遇到新任务类型崩溃 | 通过记忆积累逐步适应 |
| 理论基础 | 分类/偏好学习 | Contextual Multi-Armed Bandit |
3.2 ACRouter 的三模块架构
#### ① Orchestrator（指挥者）—— 做决策
输入信号有三路：
- DimensionBest prior：各维度上历史最优模型（粗粒度先验）
- Memory kNN：从在线记忆中检索 top-10 个最相似的历史任务及其结果（细粒度经验）
- 任务元数据：维度、难度、语言等
为什么用小模型当指挥者？ 因为 router 本身需要被频繁调用（每个任务一次），用 0.8B 模型在 H100 上自托管，每百万 token 成本仅 ＄0.054——比调一次 Claude API 便宜两个数量级。
#### ② Verifier（验证者）—— 产信息
Verifier 是 ACRouter 的信息引擎。它不只返回"对/错"，而是综合多个信号生成一个统一分数 u_i ∈ [0,1]：
| 验证层级 | 工具 | 适用场景 |
|---|---|---|
| AST 解析 | 语法树检查 | 所有代码任务 |
| Sandbox 执行 | 在 Docker 里跑测试 | 可执行代码（Code Generation, Bug Fix 等） |
| Prompt 内嵌测试 | 检查输出是否包含预期测试 | 有标准输入输出的任务 |
| Rule-based 信号 | 格式检查、长度检查等 | 所有任务 |
| 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 条目，超出时淘汰最早的
---
四、CodeRouterBench：为 router 量身定做的考场
现有 benchmark 无法评估 streaming router，因为：
- 大多数 benchmark 只测"单次准确率"，不测累积 regret
- 没有 pre-collected 的 per-task per-model 结果矩阵，无法计算 oracle 上限
4.1 Benchmark 构造
CodeRouterBench 包含 ~10K 任务，10 个 coding 维度：
| 维度 | 任务数 | 评估方式 | 来源 |
|---|---|---|---|
| 代码生成 | 1,111 | Sandbox pass@1 | HumanEval+, MBPP+, BigCodeBench |
| 算法设计 | 1,111 | Sandbox pass@1 | LiveCodeBench, BigCodeBench |
| Bug 修复 | 1,111 | Sandbox pass@1 | DebugBench, SWE-bench Lite |
| 代码补全 | 1,111 | Sandbox pass@1 | CRUXEval, HumanEval+ |
| 代码重构 | 1,111 | LLM-as-Judge | Bugs2Fix, CanItEdit |
| 数据科学 | 1,111 | Sandbox pass@1 | DS-1000, BigCodeBench |
| 多语言 | 1,111 | Sandbox pass@1 | HumanEval-X, MultiPL-E |
| 代码理解 | 1,111 | LLM-as-Judge | CodeXGLUE |
| 测试生成 | 1,111 | Sandbox pass@1 | LiveCodeBench, HumanEval+ |
| Agentic Programming (OOD) | 176 | Docker sandbox | SWE-bench, LongCLI, FeatureBench |
- 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
| 模型 | 输入价(＄/M) | 输出价(＄/M) | 成本层级 |
|---|---|---|---|
| Claude Opus 4.6 | ＄5.00 | ＄25.00 | premium |
| Claude Sonnet 4.6 | ＄3.00 | ＄15.00 | high |
| GPT-5.4 | ＄2.50 | ＄15.00 | high |
| Qwen3-Max | ＄1.20 | ＄6.00 | mid |
| GLM-5 | ＄0.88 | ＄3.22 | mid |
| Kimi-K2.5 | ＄0.60 | ＄3.07 | mid |
| Qwen3.5-Plus | ＄0.40 | ＄2.40 | low |
| MiniMax-M2.7 | ＄0.30 | ＄1.20 | low |
五、实验结果：ACRouter 全面领先
5.1 In-Distribution（同分布测试）
| Router | AvgPerf% | CumReg↓ | Perf/＄↑ | 分析 |
|---|---|---|---|---|
| Oracle | 57.00 | 0 | 8.20 | 理论上限 |
| ACRouter | 49.98 | 205.5 | 3.79 | 唯一接近 oracle 的 |
| DimensionBest | 47.50 | 277.4 | 3.69 | 启发式，无学习 |
| LinUCB | 46.84 | 296.9 | 4.38 | 在线 bandit，但线性模型弱 |
| LinTS | 46.48 | 307.4 | 4.49 | 同上 |
| Qwen3.5-FT | 46.41 | 309.1 | 6.82 | 静态 fine-tuned，OOD 会崩 |
| RouteLLM-BERT | 47.22 | 285.5 | 6.22 | 静态分类器 |
| Always-Opus 4.6 | 43.83 | 387.1 | 1.29 | 最贵，但只排第 9 |
| Always-Kimi-K2.5 | 36.66 | 593.3 | 12.62 | 最便宜但性能差 |
| Random | 38.75 | 533.6 | 2.48 | 随机选 |
- 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 | AvgPerf% | CumReg↓ | Perf/＄↑ | 分析 |
|---|---|---|---|---|
| Oracle | 75.89 | 0 | 2.32 | 上限 |
| ACRouter | 62.50 | 17.0 | 1.18 | 唯一 > 60% 的 router |
| Always-Opus 4.6 | 57.14 | 26.7 | 0.64 | 单模型最强，但贵且不如 ACRouter |
| Qwen3.5-FT | 55.36 | 27.2 | 0.74 | 静态训练的在 OOD 还行？ |
| LinUCB | 49.82 | 31.1 | 0.96 | 在线更新救了一命 |
| LinTS | 46.43 | 35.9 | 0.75 | 同上 |
| Random | 31.25 | 50.4 | 0.85 | 随机基准 |
| RouteLLM-BERT | 21.43 | 59.4 | 1.30 | 静态分类器崩溃 |
| LogReg | 19.64 | 61.8 | 1.17 | 崩溃 |
| TF-IDF+MLP | 13.39 | 67.9 | 1.17 | 彻底崩溃 |
| RouteLLM-MF | 8.93 | 72.7 | 0.94 | 最惨 |
静态 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%
5.3 Cumulative Regret 曲线（Figure 5）
论文画了 regret 随任务流累积的曲线：
- 静态 router：regret 线性增长，最终很高（284-317）
- Bandit (LinUCB/LinTS)：regret 增长稍慢，但线性趋势仍在（297-307）
- ACRouter：regret 增长明显更慢，最终最低（205.5）——因为 Memory 不断积累，决策越来越准
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 执行产生真实反馈
6.3 Memory 的 FIFO 设计：为什么只保留 20K？
Memory 是 FIFO 20K 条目，不是无限增长。为什么？
- 任务分布漂移：coding 任务的类型和难度会随时间变化（比如新语言、新框架），过旧的经验可能误导
- 检索效率：20K 条向量检索在延迟和精度之间平衡
- 在线学习：FIFO 保证 router 始终基于近期经验做决策，适应分布变化
---
七、对开发者的实践启示
7.1 多模型策略不是"备选项"，是"必选项"
如果你还在用单一模型做 coding agent：
- 你大概率在某些任务上严重浪费钱（用 Opus 做 Kimi 就能做好的事）
- 你大概率在某些任务上严重损失性能（Opus 做算法设计不如 GLM-5）
7.2 Router 不要冻住，要让它"活"着
静态 router（训练一个分类器就部署）的问题：
- 模型版本更新（GPT-5.4 发布）→ 需要重新训练
- 新任务类型出现（agentic programming）→ 直接崩溃
- 模型价格变化（促销、降价）→ 无法自适应
- 在线 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）
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 的累积差距
---
结语：从"选模型"到"模型自己会选"
Agent-as-a-Router 的核心思想是：路由不应该是一个静态分类问题，而应该是一个持续学习的决策问题。
当 coding agent 面对一个任务时：
- 静态路由："根据训练数据，这类任务通常用模型 X"
- ACRouter："让我看看过去 100 个类似任务上各个模型表现如何，结合当前任务的特征，选一个在相似任务上验证过的模型"
对于正在构建 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
🌟 智谱 GLM-5 已上线
我正在智谱大模型开放平台 BigModel.cn 上打造 AI 应用，智谱新一代旗舰模型 GLM-5 已上线，在推理、代码、智能体综合能力达到开源模型 SOTA 水平。
🎁 领取 2000万 Tokens