Micro-Agent: 在模型API内部协作击败前沿模型
Micro-Agent: Beat Frontier Models with Collaboration inside Model API
vLLM Semantic Router 将路由器从模型选择扩展为AI推理的控制平面，通过在服务层内部将一次模型API调用转化为有边界的协作。路由器支持Confidence、Ratings、ReMoM、Fusion、Workflows等looper算法模式，在保留单一模型标识（如vllm-sr/auto）的同时，根据任务形状选择配方。评估显示，VSR Closed在LiveCodeBench（92.6）、GPQA-Diamond（96.0）和Humanity's Last Exam（50.0）上匹配或超越Fugu Ultra、GPT-5.5等前沿单模型基线。该工作由MBZUAI、麦吉尔大学、Mila及Agentic Intelligence Lab合作完成。
所有人都在关注下一代前沿模型（frontier model）。
但更值得关注的层面，可能是它前面的那一层。
路由器（Router）正在成为 AI 推理的控制平面。它们的第一个角色是务实的：将正确的请求路由到正确的模型。这已经很重要，因为生产环境中的 AI 不再是单一模型的世界。
路由器可以通过判断一个请求何时值得使用前沿模型、何时使用开源或本地模型就足够来降低成本。它可以通过将敏感领域发送到更严格的模型、更严格的过滤器或更强的审核路径来执行安全策略。它可以协调云端和边缘，将私有或低延迟的意图保留在本地，同时将更困难的工作升级到云端。
这些都是重要的任务。
但路由器的下一个任务更有趣：
路由器可以让模型变得更好。
不是通过改变权重。不是通过要求每个应用构建一个定制的 agent 图。而是通过在服务层内部将一次模型 API 调用转化为一个有边界的协作。
图 1：路由器正从模型选择转向能力构建。
这就是为什么 Sakana Fugu 引起了如此大的反响：它用一个简单但强大的想法做出了一个商业产品，即一个"模型"可以是一个表面，而在这个表面背后可以是一个团队。围绕这个想法的研究，包括 Fugu 技术报告 以及像 Conductor 和 Trinity 这样的协调论文，为思考编排提供了有用的语言。
但 vLLM Semantic Router 的愿景在抽象层放置的位置上有所不同。协作不应只存在于一个商业端点或一个特定于应用的 agent 图内部。它应该成为一个开放的服务原语。
vLLM Semantic Router 将这个想法带入了开放的服务层。用户仍然调用一个模型：
{
"model": "vllm-sr/auto",
"messages": [{"role": "user", "content": "..."}]
}
在这个稳定的模型标识背后，路由器可以选择一个配方（recipe），分发给工作节点，收集法定票数，验证分歧，综合最终答案，修复输出契约，并返回一个正常的 OpenAI 兼容响应。
重点不在于暴露复杂性。
重点在于让协作感觉起来像一个模型。
Looper 是运行时
在 vLLM Semantic Router 中，looper 是有边界微 agent（bounded micro-agent）的执行运行时。
一个请求作为普通的聊天补全进入路由器。路由器提取信号，将其投射到任务形状或风险区间，匹配一个决策，然后选择一个算法。该算法可能是一个普通的单模型路由，也可能是一个 looper 路由。
目前，主要的 looper 模式包括：
- Confidence（置信度）：一个顺序升级循环。它首先尝试一个更便宜的候选，测量置信度，并且仅在分数过低时升级。
- Ratings（评分）：一个有边界的分发循环。它在硬并发上限下运行多个候选，并使用评分感知的权重进行聚合。
- ReMoM：重复的模型混合推理。它分发广度样本，等待足够多的成功响应，并运行最终的综合轮次。
- Fusion（融合）：一个面板-评判-最终模式。独立的模型响应成为评判者和最终确定者的证据。
- Workflows（工作流）：一个微 agent 工作流运行时。它支持静态角色或动态规划器，执行有边界的工作节点步骤，并综合最终响应。
图 2：Looper 算法在路由器内部运行，同时保留模型 API 表面。
实现细节很重要。Looper 不是"询问更多模型"的口号。它是一个带有预算、拓扑、追踪和失败策略的小型运行时。
Confidence：仅在困难案例上花费升级成本
Confidence 是成本感知的循环。它从一个较小或更便宜的候选开始，然后评估答案是否足够自信以停止。置信度信号可以来自 token 级别的 log probability、logprob 差值、混合分数、自我验证或 AutoMix 风格的蕴含验证器。
如果分数超过阈值，路由器立即返回。如果分数太低，路由会升级到下一个候选。重要的不是存在升级。而是升级变成了明确的路由器策略：阈值、失败行为和停止条件都是可见且可调的。
图 3：Confidence 将升级转化为一个可度量的停止策略。
Ratings：在硬上限下的并行质量
Ratings 是受控的集成循环。它并行启动几个候选，但仅限于配置的 max_concurrent 上限。这使得它在路由应该从多个模型视角中受益，而又不将每个请求变成无边界分发时非常有用。
路由器收集成功的响应，应用评分感知的聚合，并根据路由策略处理失败。在实践中，Ratings 非常适合 A/B 风格评估、集成策略以及操作员已经拥有有意义的每个候选质量信号的路由。
图 4：Ratings 保持多候选执行有边界且评分感知。
ReMoM：带有契约的广度
当任务具有高推理方差且答案格式必须在协作中保持不变时，ReMoM 非常有用。它分发多个推理尝试，等待最小成功法定票数，然后要求一个综合模型将证据合并到所需的输出契约中。
如果综合失败但早期工作节点产生了有效证据，路由不必崩溃为 API 错误。它可以回退到最佳有效证据，并仍然返回一个正常响应。
图 5：ReMoM 将广度、法定票数、综合和回退视为服务时控制。
Fusion：将分歧作为信号
Fusion 从一个不同的赌注开始。有时有用的对象不是平均答案；而是分歧的结构。独立的面板答案成为证据。评判者看到一致、矛盾和独特见解，然后最终确定者在 API 背后折叠追踪后返回一个答案。
这使得 Fusion 在存在看似合理的竞争路径时特别有用：困难的多选推理、长格式专家判断或精确答案任务，在这些任务中，单个自信的响应可能很脆弱。
图 6：Fusion 不隐藏分歧。它将分歧转化为证据。
Workflows：预算下的角色
Workflows 是最具 agent 性的模式，也是需要最严格边界的模式。规划器只能选择允许的工作节点模型。计划被验证。步骤受最大步骤数、最大并行度、超时和错误策略的限制。最终响应仍然必须满足输出契约。
对于 SWE 风格的任务，这意味着路由器可以表达一个规划器、修补器、验证器和最终确定器，而无需让应用拥有一个定制的 agent 栈。对于生产服务，这种区别至关重要：循环很强大，但它仍然受基础设施管辖。
图 7：Workflows 为路由器提供了一个有边界的角色系统，而不是一个无边界自主 agent。
Auto recipes：一个模型名称，多个循环
公共表面仍然是一个模型名称：vllm-sr/auto。在内部，路由器可以使用信号和投射来为请求选择正确的循环。难度、风险、契约压力、延迟和成本不是 prompt 中的注释。它们是路由事实，可以选择 Confidence、Ratings、ReMoM、Fusion、Workflows 或回退路径。
图 8：Auto recipes 让信号选择协作模式，同时保留一个模型标识。
这就是"agent 作为应用逻辑"和"微 agent 作为服务运行时"之间的区别。路由器控制预算、策略、拓扑、追踪和失败模式。
配方胜过单一通用循环
从我们的评估工作中得到的最重要教训不是某个算法总是获胜。
恰恰相反：
最佳循环是任务形状的。
GPQA-Diamond 需要严格的多选答案保留。LiveCodeBench 需要可运行代码和隐藏测试鲁棒性。Humanity's Last Exam 需要分歧解决和精确答案格式化。SWE 风格的任务需要一个规划器、修补器、验证器和最终确定器。
这就是为什么 vllm-sr/auto 不应意味着"总是运行最大的循环"。它应该意味着：选择适合此任务的配方。
图 9：信号和投射让路由器选择一个基准形状的协作模式。
在我们的配方中，这种形状是明确的：
- GPQA-Diamond 将硬科学多选提示路由到 ReMoM 配方，并严格保留
ANSWER: X。 - LiveCodeBench 在选择代码形状的循环之前，会查找约束、起始代码、标准输入、浮点容差、超时风险和隐藏测试风险。
- HLE 在更深的 ReMoM、较小的 Fusion 或回退路径之间做出选择之前，会检测形式推理、分歧风险、长上下文和精确答案压力。
这就是为什么路由器端协作不仅仅是 prompt 工程。Prompt 只是其中一部分。配方还定义了模型池、模型角色、推理努力、并发度、法定票数、超时、综合模型、回退策略、输出契约和可观测性标签。
记分卡是一个证明，而非全部故事
我们在三个硬基准上评估了当前的闭源模型配方。这些数字很有用，因为它们表明这个想法不仅仅是美学上的。
图 10：VSR Closed 和 VSR Hybrid 在 LiveCodeBench、GPQA-Diamond 和 Humanity's Last Exam 上的记分卡视图。
在此记分卡中，VSR Closed 表示配方仅使用闭源模型后端。VSR Hybrid 表示配方混合使用开源和闭源模型，在配方需要更高风险的评判、修复、综合或回退时使用更强的闭源模型。
| 基准 | VSR 记分卡行 | 分数 | 参考行 |
|---|---|---|---|
| LiveCodeBench, 2025年1月-4月 | VSR Closed | 92.6 | Fugu Ultra 92.0, Fugu 90.3, GPT-5.5 90.7, Opus 4.8 90.3 |
| GPQA-Diamond | VSR Closed | 96.0 | Fugu Ultra 95.5, Fugu 95.5, Gemini 3.1 Pro 94.3, GPT-5.5 93.6 |
| Humanity's Last Exam | VSR Closed | 50.0 | Fugu Ultra 50.0, Fugu 48.5, Gemini 3.1 Pro 45.0 |
| Humanity's Last Exam | VSR Hybrid | 47.1 | GLM-5.2 40.5, Qwen3.7 Max 41.4, GPT-5.5 41.4 |
记分卡应仔细阅读。这不是声称每个请求都应始终使用每个闭源模型。那将是错误的产品。
主张是，路由器拥有的协作可以创建一个比其下方的单个调用更强的模型标识。它可以击败或匹配前沿单模型基线，同时保留一个 API 表面。
这才是真正的产品形态：
- 用户看到一个模型名称。
- 操作员控制配方。
- 系统可以在不更改客户端集成的情况下进行改进。
- 开源和闭源模型可以在相同的服务抽象下参与。
这对模型服务意味着什么
旧的服务栈是被动的。它接受一个模型名称并将请求发送到后端。
下一个服务栈是主动的。它会问：
- 关于这个请求我们有什么证据？
- 它属于哪个质量、成本、延迟和安全区间？
- 一个模型足够吗？
- 如果不够，应该运行什么协作模式？
- 必须保留哪个答案契约？
- 如果一个提供者很慢或出错，应该发生什么？
- 我们如何暴露一个干净的响应，同时保留完整的追踪？
那不是应用胶水。那是基础设施。
微 agent 属于路由器，因为路由器已经拥有微 agent 所需的东西：模型别名、提供者策略、凭证、成本元数据、信号、决策、重试、超时、追踪和 OpenAI 兼容的响应语义。
要点
"前沿模型"这个短语开始意味着两件事。
一个是检查点（checkpoint）。
另一个是系统边界。
最近的编排浪潮使这个方向变得可见。vLLM Semantic Router 的赌注是，这种能力应该在服务层是可编程、可观察和开放的。
下一场模型竞赛仍将涉及更好的模型。但它也将涉及更好的路由器：知道何时省钱、何时执行安全、何时留在边缘、何时上云、以及何时将一个请求变成一个小型、纪律严明的团队的路由器。
这就是微 agent 在 Model API 内部的承诺。
致谢
我们感谢来自 MBZUAI、麦吉尔大学、Mila 和 Agentic Intelligence Lab 的研究人员，特别是 Prof. Xue Liu 和 Dr. Bowei He，感谢他们在路由器端模型协作方面的研究合作与讨论。
个人贡献者：Huamin Chen、Yincheng Ren。
我们也感谢 AMD 的 Andy Luo 和 Haichen Zhang 提供的 AMD GPU 评估支持。