Micro-Agent：在模型 API 内部通过协作击败前沿模型

背景

当前，AI 行业的焦点高度集中在寻找下一个“前沿模型”（Frontier Models）上。然而，比模型本身更值得关注的层级，可能是位于模型之前的控制平面。

随着生产环境中的 AI 不再依赖单一模型，路由器（Routers）正逐渐成为 AI 推理的控制中枢。其最初的角色是实用性的：将正确的请求路由到正确的模型。这一功能至关重要，因为路由器不仅能通过判断何时需要前沿模型、何时开源或本地模型已足够来降低成本，还能通过执行安全策略（如将敏感领域请求发送至更严格的模型或过滤器）来保障安全，并协调云端与边缘计算，将私密或低延迟意图保留在本地，而将复杂任务升级至云端。

然而，路由器的下一个角色更具变革性：路由器可以让模型变得更好。

这种改进并非通过修改模型权重，也不是要求每个应用程序构建定制化的智能体图（Agent Graph），而是通过将一次模型 API 调用转化为服务层内的有界协作（Bounded Collaboration）来实现。Sakana AI 推出的 Fugu 项目正是基于这一简单但强大的理念：一个“模型”可以只是一个表面，其背后可以是一个团队。相关的学术研究（如 Fugu 技术报告、Conductor 和 Trinity 等协调论文）为思考编排问题提供了有用的语言。

vLLM Semantic Router 的愿景与此不同，它将该抽象定位在开放的服务层中。协作不应仅存在于某个商业端点或特定于应用的智能体图中，而应成为一种开放的服务原语（Serving Primitive）。

核心内容

vLLM Semantic Router 将这一理念带入开放的服务层。对用户而言，调用依然是一个模型：

在该稳定的模型身份背后，路由器可以选择一个“配方”（Recipe），向工作节点扇出（Fan out），收集法定人数（Quorum），验证分歧，合成最终答案，修复输出契约，并返回一个标准的 OpenAI 兼容响应。

其核心目的不是暴露复杂性，而是让协作感觉像一个模型。

Looper 是运行时

在 vLLM Semantic Router 中，Looper 是有界微智能体（Micro-agents）的执行运行时。

请求以普通的聊天补全（Chat Completion）形式进入路由器。路由器提取信号，将其投影到任务形状或风险带中，匹配决策，然后选择算法。该算法可以是正常的单模型路由，也可以是 Looper 路由。

目前主要的 Looper 模式包括：

• Confidence（置信度）：一种顺序升级循环。它首先尝试一个更便宜或更小的候选模型，测量置信度，仅当分数过低时才进行升级。
• Ratings（评级）：一种有界扇出循环。它在严格的并发上限下运行多个候选模型，并使用评级感知的权重聚合结果。
• ReMoM (Repeated Mixture-of-Model)：重复的混合模型推理。它扇出广度样本，等待足够多的成功响应，然后运行最终的合成轮次。
• Fusion（融合）：一种“小组评审-最终裁定”模式。独立的模型响应成为评审者（Judge）和最终裁定者（Finalizer）的证据。
• Workflows（工作流）：微智能体工作流运行时。它支持静态角色或动态规划器，执行有界的工作者步骤，并合成最终响应。

实现细节至关重要。Looper 不是“询问更多模型”的口号，而是一个具有预算、拓扑、追踪和故障策略的小型运行时。

1. Confidence：仅在困难案例上花费升级成本

Confidence 是一种成本感知的循环。它从较小或较便宜的候选模型开始，评估答案是否足够自信以停止处理。置信度信号可以来自 token 级的对数概率（log probability）、logprob 边际、混合分数、自我验证或 AutoMix 风格的蕴含验证器。

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

2. Ratings：在硬限制下的并行质量

Ratings 是一种受控的集成循环。它并行启动几个候选模型，但仅限于配置的 max_concurrent 上限。这使得它在路由需要从多个模型视角受益，而不愿将每个请求变成无界扇出时非常有用。

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

3. ReMoM：带有契约的广度

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

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

4. Fusion：将分歧作为信号

Fusion 基于不同的假设。有时有用的对象不是平均答案，而是分歧的结构。独立的小组回答成为证据。评审者看到一致、矛盾和独特见解，然后最终裁定者返回一个答案，并将追踪过程折叠在 API 背后。

这使得 Fusion 在存在合理竞争路径时特别有用：例如困难的多项选择推理、长篇幅专家判断，或单一自信响应可能脆弱的精确答案任务。

5. Workflows：预算下的角色

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

对于 SWE（软件工程师）风格的任务，这意味着路由器可以表达规划器、修补程序、验证器和最终裁定者，而无需让应用程序拥有定制的智能体堆栈。对于生产服务，这种区分至关重要：循环功能强大，但仍受基础设施治理。

Auto Recipes：一个模型名称，多种循环

公共表面保持为一个模型名称：vllm-sr/auto。在内部，路由器可以利用信号和投影为请求选择正确的循环。

难度、风险、契约压力、延迟和成本不再是提示词中的注释，而是可以选择 Confidence、Ratings、ReMoM、Fusion、Workflows 或回退路径的路由事实。

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

配方胜过单一通用循环

评估工作最重要的教训不是某种算法总是获胜。恰恰相反：

最好的循环是由任务形状决定的。

• GPQA-Diamond 需要严格的多项选择答案保留。
• LiveCodeBench 需要可运行代码和隐藏测试的鲁棒性。
• Humanity's Last Exam (HLE) 需要分歧解决和精确答案格式化。
• SWE 风格任务 需要规划器、修补程序、验证器和最终裁定者。

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

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

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

这就是为什么路由器侧的协作不仅仅是提示词工程。提示词只是一部分。配方还定义了模型池、模型路由策略等基础设施层面的细节。

关键要点

• 路由器的演进：路由器已从简单的流量分发工具演变为 AI 推理的控制平面，具备成本控制、安全执行和云边协同能力，并进一步发展为通过协作提升模型性能的关键组件。
• 协作即模型：核心思想是将“模型”视为一个表面，其背后是一个由多个模型组成的团队。通过