AI Agent 调用搜索、测试、数据库、浏览器或远程 API 后，经常会停下来等待。新论文 Second Thought 把从发起动作到收到观察结果的这段时间称为“推理空档”。它提出的系统会在主线程选定动作后，再启动四条辅助推理分支：检查当前假设、回忆早先约束、预演下一步，以及准备替代路线。工具返回时，系统丢弃未完成片段，把已经闭合的“原子想法”交给下一轮主推理。
论文报告了几组很吸引人的数字：在 9 个“模型 × 基准测试”组合中，平均回合数都下降；其中两组的 Pass@1 有统计显著提升；一次配对墙钟回放里，单任务中位延迟降低了 10.9%。但成本表给出了另一面：在 SWE-Bench Pro 配置中，四分支方案让单任务 API 成本增加 66.4%–181.5%；保留一条分支后，增幅缩小到 16.3%–35.5%。
这不是一个普适的“免费加速”，而是多了一个可以买计算量的位置。
因此，小团队真正要回答的，不是“要不要实现 Second Thought”，而是：哪些工具等待足够长、足够可预测，值得放入有限的并行推理；在计入完整成本、上下文膨胀、取消效果和失败恢复后，它能否改善有效终态或用户真正感受到的等待？
本文给出一套配对试验。Y Build 没有运行下文的 ParcelDesk 实验；所有阈值、样本量与结果字段都留空或标为团队自定。论文数字是作者在特定模型、基准测试、价格与运行脚手架下得到的研究结果，不是我们的产品实测。
先看清 Agent 循环，再谈优化
ReAct 让“推理—动作—观察”交替成为常见 Agent 结构。简化后，一轮大致是：
根据当前状态推理
选择并序列化工具调用
等待工具结果
读取观察结果
为下一步继续推理
“等待”并非一个不可拆分的黑盒。它可能包括请求序列化、网络往返、排队、服务端执行、本地进程、上下文拼装、校验和结果返回。OpenAI 关于 Responses API WebSocket 模式的工程文章，把延迟拆成模型推理、API 服务和客户端工具/上下文处理三部分，并说明如何减少多轮循环中的重复处理。这提醒团队：先清除已知的传输与编排浪费，再考虑增加模型调用。
Second Thought 处理的是另一段时间。当前工具已经选定，辅助分支不能改变这一轮动作；它们只是在工具执行期间，为下一轮做准备。论文的参考实现包含四种角色：
| 分支 | 它提前准备的问题 | 出错时的产品风险 |
|---|---|---|
| Check | 观察结果可能推翻哪个假设？ | 下一轮可能被一个并不存在的问题锚定。 |
| Recall | 哪条早先约束仍然有效？ | 可能把过期或无关规则重新塞回上下文。 |
| Rehearse | 几种可能结果分别应如何处理？ | 可能围绕不会发生的结果过度准备。 |
| Alternative | 如果当前路线失败，还有什么选择？ | 可能干扰本来已经有效的计划。 |
每条分支输出短小、可独立解析的单元。论文把每条分支最多收取的想法限制为 5 条，并在观察结果抵达时取消生成。如果一条完整想法也没产生，系统自然退化为原来的串行循环。
机制本身并不难理解。它是否属于你的产品，要看产品到底有多少等待窗口、这些想法是否真的被下一轮采用，以及供应商缓存和取消在现实账单里如何运作。
读结论时，别把分母丢掉
Second Thought 使用三种推理模型和三类 Agent 场景：随机抽取的 150 个 SWE-Bench Pro 任务、89 个 Terminal-Bench 任务，以及工具型对话基准测试中的 97 个银行任务。相关原始论文能帮助理解边界：SWE-Bench Pro 聚焦长链条的代码仓库问题；Terminal-Bench 使用容器化终端任务与任务专属验证脚本；相关的 tau-squared benchmark 则强调动态的“双控制”客服环境，Agent 与用户都可能改变状态。
这些环境都很有价值，但它们并不代表所有生产 Agent。250 毫秒返回的客服查询、40 秒测试、5 分钟部署，以及等待真人审批，提供的推理空间和风险完全不同。
论文结果也不能压缩成一句宣传语：
- 9 个组合的平均回合数都减少；
- 7 个组合的 Pass@1 没有显著差异，2 个 Terminal-Bench 组合显著提升；
- 6 个组合的主线程输出 token 减少，部分大致不变，还有一组在准确率提升的同时明显增加；
- 只有 28.7% 的回合收到了可用收获，但 96.5% 的任务至少收获过一次；
- 最长的一组等待窗口贡献了大部分收获；
- 四条分支带来的 API 成本增幅，远大于中位延迟降幅。
作者认为，成本主要来自反复读取已经缓存的长前缀。若四条分支共享 KV 缓存，底层边际计算可能很低；但客户支付的是供应商计费规则，不是理论边际算力。缓存折扣、取消计费、并发限制与限流策略都会改变最终经济性。
更克制的结论是：研究证明了“在工具等待期推理”在部分 Agent 设置中可能改善准确率与延迟的组合；它没有证明四分支应成为默认值，也没有证明计费一定贴近真实算力，更没有证明你的用户一定会觉得更快。
加分支之前，先测量等待窗口
先保持现有 Agent 不变，采集一组能代表真实任务的轨迹。不要从“总任务时间很长”推断存在优化空间，必须逐轮记录动作到观察的间隔。
idle_window_ms = observation_received_at - main_thought_finished_at
每个回合至少记录：
| 字段 | 用途 |
|---|---|
task_id、trial_id、turn_id | 支持配对比较与回放 |
| 工具名与效果类型 | 区分只读等待和有副作用动作 |
| 推理结束、调用发出、工具开始/结束、观察抵达时间 | 拆出序列化、排队、执行与返回时间 |
| 缓存状态与供应商请求 ID | 验证前缀复用是否真正发生 |
| 重试、超时与取消状态 | 防止后台继续运行的工作从台账中消失 |
| 输入/输出 token 与实际计费 | 统计总成本，而不是只看主线程 |
| 最终任务结果 | 让速度始终服从有效终态 |
按工具与任务类型画出等待窗口的 p50、p90 和 p95，再统计超过 250 毫秒、1 秒、5 秒等候选分支预算的回合占比。这些只是描述桶，不是通用门槛。
如果多数工具在分支生成一条完整想法前就返回，系统根本没有可用空间。论文也观察到，窗口越长，产生收获的概率越高。你的等待分布决定了这项技术在产品里有没有实际发挥空间。
这一步要在写分支提示词之前完成，否则团队很容易为并不存在的等待，造出一套精致的并发系统。
先定义一个产品场景
假设 ParcelDesk 是一款为商家处理丢件请求的小型客服产品。普通流程会读取订单、查询承运商、检索退款政策、起草回复；只有员工批准后，系统才允许创建退款工单。
团队观察到两个较慢的只读工具：
- 承运商轨迹查询通常要几秒，有时会超时；
- 在商家专属大型知识库里检索政策。
这次决策应写得很窄：
在承运商与政策查询等待期间加入有限并行推理，能否缩短“有效客服工单”的完成时间，同时不增加政策引用错误、无依据的确定语气、审批绕过、计划冲突，也不让完整成本超过预先设定的上限？
退款执行、权限变更、对外发消息等动作都不在试验范围内。辅助分支可以给下一轮主推理建议，但不能自行调用工具、锁定库存、联系客户或预先批准退款。
“有效结果”也不能定义成“Agent 给出了回复”。它应包括：订单与承运商事件匹配正确；草稿有政策依据；证据不足时明确表达不确定；审批前外部状态没有变化。只有这个合同通过，速度才有意义。
同时比较基线、单分支和四分支
从产品真实任务类型建立配对样本，至少覆盖：普通成功、慢响应、空结果、结果冲突、超时、重试、陈旧数据、政策例外，以及必须升级给人的情况。固定模型快照、提示词、工具结构定义、权限、检索语料、超时规则和终态评分器。
设置三种条件：
| 条件 | 目的 |
|---|---|
| A：基线 | 保留当前串行循环 |
| B：单分支 | 用较小预算测试最符合任务的一种分支 |
| C：四分支 | 测试更完整的准备能力与全部开销 |
论文的消融实验中，Alternative 是表现最强的单分支。但这不代表 ParcelDesk 也一样。政策密集型客服可能更需要 Recall；经常遇到接口失败的产品也许更适合 Check 或 Rehearse。应该从产品失败记录选角色，而不是复制论文平均值。
在每个样本内随机化条件顺序，并对非确定性系统重复运行。每次恢复相同外部状态；比较需要时也应重置缓存、用户模拟器与限流环境。供应商若提供随机种子，可以记录，但不能把它当成确定性回放的证明。
终态评分必须对试验条件盲化，也不能向评分者展示分支轨迹。否则，输出更多流畅建议文字的条件，可能得到与最终产品状态无关的质量优势。先锁定终态判定，再在独立的一轮里审查分支利用率。
样本量要能识别团队真正会采取行动的最小变化。对不同基线成功率和延迟方差，一刀切的“30 个任务”都不可靠。先登记有意义的最低延迟改善、可接受成本增幅、严重失败规则与不确定性方法。样本不足以区分方案时，结论应是 insufficient_evidence，而不是让最好看的点估计晋级。
建一份分支价值台账
主线程 token 减少，不等于产品结果更好。分支可能让下一轮主推理变短，却增加总 token、上下文长度和冲突。每条被收取的想法都要记录它是否真的可用。
idle_window_trial:
task_id: "<fixture>"
condition: "baseline | one_branch | four_branch"
tool_wait:
tool: "<name>"
effect: "read_only | reversible | irreversible"
idle_ms: null
branch_budget_ms: null
harvest:
completed_units: null
discarded_partial_units: null
used_next_turn: null
duplicated_main_reasoning: null
contradicted_observation: null
introduced_stale_constraint: null
outcome:
accepted: null
severe_failure: null
wall_clock_ms: null
turns: null
total_input_tokens: null
total_output_tokens: null
billed_cost: null
human_correction_minutes: null
cancellation:
requested_at: null
provider_confirmed: null
tokens_after_cancel: null
只有当下一轮动作或可验证终态确实依赖它时，才把想法标成 used。“进入过上下文”不算使用。另外还要记录四种结果：
- 重复：只是换句话复述主推理，没有改变决策；
- 失效：新观察使它变成错误或无关信息；
- 冲突：与已验证约束或另一条分支相矛盾；
- 有害：促成错误动作、错误主张或错误恢复步骤。
可以先让盲化的人类审查一小部分。模型评分器在校准后可协助，但不应让同一模型家族独自评判自己产生的推理。这里不是要审计不可见的私有思维链，而是评估产品明确写回上下文的短建议工件。
同时测完整关键路径和完整账单
报告至少分成五组。
1. 有效结果与严重性。 任务成功、终态检查、政策遵循、如实升级，以及“观察到 0 次严重失败”的完整分母。
2. 用户可感知时间。 端到端 p50/p90/p95、首次有效状态更新时间、形成可审批草稿的时间、超时率与恢复时间。平均值下降，可能掩盖 p95 变差。
3. 流程效率。 回合数、工具调用、重试、主线程 token、分支总 token、新增上下文与人工修正分钟数。
4. 窗口利用。 符合条件的窗口数、有完整收获的窗口数、完整想法数、有效想法数、每个计费分支请求带来的有效想法，以及真正节省的有效分钟。
5. 完整经济账。 模型输入/输出、缓存读取、工具、检索、评分器、重试、可观测性与人工复核。
下面两个比率能把交换关系写清楚：
有效收获率 = 被采用的收获单元 / 完整收获单元
每增加 1 美元节省的有效分钟 =
（基线有效任务分钟 - 候选有效任务分钟）
/（候选完整成本 - 基线完整成本）
如果分母为零或负数，直接报告原始值，不要强造比率。比较的是“每个有效任务成本”，不是“每次尝试成本”。更快地产生更多废稿，不叫高效。
其他延迟研究也支持这种系统视角。PASTE 会推测未来工具调用，并在主线程确认前隔离结果；SPAgent 使用自适应推测与考虑引擎负载的调度器。它们与 Second Thought 的机制不同，但都提醒同一件事：并发可能把瓶颈移到无效工作、验证或服务拥塞。因此，这些成本必须进入你的试验。
主动制造失败，而不是等平均数报警
结构性问题不应该靠汇总指标偶然暴露。至少加入以下故障样本。
观察结果推翻全部分支
让承运商返回意外事件或权限错误。下一轮必须优先信任已验证观察，而非预计算建议，并测量陈旧分支文字是否增加了修正时间。
取消太慢，或者只是界面动作
混合很短与变化很大的等待。确认供应商是否真的停止分支请求、取消后是否继续计费，以及后台流量是否仍占用并发或限流额度。
上下文变长，却没有价值
运行一个包含多次等待的长任务。检查总上下文、缓存命中、下一轮延迟、重复率，以及更早的用户约束是否更难找回。
分支彼此冲突
设计一个 Recall 要求保留严格商家规则、Alternative 却提出捷径的场景。主 Agent 必须用权威产品状态解决冲突，而不是挑更流畅的那条。
并行负载拖慢主请求
按预期并发量运行，而不是只测单任务。四条额外生成可能与主线程或其他客户争用资源，尤其是在供应商限流或自托管 GPU 池已接近饱和时。
建议偷偷获得了权限
检查日志和工具控制，证明辅助分支不能调用工具或绕过审批。分支只是建议缓冲区，不能变成第二个控制面。
“更快”掩盖了更差的恢复
注入超时、部分响应、格式错误和工具重试。测最终有效率与恢复分钟数。预计算计划可能加快顺利路径，却让意外处理更脆弱。
用晋级凭证做决定，不用延迟截图
在看结果之前先写好决策工件。
parallel_reasoning_promotion:
scope:
tools: ["<eligible read-only tools>"]
task_population: "<declared segment>"
excluded_effects: ["messages", "refunds", "permission changes"]
frozen_system:
model: "<snapshot>"
harness_commit: "<sha>"
prompts_hash: "<hash>"
tool_schema_hash: "<hash>"
provider_region: "<region>"
gates:
accepted_task_delta: "<team-set>"
severe_failures: "0 observed / <N> trials"
p95_latency_delta: "<team-set>"
max_cost_increase: "<team-set>"
max_harmful_harvest_rate: "<team-set>"
cancellation_verified: false
evidence:
paired_trials: null
window_coverage: null
useful_harvest_rate: null
confidence_or_interval_method: "<method>"
trace_bundle: "<uri>"
decision: "hold | shadow | limited_go | promote"
owner: "<name>"
reviewer: "<name>"
expires_on_change:
- model
- branch prompts or count
- provider caching or pricing
- tool latency distribution
- permissions or approval flow
这里的 0 代表“在 N 次试验里观察到 0 次”，不是总体失败率为零的证明。Promote 只能覆盖明确工具与任务类型。某套分支策略对慢速、只读的承运商查询有效，并不意味着它自动获得支付工具或短数据库查询的资格。
先做影子运行。生成并记录辅助建议，但暂时不把它写入下一轮主上下文。先验证解析、取消、成本、泄漏与窗口覆盖；然后再对小范围配对流量启用，并保留立即退回基线的路径。基线必须一直可以部署。
明确适用边界，也明确不适用边界
最适合的流程通常有明显等待、多步重复工作、可验证终态，而且提前准备确实可能减少推理失败。例如：代码仓库搜索后等待测试、研究 Agent 等待远程来源、客服 Agent 检索多条政策、数据流程等待慢速只读任务。
最不适合的流程是：工具通常不到一秒、任务只有一步、并发资源稀缺、输入 token 极贵，或者副作用必须依赖最新观察和真人审批。高风险动作不能被推测性授权。等待真人决定是另一类空档；在此期间制造更多模型建议，可能只是给审批者增加压力。
还应先尝试更简单的办法：删掉不必要的回合；并行调用彼此独立的工具；使用长连接与缓存；减少重复上下文；给边界清楚的路由换更快模型。OpenAI 当前的模型指南明确建议，在保持质量门槛的前提下，同时比较总 token、延迟、成本、调用、回合与重试。并行推理应排在这些基本核算之后。
最后，Second Thought 目前是 v1 预印本。论文链接的匿名代码端点，在本次命令行检查中返回 HTTP 401；这不能证明它对所有访问者都不可用，但意味着本文只能依据论文公开的方法和表格，不能声称完成了独立代码复现。供应商模型、价格、缓存与限流也会变化。这些不确定性正是要运行产品试验的原因，而不是照抄论文结论的理由。
一套 48 小时 Build Lab 试验
第 0–4 小时：写清决策。 定义任务人群、符合条件的只读工具、有效终态、严重失败，以及值得购买的最低延迟或质量变化。
第 4–12 小时：测基线等待。 加入回合时间戳、效果类型、token、计费、重试与终态检查，按工具生成等待分布。
第 12–20 小时：实现影子分支。 先用一条任务匹配分支、可中断的独立单元、严格数量上限与可验证取消；暂时不要把建议写回线上下一轮。
第 20–30 小时：运行失败样本。 覆盖短等待、长等待、冲突结果、超时、错误格式、限流和并发饱和。轨迹与控制面有缺口时，先修缺口，不急着评判质量。
第 30–42 小时：执行配对试验。 在固定样本和重复试验中比较基线、单分支与四分支。先审有效终态，再看经济性。
第 42–48 小时：签署凭证。 选择 hold、shadow、limited_go 或 promote；保存轨迹与限制；设置失效条件；确认回滚到基线仍然有效。
最有价值的第一轮结果，可能是“我们的等待太短”或“一条分支已经拿到几乎全部价值”。这不是试验失败，而是省下了一套编排工程，并让团队真正看清产品关键路径。
Build Lab 结论
Second Thought 找到了一块真实的设计空间：环境忙碌时，Agent 可以提前准备。它的证据也说明，团队不该轻易使用“免费”这个词。把推理移出串行关键路径，可能减少回合或延迟，但仍会消耗请求、缓存输入、输出 token、上下文、调度容量和审查精力。
把等待窗口当成库存来管理：先量出多少窗口真实存在；判断哪些等待有资格使用；定义窗口里可以产生什么短工件；再计算每条有效收获的成本。只有当有效终态不退步、用户感知时间有实质改善、取消确实生效、有害建议低于预设门槛，而且完整账单符合产品条件时，才晋级并行推理。
今天最值得改变的一项决策是：不要给每个工具调用默认增加四条推理分支。先测量，再从一个慢速只读等待和一条有限建议分支开始，让它通过配对产品证据赢得上线资格。
参考资料
- Sun 等，Second Thought: Reasoning in Parallel as LLM Agents Act and Observe，2026。
- Yao 等，ReAct: Synergizing Reasoning and Acting in Language Models，2022/2023。
- Deng 等，SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks?，2025。
- Merrill 等，Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces，2026。
- Barres 等，tau-squared-Bench: Evaluating Conversational Agents in a Dual-Control Environment，2025。
- Sui 等，Parallelizing Tool Execution and LLM Generation for Low-Latency Agent Serving，2026。
- Huang 等，Reducing Latency of LLM Search Agent via Speculation-based Algorithm-System Co-Design，2025。
- OpenAI，Speeding up agentic workflows with WebSockets in the Responses API，2026。
- OpenAI，Model guidance，访问于 2026 年 8 月 18 日。