宽度才是便宜的维度：AI搜索比深度思考更划算

Breadth is the cheap axis

八个电路设计任务里,有七个被一个LLM驱动的搜索方法击败了此前的最优解。这篇论文研究的是量子电路,但真正让人反复回味的,是它把算力花在了哪里。

它没有要求模型"想得更用力"。它让模型大量提出候选方案,然后把真正的预算花在筛选上。模型是这个循环里最便宜的部分,搜索才是昂贵的部分,而收益恰恰藏在那里。

看看大多数agent架构怎么消耗token,你会发现方向完全相反:一条思维链不断拉长,反复叮嘱"仔细推理",更大的上下文窗口。全是深度,没有宽度。深度是你在无法生成替代方案时的选择——当你唯一的动作就是把那一个答案改得更好。

我真正跟踪的数字

N次命中的命中率。N个候选里,至少有一个达到标准的频率是多少?

如果这条曲线随N增长而变平,说明你的采样器坏了。你花了八倍成本,买到八个一模一样的答案。如果曲线在爬升,说明宽度在真正起作用,你应该继续加大N,直到曲线出现拐点。那个拐点就是你的预算线,每个任务都不一样。我从来没猜对过,只能靠测量。

多样性是整个游戏的核心。温度0.2、同一个prompt采样八次,等于一次采样多走了几步。我的经验是,变换提问框架比调整温度更有效——同一个问题,作为约束问题问、作为搜索问题问、作为"什么会打破它"来问。不同的分解方式会产生真正不同的候选。对同一个prompt做微小扰动,只会得到一批"兄弟样本"。

温度（temperature） 是LLM采样时控制随机性的参数，取值通常在0到2之间。温度越低（如0.2），概率分布越尖锐，模型倾向于选择最高概率的token，输出更确定、更保守；温度越高，分布越平坦，低概率token也有机会被选中，输出更发散。但温度调节有一个根本局限：它只改变同一个概率分布上的采样位置，不改变分布本身。因此温度0.2采样八次，往往得到的是同一个答案的微小变体，而非真正不同的思路。这正是文中强调"变换提问框架比调整温度更有效"的原因——改变prompt是从根本上重塑了条件概率分布，而调温度只是在同一个分布上换了个采样点。

N次命中率（pass@N） 是评估生成式模型采样质量的核心指标，源自代码生成领域的pass@k度量。它回答的问题是：如果独立采样N个候选，至少有一个满足目标标准的概率是多少？计算上通常用1减去N个候选全部失败的概率来估计。这个指标之所以关键，是因为它把"模型能力"和"采样策略"解耦了：如果pass@N随N增长迅速趋近于1，说明模型其实"知道"答案，只是单次采样没有命中，此时增加N是高效的；如果pass@N随N增长缓慢甚至持平，说明模型根本没有覆盖正确答案的分布，增加N只是浪费算力。文中所说的"拐点"，就是pass@N曲线的边际收益开始递减的位置，它直接给出了该任务上最优的采样预算。

为什么没人这么做

主要是延迟。扇出感觉更慢,即使实际上并不慢——如果你的服务商允许并发,八个并行调用大约和一个调用同时完成。然后是成本核算问题:按token计费让8倍看起来就是8倍,没人愿意在账单上解释这一项。再就是应用的思维模型是"一个请求,一个响应"。扇出打破了这个模型,你的日志从一条线变成了一棵树。

这些都是真实的阻力。但没有一条构成"这技术不管用"的理由。

扇出（fan-out） 是分布式系统里的经典模式，指一个请求被复制成多个并行副本，分别处理后汇总结果。在LLM agent里，扇出意味着同一个任务并发发起N次采样，然后由筛选器（验证器、打分模型、启发式规则）选出最优候选。扇出与串行"思维链延长"形成对比：后者在单条轨迹上不断自我修正，前者在横向上铺开探索空间。扇出的工程障碍主要在三个地方：一是延迟感知，即使并发调用总时长约等于单次调用，用户心理上仍觉得"发八个请求"更慢；二是按token计费让成本呈线性放大，缺乏摊销机制；三是可观测性，日志从单条线性轨迹变成树状结构，调试和归因变得更复杂。

它在哪里失效

工具调用。

如果每个候选是一条完整的agent轨迹,N个候选就意味着N组副作用。N次写入、N封邮件、N笔扣款。对于文本,采样几乎免费;对于动作,采样极其昂贵。一旦候选开始触碰真实世界,宽度就不再是那个便宜的维度了。

这指向一个我一直在收敛的形态:让执行阶段保持单线程,把宽度放在上游——放在只产生文本的那部分。广泛提议,一次执行。昂贵且不可逆的步骤只给一次机会,便宜且可逆的步骤给尽可能多次。

副作用（side effect） 在agent语境下指的是候选轨迹对外部世界产生的不可逆改变。纯文本生成是幂等的：生成一百个候选，最坏情况只是浪费token，世界状态不变。但一旦候选轨迹包含工具调用——写数据库、发邮件、调用支付API、执行shell命令——每一个候选都会真实地改变外部状态。这使得"先广泛采样再筛选"的模式在结构上失效：你无法在候选执行完毕后再淘汰它们，因为淘汰不能撤销已经发生的副作用。可行的变通包括：在沙箱或事务中执行候选，确认后再提交；或者把有副作用的动作抽象成可回滚的两阶段操作。但这些都需要系统层面的支持，不是简单换个prompt就能解决的。