斯坦福大学与MIT的研究团队在NeurIPS 2025上提出ReCAP（Recursive Context-Aware Reasoning and Planning，递归上下文感知推理与规划）。
它通过在共享上下文中进行递归推理和规划，让大模型能够像人类一样，在坚持总体目标的同时，灵活应对执行中的变数。
ReCAP利用递归上下文感知与结构化回溯机制，在共享的滑动窗口中动态维护层级计划，解决了大模型在长链路任务中容易走神和遗忘的根本难题。
智能的核心特征之一，是在高层抽象推理与低层具体执行之间平滑过渡。
人类在处理复杂任务时，这种能力表现得淋漓尽致。
想象一下组织一次多日旅行：你首先会制定一个宏观计划——确定目的地、交通方式和住宿；随后，你会将这个宏观计划细化为可执行的子任务，比如预订特定航班或安排当地接送。
现实世界的执行过程很少完全按照脚本进行：资源可能不可用，中间步骤可能失败，或者时间表可能发生冲突。
这种情况要求长程推理既要保留全局意图，保持计划中不同细节层级之间的一致性，又要随着反馈的展开灵活地修正步骤。
当前的基于大语言模型的方法在这里面临严峻挑战。
顺序提示方法（如ReAct）容易出现上下文漂移，早期的计划往往因超出上下文窗口而被遗忘，导致模型在错误中循环；而分层提示方法往往会削弱层级之间的连续性，或因冗余的记忆使用而产生巨大的运行时开销。
为了解决这些场景，我们需要一种具备上下文感知的长程自适应推理与规划系统。
上下文漂移与长程任务的痛点
要理解ReCAP的价值，我们必须先剖析现有方法的局限性。
目前的推理框架使LLM能够将推理与行动交织在一起，提高了多步设置中的问题解决能力。
最典型的是链式思维（CoT）、ReAct和Reflexion。
这些方法主要以线性方式运作：模型沿着单一轨迹生成逐步的想法、行动和观察。在短期任务上，这些方法简单有效。
但在长程环境中，问题暴露无遗。
随着对话历史的累积，早期的宏观计划往往会被挤出上下文窗口，或者即使在扩展窗口中也变得陈旧，不再能指导当前的行动。
这被称为上下文漂移（Context Drift）。模型忘记了原本要做什么，甚至忘记了刚才做了什么，导致目标信息丢失和反复的失败循环。
即使是Ada-Planner这样试图通过明确的闭环改进来编辑单一全局线性计划的方法，在长程上仍然容易偏离计划轨迹。
为了应对这一挑战，分层提示方法应运而生。
Tree of Thoughts (ToT) 探索思维树的分支和回溯；THREAD递归地生成子问题；ADaPT交替使用规划者和执行者提示来细化子目标。
虽然这些方法在组织推理上引入了层级，但它们存在两个主要缺陷：
层级割裂：当子任务在隔离的上下文中被提示时（如THREAD），层级之间的推理连续性会降低，子目标提示只携带部分父级信息，导致各干各的，缺乏全局视野。
开销巨大：引入了增加的运行时开销，并强烈依赖于先前的轨迹或特定工具的状态。
ReCAP的设计初衷，就是在保持高效的同时，解决层级间的连贯性问题。
ReCAP的核心机制：递归与回溯
ReCAP并非单纯地增加上下文长度，而是改变了上下文的组织和使用方式。它建立在三个核心机制之上，构成了一个严密的逻辑闭环。
1. 预先计划的任务分解（Plan-ahead Task Decomposition）
传统的ReAct是一步一步想，一步一步做。ReCAP则采用了走一步，看三步的策略。在每个深度，模型不是一次生成一个子任务，而是一次生成一个完整的子任务列表（Subtask List）。
但关键在于执行策略：模型只承诺执行列表中的第一项。
如果第一项是一个原子动作（Primitive Action），直接执行；如果是一个复杂的复合任务，则进入递归。
对于列表中剩余的子任务，ReCAP将它们暂时保留。
为什么要保留？因为环境是动态的。执行完第一项后，世界可能已经变了，剩下的计划可能需要调整。
这种生成全表，只做首项，余下待定的策略，既保证了行动有方向，又保留了极大的灵活性。
2. 结构化注入与一致的多级上下文（Consistent Multi-level Context）
这是ReCAP最精妙的设计。它没有为每个子任务开设新的对话窗口，而是维护一个共享的LLM上下文树。
当从子目标返回时（无论是成功还是失败），父级的计划（最新的想法和剩余的子任务）会被重新注入（Re-injected）到活跃的上下文窗口中。
这种机制确保了跨层级的连续性。
想象你在做一道复杂的菜。当你切完洋葱（子任务完成）回到主流程时，ReCAP会提醒你：你刚才切好了洋葱，原本的计划是切洋葱、炒肉、混合。现在洋葱好了，环境变成了这样，请根据现有情况优化剩下的步骤。
这种结构化注入相当于一种显式的回溯（Backtracking）：子任务结束后，其结果和新的环境观察被附加到上下文中，提示LLM细化父级的推理并更新剩余计划。
通过这种方式，ReCAP根据执行反馈动态地修剪或修改子任务，确保持续的计划细化。
所有推理都保留在一个演变的上下文中，而不是在每个层级分配单独的上下文，这使得ReCAP能够支持一致的上下文更新，利用历史对话作为上下文感知的演示，从而确保连贯的多级规划。
3. 滑动窗口与可扩展的内存效率
无限的上下文是昂贵且不可行的。ReCAP设计了一种内存高效的执行方式。
活跃的LLM提示受到滑动窗口的限制（例如保留最近的64轮对话）。旧的对话轮次会被自动移除。你可能会担心，移除旧对话会不会导致遗忘？
不会。因为关键的规划信息通过结构化注入被重新引入了。每当递归返回，高层意图就被再次刷进当前窗口。因此，截断不会导致高层结构的丢失。
这种设计使得外部状态的大小仅随递归深度线性增长，而不是随整个交互轨迹的长度增长。
ReCAP不需要在每次递归调用中重复冗余的少样本（Few-shot）演示，而是在初始化时放置一次。这显著增加了可用于LLM推理的token比例。
在每一步，只有从根节点到当前节点的路径保持活跃，既节省了显存，又保证了关键信息的在场。
实验数据：严格条件下的全面碾压
为了验证ReCAP的有效性，研究团队选择了四个具有不同规划视野和反馈动态的基准测试：Robotouille（烹饪）、ALFWorld（家庭活动）、FEVER（事实验证）和SWE-bench Verified（代码编辑）。
评估采用最严格的pass@1设置：每个代理只允许一次推理-执行轨迹，没有重试，没有波束搜索，没有集成。
这是为了考察代理最原始的决策能力，排除了自我一致性（Self-consistency）或多路尝试带来的性能虚高。
Robotouille是一个具体的烹饪环境，特别适合评估长程任务。它分为同步（Synchronous）和异步（Asynchronous）两种模式。异步模式更难，因为烹饪或注水等动作有延迟，代理需要在等待期间穿插其他子任务。
在这里，ReCAP的表现令人印象深刻。
在同步模式下，ReCAP的成功率达到70.0%，而标准的ReAct只有38.0%，提升了32%。
在更复杂的异步模式下，ReCAP达到53.0%，ReAct仅为24.0%，ADaPT更是只有14.0%。
这巨大的差距源于任务的复杂性。
Robotouille中的子任务往往需要多个原子动作。例如，切菜看似简单，实际上在环境中需要三次连续的切动作。
ReAct这种扁平的提示方法，很容易在做完前两个切动作后，被新的观察干扰，忘记了要切第三下，或者忘记了切完之后要把菜放到哪里。
ReCAP通过层级结构锁定了切菜这个子目标，直到它彻底完成才释放控制权，从而避免了这种低级错误。
ALFWorld的任务相对较短，通常需要5-15步。ReCAP在这里达到了91.0%的成功率，高于ReAct的84.0%。
FEVER是一个事实验证任务，通常少于10步。ReCAP和ReAct都达到了63.5%的准确率。这符合预期：当推理步骤很少时，显式层级结构和回溯的优势会减弱。
但重要的是，ReCAP没有因为复杂的机制而降低性能，这显示了其广泛的适应性。
SWE-bench是代码修复的真实基准。这里的动作空间是无限的（可以写任意代码）。ReCAP在这里达到了44.8%的解决率，优于ReAct的39.58%。
在代码任务中，ReCAP将每一次工具调用（Tool Call）视为一个子任务节点。
因为代码编辑往往需要多次尝试和修正，ReCAP的执行-观察-回溯-细化循环非常适合这种场景。它能够在工具调用失败后，利用回溯机制重新思考参数或策略，而不是像ReAct那样容易陷入死胡同。
这种差异本质上是错误恢复能力的差异。ReAct在错误中容易迷失，而ReCAP利用层级上下文将其识别为需要上一级决策介入的信号。
成本与效率：值得的交换
在三个具有代表性的Robotouille任务上，对四种模型进行了基准测试。
ReCAP在所有评估模型中始终优于ReAct，表现出强大的鲁棒性和广泛的适用性。
这些结果突出了递归框架在不同模型之间的兼容性和可靠性，而不需要任何特定于模型的调优或代码修改。
天下没有免费的午餐。ReCAP的优异性能是以增加推理成本为代价的。
在Robotouille任务中，ReCAP的平均LLM调用次数约为75次，完成一次任务的平均成本约为7.77美元。
相比之下，ReAct在ALFWorld上的成本仅为ReCAP的三分之一左右。额外的成本主要来自中间任务分解所需的额外步骤以及输入中保留的推理痕迹。
然而，从解决率的角度看，这种投入是划算的。
在SWE-bench这样的高价值代码任务中，ReAct往往因为无法处理复杂的依赖关系而彻底失败，成本虽低但产出为零。ReCAP虽然想得多，但确实做成了。
对于需要高可靠性的长程智能体应用来说，这种以计算换智能的策略是合理的。
此外，ReCAP的滑动窗口机制确保了成本是可控的。
随着任务长度增加，每次调用的Prompt长度并没有爆炸式增长，而是保持在一个常数级别，外部状态的存储也只与树的深度成正比，而非整个历史长度。
这意味着ReCAP在理论上可以支持极长周期的任务，而不会因为上下文溢出而崩溃。
尽管表现强劲，ReCAP并非完美无缺。
首先，它完全依赖于底层模型的原始能力。
所有的分解、执行和回溯决策都由LLM自己做出，缺乏外部的验证器或模拟器。
如果模型本身比较弱，或者产生了幻觉，ReCAP结构无法神奇地修正它，甚至可能因为层级传播而放大错误。
其次，递归设计不可避免地增加了交互的轮次，导致端到端的延迟增加。在对实时性要求极高的场景下，这可能是一个瓶颈。
一种可能的改进方向是架构模块化，将高层规划（由大模型负责）与低层执行（由轻量级小模型负责）解耦，以提高效率。
另一种方向是探索更高级的记忆结构，例如将上下文组织为可执行的图（Executable Graph），而不仅仅是文本树，这将允许更精准的信息检索和强化学习的介入。
ReCAP揭示：在长程任务中，如何组织和再注入上下文，比单纯增加上下文的长度更为重要。它告诉我们，让模型在正确的时间看到正确的信息，比一次性把所有信息都塞给它要有效得多。
参考资料：
https://arxiv.org/abs/2510.23822
----C++重要基础入门知识)
