微代理：通过模型API内部协作超越前沿模型

# Micro-Agent：将协作嵌入模型API，突破前线模型 来源：https://vllm.ai/blog/2026-06-29-micro-agent-frontier-models 每个人都在期待下一个前沿模型。 但更有趣的层面，可能是它前面的那一层。 路由器正在成为AI推理的控制面。它们最初的职责很务实：将正确的请求路由到正确的模型。这之所以重要，是因为生产环境下的AI已经不再是单一模型的世界。 路由器可以通过决策何时该用前沿模型、何时开源或本地模型就足够，来降低成本。它可以通过将敏感领域路由到更严格的模型、更严格的过滤器或更强的审查路径，来使安全策略得以执行。它还可以协调云端与边缘计算，将私有或低延迟的意图留在本地，而将更困难的任务升级到云端。 这些都是重要的任务。 但路由器的下一个任务更有意思： > 路由器可以让模型变得更好。 不是通过改变权重。也不是要求每个应用都构建一个定制的智能体图。而是将一个模型API调用转变为服务层内部一个受约束的协作。 图1：路由器正从模型选择转向能力构建。 这就是Sakana Fugu (https://sakana.ai/fugu/) 引起如此大反响的原因：它把一个简单但强大的想法变成了商业产品——"模型"可以是一个界面，而这个界面背后可以是一个团队。围绕这个想法的研究，包括Fugu技术报告 (https://arxiv.org/abs/2606.21228) 以及协调方面的论文如Conductor (https://arxiv.org/abs/2512.04388) 和Trinity (https://arxiv.org/abs/2512.04695)，为思考编排提供了有用的语言。 但 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）**：一个微智能体工作流运行时。它支持静态角色或动态规划器，执行受约束的 worker 步骤，并合成最终响应。 图2：Looper 算法在路由器内部运行，同时保留模型 API 接口。 实现细节很重要。Looper 不是“多问几个模型”的口号。它是一个小型的运行时，拥有预算、拓扑、跟踪和故障策略。 ### 置信度：只在困难案例上花费升级成本 置信度是一种成本感知的循环。它从一个较小或较便宜的候选开始，然后评估答案是否足够自信以停止。置信度信号可以来自 token 级的对数概率、对数概率边际、混合分数、自我验证或 AutoMix 风格的蕴涵验证器。 如果分数超过阈值，路由器立即返回。如果分数太低，路由升级到下一个候选。重要的不是存在升级，而是升级成为显式的路由器策略：阈值、失败行为和停止条件都是可见且可调的。 图3：置信度将升级转化为可测量的停止策略。 ### 评分：在硬上限下的并行质量 评分是一种受控的集成循环。它并行启动多个候选，但仅限制在配置的 `max_concurrent` 上限内。这使得它在需要从多个模型视图中获益，但又不想让每个请求变成无限制扇出的场景下非常有用。 路由器收集成功的响应，应用评分感知的聚合，并根据路由策略处理失败。在实践中，评分非常适合 A/B 风格评估、集成策略，以及操作者已经拥有有意义的每个候选质量信号的路由。 图4：评分保持多候选执行在界限内且评分感知。 ### ReMoM：带契约的广度 当任务具有高推理方差且答案格式必须经受住协作考验时，ReMoM 非常有用。它扇出多个推理尝试，等待最小成功法定人数，然后要求一个合成模型将证据合并到所需的输出契约中。 如果合成失败但之前的 worker 产生了有效的证据，路由不必崩溃为 API 错误。它可以回退到最佳有效证据，并仍然返回正常的响应。 图5：ReMoM 将广度、法定人数、合成和回退视为服务时控制。 ### 融合：将分歧视为信号 融合从一个不同的假设开始。有时有用的对象不是平均答案；而是分歧的结构。独立的专家组答案成为证据。评审看到一致性、矛盾和独特见解，然后终审者返回一个答案，同时跟踪信息折叠在 API 背后。 这使得融合在存在看似合理的竞争路径时尤为有用：困难的多选推理、长篇专家判断，或者单个自信响应可能脆弱的精确答案任务。 图6：融合不隐藏分歧。它将分歧转化为证据。 ### 工作流：预算下的角色 工作流是最具智能体特征的模式，同时也是最需要严格边界的模式。规划器只能选择允许的 worker 模型。计划被验证。步骤受最大步数、最大并行度、超时和错误策略约束。最终响应仍然需要满足输出契约。 对于 SWE 风格的任务，这意味着路由器可以表达规划器、补丁器、验证器和终审者，而无需让应用程序拥有自己的定制智能体栈。对于生产服务来说，这一区别至关重要：循环很强大，但它仍然受基础设施治理。 图7：工作流为路由器提供了有边界的角色系统，而非无限制的自主智能体。 ### 自动配方：一个模型名称，多种循环 公共表面仍然是一个模型名称：`vllm-sr/auto`。在内部，路由器可以使用信号和投射来为请求选择正确的循环。难度、风险、契约压力、延迟和成本不再是提示中的注释。它们是路由事实，可以选择置信度、评分、ReMoM、融合、工作流或回退路径。 图8：自动配方让信号选择协作模式，同时保留单一的模型身份。 这就是"智能体即应用逻辑"与"微智能体即服务运行时"之间的区别。路由器控制预算、策略、拓扑、跟踪和故障模式。 ## 配方胜过单一通用循环 我们从评估工作中得到的最重要教训不是某一种算法总是赢。 恰恰相反： > 最好的循环是任务定制的。 GPQA-Diamond 需要严格的多选答案保留。LiveCodeBench 需要可运行代码和隐藏测试的鲁棒性。Humanity's Last Exam 需要分歧解决和精确答案格式化。SWE 风格的任务需要规划器、补丁器、验证器和终审者。 这就是为什么 `vllm-sr/auto` 不应该意味着"总是运行最大的循环"。它应该意味着：选择适合这个任务的配方。 图9：信号和投射让路由器选择与基准测试形状匹配的协作模式。 在我们的配方中，这种形状是显式的： - GPQA-Diamond 将硬科学多选提示路由到一个具有严格 `ANSWER: X` 保留的 ReMoM 配方。 - LiveCodeBench 在选择代码形状循环之前，寻找约束、起始代码、标准输入、浮点容差、超时风险和隐藏测试风险。 - HLE 检测形式推理、分歧风险、长上下文和精确答案压力，然后选择更深的 ReMoM、较小的融合或回退路径。 这就是为什么路由器侧的协作不仅仅是提示工程。提示只是其中一部分。配方还定义了模型池、模型角色、推理努力、并发度、法定人数、超时、合成模型、回退策略、输出契约和可观测性标签。 ## 记分卡是证明，但不是全部故事 我们在三个硬基准上评估了当前的闭源模型配方。这些数字很有用，因为它们表明这个想法不仅仅是美学上的。 图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 表面。 这才是真正的产品形状： - 用户看到一个模型名称。 - 操作者控制配方。 - 系统可以在不更改客户端集成的情况下改进。 - 开源和闭源模型可以在相同的服务抽象下参与。 ## 这对模型服务意味着什么 旧的服务栈是被动的。它接受模型名称并将请求发送到后端。 下一个服务栈是主动的。它会问： - 关于这个请求，我们有什么证据？ - 它属于什么质量、成本、延迟和安全区间？ - 一个模型够了吗？ - 如果不够，应该运行什么协作模式？ - 必须保留哪个答案契约？ - 如果某个提供者慢或出错，应该怎么办？ - 如何暴露一个干净的响应，同时保留完整的跟踪？ 那不是应用胶水。那是基础设施。 微智能体属于路由器，因为路由器已经拥有微智能体所需的一切：模型别名、提供者策略、凭证、成本元数据、信号、决策、重试、超时、跟踪和 OpenAI 兼容的响应语义。 ## 总结 "前沿模型"这个短语开始意味着两件事。 一个是检查点。 另一个是系统边界。 最近的编排浪潮使这个方向变得可见。vLLM Semantic Router 的赌注是：这种能力应该是可编程的、可观测的和开放的服务层原生的。 下一轮模型竞赛仍将涉及更好的模型。但它也将涉及更好的路由器：知道何时省钱、何时强制执行安全、何时留在边缘、何时上云，以及何时将一个请求转化为一个小的、纪律严明的团队。 这就是模型 API 内部微智能体的承诺。 ## 致谢 我们感谢来自 MBZUAI (https://mbzuai.ac.ae/)、McGill University (https://www.mcgill.ca/)、Mila (https://mila.quebec/) 和 Agentic Intelligence Lab (https://agentic-in.ai/) 的研究人员，尤其是 Prof. Xue Liu (https://www.linkedin.com/in/xueliu) 和 Dr. Bowei He (https://www.linkedin.com/in/bowei-he-8a9450199/)，感谢他们在路由器侧模型协作方面的研究合作与讨论。 个人贡献者：Huamin Chen (https://www.linkedin.com/in/huaminchen/)，Yincheng Ren (https://www.linkedin.com/in/yincheng-ren/)。 我们还感谢 AMD 的 Andy Luo (https://www.linkedin.com/in/andyluo77/) 和 Haichen Zhang (https://www.linkedin.com/in/haichen-zhang-9010b6382/) 提供的 AMD GPU 评估支持。