Transformer 开始「选工具」了：一篇论文证明它能内隐地切换算法

我盯这篇论文好几天了。不是因为它用了什么花哨的架构，而是它问了一个我一直在猜但没人认真验证过的问题：一个 transformer 在推理时，到底知不知道自己在解决哪种问题？

它有没有在「内部打一个标签」，告诉自己现在要用哪种算法来处理当前这条数据？

这篇被 COLM 2026 接收的论文，标题叫《Grounding latent algorithm routing in transformer reasoning》，来自 Xiangbo Zhang 和 Xiaoxu Ma。核心贡献是两个：一个叫 ROUTEBENCH 的诊断基准，和一套针对「算法路由」行为的控制实验。他们设计了一组任务，迫使模型在四种不同的解法家族里自动选择，然后检查它到底能不能做到，以及做到什么程度。

四种算法，一个模型，看它怎么选

ROUTEBENCH 的思路很简单但设计得很干净。它构造了四种数据生成机制，每种都偏向一种经典解法：ridge（全局收缩）、lasso（稀疏）、Huber（鲁棒）、kNN（局部）。问题本身的形式是固定的，但数据背后的「潜规则」在变。模型必须在不知道标签的情况下，仅凭上下文线索感知当前该用哪一套「解题思路」。

论文用了一堆 44M 到 612M 参数的纯 decoder-only transformer，从零开始训练。结果最有代表性的是一张 306M 的模型：它关闭了 80.9% 的「oracle 路由差距」（也就是和上帝视角的完美路由比），路由 F1 达到 84.1。这个数字的意思是，模型不仅能给出正确答案，它的内部状态也真的在「按需切换算法模式」，而不是靠某种万能近似蒙混过关。

这套能力没有被 prompt 的表面形式锁死。换成自然语言描述、打乱 support set 顺序、换同义表述，甚至在四路混合场景下，路由行为依然稳健。论文还加了一组更强的 baseline——一个输入条件的软混合路由和一个无监督 Gumbel 路由器——但它们在路由 F1 和 OOD 表现上都没超过 306M 和 612M 的纯 dense 模型。

真的在「路由」，还是我们想多了？

论文后半段最扎实。他们用 probe 和 activation patching 做了两套控制实验。Probe 的结果是，模型内部确实存在可解码的路由方向向量，不同算法族的激活模式是可分的。Activation patching 更直接：人为干预这些方向向量，模型的输出就会从一种算法族偏向另一种，而且预测精度的损失可控。

这就不是「相关性」了，是因果关系。内部那个路由变量确实在干活。

但论文自己也划了一条清晰的线：这些结果是在受控设定下，从零训练的模型上得到的。它们不意味着任意一个预训练的大语言模型内部已经长出了类似的路由机制，也不代表这种路由能直接推广到开放的自然语言推理场景。目前只能说，dense transformer 有能力发展出这种内部变量——前提是任务结构逼它这么做。

这意味着什么

如果你是在做模型推理、Agent 工具调度、或者 Mixture-of-Experts 相关的工作，这篇论文值得仔细看一遍。它把一个观点掰开揉碎了摆在台面上：模型内部的「能力切换」不一定靠显式的 router 模块或 gating 网络来实现，dense 模型本身就能在隐空间里完成类似的操作。

代价也明显。论文里的模型是从头训练的，ROUTEBENCH 的 task 形式也是高度结构化的。现实世界的长尾问题和模糊指令，能不能也逼出这种路由行为，是下一步的问题。

但至少有一件事清楚了：transformer 不只是在「做模式匹配」，它可能在内部悄悄维护了一张「当前该用什么算法」的标签。而我们才刚刚开始学会怎么读这张标签。

相关链接：
- 论文页面：https://arxiv.org/abs/2607.24471
- PDF：https://arxiv.org/pdf/2607.24471