深度解析塑造未来的技术文章。

混合推理智能体:潜空间思考,文本行动

混合推理智能体把思维链搬进潜空间,token 用量减少 35–55%。它在效率上的收益,以及在可解释性上的代价。

一个 Transformer 神经网络分成两条路径:一条是发光的文本 token,另一条是稠密的连续向量,在一个开关处汇合。
混合智能体在一次生成过程中,在文本思考和连续潜向量之间切换。

关于 LLM 智能体,有个不太舒服的事实:它们生成的大部分 token 都是昂贵的水词。一个解数学题的推理智能体,会毫不犹豫地用全额推理成本写下“让我重读一遍题目”和“到目前为止我发现……”,在修辞性的清嗓子上烧掉的算力,和真正做算术用的一样多。潜推理——把思考放在模型的隐状态里进行,而不是写成文本——一直是显而易见的解法,而一篇关于混合推理智能体的新论文表明它终于可以落地了。但这个显而易见的解法有个代价,这个领域没人愿意付:你再也读不懂模型在想什么了。

这些年我一直看着各个团队尝试让思维链变得更便宜。每种方法都撞上同一堵墙,所以值得搞清楚混合方案到底哪里不同,以及为什么我还是不敢把它部署到任何一个承受不起静默失败的地方。

为什么基于文本的思维链会浪费 Token

思维链是一项真正伟大的发现。让模型把中间步骤写出来,数学、逻辑和多跳问题上的准确率会大幅提升。问题在于,语言作为计算的序列化格式其实很糟糕。文字有损、冗余,而且——对于你的推理账单来说最关键的是——它是顺序生成的。

想想模型在解题前“复述题目”时发生了什么。这是几百个 token 一个一个生成出来的,每个都要完整跑一次前向计算,但信息量几乎为零,因为题目本身已经在上下文里了。现在的推理模型里充满了这类内容。看过当代推理模型推理轨迹的人都见过大段的自我打气、复述和含糊其辞,人类工程师会直接称之为噪声。在带工具调用的智能体任务中情况更糟:模型先描述它打算做什么,然后做,然后再描述它刚刚做了什么。

这些成本在智能体规模下会叠加。一个智能体每次调用工具前都带着冗长的推理前言,连调十次工具,可能有 80% 的 token 预算花在了叙述上。如果你按 token 付费——而你确实是——这就是真金白银。它也是延迟,对于有人在等待的智能体来说这一点至关重要。这也正是推动更便宜、更快的推理档位的同一股压力:瓶颈不在于智能,而在于用文字表达智能的成本。

失败的尝试:截断、蒸馏与纯潜推理

这个领域从三个方向攻过这个问题,每一个都以富有启发性的方式失败了。

尝试一:直接少生成点 token

预算强制、长度惩罚、精简推理的微调——最朴素的思路就是让模型在文本里少想一点。这在一定程度上有效,然后准确率就断崖式下跌。冗长的推理轨迹并非纯粹的浪费,其中一些看似冗余的部分其实是承重的。盲目压缩会把计算和水词一起扔掉,而从外部你分不清哪些是哪些。

尝试二:纯潜推理

思路更优雅:根本不生成思考 token。把模型的输出嵌入直接作为输入喂回去——用连续的“思维向量”取代离散的词——让它在内部推理很多步之后再输出答案。COCONUT 等研究表明,在某些任务上这种方式能以极少的前向计算次数达到甚至超过文本思维链的效果。但纯潜推理对智能体有两个致命问题。第一,外部世界说的是文本:工具 API 接收字符串参数,搜索引擎接收查询词,用户想要的是自然语言的答案。只会用向量思考的模型,在边界处仍然要把一切翻译一遍,而错误恰恰藏在翻译环节。第二,也是大家最爱争论的一点:思考变成了黑盒。推理轨迹完全丢失了,而它恰恰是我们目前了解模型“为什么这么做”的唯一还算靠谱的窗口。

尝试三:停顿 token 与填充式计算

还有一条不太起眼的路线,尝试插入没有实际意义的“停顿”token,在不增加内容的前提下给模型额外的算力。效果喜忧参半,而且从未走出实验室。事实证明,中间 token 的内容对引导计算很重要,而不仅仅是它们的存在。

真正可行的方案:混合推理智能体

HybridAgent 这篇论文采取了我希望更多研究采用的务实立场:不再在潜推理和文本推理之间二选一,而是让模型在生成过程中途自由切换。做内部计算时用潜空间思考;需要调用工具、读取其输出,或者向人类解释自己的时候,就切换回文本。

这个架构有三个值得了解的部分。一个轻量模块叫HybridLink,负责处理切换——把潜段最终的隐状态转换成文本模式的模型可以接着生成的形式,反之亦然。一个连续工作记忆在多轮之间保留完整的混合上下文,因此第一轮的潜思维在第五轮仍然可用,而不是被压缩进文本摘要里。训练方面分两个阶段:HybridSFT 先教会主干模型与 HybridLink 协同工作,然后 HybridRL 用强化学习教它何时使用每种模式才值得付出代价。

在我看来,最后这部分才是真正的贡献。难点从来不是“模型能不能在潜空间里推理”——我们早就知道它可以。难点在于策略:任务中哪些部分值得花便宜但不透明的计算,哪些部分值得花昂贵但可检查的文本。用强化学习、依据真实任务奖励去学习这套策略,才能得到真正能用的东西,而不只是能演示的东西。

论文报告的数字很亮眼:在涵盖数学、科学、医学、搜索和智能体推理的 11 个基准测试中,混合智能体相比文本基线和潜空间基线,声称有约 10% 的性能提升,同时 token 减少 35–55%,推理快 1.8–2.6 倍,成本约降低 3 倍。对单篇论文的基准数字要保持一定的怀疑——基准测试往往无法反映真实工作负载的样子——但结果的方向与理论吻合。如果一条轨迹的大部分是水词,那么去掉大部分轨迹,应该主要去掉成本,而不是能力。

一只机械手伸向工作台上的工具,它头顶上方悬浮着一团半透明的抽象几何图形云,而不是一个对话气泡。
混合路线的押注:工具调用和答案保留在文本中,把推演转移到连续空间。

在代码里,潜推理实际长什么样

从机制上看,这个技巧比听起来简单。在文本模式下,你采样一个 token,把它嵌入,再喂回去。在潜模式下,你跳过采样,直接把模型自己的输出向量——可能先经过一个小的投影层——作为下一步的输入喂回去。一个特殊的控制 token 或一个学习得到的门控决定当前处于哪种模式。示意如下:

def hybrid_step(hidden_state, mode_gate, hybrid_link):
mode = mode_gate(hidden_state)  # learned: LATENT or TEXT
if mode == LATENT:
# No sampling. Feed the continuous thought back in.
next_input = hybrid_link.latent_in(hidden_state)
return next_input, None  # nothing human-readable emitted
# TEXT mode: normal autoregression
logits = lm_head(hidden_state)
token = sample(logits)
next_input = hybrid_link.text_in(embed(token))
return next_input, token  # inspectable output

真实系统还加入了工作记忆和训练机制,但核心循环就是这些。注意这对你的服务架构意味着什么:潜步骤依然是完整的前向计算。你节省的是 token 数量——输出长度、上下文增长,以及长轨迹带来的 KV 缓存压力——而不是每一步的计算量。超过两倍的推理加速主要来自更短的序列和更少的自回归文本解码,而不是免费的思考。论文的一位评论者建议更进一步,让潜路径与文本生成并行运行,因为反正前向计算的开销已经付了。这是个相当有意思的想法,也说明这个设计空间还非常年轻。

没人愿意付的可解释性代价

现在说说我不说就是失职的部分。推理轨迹不只是调试的便利,它还是一种安全机制。当智能体在生产环境中做出怪异举动时,你做的第一件事就是读它的轨迹。当对齐研究人员探测欺骗性行为时,他们会寻找与最终答案相矛盾的推理。一旦把推理搬进向量里,这两种工作流程都会陷入黑暗。

论文声称连续工作记忆让潜思维“可以直接检视”。我会把这句话归为技术上正确、实践上误导。你可以像检视任何隐状态那样检视这些向量:用探测分类器、解码器投影、嵌入空间中的最近邻分析。这是研究级的工具,不是值班时能用的工作流程。这就像是读日志文件和给核心转储挂上调试器之间的区别。我们中有些人对可解释性的过度宣传已经保持警惕很久了,而一个工作记忆缓冲区并不会改变根本的不对称性:文本谁都能读懂,潜变量几乎没人读得懂。

还有一种较少被讨论的失败模式:静默的错误传播。在文本轨迹里,错误的中间步骤是可见的,有时还能自我纠正——模型在重读时会发现自己的错误。而错误的潜思维会在工作记忆中传播,却不留下任何文本痕迹。无论潜空间里的推演是合理还是垃圾,智能体的最终答案看起来都同样流畅。对于在生产环境中运行智能体的团队来说,这直接关系到遏制与监控之间的权衡:混合智能体会把你推向遏制,因为监控已经变得难了很多。

这篇论文的讨论中有人指出,出于上述原因,潜推理在研究界的部分圈子里曾被默认禁忌。这个禁忌显然已经过去了。我并不认为这必然是坏事,但那些为效率数字欢呼的人应该坦诚:他们是在用可解释性换取这些数字。

论文与你的 GPU 之间的差距

代码、权重和数据都是公开的,这非常好。它也很快带来了现实的检验。几个小时内,在本地运行已发布模型的开发者就报告了退化行为:一个量化的 8B 版本在回答“教皇是谁”时,陷入无限重复同一段文本模式的推理;一个 14B 版本在一个常规的搜索加摘要任务上,围绕同一段内容的变体循环了五分钟,而同类模型处理这种任务完全没问题。

也许这些是量化的副作用,或者聊天模板不匹配——对于全新架构,llama.cpp 的支持总是碰运气。但我怀疑循环失败并非巧合。模式切换是一种习得的行为,而习得的行为恰恰是量化和分布偏移最先破坏的东西。一个潜文本策略稍有偏差的模型,不会大声地失败,而是永远不决定停止思考。对于生产环境的智能体,这比给出错误答案的模式危险得多,因为它会无限期地烧预算。如果你今天正在构建智能体循环,这又是一个理由:无论采用哪种推理范式,都应该在每次模型调用周围设置严格的轮次和 token 预算——这正是智能体 CLI 如何组织循环中讨论的那类纪律。

一个飞行员的驾驶舱,仪表盘一半是清晰可读的仪表,另一半是光滑不透明的玻璃面板,内部隐约发出图案的光。
仪表盘的一半清晰可读,另一半闪烁着只有机器才懂的图案。

那么你该在意吗?一个务实者的结论

该在意,但应把它当作路标,而不是依赖项。我的诚实判断是:

  • 效率的论点是真实的,也是结构性的。文本是内部计算的糟糕媒介,随着智能体的任务周期越来越长,叙述的 token 税只会越来越高。某种形式的潜推理迟早会进入生产模型,不管我们喜不喜欢——可以说,前沿实验室那种不透明的“推理摘要”做法,已经是朝这个方向迈出的一步。
  • 可解释性的代价也是真实的,而且目前被严重低估。如果你的场景需要审计智能体为什么这样行动——医疗、金融,或任何受监管的领域——文本轨迹是一项你放弃就要自担风险的功能。
  • 当前的产物仍处于研究级别。简单提示上的退化循环、不确定的量化行为,以及难以检查的模式切换策略,都不是你应该放在面向客户的 API 后面的东西。
  • 混合的框架是正确的。纯潜推理从来经不起工具 API 和用户的考验;纯文本推理则经不起推理账单的考验。两者之间一个习得的边界,才是这件事最终的归宿。

更深层的一点是,“用文字思考”一直只是我们训练这些模型的方式所导致的偶然,而不是认知的规律。没有任何定理说语言是机器思维的正确粒度——令人意外的是它竟然效果这么好。混合推理智能体是对“之后会是什么”的第一个可信草图:模型私下里深思熟虑,只在需要开口的时候才说话。我认为,我们能否在构建那样的未来的同时,不丧失检查机器工作的能力,是当下智能体设计中最重要的开放问题。