Multi-Head Latent Control：让智能体从“内部状态”判断何时回答、求助或调用工具

导语

随着大语言模型被包装成智能体，系统真正要解决的已不只是“生成下一个 token”。一个可用的智能体需要在运行中判断：当前模型是否足够强，是否应该把任务交给更大的模型，用户信息是否不足，是否需要外部工具，或者在条件不允许时直接 abstain（不作答）。论文 Multi-Head Latent Control 给出的思路是：不要只看输入，也不要完全依赖外部规则，而是读取模型生成过程中的隐藏状态，让模型的“内部轨迹”成为决策信号。

核心要点

• 从输入路由转向潜在状态路由：现有方案常用提示词、外部编排器或任务定制微调来决定路由和工具调用，维护成本高，并且模型底座变化后往往需要重做适配。该论文尝试直接从冻结 LLM 或 VLM 的隐藏状态轨迹中提取控制信号。
• 两个控制头分工明确：Capability Head 用来预测当前模型能否解决该实例，还是应交给更强的协作者；Resolution Head 则预测更合适的处理方式，包括请求澄清、调用工具、拒答或直接回答。
• 不修改主模型：两个头只基于同一冻结模型产生的 latent traces 训练，因此更像是部署后加装的轻量控制层，而不是重新训练整个智能体。
• 支持早期交接：论文强调，该方法可以从部分生成中提前判断是否需要 handoff，避免小模型继续消耗 token 后才发现能力不足。
• 实验收益集中在质量—成本权衡：在小模型加大模型的路由执行中，论文报告 AndroidWorld 上大模型使用量最高减少 90.7%，跨基准平均减少 27%–53%，同时保留大模型大部分性能。工具使用方面，控制信号带来最高 +158% 的相对得分提升，并使漏掉必要工具调用的情况减少 65.5%。

意义与影响

这项工作的重要性在于，它把智能体控制从“外部流程工程”部分拉回到模型自身的生成动态中。对企业部署而言，如果轻量头能稳定判断哪些请求需要升级、哪些请求必须用工具，就有机会降低大模型调用成本，同时减少错误自信回答。

不过，这也提出新的工程问题：隐藏状态访问、不同模型架构的适配、控制头训练数据构造，以及在真实生产环境中如何评估误路由风险。尤其是拒答、工具调用和模型升级都涉及用户体验与安全边界，不能只看平均指标。

总体来看，Multi-Head Latent Control 提供了一种有吸引力的智能体接口：让 LLM 不仅输出答案，也输出关于自身能力和下一步动作的控制信号。若后续能在更多开放场景中验证，它可能成为多模型智能体系统中比手写规则更可维护的调度层。

来源：Hugging Face Daily Papers