vLLM Semantic Router 发布 Micro-Agent：在模型 API 内用协作超越前沿模型

人人都在关注下一个前沿模型。

更有趣的层面或许就在它前面。

路由器正在成为 AI 推理的控制平面。它们的第一个角色很务实：把正确的请求路由到正确的模型。这一点已经很重要，因为生产级 AI 不再是单一模型的世界。

路由器可以通过判断一个请求何时值得动用前沿模型、何时开源或本地模型就足够来降低成本。它可以通过将敏感领域发送给更严格的模型、更严格的过滤器或更强的审查路径，让安全策略变得可执行。它可以协调云端和边缘，将隐私或低延迟意图保留在本地，同时将更困难的工作升级到云端。

这些都是重要的工作。

但路由器的下一个工作更有趣：

路由器可以让模型变得更好。

不是通过改变权重。不是要求每个应用都构建定制的智能体图。而是通过将一次模型 API 调用转变为服务层内部的有界协作。

这就是为什么 Sakana Fugu 引起了如此大的反响：它把一个简单但强大的想法变成了商业产品——一个“模型”可以是一个表面，而在这个表面背后可以是一个团队。围绕这一想法的研究，包括 Fugu 技术报告 以及 Conductor 和 Trinity 等协调论文，为思考编排提供了有用的语言。

但 vLLM Semantic Router 的愿景不同之处在于它把抽象放在哪里。协作不应只存在于一个商业端点或一个特定于应用的智能体图内部。它应该成为一种开放的服务原语。

vLLM Semantic Router 将这一想法带入开放服务层。用户仍然只调用一个模型：

{
  "model": "vllm-sr/auto",
  "messages": [{"role": "user", "content": "..."}]
}

在这个稳定的模型身份背后，路由器可以选择一个配方、扇出到工作节点、收集法定人数、验证分歧、综合最终答案、修复输出契约，并返回一个正常的 OpenAI 兼容响应。

重点不是暴露复杂性。

重点是让协作感觉像一个模型。

Looper 就是运行时

在 vLLM Semantic Router 中，looper 是有界微智能体的执行运行时。

一个请求作为普通的聊天补全进入路由器。路由器提取信号，将它们投射到任务形态或风险区间，匹配一个决策，然后选择一个算法。该算法可能是普通的单模型路由，也可能是 looper 路由。

如今，主要的 looper 模式有：

• Confidence：顺序升级循环。它先尝试一个更便宜的候选，测量置信度，只有当分数太低时才升级。
• Ratings：有界扇出循环。它在硬性并发上限下运行多个候选，并用评分感知权重进行聚合。
• ReMoM：重复的模型混合推理。它扇出广度样本，等待足够多的成功响应，并运行最终综合轮次。
• Fusion：小组-评判-最终模式。独立的模型响应成为评判者和最终确定者的证据。
• Workflows：微智能体工作流运行时。它支持静态角色或动态规划器，执行有界的工作步骤，并综合最终响应。

实现细节很重要。Looper 不是“多问几个模型”的口号。它是一个小型运行时，带有预算、拓扑、追踪和失败策略。

置信度：只对困难案例进行支出升级

置信度是成本感知的循环。它从一个更小或更便宜的候选开始，然后评估答案是否足够自信以停止。置信度信号可以来自 token 级对数概率、logprob 边际、混合分数、自验证或 AutoMix 风格的蕴含验证器。

如果分数通过阈值，路由器立即返回。如果分数太低，路由会升级到下一个候选。重要的不是升级存在，而是升级成为显式的路由器策略：阈值、失败行为和停止条件都是可见且可调的。

评分：硬上限下的并行质量

评分是受控的集成循环。它并行启动多个候选，但最多不超过配置的 max_concurrent 上限。当一条路由应该从多个模型视角中获益，而又不想让每个请求都变成无限制的扇出时，这很有用。

路由器收集成功的响应，应用评分感知的聚合，并根据路由策略处理失败。在实践中，评分非常适合 A/B 风格的评估、集成策略，以及操作者已经拥有有意义的每个候选质量信号的路由。

ReMoM：有契约的广度

当任务具有高推理方差且答案格式必须在协作中保持时，ReMoM 很有用。它扇出多个推理尝试，等待最低成功法定人数，然后要求合成模型将证据合并到所需的输出契约中。

如果合成失败但较早的工作者产生了有效证据，路由不必崩溃为 API 错误。它可以回退到最佳有效证据，仍然返回正常响应。

融合：将分歧作为信号

融合从一个不同的赌注开始。有时有用的对象不是平均答案，而是分歧的结构。独立小组的答案成为证据。评判者看到一致、矛盾和独特见解，然后最终化器返回一个答案，追踪折叠在 API 后面。

当存在看似合理的竞争路径时，这使得融合特别有用：困难的 multiple-choice 推理、长篇专家判断，或单一自信响应可能脆弱的精确答案任务。

工作流：预算下的角色

工作流是最具代理性的模式，也是最需要严格边界的模式。规划器只能选择允许的工作模型。计划经过验证。步骤受最大步骤数、最大并行度、超时和错误策略的限制。最终响应仍然必须满足输出契约。

对于 SWE 风格的任务，这意味着路由器可以表达规划器、修补器、验证器和最终化器，而不让应用程序拥有定制的代理栈。对于生产服务，这种区别至关重要：循环很强大，但它仍然受基础设施治理。

自动配方：一个模型名，多种循环

公开接口仍然只有一个模型名：vllm-sr/auto。在内部，路由器可以使用信号和投影来为请求选择合适的循环。难度、风险、契约压力、延迟和成本不是提示词中的注释，而是路由事实，可用于选择 Confidence、Ratings、ReMoM、Fusion、Workflows 或回退路径。

这就是“智能体作为应用逻辑”与“微智能体作为服务运行时”之间的区别。路由器控制预算、策略、拓扑、追踪和失败模式。

配方胜过单一通用循环

我们从评估工作中得到的最重要教训，并不是某个算法总是胜出。

恰恰相反：

最好的循环是因任务而异的。

GPQA-Diamond 要求严格保留多项选择答案。LiveCodeBench 要求可运行的代码和对隐藏测试的鲁棒性。Humanity's Last Exam 要求解决分歧并精确格式化答案。SWE 类任务需要规划器、补丁器、验证器和终结器。

这就是为什么 vllm-sr/auto 不应意味着“总是运行最大的循环”，而应意味着：选择适合此任务的配方。

在我们的配方中，这种形态是显式的：

• GPQA-Diamond 将高难度科学多项选择提示路由到 ReMoM 配方，并严格保留 ANSWER: X。
• LiveCodeBench 在选择代码形态的循环之前，会检查约束、起始代码、标准输入、浮点容差、超时风险和隐藏测试风险。
• HLE 在更深的 ReMoM、较小的 Fusion 或回退路径之间做出选择之前，会检测形式推理、分歧风险、长上下文和精确答案压力。

这就是为什么路由器侧协作不仅仅是提示工程。提示词只是其中一部分。配方还定义了模型池、模型角色、推理投入、并发、法定人数、超时、合成模型、回退策略、输出契约和可观测性标签。

记分卡是证明，但不是全部

我们在三个高难度基准上评估了当前的闭源模型配方。这些数字很有用，因为它们表明这个想法不仅停留在美学层面。

在此记分卡中，VSR Closed 表示配方仅使用闭源模型后端。VSR Hybrid 表示配方混合使用开源和闭源模型，在配方需要更高风险评判、修复、合成或回退的地方使用更强的闭源模型。

记分卡应仔细解读。它并不是声称每个请求都应始终使用所有闭源模型。那将是错误的产品。

其主张是，路由器拥有的协作可以创造出比其底层各个调用更强的模型身份。它可以在保持单一 API 接口的同时，超越或匹敌前沿单模型基线。

这才是真正的产品形态：

• 用户看到一个模型名。
• 运营者控制配方。
• 系统可以在不改变客户端集成的情况下持续改进。
• 开放模型和闭源模型可以在同一服务抽象下参与。

这对模型服务意味着什么

旧的服务栈是被动的。它接受一个模型名称，然后把请求发送到后端。

下一代服务栈是主动的。它会问：

• 关于这个请求，我们有哪些证据？
• 它属于哪个质量、成本、延迟和安全区间？
• 一个模型就够了吗？
• 如果不够，应该运行哪种协作模式？
• 必须保留哪个答案契约？
• 如果某个提供方很慢或出错，应该怎么办？
• 我们如何在保留完整追踪的同时，对外暴露一个干净的响应？

这不是应用层的胶水。这是基础设施。

微代理属于路由器，因为路由器已经拥有微代理所需的东西：模型别名、提供方策略、凭证、成本元数据、信号、决策、重试、超时、追踪，以及兼容 OpenAI 的响应语义。

要点

“前沿模型”这个说法开始意味着两件事。

一个是检查点。

另一个是系统边界。

最近的编排浪潮让方向变得清晰。vLLM Semantic Router 押注的是：这种能力应该可编程、可观测，并在服务层开放。

下一轮模型竞赛仍将涉及更好的模型。但它也会涉及更好的路由器：知道何时省钱、何时执行安全策略、何时留在边缘、何时上云，以及何时把一个请求变成一个小而有序的团队。

这就是 Model API 内微代理的承诺。

致谢

我们感谢来自 MBZUAI、McGill University、Mila 和 Agentic Intelligence Lab 的研究人员，特别是 Prof. Xue Liu 和 Dr. Bowei He，感谢他们在路由器侧模型协作方面的研究合作与讨论。

个人贡献者：Huamin Chen、Yincheng Ren。

我们还感谢 AMD 的 Andy Luo 和 Haichen Zhang 提供的 AMD GPU 评估支持。