浅谈 ReCAP（Recursive Context-Aware Reasoning and Planning）——大模型推理与规划的递归范式

ReCAP（Recursive Context-Aware Reasoning and Planning） （论文链接：https://arxiv.org/pdf/2510.23822）提出了一种"递归、可回溯、可修正"的长链推理机制，使 LLM 能够规划复杂多步骤任务，并在执行过程中根据环境反馈自我修正。

相比传统的 Chain-of-Thought、ReAct 和普通 Planner-Executor，ReCAP 更接近类程序化的智能体推理框架。

本文将带领读者朋友逐步解析 ReCAP 的思想、架构以及算法流程。

---

1. 为什么需要 ReCAP？

大模型在复杂任务（如多步骤规划、数据分析、多工具调用、策略推演）中经常遇到三个限制：

传统范式	主要问题
Chain-of-Thought	单次长思考，不可修正、不可回溯，失败即失败
ReAct	虽支持工具调用，但序列化执行，没有层级结构，难以控制
基本 Planner-Executor	Planner 一次性生成全局计划，无法根据执行反馈自动调整

这些机制都缺乏一个关键能力：

如何让 LLM 像程序一样递归执行，并在过程中根据反馈不断修正？

而 ReCAP 提供了答案。

---

2. ReCAP 的核心思想

论文提出的核心思想可以压缩为一句话：

将复杂任务拆解为嵌套子任务，每个子任务自身可以规划、执行、回溯，然后把结果反哺给父任务。整个过程以递归方式运行。

它引入了三个关键组件：

---

2.1 π ( C )：上下文感知规划函数（Plan）

给定当前任务 T 和上下文 C，生成：

• 思考（think）
• 子任务列表（subtasks）

公式：

T, S = π(C)
T = think（推理文本）
S = 子任务列表

π ( C ) 会参考：

• 当前任务
• 上下文（历史、反馈、执行结果）
• 父任务的信息（因为是递归结构）

所以叫"Context-Aware Planning"。

---

2.2 执行框架：递归任务栈

与程序语言的执行栈一模一样：

• 每一个待办任务是一个栈帧 frame

• 任务 frame 内包含：

  • task 描述
  • think 推理内容
  • subtasks 子任务列表
  • cursor 指向当前执行到哪一步

当遇到非 primitive 子任务时：

把子任务当作一个新的任务入栈 → 递归执行

实现了"任务树"的深度优先执行。

---

2.3 ρ ( C ) ：基于环境反馈的计划修正（Refine）

每执行完一个子任务都会得到环境反馈 obs。

ρ ( C ) 的作用：

• 根据 obs 调整当前计划（删除、扩展、重排子任务）
• 更新子任务 S'
• 更新 think'
• 控制任务是否继续

ReCAP 的关键思想就在这里：

失败不是终点，错误是新的信息。任务应被动态重写，而不是直接报错退出。

这让智能体具备了"恢复能力（resilience）"。

---

3. ReCAP 的整体执行算法

3.1 ReCAP 的核心循环（伪代码）：

def solve_task(task):
    T, S = plan(task)  # π(C)

    while S 不为空:
        if S[0] 是 primitive:
            obs = 执行(S[0])
        else:
            solve_task(S[0])  # 递归

        # 回到当前位置，基于反馈 obs 调整计划
        S = refine(T, S[1:], obs)     # ρ(C)

    return

在上述过程中：

1. plan 生成当前任务的 plan（T）与子任务 S
2. 每次执行 S 的第一个子任务
3. 执行后获得反馈 obs
4. refine 更新计划，使其适配最新环境
5. S 的长度不断缩短直到为空 → 当前任务完成
6. 返回父任务继续执行

ReCAP 的执行顺序是类似深度优先搜索（DFS）的递归模式。

---

4. ReCAP 的"任务树"与递归结构

在执行过程中：

• 根任务产生子任务
• 子任务产生孙任务
• 每一层都运行自己的 plan → act → refine 循环
• 执行完子任务后回到父任务并更新其 S 列表

就像这样一个任务树：

做牛肉汉堡
├── 准备食材
│   ├── 拿面包
│   └── 切生菜
├── 处理牛肉
│   └── 煎牛肉饼
└── 组装汉堡
    ├── 涂酱
    └── 组合

ReCAP 递归地、层层完成每个节点。

---

5. ReCAP 相比 ReAct / CoT 的根本提升

能力	CoT	ReAct	Planner-Executor	ReCAP
分步骤推理	✔	✔	✔	✔
工具调用	✖	✔	✔	✔
递归结构	✖	✖	✖	✔
错误自我修复	✖	部分	✖	✔
上下文精确对齐	弱	弱	中	强（递归上下文）
可视化解释性	中	低	中	极高（栈结构）

ReCAP 的本质就是：

给 LLM 配上了一个类似"函数调用栈 + 回溯 +自我修复"的执行框架

这不仅实现了在认知上表现得比较聪明，同时也在工程上极具可控性。

---

6. 为什么 ReCAP 能执行长链任务？

ReCAP 通过三个机制解决了长链任务的关键问题：

6.1 结构化上下文（Structured Context）

每一层任务都有独立的上下文：

• 层级清晰
• 信息不会互相污染
• 不会形成巨大 prompt 塞入 LLM

这使得长任务执行成为可能。

6.2 错误修复与偏差矫正（Error Recovery）

如果某一步执行失败，ReCAP：

• 将错误 obs 重新输入 refine
• 自动补充一个"修复子任务"

这等价于自动生成：

"哎呀，这一步不对，我需要做 XXX 来修正它"

而不是直接报错。

6.3 子任务级别的状态压缩（State Compression）

不是把所有历史都堆进 prompt，而是：

• 每一层只保留它需要的上下文
• 子任务完成后，上下文不会无限扩张

从工程角度极大降低 token 成本。

---

7. ReCAP 在实际 Agent 系统中的价值

现代智能体越来越接近"复杂软件执行器"，而 ReCAP 提供的递归执行框架天然适合：

✔ 多步骤任务计划器（Planner）

递归拆分任务，像程序一样执行。

✔ 工具链编排（Toolchain Orchestration）

每个 subtree 可以独立规划工具调用序列。

✔ 数据处理 / ETL 管道

每个阶段失败都能修复，而不是全部重跑。

✔ 自动化运维智能体（AIOps）

当某次探测执行失败时，ReCAP 能自动 patch 任务计划。

✔ 多模态执行（如机器人控制）

ReCAP 的"计划---执行---修复"正是机器人规划的结构。

---

8. 一个直观示例：做一个牛肉汉堡

用伪代码理解 ReCAP：

做汉堡
└─ 准备食材
     ├─ 拿面包
     └─ 切生菜
└─ 处理牛肉
     └─ 煎牛肉饼
└─ 组装汉堡
     ├─ 涂酱
     └─ 组合

执行过程：

1. 根任务 plan → 拆分 3 个子任务
2. 执行第 1 个子任务"准备食材"
3. plan 子任务 → 子任务有两个步骤
4. 执行"拿面包" → 成功 → refine 更新
5. 执行"切生菜" → 成功 → refine 更新
6. 返回父任务 → refine 父任务计划
7. 继续执行"处理牛肉"
8. ...
9. 所有子任务完成 → 返回根任务 → 完成

整个过程完全等价于 DFS + 回溯。

---

9. ReCAP 的工程化扩展

在下一篇博客中，笔者将给出这篇论文的 LangGraph + ReCAP 简易实现，其中：

• 栈帧 Frame → 论文中每个任务的上下文 C
• plan_llm → π ( C )
• refine_llm → ρ ( C )
• 栈结构 → 递归执行与回溯
• LangGraph → 有向图驱动执行主循环

敬请期待~

续更（用 LangGraph 从零实现 ReCAP：一个可运行的递归任务规划框架（纯模拟版））

---

10. 总结

ReCAP 的价值可以总结成一句话：

把 LLM 的推理过程从"一次性长思考"升级为"可执行、可递归、可修正的规划程序"。

它为智能体带来了：

• 层级性（Hierarchy）
• 可控性（Control）
• 稳定性（Robustness）
• 解释性（Explainability）
• 低 token 成本（Scalability）

展望一下，或许未来所有高阶智能体都会内置 ReCAP 或类似的递归执行机制 hh~