23.6 交错推理(Interleaving Reasoning)
从 OpenAI o1 到 DeepSeek-R1,"长链推理"(Chain-of-Thought)已经成为大模型能力的重要标志。但这些推理过程本质上是封闭的——模型在单次生成中完成所有思考,既不能回头看图片的细节,也不能中途去搜索新信息,更不能与其他模型协商。这就像一位科学家被关在没有网络、没有同事、没有实验设备的房间里思考——即使推理链再长,也无法弥补信息源的匮乏。
交错推理(Interleaving Reasoning)提出了一种截然不同的范式:推理过程不再是单一模态的线性思维链,而是将思考(Think)与行动(Act)交替编织在一起。模型可以在推理途中观察一张新图片、发起一次搜索、执行一段代码、调用一个工具,甚至与另一个模型讨论,然后将获取的新信息纳入后续推理。这种"边思考边行动"的模式更接近人类解决复杂问题的真实方式。
OpenAI o3、Deep Research、Zochi 和 BAGEL 等系统的发布,表明交错推理正在成为工业界追逐的下一代推理范式。学术界也在快速跟进——ICCV 2025 组织了专门的 Multi-Modal Reasoning for Agentic Intelligence Workshop(MMRAgi-2025),以 Awesome Interleaving Reasoning 为代表的研究合集首次对这一方向进行了系统梳理。
本节将从四个维度系统介绍交错推理的前沿进展:多模态交错推理(§23.6.1)、多轮行动交错推理(§23.6.2)、多智能体交错推理(§23.6.3),以及统一理解生成的交错推理(§23.6.4)。最后在 §23.6.5 中提炼统一框架并讨论未来方向。

图 23-21:交错推理的四大范式。从左到右依次是:(1)多模态交错推理——推理过程中交替处理文本与视觉信息;(2)多轮行动交错推理——推理中穿插搜索、代码执行等外部动作;(3)多智能体交错推理——多个模型在推理中交替发言与协作;(4)统一理解生成交错推理——推理过程中同时进行内容理解与多模态生成。
23.6.1 多模态交错推理:用图片思考
传统的视觉-语言模型(VLM)在处理图像时遵循一种"一次性消费"模式:图像在输入端被编码为一组 token,随后模型在纯文本空间中完成所有推理。这种模式在简单任务(如图片描述)上表现良好,但在需要细粒度视觉推理的任务(如计数密集场景中的目标、理解复杂图表关系、定位图片中的微小细节)中经常失败——因为模型在推理过程中无法"回头看"图片。
问题的根源在于信息瓶颈:视觉编码器将整张高分辨率图像压缩为几百个 token(例如 ViT-L/14 输出 256 个 token),推理过程中所有的视觉信息都必须从这些压缩后的表示中提取。当任务需要关注图片中某个很小的区域(如一张复杂图表中某一行的数值)时,压缩后的全局特征往往无法提供足够的细节。
多模态交错推理的核心思想是:让推理过程本身成为多模态的。模型不仅在开始时接收图像,还在推理的每一步中主动与视觉信息交互——放大关键区域、标注推理中间结果、甚至生成辅助图像来帮助思考。
DeepEyes:o3 风格的视觉推理。 DeepEyes(Guo et al., 2025)是首个开源的"o3 风格"视觉推理模型,其核心创新在于将视觉接地(Visual Grounding)深度集成到推理链中。在传统 CoT 推理中,模型只输出文本 token;而 DeepEyes 在推理过程中可以输出特殊的视觉操作指令,例如:
<think>
图片中有很多小目标需要精确计数。
让我先定位所有目标...
<zoom_in region="top-left" scale=2.0>
[系统返回放大后的图像 token]
在左上区域我看到了 3 个目标。
<zoom_in region="top-right" scale=2.0>
[系统返回放大后的图像 token]
在右上区域我看到了 5 个目标。
...
总计 17 个目标。
</think>这种设计实现了一个关键突破:推理链中的每一步都可以获取新的视觉证据。模型不再依赖初始编码时压缩的全局特征,而是可以根据推理需要动态获取高分辨率的局部信息。从技术实现角度,DeepEyes 在推理过程中维护一个视觉状态栈:初始状态是完整的原图,当模型生成 <zoom_in> 指令时,系统从原图中裁剪指定区域并重新编码为视觉 token,这些新 token 被追加到推理上下文中。模型可以多次嵌套放大,逐步聚焦到越来越精细的区域。
DeepEyes 的训练采用了两阶段方案:
- SFT 冷启动:构建包含视觉操作指令的推理轨迹数据,让模型学会基本的视觉操作指令格式和触发时机
- GRPO 强化学习:以最终答案的正确性作为奖励信号,通过 Group Relative Policy Optimization 让模型自主学习何时、对哪个区域执行视觉操作
实验表明,经过 RL 训练后,DeepEyes 在视觉计数任务上相比基线 VLM 提升超过 20%,在需要细粒度空间推理的基准测试中也展现出显著优势。
CoF(Chain of Focus):自适应视觉搜索。 如果说 DeepEyes 让模型学会了"放大镜",那么 CoF(Chain of Focus)则赋予模型一种更系统化的视觉搜索策略。CoF 的灵感来自人类观察复杂场景的方式——我们不会一次性扫描整张图片的所有细节,而是先形成全局印象,然后根据任务需要将注意力聚焦到关键区域,再进一步聚焦到更精细的细节。
CoF 将这种层次化的注意力策略形式化为一个迭代过程:
其中
与 DeepEyes 的"主动放大"不同,CoF 更强调搜索策略的自适应性——模型不仅要决定看哪里,还要判断何时停止搜索。一个经过良好训练的 CoF 模型会展现出有趣的行为模式:对于简单问题(如"图中有几棵树?"),它可能只进行一两步全局扫描就直接回答;而对于复杂问题(如"图表中第三季度的哪个指标增长最快?"),它会层层深入,从全图定位到图表区域,再聚焦到第三季度对应的列,最后逐一比较各指标的数值。
DeepEyes 与 CoF 的对比:两者都实现了"推理中回看图片"的能力,但设计哲学有所不同。DeepEyes 偏向于工具调用风格——视觉操作是推理链中的特殊指令,模型需要显式生成操作命令;CoF 偏向于注意力引导风格——视觉搜索本身是推理过程的有机组成部分,模型只需输出关注区域的坐标。两者的训练都依赖 RL,但 CoF 的搜索策略更具结构性(层次化从粗到细),而 DeepEyes 的操作更灵活(可以在任意时刻放大任意区域)。在实际应用中,CoF 更适合需要系统化视觉搜索的任务(如复杂图表理解),DeepEyes 更适合需要灵活视觉交互的任务(如开放域视觉问答)。
23.6.2 多轮行动交错推理:边做边想
如果说多模态交错推理让模型学会了"用眼睛思考",那么多轮行动交错推理(Multi-Round Acting Interleaving Reasoning)则让模型学会了"用手思考"——在推理过程中主动与外部世界交互,通过搜索引擎获取知识、通过代码执行器验证假设、通过 UI 操作完成任务。
这类方法的统一框架可以表示为一个交错序列:
这一框架继承了 ReAct(Yao et al., 2023)的 Thought-Action-Observation 范式,但关键区别在于:交错推理强调推理的连续性——Think 阶段不是简单的一句话规划,而是深度的 CoT 推理;Act 和 Observe 是嵌入在推理链中的"插曲",推理在获取新信息后无缝继续深入,而不是重新开始新一轮。
从训练角度看,多轮行动交错推理的主流方法都采用端到端强化学习:整个 Think-Act-Observe 序列被视为策略网络的一次完整 rollout,最终结果(任务是否完成)作为奖励信号。关键技术挑战在于:如何在不同来源的 token(模型自生成的 vs 环境返回的)之间正确地计算梯度。
根据外部动作的类型,我们将其分为三个主要方向。
搜索类:Search-R1 与知识增强推理。 Search-R1(Jin et al., 2025)是将搜索与推理交错的代表性工作(在 §21.10 的 Deep Research 语境中已有介绍,这里聚焦其作为交错推理范式的技术细节)。它将搜索增强推理建模为一个完全可观测的马尔可夫决策过程(MDP),模型在 <think> 标签内进行推理,遇到知识空缺时生成 <search> 标签触发检索,搜索引擎返回的结果被包裹在 <result> 标签中注入上下文,模型随后在新信息的基础上继续推理。
Search-R1 的训练创新在于掩码策略:在计算策略梯度损失时,检索返回的 token(即 <result>...</result> 内的内容)被掩码排除——因为这些 token 不是模型自己生成的,将其纳入损失计算会引入噪声。这一设计可以形式化为:
其中
Search-R1 的后续工作 R1-Searcher 进一步扩展了动作空间:在一次搜索动作中,模型可以发出多个并行查询,从不同角度覆盖更广的检索空间。这在需要多源信息综合的任务(如多跳推理)中尤为有效。OpenAI 的 Deep Research 功能可以被视为这一范式的工业级实现——模型在数分钟到数十分钟的推理过程中,动态发起数十次搜索、浏览多个网页、综合数百个信息源,最终生成一份结构化的研究报告。
代码类:ReTool 与 MathCoder。 数学推理是大模型的经典挑战场景。纯文本推理在处理复杂计算、符号推导、数值验证时容易出错——即使推理逻辑正确,一个算术错误就可能导致整个推导链崩溃。代码交错推理通过在推理过程中穿插代码执行来解决这一问题。
ReTool(Reasoning with Tool)采用了一种优雅的设计:模型在自然语言推理中可以随时生成 Python 代码块,这些代码块被发送到外部解释器执行,执行结果被注入回推理上下文。这使得模型可以将复杂计算"外包"给可靠的代码执行器,自己专注于高层推理逻辑:
<think>
要计算 C(52,5) 的值,即从 52 张牌中选 5 张的组合数。
<code>
from math import comb
result = comb(52, 5)
print(result)
</code>
<output>2598960</output>
所以总共有 2598960 种不同的 5 张牌组合。
接下来需要计算其中恰好包含 2 对的组合数...
</think>ReTool 的训练同样采用 RL 方案,奖励信号基于最终答案的正确性。一个重要的发现是:经过训练后,模型自主学会了选择性使用代码——对于简单的算术运算(如两位数乘法)直接在文本中完成,只在复杂计算(大数阶乘、排列组合、数值积分等)时才调用代码执行器。这种自适应行为不是人工设计的,而是通过 RL 自然涌现的。更有趣的是,模型还学会了在代码出错时进行自我修正——当执行结果与预期不符时,模型会在推理中分析错误原因,重新生成修正后的代码。
MathCoder(Wang et al., 2024)在此基础上构建了一个更完整的数学推理框架,支持三种代码交互模式:
- 计算验证:生成数值计算代码,验证推理过程中的关键计算步骤
- 符号推导:生成 SymPy 代码进行代数化简、方程求解、极限计算等符号运算
- 可视化辅助:生成 Matplotlib 代码绘制函数图像,帮助模型建立直觉判断
MathCoder 的训练数据通过自动化管道构建:先用强模型(如 GPT-4)生成包含代码交错的推理轨迹,再用这些轨迹对较小模型进行 SFT,最后通过 RL 进一步优化。这种"蒸馏 + RL"的两阶段方案已经成为代码交错推理的标准训练范式。
代码交错推理的成功关键在于推理与计算的分工:模型负责"想清楚要算什么",代码负责"算对"。这种分工避免了让模型同时承担推理和精确计算的双重负担,使其能够在更复杂的数学问题上保持可靠性。
UI 类:UI-TARS 与 GUI-R1。 搜索和代码操作的交互对象是结构化的(API 返回 JSON、代码执行器返回文本),但人类日常使用的大量软件是通过图形用户界面(GUI)交互的。UI 交错推理将推理与 GUI 操作(点击、滑动、输入、滚动等)交替进行,让模型能够像人类一样操作手机和电脑。
UI-TARS(ByteDance, 2025)是一个端到端的 GUI Agent 模型,其核心创新在于将 GUI 交互建模为一个视觉-语言-行动的交错序列。在每一步中,模型接收当前屏幕截图作为视觉输入,结合任务描述和历史动作进行推理,然后输出下一步操作(如 click(x=324, y=567) 或 type("Hello World"))。操作执行后,环境返回新的屏幕截图,模型在此基础上继续推理和行动。
一个典型的 UI-TARS 推理轨迹如下所示(以"在日历应用中创建明天下午 2 点的会议"为例):
[屏幕截图 1: 手机主屏幕]
Think: 我需要打开日历应用。我看到主屏幕上有日历图标。
Act: click(x=215, y=480)
[屏幕截图 2: 日历月视图]
Think: 日历已打开。我需要点击明天的日期来创建事件。
明天是15号,我能在日历网格中看到它。
Act: click(x=310, y=355)
[屏幕截图 3: 日期详情页]
Think: 现在我看到了明天的日程。我需要点击右下角的"+"
按钮来创建新事件。
Act: click(x=380, y=720)
[屏幕截图 4: 新建事件页面]
Think: 事件创建页面已打开。我需要先输入会议标题,
然后设置时间为下午 2 点。
Act: type("会议")
...UI-TARS 的训练面临一个独特挑战:动作空间极其庞大且连续(屏幕上任意像素都可以被点击),而且不同的 GUI 布局之间差异巨大——同一个"设置闹钟"任务在不同品牌手机上的操作路径完全不同。为此,UI-TARS 采用了三阶段训练策略:
- 感知预训练:在大量 GUI 截图上训练模型理解界面元素(按钮、文本框、菜单等),建立从像素到语义的映射
- 动作 SFT:用人类操作轨迹训练模型学习基本的 GUI 操作能力,包括坐标预测和动作类型选择
- 在线 RL:在模拟环境中通过强化学习优化多步决策,奖励信号基于任务是否成功完成
GUI-R1 则将 DeepSeek-R1 风格的长链推理引入 GUI 操作场景。与 UI-TARS 在每一步进行简短推理后立即输出动作不同,GUI-R1 在每一步输出动作之前先进行显式的深度推理——分析当前界面状态、回顾任务目标、预判可能的操作路径、评估各路径的风险,然后才执行具体动作。这种"先想后做"的模式在需要多步规划的复杂 GUI 任务中表现出明显优势——例如,当需要在设置菜单的多层嵌套结构中找到某个特定选项时,GUI-R1 会先推理可能的菜单层级,再有目的性地逐层导航,而不是盲目点击。
三类行动交错推理的共同范式与差异:搜索、代码和 UI 三类动作的核心设计思想一致——将外部世界建模为推理链中的"可调用函数",模型在推理时可以随时"暂停",执行一个外部动作获取新信息,然后带着新信息继续推理。但它们的反馈特性有显著差异:搜索返回的是文本片段(信息密度高但可能包含噪声),代码返回的是确定性结果(精确但表达力受限于程序逻辑),UI 返回的是视觉截图(信息丰富但解析成本高)。这些差异影响了各自的训练策略和模型设计。
23.6.3 多智能体交错推理:思想碰撞
前两类交错推理关注的是单个模型与外部信息源的交互。多智能体交错推理则转向一个更具挑战性的方向:让多个推理主体在同一个问题上进行交互式推理。不同的模型(或同一模型的不同实例)在推理过程中交替发言、相互质疑、互相补充,通过"思想碰撞"达成更可靠的结论。
这一方向的动机来自两个观察:(1)单个模型的推理存在系统性偏差(bias),不同模型的偏差方向往往不同,交叉验证可以有效降低错误率;(2)复杂问题通常需要多种专业知识的综合,没有任何单个模型能在所有维度上都表现最优。
辩论系统:Society of Minds。 "Society of Minds"(Du et al., 2023)提出了一种简洁而有效的多智能体辩论框架。核心想法直观:让多个 LLM 实例就同一个问题分别生成初始回答,然后进入辩论阶段——每个模型能看到其他模型的回答,并在此基础上修正自己的答案。这个过程迭代进行多轮,直到达成共识或达到最大轮数。
辩论过程可以形式化描述如下。设有
最终答案通过多数投票(Majority Voting)或置信度加权(Confidence Weighting)从第
但 Society of Minds 也暴露了两个有趣的局限:
- 回音室效应(Echo Chamber):当所有模型倾向于相同的错误答案时,辩论可能强化而非纠正这种错误。这在所有模型共享相似训练数据时尤为明显
- 顺从偏差(Conformity Bias):较弱的模型在看到较强模型的自信回答后,即使自己原本是正确的,也可能被"说服"而改变答案
这些发现提示:有效的多智能体辩论需要异构性——参与者应来自不同的模型家族、使用不同的训练数据、甚至采用不同的推理风格。后续研究引入了多种改进策略:例如设置"魔鬼代言人"(Devil's Advocate)角色专门负责质疑多数意见、使用匿名机制避免模型被对方的"品牌效应"影响、以及引入投票权重使推理更可靠的模型拥有更大的话语权。
协作框架:MetaGPT 与 Zochi。 辩论系统中的多个模型是对等的——它们扮演相同的角色,只是提供不同的视角。MetaGPT(Hong et al., 2024)和 Zochi(OpenAI, 2025)则引入了角色分工,让不同的模型承担不同的职责,像一个真正的团队那样协作。
MetaGPT 将软件开发中的标准化流程引入多智能体系统。它为每个 Agent 分配明确的角色——产品经理、架构师、工程师、测试员——并通过标准化输出协议(如 PRD 文档、API 设计文档、代码审查报告)实现角色之间的高效沟通。MetaGPT 的关键创新在于结构化通信机制(Standardized Operating Procedures, SOPs):Agent 之间不是自由对话,而是通过预定义格式的"工件"(Artifact)传递信息,这大大减少了多智能体通信中的噪声和歧义。
MetaGPT 的工作流程可以概括为一个角色间的交错推理链:
- 产品经理 Agent 将用户需求分解为结构化的需求文档(PRD),明确功能点和验收标准
- 架构师 Agent 基于 PRD 设计系统架构,输出接口定义和数据流图
- 工程师 Agent 根据架构设计实现具体代码,生成可运行的程序
- 测试员 Agent 对代码进行自动化测试并反馈缺陷报告
- 若测试未通过,缺陷报告回传给工程师,触发修复-重测循环
这种分工合作本身就是交错推理的一种体现:每个 Agent 的输出是下一个 Agent 的输入,推理在不同角色之间交替进行。与自由对话相比,结构化通信将 token 消耗降低了约 50%,同时使协作质量更加稳定可控。
Zochi(OpenAI, 2025)代表了多智能体协作的最新进展。它是 OpenAI 发布的一个研究系统,能够协调多个专家模型在科学发现、复杂分析等任务上进行协作推理。Zochi 的核心理念是异构专家协同——不同的模型被训练为某一领域的专家(如数学推理专家、代码生成专家、文献综合专家),然后由一个协调器(Orchestrator)根据任务需要动态调度合适的专家参与推理。
与 MetaGPT 的固定流水线不同,Zochi 的协作模式是动态的:协调器在推理过程中根据当前状态决定下一步应该调用哪个专家。这使得系统能够应对高度开放和不确定的任务——在问题本身都没有明确定义的情况下,通过多个专家的交替推理逐步厘清问题结构并找到答案。协调器本身也是一个 LLM,它通过分析当前推理上下文中的"知识缺口"来决定调度策略——例如,当推理进入数学推导阶段时调用数学专家,当需要文献支撑时调用文献检索专家。
下表对比了三种多智能体交错推理的设计选择:
| 特性 | Society of Minds | MetaGPT | Zochi |
|---|---|---|---|
| 角色关系 | 对等辩论 | 固定流水线 | 动态调度 |
| 通信方式 | 自然语言对话 | 结构化工件 | 混合(结构化+自然语言) |
| 异构性 | 可选(同/异模型) | 角色异构 | 专家异构 |
| 协调机制 | 无(对称) | 预定义流程 | 协调器 LLM |
| 适用场景 | 事实性问答 | 软件开发 | 开放式研究 |
多智能体交错推理的核心挑战不在于单个模型的推理能力,而在于协调机制的设计:如何让多个模型高效沟通而不产生信息过载?如何分配信用(Credit Assignment)使得每个模型都能从整体成功中学习?如何避免"群体思维"(Groupthink)导致集体犯错?这些问题与人类组织行为学中的经典难题高度平行。
23.6.4 统一理解生成交错推理:理解即生成
前三类交错推理都围绕"理解"展开——模型通过与外部信息源的交互获取更好的理解。第四类交错推理则走得更远:将理解与生成统一在同一个推理过程中。模型不仅能在推理中消费多模态信息,还能在推理中创造多模态内容——生成图像、编辑图片、创作视觉内容——并将这些生成的内容反馈到后续推理中。
这一方向的理论基础在于一个深刻的观察:理解和生成是同一枚硬币的两面。能够准确生成一张猫的图片的模型,必然对"猫"的视觉特征有深入的理解;反过来,深入理解视觉世界的模型也应该能够想象和创造视觉内容。将这两种能力统一在同一个框架中,不仅是架构上的优雅,更能带来能力上的相互增强。
BAGEL:多模态预训练新范式。 BAGEL(Dang et al., 2025)是一个统一的多模态模型,能够在同一个框架内同时处理图像理解和图像生成任务。这种"理解+生成"的统一不是简单的多任务学习——BAGEL 的核心洞察是:理解能力和生成能力是相互增强的。
BAGEL 的架构基于一个精巧的双路径设计:
- 理解路径:图像通过视觉编码器(如 ViT)编码为连续的视觉 token,与文本 token 拼接后送入 Transformer 进行自回归推理。这一路径与标准 VLM(如 LLaVA)的设计一致
- 生成路径:Transformer 在推理过程中可以输出特殊的"图像生成 token",这些 token 被送入扩散模型解码器(Diffusion Decoder)生成图像。生成 token 的维度和格式经过专门设计,使其能够作为扩散模型的条件输入
- 交错路径:理解和生成可以在同一个推理链中交替进行——模型可以先理解一张输入图像,在推理中生成一张辅助图像(如流程图、示意图),然后基于这张辅助图像继续推理
BAGEL 的预训练采用渐进式策略,分为四个阶段:
- 纯文本预训练:在大规模文本语料上训练基础语言能力
- 图文对齐:在图文对数据上训练视觉理解能力,冻结视觉编码器,仅训练投影层和 LLM
- 生成能力注入:引入扩散模型解码器,在图像生成数据上训练从 LLM 隐状态到图像的映射
- 交错训练:在包含理解和生成交替出现的数据上联合训练,使模型学会在两种模式之间自然切换
这种渐进式预训练使模型在保持各单项能力的同时,逐步获得在理解和生成之间灵活切换的能力。BAGEL 与 §23.1 中介绍的 Janus 系列有异曲同工之处——两者都追求理解与生成的统一,但 BAGEL 更强调在推理链中的动态交错,而 Janus 侧重于架构层面的解耦设计。
GoT-R1:视觉生成中的推理。 如果说 BAGEL 侧重的是"在推理中生成",那么 GoT-R1(Generation of Thought for R1)则聚焦于"在生成中推理"。GoT-R1 将 R1 风格的长链推理引入视觉内容生成过程,使模型在生成图像之前和之中进行显式推理。
传统的文生图模型(如 Stable Diffusion、DALL-E)将提示词直接映射为图像,中间没有显式的推理过程。这导致模型在处理复杂提示词时经常出错——例如"一只猫坐在三本书上面,最左边的书是红色的"这样的描述,需要模型同时处理物体计数、空间关系和属性绑定,而端到端生成模型很难同时满足所有约束。GoT-R1 通过引入推理阶段来解决这一问题:
- 推理阶段:模型首先对提示词进行深入分析——分解场景元素(猫、三本书)、确定空间关系(猫在书上方)、明确属性约束(最左边的书是红色的)
- 规划阶段:基于推理结果,模型生成一个详细的布局规划,包括各物体的位置坐标、大小比例、颜色属性等
- 生成阶段:扩散模型在布局规划的条件引导下生成图像
- 验证阶段:模型对生成的图像进行视觉推理(利用理解能力),检查是否满足原始提示词的所有要求——猫确实在书上方吗?书确实有三本吗?最左边的确实是红色吗?若不满足,则回到推理阶段进行修正
这种"推理-生成-验证"的闭环使 GoT-R1 在复杂场景生成、精确属性控制等任务上显著优于传统的端到端生成模型。它本质上将图像生成从"一次性映射"转变为"迭代优化",每一轮迭代都通过推理来缩小当前图像与目标描述之间的差距。
BAGEL 与 GoT-R1 的互补关系。 BAGEL 和 GoT-R1 从两个方向逼近同一目标——统一的多模态推理生成系统。BAGEL 的起点是一个统一的预训练框架,理解和生成能力在训练过程中自然融合;GoT-R1 的起点是现有的生成模型(扩散模型),通过在其上层叠加推理能力来增强可控性。两者的最终愿景是一致的:一个能够在推理中自由消费和创造多模态内容的通用智能系统。
统一理解生成的深层意义:传统的 AI 系统将"感知"和"行动"视为两个独立模块。统一理解生成的交错推理打破了这一边界——模型可以在同一个推理链中自由切换理解和生成模式,这不仅提升了各自的能力,更开启了全新的应用可能:例如在数学推理中自动生成辅助几何图形、在科学分析中绘制数据可视化图表、在创意写作中插入配图等。
23.6.5 交错推理的统一视角与未来方向
回顾本节介绍的四大交错推理范式,可以提炼出一个统一的形式化框架。设推理过程为一个状态序列
| 操作类型 | 描述 | 代表方法 |
|---|---|---|
| Think | 纯文本内部推理 | 所有方法的基础操作 |
| Perceive | 获取新的视觉信息 | DeepEyes(放大)、CoF(聚焦) |
| Search | 从外部知识库检索信息 | Search-R1、R1-Searcher |
| Execute | 执行代码并获取结果 | ReTool、MathCoder |
| Interact | 与 GUI 环境交互 | UI-TARS、GUI-R1 |
| Consult | 与其他模型交流 | Society of Minds、Zochi |
| Generate | 生成多模态内容 | BAGEL、GoT-R1 |
交错推理的关键在于:模型在推理过程中可以自主选择执行哪种操作,而这种选择能力通过强化学习从奖励信号中涌现。从 MDP 的角度看,状态
下表从多个维度对比了四大范式的技术特点:
| 维度 | 多模态交错 | 多轮行动交错 | 多智能体交错 | 统一理解生成 |
|---|---|---|---|---|
| 交互对象 | 视觉信息 | 外部工具 | 其他模型 | 生成模块 |
| 信息流向 | 环境→模型 | 双向 | 模型↔模型 | 模型内部循环 |
| 延迟特性 | 低(裁剪编码) | 中(API 调用) | 高(多轮对话) | 高(扩散生成) |
| 训练范式 | SFT + RL | RL 为主 | Prompt 或 SFT | 渐进式预训练 |
| 核心难题 | 视觉搜索策略 | 工具选择时机 | 信用分配 | 模态切换协调 |
训练范式的共性。 纵观四大范式,RL 是交错推理最核心的训练手段。其原因在于:交错推理中"何时执行什么操作"的决策是离散且组合爆炸的,无法通过人工规则穷举;而 RL 通过试错学习,可以让模型从大量 rollout 中自主发现最优策略。具体而言:
- SFT 提供冷启动:让模型学会基本的操作格式和触发条件
- RL 实现策略优化:以 GRPO 为主流算法,通过最终结果的奖励信号优化模型的决策策略
- 掩码机制处理混合序列:对环境返回的 token 进行梯度掩码,只对模型自身生成的 token 计算策略梯度
当前的核心挑战。 交错推理虽然前景广阔,但仍面临若干技术瓶颈:
上下文长度爆炸。 交错推理的每一步外部交互都会向上下文注入新信息(搜索结果、代码输出、屏幕截图等),这使得上下文长度快速膨胀。以搜索类交错推理为例,每次搜索返回的文档片段通常有数百到数千 token,10 次搜索就可能产生 5k-20k token 的额外上下文;而 UI 类交错推理中,每一步的屏幕截图编码后也需要数百个视觉 token。一个复杂的 Deep Research 任务可能产生超过 100k token 的推理轨迹,这对模型的长上下文处理能力提出了极高要求。
ReSum 等工作通过引入摘要压缩机制来缓解这一问题——在推理过程中周期性地将历史交互压缩为简短摘要,从而控制上下文增长。但如何在压缩中保留关键信息、避免"遗忘"早期获取的重要证据,仍是开放问题。
信用分配困难。 当推理链中包含数十次外部交互时,最终结果的好坏难以归因到具体的某一步操作。这使得 RL 训练中的信用分配(Credit Assignment)成为核心难题。当前的解决方案包括阶段化奖励(R1-Searcher)、蒙特卡洛信用分配(C-3PO)以及多角色独立奖励(MMOA-RAG),但距离理想的细粒度信用分配仍有差距。
多模态推理的统一架构。 当前的交错推理系统大多针对特定的交互类型设计(如专门用于搜索的 Search-R1,专门用于代码的 ReTool,专门用于 GUI 的 UI-TARS)。一个真正通用的交错推理系统应该能够在同一个框架内统一所有类型的交互——像人类一样在解决问题时自由地在搜索、计算、绘图、讨论之间切换。这需要在架构设计、训练方法和评估体系上实现全面的统一,是交错推理走向成熟的必经之路。
评估标准缺失。 现有基准测试大多针对单一类型的交错推理设计——MathBench 评估代码交错推理,WebArena 评估 UI 交错推理,MMMU 评估多模态推理。但对于需要同时使用多种交互类型的复合任务(如"阅读一篇包含图表的论文,搜索相关工作进行对比,用代码复现实验,生成可视化结果"),目前尚缺乏统一的评估框架。构建这样的综合基准测试是社区亟需解决的问题。
从交错推理到持续推理。 当前的交错推理仍然是"会话级"的——每次推理从零开始,推理结束后所有中间状态都被丢弃。一个更长远的方向是持续推理(Persistent Reasoning):模型在多次推理会话之间保持记忆,积累的知识和经验可以在后续推理中复用。例如,一个科研 Agent 在阅读了 100 篇论文后,应该能够利用之前积累的领域知识来加速对新论文的理解——而不是每次都从零开始建立知识体系。这将把交错推理从"解决一个问题"扩展到"持续学习和成长",距离真正的通用智能更近一步。
本节小结。 交错推理代表了从"封闭推理"到"开放推理"的范式转变。通过将推理与多模态感知、外部工具调用、多智能体协作、内容生成交织在一起,模型获得了远超纯文本 CoT 的问题解决能力。四大范式——多模态交错推理(DeepEyes、CoF)、多轮行动交错推理(Search-R1、ReTool、UI-TARS)、多智能体交错推理(Society of Minds、MetaGPT、Zochi)、统一理解生成(BAGEL、GoT-R1)——分别从不同维度扩展了推理过程的边界。随着这些技术的逐步成熟与统一,交错推理有望成为迈向 AGI 的下一代推理系统的核心范式。