让AI智能体在等待时也别闲着：一个关于"摸鱼式思考"的研究

你有没有经历过这样的场景：给同事发了一条消息问一个问题，对方回复"我去查一下"，然后就真的坐在那里一动不动，眼神放空，直到查完为止？没有人会这样工作。正常人查资料的时候，脑子不会停，你会顺便想想接下来要不要顺便问问别的事，会不会有什么之前忘了考虑的坑。

但现在的AI智能体，恰恰就是这种"死等"的状态。

现在主流的AI智能体几乎都遵循一种叫ReAct的工作范式。

**ReAct**：全称Reasoning + Acting，是一种让大模型交替进行"思考"和"行动"的框架，模型先想清楚要做什么（Thought），再去执行一个具体操作比如调用工具（Action），然后等外部环境给反馈（Observation），如此循环，直到任务完成。

这套流程用在写代码、跑测试、查资料的智能体上非常普遍。问题是，思考这个动作只发生在Thought阶段。一旦模型说完"我要做什么"，进入Action阶段去真正执行动作，比如调用一个命令行工具，模型自己的"脑子"就彻底停摆了。它要等命令执行完、等服务器返回结果，这段时间里模型完全是空转的，没有产生任何一个新想法。

新加坡管理大学的研究团队盯上了这段空白期。他们给它起了个名字，叫"推理空闲窗口"，并且提出一个问题：这段时间明明可以拿来想点什么，为什么现在的智能体全都在这里发呆？

核心问题：思考被锁死在了一个狭窄的窗口里

要理解这个问题的分量，得先说清楚现在提升AI智能体推理能力的主流做法是什么。

答案很简单粗暴：让模型多想一会儿。业界管这个叫"推理时扩展"（inference-time scaling），说白了就是让模型在Thought阶段生成更长的思考链，想得越细致，答案通常越准。这个思路在各种基准测试上确实管用，但代价也很直白：每多生成一个推理token，都是实打实地排在处理队列里，用户就要多等一会儿。想得越深，等得越久，这是一条硬邦邦的正比关系。

于是问题就来了。智能体一轮任务里，真正在"想"的时间只占一小部分，剩下大量时间是在等工具执行、等网络响应、等服务器返回数据。这些时间被完全浪费掉了，而想要提升准确率，唯一的办法却是往本就拥挤的思考阶段里塞更多token,两头都不讨好。

论文用一个debug任务的例子把这个问题讲得很生动。假设一个智能体要修一个CLI程序的bug，用户通过环境变量设置超时时间时程序会崩溃，同时有个约束条件：修复过程中不能破坏`load_config()`函数的对外接口兼容性。普通ReAct智能体的表现是这样的：先是搜错了函数名，扑了个空,然后满世界翻文件,终于找到问题所在,但改的时候图省事直接改了函数签名,加了个新的必填参数,结果一跑测试,27个用例全挂,报错说少了个参数。这时候智能体才反应过来，之前"不能破坏兼容性"这个约束早被自己忘到了脑后，只能推倒重来。

这一步返工，就是白白多花的时间和token。而这背后的真正问题是,智能体在漫长的执行过程中，早期设下的约束条件会随着上下文变长而逐渐"褪色"，模型对它的关注度会衰减，这是一个已经被研究证实的现象，论文里管这个叫"context attrition"（上下文注意力衰减）。

所以现在的矛盾很清楚：一边是有限的思考时间必须精打细算，不能随便浪费在无意义的重复劳动上；另一边是大量的等待时间被完全闲置，一点思考都没发生。这两件事明明可以互相弥补，却被现有框架硬生生地隔开了。

Second Thought：趁着行动和观察的空档，偷偷多想几步

研究团队给出的方案叫Second Thought，翻译过来大概是"第二个念头"，思路其实相当直白：既然模型在等工具执行结果的时候闲着，那就让它顺便再想点别的。

具体怎么做？每当主线程刚说完一句"我打算这么做"（Thought阶段结束），系统就立刻分叉出四条辅助推理支线，这四条支线跟主线程同时运行，各自朝不同方向琢磨点东西。等到工具执行完、观察结果（Observation）真正返回的那一刻，系统把这几条支线上已经想好的内容收上来，塞进下一轮对话的上下文里，然后主线程带着这些"顺便想到的东西"继续往下走。

这里有个细节特别重要：这四条支线不是在跟主线程抢答案,它们不参与当前这一步该做什么的决策,因为决策已经做完了，动作已经在执行的路上了。它们纯粹是在给未来的自己攒弹药。

这就好比你去银行办事,柜员说"您的申请我需要核实一下，请稍等"。这时候如果你只是干坐着，五分钟就白白浪费了。但如果你是个会来事的人，你会趁这五分钟想想:等会儿柜员问起利率的事该怎么答，之前提到的那份收入证明是不是还得补充说明，万一核实不通过还有没有备选方案。这些念头跟"柜员核实"这件事本身没有任何冲突，它们不会改变柜员正在做的事情，但会让你在柜员回来的那一刻应对得游刃有余。如果不这么想，等柜员回来问你问题的时候，你就得从零开始现想，白白多花好几分钟临场组织语言。Second Thought做的就是这件事：让模型在"柜员核实"的空档里，把接下来大概率用得上的念头先想好，等结果一回来直接拿来用。

那这四条支线具体都在想什么呢？研究团队把它们分成了四类，从两个维度切入：一个是时间方向（回顾过去 vs 展望未来），一个是范围（只看当前这一步 vs 看整个历史）。

**Check（核查）**：审视刚刚做出的判断里有没有站不住脚的假设。比如"我假设测试框架是pytest，但其实没有真正确认过配置文件里写的是什么"，一旦观察结果和假设不符，这条思路就提前埋好了警觉。

**Recall（回想）**：把早期提到但可能已经被遗忘的关键约束重新捞出来。就像前面提到的debug例子里,"公开接口必须保持向后兼容"这条约束，如果有一个支线专门负责在每一轮都把它重新提一遍，模型就不容易在改代码的时候把这茬儿忘了。

**Rehearse（预演）**：提前想好几种可能出现的结果该怎么应对。比如"如果grep搜索返回空结果，那就换用符号片段搜索"，这样等真正的结果一返回，模型不用现想对策，直接照着预演好的走。

**Alternative（备选）**：在主思路可能失败的情况下，提前准备几个候选方案和触发条件，避免在一条路走到黑的时候手足无措。

看到这四个名字，你可能会觉得眼熟，它们其实分别对应了智能体在实际工作中最常踩的四个坑:轻信没验证的假设、忘记早期的约束、被意外结果打个措手不及、在错误的方向上死磕到底。

让"打断"变得毫无损失：原子化思考

这里有个技术上的难题必须解决:这四条支线到底能想多久，其实是不确定的。

想象一下，你让四个人分别去想不同的事情，但你不知道领导什么时候会突然打断说"好了，说结果"。如果每个人的想法都是一整段完整的论述，中间被打断，那半句话可能完全没法用，甚至会造成误解。

研究团队的解法是要求每条支线把自己的思考拆成一个个"原子化思考"（atomic thought）。

**原子思考**：每个思考单元只包含一个独立、自足的想法，长度控制在25个词以内，不依赖前后其他单元的内容，并且用明确的XML标签`<thought>...</thought>`包裹起来，方便系统识别边界。

这个设计的关键在于，就算生成过程被腰斩，只要某个思考单元已经完整地写完并且闭合了标签，它就是可用的；只有正在生成、还没写完的那一个会被扔掉。这就好比写便利贴，你每想到一件事就写一张，贴在墙上，而不是把所有想法写在同一张纸上连成一段话。领导随时进来打断都没关系，墙上已经贴好的便利贴照样能用，顶多是手里正在写的那一张作废。如果不这样设计，用连续大段文字来记录思考，那被打断的那一刻很可能正好卡在一句话说到一半，前言不搭后语，整段内容基本就废了。

当观察结果真正到达的那一刻，系统会把所有支线立刻叫停，从每条支线里已经完整生成的思考单元中最多挑5条，拼接到工具返回结果的后面，一起交给主线程。如果某条支线一个完整的想法都没来得及生成，那就直接跳过，不影响整体流程；极端情况下如果四条支线全都没来得及产出任何东西，系统就退化成普通的ReAct智能体，不会出错，也不会拖慢速度。

实验结果：turn数全降了，准确率大多没掉

光有设计思路不够，得看实际跑起来效果怎样。研究团队在三个智能体基准测试上做了验证。

**SWE-Bench Pro**：一个真实的软件工程基准，让智能体在容器化的代码仓库里定位并修复真实bug，用隐藏的测试用例来判断修复是否成功。

**Terminal-Bench 2.1**：考察智能体在命令行环境里完成系统管理、数据处理、软件构建等任务的能力。

**τ?-bench**：银行业务场景下的多轮客服对话任务，智能体要一边跟模拟用户对话，一边调用工具查政策文档，回答必须有据可依。

配合三种不同厂商的推理大模型：DeepSeek-V4-Flash、Qwen3.6-Plus、MiniMax-M3，一共凑出九组"模型+基准"的组合。

结果是，九组组合里，Second Thought全部降低了平均轮次数，其中六组主线程的解码token数量也明显降低，降幅最高达到43%（在SWE-Bench Pro配合Qwen3.6-Plus这一组，主线程输出token从36519降到20798）。准确率方面，九组里有七组没有出现统计意义上的显著变化，只有一组出现了微小的下降（52.0%降到51.3%，实际就是150个样本里错了1个，谈不上显著），而另外两组出现了显著提升，最大的一次提升达到12.4个百分点（在Terminal-Bench 2.1配合Qwen3.6-Plus这一组，准确率从39.3%涨到51.7%）。

论文里还设置了一个特别值得说的对照组，叫s1，这个名字来自一篇叫"Simple Test-time Scaling"的论文提出的budget forcing方法。

**s1 / budget forcing**：一种强迫模型继续思考的技巧,当模型的思考本该结束时，故意抑制"思考结束"的标记，强迫模型把思考长度继续拉长，直到消耗掉指定的token预算为止。

s1被用来当作"预算相同"的对照实验:它花掉了跟Second Thought一样多的额外token，但这些token是全部堆在主线程自己的思考过程里的，也就是老老实实排队等着被处理，而不是分流到旁边的支线上去。结果显示，在SWE-Bench Pro配合Qwen3.6-Plus这组实验里，s1把输出token从36519一路推高到65634，代价却是准确率从52.0%掉到了48.7%。同样多花的token，一个换来了准确率下降，一个（Second Thought）反而在减少主线程token的同时保住了准确率。这说明关键不在于"多花token"这件事本身,而在于这些token花在了什么地方，以及有没有真正用来补上主线程原本会缺失的思考维度。

用一个具体数字来体会这个对比的分量:在Terminal-Bench 2.1配合Qwen3.6-Plus这组里，Second Thought比s1少用1.3倍的主线程token（31396 vs 40642），但准确率反而比s1高出5.6个百分点。同样是砸钱，一个花在明处排队等待，一个花在暗处顺路搭车，效果差了一大截。

下面这张表格是论文里的核心数据，展示了九组实验的完整对比：

| 基准 | 模型 | 设置 | Pass@1 | 主线程输出token | 轮次 |

|---|---|---|---|---|---|

| SWE-Pro | DeepSeek-V4 | 基线 | 48.7 | 23841 | 56.2 |

| | | s1 | 49.3 | 54463 | 58.5 |

| | | **Second Thought** | **52.0** | **20255** | **52.8** |

| SWE-Pro | Qwen3.6 | 基线 | **52.0** | 36519 | 57.1 |

| | | s1 | 48.7 | 65634 | 55.7 |

| | | Second Thought | 51.3 | **20798** | **50.6** |

| TB2.1 | DeepSeek-V4 | 基线 | 50.6 | 48202 | 40.2 |

| | | s1 | 50.6 | 68003 | 33.4 |

| | | **Second Thought** | **52.8** | **32892** | 35.8 |

| TB2.1 | Qwen3.6 | 基线 | 39.3 | 25158 | 25.5 |

| | | s1 | 46.1 | 40642 | **22.1** |

| | | **Second Thought** | **51.7** | 31396 | 24.0 |

| TB2.1 | MiniMax-M3 | 基线 | 49.4 | 36686 | 44.6 |

| | | **Second Thought** | **59.6** | 36705 | **43.1** |

| τ?-bench | Qwen3.6 | 基线 | 16.7 | 16755 | 26.1 |

| | | **Second Thought** | **19.8** | **13764** | 25.9 |

（表格为部分数据摘录，突出对比较明显的结果）

值得一提的是，研究团队还做了消融实验，把四条支线拆开单独测试。结果发现，只留一条支线（比如只留Recall）虽然能省下最多的token，但准确率跌得也最厉害；反过来，如果去掉Recall这一条支线，准确率掉得最狠，说明"回想早期约束"这个功能是最不能丢的一环；而去掉Rehearse（预演）虽然准确率没怎么变，但主线程的输出token反而涨了10%,这说明Rehearse这条支线的作用主要是替主线程提前把活干了，省的就是这部分算力。四条支线各管一段，缺一个就少一块拼图,把它们凑齐了才是效果最好的组合。

时间真的省下来了吗？一次真刀真枪的重放实验

前面说的token数量减少，听起来很美好，但token少了是不是等于真的更快？这中间隔着一层：API调用速度会受网络波动、服务器负载影响，直接拿原始实验的耗时数据比较是不公平的，因为两次实验可能碰上了完全不同的服务器状态。

研究团队为此专门做了一次"重放实验"，把50个SWE-Bench Pro任务用DeepSeek-V4-Flash重新跑一遍，而且是让基线版本和Second Thought版本背靠背在同一个时间窗口、同样的并发设置下各跑三次，取中位数，这样服务器状态的波动对两边的影响是对等的。

结果显示，每个任务的中位耗时从256.9秒降到了229.0秒，降幅10.9%。拆开来看，主线程解码耗时从168.7秒降到146.1秒，降幅13.4%，跟主线程token减少15.0%的比例基本对得上；工具执行时间从71.6秒降到67.3秒，降幅6.0%，跟轮次数从56.2降到52.8基本吻合。

有意思的是，13.4%的时间降幅比15.0%的token降幅要小一点点，这个差距来自哪里？答案是四条支线同时运行会争抢一部分服务器资源，导致主线程本身的解码速度略微变慢了（从每秒141.3个token降到138.6个），这部分"资源争抢成本"大概是2.8秒，相比省下的27.9秒来说是很小的代价。研究者解释说，这是因为支线在运行时关闭了模型自带的深度思考模式，而且共享了主线程的提示词缓存，所以额外占用的计算资源本身就很有限。

这个实验的意义在于证明了一件事:表格里那些好看的token数字不是统计上的障眼法，是真的能落地成用户能感知到的更短等待时间。

空闲窗口到底有多少可以用？

论文里还有一组挺有意思的数据，讲的是这套系统在不同场景下"能收获多少"取决于什么。

研究团队发现，辅助支线能不能产出有效内容，直接跟这个"空闲窗口"的长短挂钩。他们把每一轮任务按窗口时长（相对于该次运行的中位数）分组，发现窗口越长，能收获到内容的比例就越高，从0%一路涨到90.1%。这说明一套固定不变的配置，在窗口长短相差好几个数量级的不同场景下都能自动适配，不需要针对每种场景单独调参。

另外一个数字也很直观：全部轮次里只有28.7%真正"收获"到了辅助思考内容，但这28.7%却占据了全部空闲时间的86.7%。换句话说，大部分空闲时间都集中在少数几个"等待特别久"的关键节点上，而这些节点恰好被Second Thought充分利用了。整体上，96.5%的任务在执行过程中至少收获过一次辅助思考。

这也解释了为什么τ?-bench（银行客服对话）这个场景的提升幅度相对较小。论文分析认为，这类任务的空闲窗口本身就短（对话式交互, 工具调用间隔不长），而且银行场景里失败的根源更多是检索质量和政策遵循问题，而不是Check、Rehearse、Alternative这几条支线主攻的"规划错误"类问题，所以能捞到的"油水"本身就有限。这也提示了一个方向：未来或许可以根据任务领域动态调整该用哪几条支线。

成本账：多花的钱到底花在哪儿了

天下没有免费的午餐，四条支线同时跑，肯定要多花钱。论文里专门算了一笔账。

结果显示，跑满四条支线会让每个任务的API调用成本增加66.4%到181.5%，具体涨多少取决于用的是哪个模型。但这里有个反直觉的地方：这笔额外开销几乎全部来自输入prompt的处理成本，而不是生成新内容的成本。换句话说，真正"新想出来"的那些token其实很便宜，贵的是每条支线都要重新读一遍完整的历史对话记录。

好消息是，由于四条支线共享主线程的提示词缓存（KV cache），这部分重复读取的费用大部分能吃到服务商的缓存折扣，实际成本没有想象中那么夸张。对于预算有限的场景，论文也给了个折中方案：只留下表现最好的Alternative支线，额外成本能压到16.3%到35.5%,大幅省钱的同时依然能保留大部分收益。

这就好比公司开会时找了四个助理同时去查不同的资料，虽然人力成本涨了，但如果这四个助理看的是同一份共享文档缓存，而不是各自重新打印一遍完整会议记录，那真正多花的钱其实没有想象中那么离谱。如果不共享这份缓存，让四个人各自从头翻阅完整的历史资料，成本可能直接翻上好几倍，那这套方案就完全不划算了。

深挖一层：窗口时长和"看没看到最新想法"到底哪个更重要

论文还做了一个挺细致的拆解实验，想弄清楚Second Thought效果好，到底是因为"多给了时间"，还是"看到了刚生成的思考内容"。

研究团队试了几种变体。一种是让支线在轮次一开始就分叉（覆盖整个Thought阶段，窗口更长），但代价是支线看不到主线程刚刚敲定的那个想法；结果准确率是51.3%，比默认设置（52.0%）略低，但支线产出的思考单元数量却翻了将近一倍（11.5条对7.1条每轮）。这说明一条支线如果不知道主线程刚决定要干什么，写出来的东西数量虽多，但质量和针对性会打折扣。

另一种是完全去掉"观察结果一到就打断"这个限制，让支线想到写完为止,这种情况下准确率飙到56.7%，比默认设置高出4.7个百分点。但这是有代价的，因为不再被打断，支线的token就会实实在在地堆到主线程的等待时间上，把原本"零成本"的额外思考变成了"排队等待"的额外思考，主线程的解码量最高可能涨到48.4k token，几乎是默认设置的2.4倍。

这组对比其实点出了一个核心权衡:窗口时长是决定收益上限的最主要因素，而Second Thought目前采用的策略，是选择了一个"额外成本为零"的甜蜜点，也就是只利用真实存在的空闲时间，绝不占用主线程的排队时间。研究者管这个叫"window-starved"（窗口饥渴），意思是目前这套方案只吃到了理论上限大约41%的收益，剩下的部分不是不可能拿到，而是需要用真实的排队时间去换，这笔账划不划算，取决于具体场景对延迟的容忍度有多高。

写在后面

读到这篇论文时，最让我意外的其实不是"支线并行"这个想法本身,这种思路在计算机系统设计里并不新鲜，异步IO、预测执行早就有类似的影子。真正让我停下来想了想的是那个"原子化思考"的设计,把一段连续的推理过程硬生生切成一颗颗独立的珠子，只是为了应对"随时可能被打断"这个约束。这其实是一种很朴素但很少被提炼出来的工程哲学：当你没法保证任务能顺利完成时，就该设计成"半途而废也不亏"的结构。这个思路其实在很多地方都用得上，写文档时按小节保存、做数据处理时用检查点、甚至日常写作时按段落而不是按整篇构思，本质上都是同一个道理。

另一个让我意外的地方是成本分析那部分。直觉上以为四条支线跑起来贵是因为多生成了内容，结果论文告诉你贵的地方几乎全在"重新读一遍历史记录"上。这提醒我们，衡量一个AI系统的成本，光看它"说了多少话"是不够的，它每次"回忆"上下文的动作本身就有价格。

论文里没细说的一个问题是，如果任务本身就是那种几乎没有工具调用等待时间的场景（比如纯对话、没有慢速外部API），这套机制岂不是彻底失去用武之地？这个空档到底还剩多少留给未来的模型和框架去挖，这事儿恐怕值得继续追问。

Q&A

Q1：Second Thought是什么？

A：Second Thought是新加坡管理大学团队提出的一种无需额外训练的推理框架，它利用AI智能体在等待工具执行结果（Action到Observation之间）的空闲时间，同步生成四条辅助思考支线（Check核查、Recall回想、Rehearse预演、Alternative备选），并在观察结果返回时把已完成的思考内容收集起来，供下一轮推理使用，从而不占用主线程的排队时间就能提升推理质量。

Q2：Second Thought会不会让AI智能体变慢？

A：不会，恰恰相反。论文的重放实验显示，Second Thought把每个任务的中位耗时从256.9秒降到229.0秒，降低了10.9%。因为四条支线是利用主线程原本就在等待工具执行的空闲时间运行的，几乎不占用额外的排队时间，只带来了很小的资源争抢成本（约2.8秒），远小于节省下来的27.9秒。

Q3：Second Thought跟直接让模型多想一会儿（比如s1方法）有什么区别？

A：区别在于额外的思考token放在了什么位置。s1是让模型在主线程里强行继续思考，这些token要排队等待处理，会直接拖慢速度，实验中甚至有一组数据显示s1让准确率从52.0%掉到48.7%。而Second Thought把额外的思考挪到了并行的辅助支线上，不占用主线程的排队时间，在多个实验组里实现了更高准确率和更少主线程token消耗的双赢。