最近读到arXiv上那篇关于LLM推理轨迹中搜索树的分析（2605.06840），感觉终于有人开始拆解“规划”这个黑盒了。论文通过四子棋游戏提取推理轨迹中的搜索树，并拟合计算模型，核心发现是：LLM所谓的“规划”其实更接近短视的局部搜索，而非全局最优的树搜索。

从一线工程实践看，这个结论和我部署推理模型时的经验高度吻合。比如在代码生成任务中，模型经常在几步之内就陷入局部最优，生成一段看似合理但后续无法扩展的代码。论文里量化的搜索树深度和宽度指标，恰好解释了为什么我们做prompt工程时，必须显式引导模型“回头检查”或“模拟未来步骤”——因为模型默认的推理轨迹本质上是一条短视的贪心路径。

我比较质疑的是，论文用四子棋这种完全信息、规则封闭的游戏来建模，是否真的能推广到开放域文本生成？现实场景中，LLM的“规划”还涉及知识检索、常识推理等非确定性因素。不过，至少这篇工作给了我们一个工具：通过提取搜索树的拓扑结构，可以量化不同prompt策略对规划深度的改变。

抛两个问题给各位：1）在实际产品中，你们是否观察到模型在长链推理任务中（如多轮对话、代码debug）有明显的“短视”现象？2）如果搜索树结构真是关键，我们能否设计专门的fine-tuning或reward shaping来迫使模型扩展搜索宽度？

行业趋势上，我认为这预示着LLM评估会从“答案正确率”转向“推理过程的结构质量”。未来，搜索树的熵、深度分布这类指标可能成为模型选型的新标准，比单纯的perplexity更有工程指导意义。