1. 长程智能体推理瓶颈到底卡在哪做长程任务智能体long-horizon agents的人大概率都经历过这种场景一个需要几十步甚至上百步才能完成的任务比如跨多个数据源做调研、自动修复一个复杂代码仓库里的连锁缺陷、或者模拟一个持续数小时的交互式决策流程单条推理链路跑到中途就开始漂移——前面几步还靠谱越往后越容易跑偏最后要么超时要么给出一个看似完整实则漏洞百出的结果。这个问题的根源不在于模型单步能力不够而在于长程任务把误差累积放大了。每一步推理都有一定概率出错步数一多正确完成整条链路的概率就指数级衰减。假设单步正确率是 95%跑 50 步之后整体成功率只剩 0.95^50 ≈ 7.7%。这就是为什么很多 demo 在短任务上惊艳一放到真实长程场景就拉胯。传统的应对手段无非两类一是把单步做得更准换更强模型、加更多监督二是把链路做短任务分解、减少依赖。但这两条路都有天花板——模型能力提升边际递减任务本身的长度又是由问题决定的砍不掉。于是parallel test-time scaling并行测试时扩展进入了视野。它的核心思路很直白既然单条链路容易崩那就在推理阶段同时跑多条独立链路用算力换成功率。这跟训练时的 scaling law 是两回事——训练扩展是堆参数堆数据测试时扩展是在推理那一刻堆并行度。而把它用在 long-horizon agents 上就变成了一个非常具体的工程问题怎么并行、并行多少条、怎么选、怎么合并、成本怎么控。这篇内容就是围绕这个主题展开的。我会把并行测试时扩展在长程智能体里的落地逻辑拆开讲包括它为什么有效、并行策略怎么设计、验证与选择机制怎么搭、成本怎么算、以及我在实际搭建中踩过的坑。适合已经了解基础 agent 框架、想进一步优化长程任务成功率的同学也适合刚接触 test-time scaling 概念、想搞清楚它和训练扩展区别的读者。2. 并行测试时扩展为什么对长程任务特别有效2.1 从单链路赌博到多链路投票的思维转变先把这个概念讲透。测试时扩展的本质是承认单次推理是一个随机过程。同一个 prompt、同一个模型因为采样温度、随机种子、甚至底层算子的非确定性每次跑出来的轨迹都不一样。短任务里这种随机性影响不大因为几步就结束了方差有限。但长程任务里随机性会被逐步放大最终结果的分布可能非常分散——有的链路成功有的失败有的跑出完全不同的解法。并行测试时扩展就是利用这种分散性与其赌一条链路不如同时开 N 条然后从 N 个结果里挑最好的或者做聚合。这在数学上等价于对成功概率做多次独立采样。如果单条链路成功率是 p跑 N 条独立链路至少有一条成功的概率是 1-(1-p)^N。还是用刚才的例子p7.7%跑 8 条并行链路至少一条成功的概率就变成 1-0.923^8 ≈ 47%。这个提升是实打实的而且不需要重新训练模型。关键在于独立两个字。如果 N 条链路之间高度相关比如都用同一个贪心解码那并行就是浪费算力因为它们会犯同样的错。所以并行测试时扩展要真正生效必须保证链路之间有足够的多样性——这就要靠采样策略、温度设置、甚至 prompt 的轻微扰动来实现。2.2 长程任务里部分正确比全错更有价值短任务往往是二元的答案对就是对错就是错。但长程任务有个特点——中间过程本身携带信息。一条链路即使最终失败了它可能在前 30 步都走对了只是在某个分叉点选错。这种部分正确的轨迹对最终选出正确答案极有价值。这就引出了并行测试时扩展在长程场景下的第二个优势可以做过程级的验证和重组。不是简单地从 N 个最终答案里投票而是可以分析每条链路的中间状态找出哪些步骤是共识多条链路都这么做哪些步骤是分歧点然后在分歧点上做更细粒度的探索。这种分叉-验证-回溯的模式比单纯的多答案投票要精细得多也更适合长程任务。我实测下来对于超过 30 步的任务纯结果投票的收益会明显下降因为最终答案的形态可能差异很大没法直接比。反而是过程级的验证——比如检查关键中间产物是否一致、关键决策点是否合理——能带来更稳定的提升。2.3 并行度和任务长度的关系不是线性的很多人第一反应是任务越长并行度就该越高。这个直觉部分对但有个陷阱并行度提升带来的收益会饱和而成本是线性增长的。从 1-(1-p)^N 这个公式看当 N 增大时成功率趋近于 1但增速越来越慢。当 p 本身很低长程任务常见你需要很大的 N 才能看到明显效果但每增加一条链路的边际收益在递减。同时长程任务单条链路的成本本来就高几十上百步的推理N 条并行意味着成本直接乘以 N。所以实际设计时不能无脑堆并行度。我的经验是先测出单链路的成功率 p然后根据可接受的成本预算反推 N。如果 p 已经低到 5% 以下与其堆并行度不如先优化单链路质量比如改进任务分解、加中间检查点把 p 拉到 15%-20% 再并行性价比高得多。这个先修单链路再上并行的顺序是我踩了不少坑才总结出来的。3. 并行链路怎么设计才能保证多样性3.1 采样温度只是最表层的手段提到让并行链路多样化大多数人第一反应是调高采样温度。这确实有用但远远不够。温度调高会带来两个问题一是链路质量整体下降高温下模型更容易胡说二是多样性可能集中在低价值的随机噪声上而不是真正有意义的解法差异。更有效的做法是在多个维度上同时引入受控的多样性。我通常会把多样性来源分成三层解码层多样性温度、top-p、top-k 的组合变化。这一层最廉价但收益也最浅。提示层多样性对任务描述做轻微改写、调整指令顺序、改变 few-shot 示例的选择。这一层能带来解法路径的差异价值更高。策略层多样性给不同的链路分配不同的角色或探索偏好比如一条链路偏保守优先选确定性高的动作一条偏激进愿意尝试不确定但可能更优的动作。这一层最贵但对长程任务最有效。实测下来单纯调温度带来的成功率提升大概只有策略层多样性的三分之一。所以如果算力有限我宁愿少开几条链路也要保证每条链路的策略有实质差异。3.2 用分叉点而不是从头并行来省算力从头并行 N 条完整链路成本是 N 倍这对长程任务来说很奢侈。一个更聪明的做法是只在关键分叉点并行。具体来说先跑一条主干链路在它做出重要决策的节点比如选择调用哪个工具、选择哪条推理路径记录下来。然后在这些分叉点上额外展开几条备选路径形成一棵推理树而不是 N 条独立直线。这样算力集中在真正有不确定性的地方而不是均匀地浪费在那些所有链路都会走对的简单步骤上。这个思路其实就是把并行测试时扩展和树搜索结合起来。它的好处是成本可控——你不需要 N 倍算力可能只需要 1.5 到 2 倍就能覆盖大部分关键分叉。代价是实现复杂度上升需要一套机制来识别什么是关键分叉点。我的做法是用一个轻量的打分器对每个决策点的不确定性打分比如看模型在该点的输出熵超过阈值才展开并行。3.3 链路之间要不要共享信息这是个容易被忽略但很关键的设计选择。完全独立的链路互相不通信实现简单但浪费了信息。完全共享所有链路实时同步状态又会导致多样性坍缩——大家很快收敛到同一条路径。我倾向于阶段性共享链路在前期独立探索保持多样性到了某个检查点比如任务过半做一次信息汇总把各条链路发现的关键事实或已验证的中间结论提取出来再分发给所有链路作为后续推理的上下文。这样既保留了探索阶段的多样性又能在后期利用集体智慧减少重复犯错。这个机制在需要大量外部信息收集的长程任务里特别有用。比如一个调研类 agent前期各条链路分头查不同来源中期汇总去重后期基于汇总结果做综合判断。实测这种先分后合的模式比全程独立或全程共享都要好。4. 结果验证与选择并行之后怎么挑出对的4.1 多数投票在长程任务里经常失效并行跑完 N 条链路最直觉的选择方法是多数投票——哪个答案出现次数多就选哪个。这个方法在短问答任务里很好用但在长程任务里经常失效原因有两个。第一长程任务的最终答案往往是结构化或自由文本不是简单的选项没法直接统计频次。两条链路可能表达的是同一个意思但字面完全不同投票机制识别不了。第二长程任务里错误答案可能比正确答案更一致。因为错误往往来自模型共同的偏见或盲区多条链路会以相似的方式犯错反而正确答案因为需要更多巧合才能凑齐显得少数派。这时候多数投票会系统性地选错。所以长程场景下验证机制必须比投票更聪明。我一般会用分层验证先做粗筛过滤掉明显失败的链路比如中途报错、超时、输出格式不对的再做细评对剩下的链路做质量打分最后才在高质量候选里做选择。4.2 用过程一致性作为验证信号一个很实用的验证信号是过程一致性。具体做法是把每条链路的中间步骤提取出来看关键步骤上各链路是否一致。如果多条独立链路在某个中间结论上达成一致这个结论的可信度就很高如果某条链路在关键步骤上和其他链路都不同那它要么是发现了新东西要么是跑偏了需要重点审查。这个信号的价值在于它不依赖最终答案的形态而是看推理过程。对于长程任务过程往往比结果更能反映质量。我通常会计算一个一致性分数把关键步骤分成若干检查点统计每个检查点上各链路的一致性然后给一致性高的链路更高权重。需要注意的是一致性高不等于正确——如果所有链路都犯了同一个错一致性也会很高。所以这个信号要和其他验证手段结合使用不能单独作为判据。4.3 引入外部验证器做最终裁决最可靠的做法是引入一个独立的外部验证器。它可以是一个专门训练的奖励模型也可以是一个规则引擎甚至可以是另一次独立的模型调用用不同的 prompt 让模型自己检查。对于有明确成功标准的任务比如代码能否通过测试、数学答案能否代入验证外部验证器最直接——直接跑测试、代入验证就行。对于开放式任务验证器可以是一个打分模型对候选答案的质量、完整性、逻辑一致性打分。我的经验是验证器的质量直接决定了并行扩展的最终收益。如果验证器很弱跑再多并行链路也挑不出好的如果验证器很强甚至不需要太多并行度就能选出正确答案。所以在资源分配上我会把相当一部分精力放在打磨验证器上而不是一味增加并行链路数。5. 成本账怎么算并行扩展的性价比边界5.1 把成功率提升换算成每单位算力收益做并行扩展最怕的是为了提升而提升最后算力花了一大堆成功率只涨了几个点。所以必须建立一个清晰的性价比模型。我的做法是定义一个指标每增加一单位算力比如每多跑一条链路成功率提升多少。用前面那个公式成功率是 1-(1-p)^N对 N 求导得到边际收益是 -(1-p)^N · ln(1-p)。当 N 增大时这个值单调递减。也就是说并行度越高每多一条链路的边际收益越低。实际决策时我会画一条曲线横轴是并行度 N纵轴是成功率同时叠加一条成本线。两条线的交点附近就是性价比最优点。超过这个点继续加并行度就是纯烧钱。这个最优点通常在 N4 到 N16 之间具体取决于单链路成功率 p 和任务成本。5.2 长程任务的隐性成本延迟和资源占用除了直接的算力成本长程任务的并行扩展还有两个隐性成本容易被忽略。一是延迟。并行 N 条链路如果资源充足理论上总延迟和单条差不多同时跑。但现实中资源往往有限N 条链路可能要排队或者争抢资源导致总延迟上升。对于有实时性要求的场景这个延迟可能比算力成本更致命。二是资源占用。长程任务单条链路可能占用大量内存要维护长上下文、大量工具调用配额要反复调外部 API。N 条并行意味着这些资源都要乘以 N。如果外部工具有速率限制并行反而会因为互相挤占而变慢。所以我在设计并行方案时会先做一次资源盘点内存够不够、工具配额够不够、延迟要求能不能满足。如果资源紧张宁可降低并行度或者改用前面说的分叉点并行来省资源。5.3 什么时候该放弃并行回去优化单链路这是最重要的一条经验并行扩展不是万能药它有明确的适用边界。如果单链路成功率 p 已经很低比如低于 5%并行扩展的性价比会非常差——你需要极大的 N 才能把成功率拉到可用水平成本高到不现实。这种情况下正确的做法是先回去优化单链路检查任务分解是否合理、提示是否清晰、工具是否好用、中间检查点是否到位。把 p 拉到 15% 以上再考虑并行。另一个该放弃并行的信号是失败模式高度一致。如果 N 条链路都以同样的方式失败说明问题不在随机性而在系统性缺陷比如任务本身无解、工具能力不足、提示有根本性误导。这时候并行再多也没用因为大家会一起错。必须先解决系统性缺陷。我踩过的一个典型坑早期做一个长程代码修复 agent单链路成功率只有 3%我天真地以为堆到 32 条并行就能解决。结果跑了 32 条成功率只到 20% 出头成本却是单链路的 32 倍。后来回头分析发现失败集中在无法正确理解跨文件依赖这个系统性问题上并行根本解决不了。改成先加一个依赖分析的前置步骤单链路成功率直接到 25%再并行 4 条就到了 70% 多。这个教训让我彻底明白了先修单链路再上并行的顺序。6. 实操中踩过的坑和几条硬经验6.1 并行链路之间的隐性耦合理论上并行链路应该互相独立但实操中经常出现隐性耦合。最常见的是共享外部状态多条链路同时调用同一个有状态的服务比如写同一个数据库、改同一个文件互相干扰导致结果不可复现。我遇到过一次几条并行链路同时操作一个临时目录结果互相覆盖了中间文件最后所有链路都失败而且失败原因看起来毫无规律。排查了很久才发现是文件冲突。解决办法是给每条链路分配独立的沙箱环境或者对共享资源加锁。这个坑很隐蔽因为单链路跑的时候完全正常一并行就出问题。6.2 随机种子管理比想象中重要做并行扩展时随机种子的管理很容易被忽视。如果所有链路用同一个种子它们会高度相关多样性大打折扣如果种子完全随机又会导致结果不可复现调试困难。我的做法是用确定性的种子派生规则给每条链路分配一个可追踪的种子比如基于任务 ID 和链路编号哈希生成这样既保证了链路间的多样性又能在需要时精确复现某条链路。调试时这个太重要了——当某条链路跑出奇怪结果你能精确重放它而不是靠运气再撞一次。6.3 别忽略失败链路的诊断价值大多数人跑完并行只看成功的那条失败的直接扔掉。这是个巨大的浪费。失败链路里藏着大量信息它们在哪一步开始偏离、偏离的模式是什么、有没有共同的失败原因。我会专门做一个失败分析环节把失败链路按失败模式聚类看看有没有系统性问题。很多时候优化单链路的灵感就来自这些失败分析。比如发现多条链路都在同一个工具调用上失败那可能是工具接口有问题发现多条链路都在某个推理步骤上绕圈那可能是提示需要改进。把失败链路当资产而不是垃圾是提升整体系统质量的关键。6.4 从小规模并行开始逐步放大最后一条经验不要一上来就开大并行度。先用 N2 或 N4 跑通整个流程验证并行机制、验证器、成本模型都工作正常再逐步放大。大并行度会掩盖很多问题——比如资源竞争、状态冲突在小规模时可能不明显一放大就集中爆发。我现在的标准流程是N1 验证单链路 → N2 验证并行机制 → N4 验证验证器 → N8 测性价比 → 根据结果决定最终并行度。每一步都记录成功率和成本形成数据支撑。这样即使最终并行度不高整个系统的可靠性也是有保障的。这套方法我在几个不同的长程任务场景里都用过从自动化调研到复杂流程编排核心逻辑是通用的先保证单链路质量再用受控的多样性做并行用强验证器做选择用成本模型定并行度最后用失败分析持续优化。并行测试时扩展不是简单地多跑几条而是一套需要精心设计的系统工程。把它做对了长程智能体的成功率能有质的飞跃做错了就是纯粹的算力浪费。