AI智能体为什么总是慢吞吞？JevSpawn用"并行猜选项"的方式让它快了15%

你有没有玩过那种填空题答题卡？老师给你几个选项，A、B、C、D，你涂一个圆圈就完事了，根本不用自己写出完整答案。

现在想象一下，如果每道题都要你手写完整的句子，一个字一个字地写，写错了还要擦掉重写。这速度能快吗？

这其实就是当下大语言模型智能体面临的真实困境。

**核心问题：AI智能体为什么跑得这么慢**

当一个AI智能体在解决任务时，比如在迷宫里找路，或者玩2048游戏，它每一步都要"想"一下该做什么动作，然后把这个动作一个字一个字地生成出来。

这个过程在技术上叫做token by token生成

*token*：可以理解为语言模型处理文字的最小单位，可能是一个字、一个词，或者一个词的一部分。模型生成文字就是一个token接一个token往外蹦。

问题是，智能体在探索的时候，经常要尝试好几种不同的动作方案，看看哪个更靠谱。每尝试一种，就要重新生成一遍完整的动作描述，哪怕这些动作长得几乎一模一样，只是某个方向或者某个数字不一样。

这就好比你每次点外卖都要把地址、电话、备注从头打一遍字，哪怕你昨天刚点过同一家店，只是换了个菜品。

效率低得让人崩溃。

论文里提到一个背景技术，叫做Jev风格模型。

*Jev风格模型*：一种可以在"有限选项范围"里快速给出概率预测的模型，不需要把答案一个字一个字写出来，而是直接从几个预先设定好的选项里打分选择。

听起来很美好对吧？但问题来了，这类模型有个前提条件，就是你必须提前把所有可能的选项列出来。这就像前面说的答题卡，老师得先把A、B、C、D印好，你才能涂。

可是AI智能体面对的是什么？是从自然语言指令里现场推导出来的任务，选项是什么根本没人提前写好，而且随着探索的深入，可用的动作还会不断变化。

这就是JevSpawn这篇论文要解决的核心矛盾：怎么让AI智能体既能享受"选择题"的速度优势，又不需要提前知道选项是什么。

**方法一：把"选项"这件事也交给模型自己去定义**

JevSpawn的第一个关键设计，是让动作的表示方式本身成为策略的一部分。

具体来说，模型拿到任务描述之后，不是直接去想"我该做什么"，而是先构造出一个行动声明

*行动声明*：由若干个字段组成的结构，每个字段代表动作里的一个可变部分，比如移动方向、移动步数，每个字段都有一个有限的取值范围。

举个例子，在一个迷宫任务里，规则是"只能往北走一步，或者往东走最多两步"。模型就会声明出两个字段：方向（北或东）、步数（如果是北则只能1，如果是东则可以是1或2）。这样一来，原本需要完整生成的"向北移动一步"这句话，就被拆解成了几个可以直接打分选择的小选项。

这个设计的精妙之处在于，它把开放式的自然语言问题，转化成了封闭式的填空题问题，而且这个转化过程是模型根据任务上下文自己完成的，不需要人工提前设定。

如果没有这一步会怎样？

答案是，你要么回到最原始的逐字生成模式，速度慢；要么像传统的Jev模型那样，必须由开发者提前手工定义好每个任务的动作字段，这意味着每出现一个新任务类型，都得重新写一遍规则，完全没法做到通用和自适应。

这就好比一家餐厅，如果每次来新顾客都要重新设计菜单格式，那效率可想而知。而JevSpawn相当于训练了一位懂行的服务员，顾客一进门，服务员立刻就能根据对方的口音、穿着、说话方式判断出大概想吃什么类型的菜，然后现场列出几个选项让顾客勾选，而不是让顾客自己口述一份完整的菜谱。

**方法二：并行尝试多个动作，而不是一条路走到黑**

有了动作声明这个结构之后，JevSpawn的第二个核心设计是并行分支探索

*分支*：智能体在某个状态下尝试的一种可能动作路径，每个分支都有独立的历史记录和执行结果。

具体的做法是，模型会同时生成多个候选动作，比如在一个十字路口，同时评估"向北走"和"向东走"这两个选项的概率，然后真的在独立的环境副本里执行这几个动作，看看哪个带来的结果更好。

这里有个很直观的例子来自论文里的PPNL路径规划任务。智能体从起点出发，目标藏在两个障碍物后面。在第一轮探索中，模型同时评估了向上、向下、向左、向右四个方向，概率分别是0.008、0.480、0.002、0.510。系统选择了概率最高的"向右"，但紧接着在下一轮又发现向右会撞上障碍物，于是又重新评估，选择向下绕过去。

整个过程持续了七轮，每一轮都是同时生成四个候选方向并打分，而不是生硬地按照某个固定顺序一条路走到黑。

那如果不并行探索，只走一条路会怎样？论文的消融实验给出了答案：当把并行探索的宽度从4降到1时，迷宫任务的成功率从0.88暴跌到0.16，网格导航任务的成功率从0.94跌到0.58，灯光熄灭谜题的得分从0.61跌到0.06。

这组数字说明了什么？意味着如果只走一条路，每10次任务里面，原本能完成8到9次的迷宫导航，会直接跌到只能完成1到2次。差距不是一星半点，而是直接决定了任务能不能做成。

这就像下棋，高手之所以厉害，不是因为他只想一步棋，而是他脑子里同时在推演好几种可能的走法，比较优劣之后再落子。如果只盯着一种走法硬走到底，输棋的概率会大大增加。

但这里有一个微妙的平衡问题，并不是分支越多越好。论文测试了把分支宽度加到10的情况，结果迷宫任务确实能全部解决，但Nullify任务的得分反而腰斩，RushHour任务的耗时直接翻倍。

这说明探索这件事也有成本，分支越多，计算量越大，耗时越长，收益却不一定线性增长。这就好比开会讨论方案，三五个备选方案大家还能认真比较，一下子甩出二十个方案，反而会让人无从下手，拖慢决策速度。

**方法三：出错了能回头，而不是一条道走到黑**

JevSpawn的第三个设计是反馈驱动的状态转移和分支回溯

*回溯*：当某条探索路径走不通时，系统可以返回之前保留的其他分支，重新尝试，而不需要从头再来。

这个设计解决的问题是，智能体在探索过程中难免会走进死胡同，比如撞墙了，或者某个动作被环境拒绝了。这时候如果没有回溯机制，要么就卡死在那里，要么就得把整个探索过程推倒重来，非常浪费。

论文里RushHour推箱子类的拼图游戏给出了一个生动的案例。智能体一开始尝试了四个动作，其中B减号这个动作直接返回"无效移动，移动被阻挡"。按照常理这条路就该放弃了，但系统并没有完全抛弃这个分支，而是在后续轮次里，当其他路径也遇到阻碍时，又回过头去重新评估这个曾经被标记为无效的分支，最终从中发掘出了新的可行动作，一路推演出九步解法，成功让红色小车逃出棋盘。

整个过程里，系统一共进行了14轮探索，其中有7轮标注为回溯，占了一半。

这个细节相当有意思，它说明在复杂任务里，"看起来走不通"和"真的走不通"不是一回事，有时候只是当前条件不满足，换个时机或者换个前置动作，原本被否决的选项又能重新焕发生机。

这就像你去应聘一家公司，第一次面试因为简历关键词不匹配被刷了，但你并没有彻底放弃这家公司，而是先去别处积累了经验，拿到了新的技能证书，几个月后同一家公司又开了新岗位，你凭借补全的履历重新投递，这次反而成功了。被拒绝不代表路彻底堵死，而是时机和条件没对上。如果没有这种"保留记忆、伺机重试"的能力，你可能这辈子都不会再考虑这家公司，错失了后来真正合适的机会。

**方法四：复用计算，别让机器重复造轮子**

JevSpawn最后一个关键设计是共享前缀与并行评估

*前缀*：指对话或任务历史中，不同分支之间共同拥有的那部分上下文内容，比如任务描述、规则说明这些不会变化的部分。

这个设计解决的是计算浪费的问题。想象一下，如果你和八个朋友同时问老师同一个问题的不同变体，老师完全没必要把题目背景重新讲八遍，只需要讲一遍背景，然后分别回答每个人的具体疑问就够了。

论文给出了具体的数据支撑，在他们的实验里，某一批次的8个请求总共涉及77个候选动作评估，GPU的token计算量通过复用公共前缀，节省了37.2%。也就是说，原本需要重复计算的那部分上下文信息，有三分之一以上被直接复用了，不用再算第二遍。

这背后还牵扯到一个硬件层面的细节。论文的实验显示，短历史（也就是前缀比较短的情况）下，GPU之间的计算间隙大约是50到125毫秒，而长历史情况下间隙缩短到了28毫秒左右，这说明当计算量更大的时候，GPU的利用率反而更高、更连续，浪费的空闲时间更少。

这个设计带来的直接效果体现在吞吐量上，论文测得JevSpawn在处理PPNL路径规划任务时，文本解码速度达到每秒544个token，在LightsOut灯光谜题任务中达到每秒580个token，都是对比的所有方法里最高的数值。

如果不做这种前缀复用，会发生什么？答案很简单，每次分支探索都要把任务描述、历史记录从头算一遍，哪怕这些内容压根没变过。这就好比你每次给同一个客户发邮件，都要把公司介绍、产品背景从头写一遍，而不是直接存一份模板复用，纯属浪费时间和精力。

**实验结果说话：JevSpawn到底强在哪**

论文在八个基准任务上，把JevSpawn和七个主流智能体方法做了对比，包括LATS、LLMCompiler、AgentPrune、HiAgent、FoldAgent、DyFlow、LatentMAS。

在Maze迷宫导航任务里，JevSpawn的成功率达到0.96，而表现最好的对比方法FoldAgent只有0.52，差了将近一倍。更关键的是，JevSpawn的耗时反而更短，只需要40.91秒，比最快的基线方法AgentPrune的47.91秒还要快。

在Grid网格导航任务里也是类似的情况，JevSpawn成功率0.95，FoldAgent只有0.73，耗时方面JevSpawn是40.58秒，比AgentPrune的61.44秒快了整整20秒。

LightsOut灯光谜题任务中，JevSpawn的奖励值达到0.61，是AgentPrune（0.34）的近两倍。而在2048数字游戏里，JevSpawn最终得分305.12，远超LLMCompiler的5.00分，这个差距大到几乎不在一个量级上。

论文还做了一个有意思的对照实验，把JevSpawn里负责打分的部分，替换成了一个叫TypeSafe Jev的外部API服务，其他部分保持不变。结果显示，这个变体在PPNL和LightsOut任务上表现更好，但耗时却明显拉长，是原版Qwen打分方案的1.4到2.1倍，这里面很大一部分开销来自网络通信延迟。

这说明本地自己训练的模型打分和调用外部API打分，各有取舍，前者速度有保证，后者有时候精度略胜一筹，但要付出通信成本。

论文还做了一个关于时间预算的实验，特别值得拿出来说一说。在不限制时间的情况下，把探索轮数从36轮加到108轮，2048游戏的得分从315分一路涨到1102分，涨了超过两倍。但如果给一个300秒的硬性时间限制，同样加到108轮，85%的2048任务会直接超时，得分反而只有124分。

这个结果挺反直觉的，探索得越久理论上应该越好，但现实世界的资源是有限的，没有无限的时间去穷举所有可能性。这其实也点出了智能体系统设计里一个绕不开的矛盾，到底是追求理论上限，还是接受实际约束下的折中方案。

**后续的延伸思考**

JevSpawn这篇论文发表于2026年9月，它站在了几条技术脉络的交汇点上。

一方面，它延续了像XGrammar和SGLang这类约束解码技术的思路，这些工作致力于让模型在生成时就遵守语法规则，跳过那些注定不合法的token选择，从而提速。但JevSpawn往前走了一步，它不只是约束"怎么生成"，而是连"生成什么样的选项结构"这件事都交给模型自己决定。

另一方面，它也呼应了像LATS、DyFlow这些强调搜索和工作流优化的智能体框架，这些框架关注的是"模型调用该怎么安排"，而JevSpawn关注的是"单次调用内部怎么提速"，两者其实是互补的维度。

一个值得继续追问的问题是，当任务的动作空间极其复杂，比如涉及自然语言生成这种真正开放式的内容时，这种"先声明字段再打分"的策略还能撑多久？论文里提到，像2048和Nullify这类任务，在探索到后期依然需要文本生成来补充声明或者给出最终答案，这说明JevSpawn目前更像是一种混合方案，而不是完全替代了传统的逐字生成。

**写在后面**

读这篇论文的时候，最让我多想了一层的，其实不是那些漂亮的加速数字，而是论文里反复出现的回溯机制在真实案例里展现出的那种"不轻易放弃"的特质。

RushHour那个案例特别打动我，一个被标记为无效的动作，在14轮里有7轮是在回头重新审视它，最终真的从里面挖出了可行解。这让我想到，很多时候我们判断一条路走不通，其实只是因为当前的条件不对，而不是这条路本身有问题。系统设计里愿意保留这种"暂时搁置但不彻底删除"的能力，其实挺考验设计者的耐心和远见的，因为从直觉上讲，丢掉无效分支、专注在有希望的路径上，才是更省资源的做法，但论文的实验恰恰说明，适度的保留和回访能带来真实的收益。

另外一个细节是，论文花了大量篇幅去讨论探索宽度、并行度这些参数该怎么权衡，宽度太窄会错过好答案，宽度太宽又会拖慢速度甚至降低某些任务的分数。这其实跟生活里很多决策场景是相通的，无论是找工作时要投多少份简历，还是做选择时要考虑多少个备选方案，都存在这种边际收益递减甚至反转的现象。技术论文里的参数调优，某种程度上就是把这种普遍存在的权衡问题，用数字精确地描摹了出来。

如果一个系统既能快速给出答案，又能在关键时刻愿意回头重新审视那些被草率否决的选项，这种设计思路能不能用在比游戏和迷宫更复杂的真实决策场景里？

Q&A

Q1：JevSpawn是什么？

A：JevSpawn是一种让AI智能体更快完成任务的技术方案，核心思路是让模型自己从任务描述里推导出"选择题"式的动作选项，而不是每次都要完整生成动作描述，从而大幅提升探索速度。

Q2：JevSpawn相比其他AI智能体方法快多少？

A：论文显示，JevSpawn在迷宫导航、网格导航等任务上，相比表现最好的基线方法，平均延迟降低了15.6%，同时在多个任务上成功率和得分也更高，实现了速度和质量的双重提升。

Q3：JevSpawn的回溯机制有什么用？

A：回溯机制让智能体在探索中遇到死胡同时，可以返回之前保留的其他分支重新尝试，而不需要从头再来。论文中RushHour推箱子案例显示，一个曾被标记无效的动作，经过多轮回溯重新评估后最终被证明是通向解法的关键一步。