Micro-Agent：在模型 API 内部用协作击败前沿模型
大家都在关注下一个前沿模型，但更有趣的可能是模型前面的那一层——Router（路由器）正在成为 AI 推理的控制平面。
Router 的第一角色是路由：将正确请求发给正确模型。它可以根据请求的价值决定是否值得用前沿模型，也可以做安全策略——敏感领域走更严格的模型或审查路径。但下一个角色更有趣：Router 可以让模型变得更强——不改变权重，而是在服务层内部组织一次有界的多模型协作。
核心思想：用户仍然调一个模型 API（vllm-sr/auto），但在那个稳定的模型身份背后，Router 可以选择一个 recipe（配方），fan-out 给多个 worker，收集多数意见，验证分歧，综合最终答案，返回一个标准的 OpenAI 兼容响应。
Looper 执行运行时
Looper 是执行运行时，支持五种协作模式：
Confidence（置信度）
先用便宜模型试，置信度不够就升级到更强的。关键不是升级本身，而是升级成为显式的 Router 策略——阈值、失败行为、停止条件都可见可调。
Ratings（评分）
受控的并行集成，在硬并发上限内并行跑多个候选。适合 A/B 评估和集成策略。
ReMoM（重复混合模型推理）
多个推理尝试并行展开，等待足够成功响应后，让一个合成模型合并证据。
Fusion（融合）
不是隐藏分歧，而是将分歧转化为证据。独立的模型回答成为证据，judge 看到一致/矛盾/独特见解，finalizer 返回最终答案。
Workflows（工作流）
最 agentic 的模式，但边界最严格。planner 只能选允许的 worker 模型，计划需验证，步骤有最大并行数和超时策略。
Auto Recipes
对外只有一个模型名 vllm-sr/auto，内部 Router 根据信号（难度、风险、延迟、成本）自动选择最佳 loop。
关键发现：不同基准需要不同的 loop
GPQA-Diamond 要严格多选答案保留，LiveCodeBench 要可运行代码和隐藏测试鲁棒性，SWE 需要 planner/patcher/verifier/finalizer。
评测结果
VSR Closed 在 LiveCodeBench 上 92.6（vs Fugu Ultra 92.0），GPQA-Diamond 96.0（vs Fugu Ultra 95.5），HLE 50.0（vs Fugu Ultra 50.0）。VSR Hybrid 在 HLE 47.1（vs GLM-5.2 40.5）。
结论
Router 拥有的协作可以创造出比底层单个调用更强的模型身份，同时保持一个 API 表面。这是真正的产品形态——用户只看到一个模型名。未来方向包括更丰富的信号、自适应配方、分布式 worker 集群等。
原文出处：https://vllm.ai/blog/2026-06-29-micro-agent-frontier-models
