🤖 AI

Agent-as-a-Router: Agentic Model Routing for Coding Tasks

本文引入了“代理即路由”（Agent-as-a-Router）框架，该框架将模型路由视为一个动态的“上下文-动作-反馈”循环，以积累基于执行的经验，从而克服静态路由的信息缺失问题，并在编程任务中实现卓越的性能与成本效率。

原作者： Pengfei Zhou, Zhiwei Tang, Yixing Ma, Jiasheng Tang, Yizeng Han, Zhenglin Wan, Fanqing Meng, Wei Wang, Bohan Zhuang, Wangbo Zhao, Yang You

发布于 2026-06-23

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Pengfei Zhou, Zhiwei Tang, Yixing Ma, Jiasheng Tang, Yizeng Han, Zhenglin Wan, Fanqing Meng, Wei Wang, Bohan Zhuang, Wangbo Zhao, Yang You

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你是一位经营着一家繁忙编程代理机构的经理。你拥有一支由八名不同专家组成的开发人员团队，每位成员都有其独特的超能力和价格标签。

开发者 A 是修复 Bug 的天才，但收费极高。
开发者 B 价格低廉且擅长编写数据脚本，但极其不擅长复杂的数学运算。
开发者 C 擅长编写测试用例，但其他方面的工作进度较慢。

在过去，大多数公司为了保险起见，会对所有任务都直接雇佣 开发者 A（最贵、最“强”的一个）。但这是一种浪费。如果你只需要一个简单的数据脚本，雇佣开发者 A 就像是请一位一级方程式赛车手去超市买菜一样。

这篇题为 《Agent-as-a-Router》（智能体即路由） 的论文，介绍了一种管理这个团队的新方法。与其盲目地挑选“最好”的开发者，作者构建了一个聪明的 交通控制器（称为“路由”），它会决定哪个特定的开发者应该处理哪项特定的任务。

以下是他们的发现与解决方案的详细拆解：

1. 问题所在：“信息差”

研究人员首先问道：为什么现有的智能路由效果不够好？
他们测试了一个标准的 AI 路由（“原生”路由），发现它经常出错。他们想知道：是因为路由本身的推理能力不够强吗？

为了测试这一点，他们给了路由一份包含 性能统计数据（例如：“开发者 B 在数据任务上的表现为 90%”）的“小抄”。

结果： 路由的性能瞬间提升了 15.3%。
教训： 路由的表现不佳并不是因为它“笨”，而是因为它“瞎”。它缺乏关于不同开发者在特定任务上实际表现的信息。瓶颈在于 信息缺失，而非缺乏智能。

2. 解决方案：“学习型交通控制器”

作者提出了一种名为 ACRouter 的新系统。它不是一个静态的规则手册，而是一个 活生生的、持续学习的循环。他们称之为 C-A-F 循环：

Context (背景/简报)： 路由查看新的编程任务，并结合从以往类似任务中学习到的经验。
Action (行动/分配)： 它为工作挑选出最合适的开发者。
Feedback (反馈/成绩单)： 开发者完成工作，随后由一个“验证器”（沙盒测试环境）检查代码是否运行正常以及消耗了多少成本。
Update (更新/记忆)： 路由获取该成绩单，并将其存储在它的 记忆 (Memory) 中。

类比：
将传统的路由想象成一张 静态地图。即使道路封锁，它也每次都指引同样的路线。
而 ACRouter 就像是一个 拥有实时 GPS 的网约车司机。

他们接载乘客（任务）。
他们将乘客送到目的地。
他们会检查乘客是否满意以及消耗了多少燃油。
他们会记住：“路线 X 非常适合这类乘客，但路线 Y 太贵了。”
下次有类似的乘客到来时，由于拥有了经验，这位司机能做出更好的选择。

3. “记忆”是关键

该系统最核心的部分是其 记忆模块 (Memory module)。

旧的路由 就像是那些为了考试而学习、考完即忘的学生。它们无法从错误中学习。
ACRouter 则记录着它处理过的每一项任务的“日记”。它会记得：“上次我把一个‘数据科学’任务交给开发者 B 时，效果完美且成本很低。上次我把它交给开发者 A 时，不仅昂贵而且失败了。”

这使得路由随着工作的开展变得越来越聪明，能够适应它从未见过的全新类型的编程挑战。

4. 结果：更聪明、更便宜

团队在一个名为 CodeRouterBench（包含约 10,000 个编程任务）的大规模基准测试中对该系统进行了测试。

在已知任务上： ACRouter 在挑选正确开发者的准确性方面表现最佳，甚至超越了“完美”的静态规则。
在新的、奇特的任务（分布外任务）上： 这正是奇迹发生的地方。当他们给出一个全新的编程挑战类型（智能体编程，即 Agentic Programming）——一种它从未见过的类型时：
- 旧的“静态”路由（仅靠记忆规则的路由）表现糟糕。
- “学习型”路由（ACRouter）通过利用其对相似模式的记忆，迅速完成了适应并取得了成功。
- 它甚至超越了“为每个任务都雇佣单一最贵、最强开发者”的策略，在提高结果质量的同时节省了成本。

总结

本文认为，要充分发挥多个 AI 编程模型的作用，你不应该仅仅挑选“最强”的那一个。相反，你需要一个 聪明的、具备学习能力的管理者，它需要：

了解每个模型的具体优势。
从自身的错误中实时学习。
构建关于“什么有效”以及“什么无效”的记忆。

通过利用这种反馈循环来弥补“信息差”，该系统变成了一个高效的、能够自我进化的路由引擎，既节省了成本，又提高了代码质量。

技术摘要：智能体即路由 (Agent-as-a-Router)

1. 问题陈述

现实世界的用户通常可以访问来自不同供应商的多个大语言模型（LLM），每个模型在特定领域（如算法设计、数据科学或代码补全）各有所长，但没有一个能统治所有任务。目前的编程智能体通常依赖于单一且固定的 LLM 来处理所有任务，这种设计优先考虑了供应商侧的可预测性，而非以用户为中心的成本效率和任务级质量。

核心问题在于自动模型路由：即如何确定哪个模型应该处理每个传入的编程任务，以在最大化性能的同时最小化成本。现有的路由方法将此视为一个静态的一次性分类问题，通常采用语言模型作为路由策略。然而，初步实验表明，静态路由与“每任务先知”（即知道每个特定任务最佳模型的模型）之间存在显著的性能差距。论文指出，现有路由器的瓶颈不在于缺乏推理能力，而在于信息缺失：静态路由器无法在部署过程中积累基于执行经验的信息。

2. 方法论

2.1. 诊断：信息缺失

作者使用了一个零样本 LLM 路由器（由 Claude Sonnet 4.6 提供动力）进行了消融研究。

原生路由器 (Vanilla Router)： 得分为 41.41% 平均性能。
+性能统计 (+Perf Stats)： 当提供来自留出探测集的先前性能统计数据时，得分上升至 47.74%（相对增益 +15.3%），甚至超过了编码了相同静态先验的最优启发式路由器（47.50%）。
结论： 主要限制是缺乏动态的、基于执行的信息，而非路由器模型本身的推理能力。

2.2. 智能体即路由框架 (Agent-as-a-Router Framework)

为了解决信息缺失问题，作者提出了 Agent-as-a-Router 框架，该框架将路由形式化为一个上下文-动作-反馈 (C-A-F) 循环。与静态路由器不同，该框架在任务流中不断演进：

上下文 ( $c_i$ )： 路由器观察任务提示词、元数据以及来自先前循环的累积历史（记忆）。
动作 ( $a_i$ )： 路由器从候选池中选择一个模型。
反馈 ( $f_i$ )： 被选中的模型输出在沙盒中执行，验证器生成评分和成本。
更新： 反馈被存入记忆并合并到下一个任务的上下文 ( $c_{i+1}$ ) 中。

该公式与上下文多臂老虎机 (contextual multi-armed bandit) 问题相关，其评估的自然指标是累积遗憾 (cumulative regret)（即路由器的性能与每任务先知之间的累积差距）。

2.3. ACRouter 实例化

该框架通过 ACRouter 进行实例化，它包含三个核心模块：

编排器 (Orchestrator)： 通过整合 DimensionBest 先验、通过余弦 kNN 从记忆中检索的前 10 个历史近邻以及任务元数据来做出路由决策。它使用一个轻量级的微调 Qwen3.5-0.8B 模型，并通过加权投票结合启发式规则进行决策。
验证器 (Verifier)： 在沙盒环境中评估模型输出。它将信号（AST 解析、执行结果、LLM-as-Judge）聚合为一个统一的性能得分 ( $u_i \in [0, 1]$ )。
记忆 (Memory)： 一个以任务嵌入为键的在线向量库。它记录所选模型、性能、成本和验证轨迹。它使用一个 FIFO 限制存储（20K 条目）以实现细粒度、上下文感知的过去成功与失败案例检索。

2.4. CodeRouterBench

为了在流式任务上评估路由，作者引入了 CodeRouterBench，该基准测试包含：

约 10,000 个任务，涵盖 10 个编程维度（9 个分布内单轮任务和 1 个分布外智能体编程维度）。
8 个前沿 LLM（包括 Claude Opus 4.6, GPT-5.4, Qwen3-Max, Kimi-K2.5 等）。
执行验证得分： 任务通过沙盒执行或 LLM-as-Judge 进行评分，为基于遗憾的比较提供地面真值观测矩阵。

3. 核心贡献

框架： 提出了 Agent-as-a-Router，它将模型路由形式化为 C-A-F 循环，使路由器能够通过基于执行的反馈主动弥合信息差距。
产物：
- ACRouter： 包含编排器、验证器和记忆模块的框架具体实例化。
- CodeRouterBench： 一个标准化的评估环境（约 10K 任务，8 个 LLM），专门设计用于在流式任务上进行基于遗憾的路由器比较，包括 OOD（分布外）智能体编程测试床。
发现：
- 信息缺失： 路由瓶颈是信息获取问题，而非推理能力。提供性能统计数据可带来 15.3% 的相对增益。
- 性能： ACRouter 在分布内任务上实现了最低的累积遗憾，并在分布外 (OOD) 智能体编程任务中表现出有效的泛化能力。
- 静态局限性： 轻量级静态路由器（训练分类器、启发式方法）在分布内任务上表现尚可，但在 OOD 任务上表现显著下降，而 ACRouter 保持了强劲性能。

4. 实验结果

实验在分布内 (ID) 和分布外 (OOD) 任务流上均进行了。

分布内性能：
- ACRouter 实现了最高的平均性能 (49.98%) 和最低的累积遗憾 (205.5)，优于静态 "DimensionBest" 启发式方法 (47.50%) 和所有训练过的策略基线。
- 它还展示了优异的成本效率（Perf/$ 比率为 3.79），相比于始终使用最强单一模型（Always-Opus 4.6，其比率为 1.29）。
分布外 (OOD) 泛化能力：
- 在智能体编程测试床上（176 个任务），ACRouter 达到了 62.50% 的平均性能，显著优于 Always-Opus 基线 (57.14%) 和所有其他路由器。
- 静态分类器（如 LogReg, RouteLLM-BERT）在 OOD 任务上崩溃，性能降至 8.93%–21.43%，甚至低于随机选择。
- ACRouter 在流中积累经过验证经验的能力使其能够适应新的任务分布，而依赖于冻结先验的静态方法则失败了。
成本分析：
- 虽然 ACRouter 为记忆和验证器模块带来了开销，但与始终选择最昂贵模型（Opus 4.6）相比，它仍然更具成本效益，同时提供了更高的质量。
- “Always-Kimi-K2.5”策略提供了最高的成本效率 (Perf/$ 12.62)，但以大幅牺牲绝对性能为代价 (36.66% AvgPerf)。

5. 重要性与主张

论文声称，通过基于执行的反馈主动弥合信息差距是构建必须在异构工具或模型间进行路由的智能体系统的通用原则。

范式转变： 这项工作将路由从静态分类问题转变为动态的、自适应的过程 (C-A-F 循环)。
实际效用： 它证明了通过动态路由任务，用户可以实现接近先知水平的性能和成本效率，而不是依赖于单一的“最佳”模型。
可推广性： C-A-F 循环不仅被呈现为一种路由机制，更是一个更广泛的决策范式，适用于工具选择、API 端点选择和精力分配。
谦逊态度： 作者承认了局限性，例如无法观察到供应商侧的缓存命中率（使得成本估算为相对值而非绝对值），以及在 OOD 任务中使用减少的步数限制以保持预算可控。他们指出，虽然目前的实例化使用了带有 kNN 记忆的 LLM 策略，但仍有待探索其他的参数级记忆技术。

总之，论文认为，对于编程智能体系统而言，未来不在于寻找单一的主导模型，而在于构建能够从执行反馈中学习，从而为正确的工作选择正确的工具的自适应路由器。