革命性AI图像生成工具Fooocus：让创意触手可及的完整解决方案
2026/5/12 23:59:19
论文: Recursive Agent Optimization
来源: arXiv:2605.06639 [cs.LG] · 2026-05-07
作者: Apurva Gandhi, Satyaki Chakraborty, Xiangjun Wang, Aviral Kumar, Graham Neubig
一句话: 用 RL 训练 Agent 学会递归 spawn 自己的子实例——不靠增大模型，靠递归结构实现 inference-time scaling。
0. 为什么这篇论文重要
2026 年 AI 领域最热的赛道之一是inference-time scaling（推理时扩展）——不训练更大的模型，而是在推理阶段投入更多计算来提升效果。
目前的主流方案：
- Chain-of-Thought: 让模型"多想一步"→ 线性扩展，遇到长上下文就崩
- Tree-of-Thought: 让模型"多条路并行"→ 搜索空间指数爆炸
- Multi-Agent: 预定义多个角色协作→ 架构固定，不能自适应
RAO 提出了第四条路：让模型自己学会递归调用自己。
本质上是把计算机科学中最经典的 divide-and-conquer（分治法）变成了一个可学习的推理策略——模型不仅学会解题，还学会"什么时候该把题目拆成子题让自己的副本去做"。
1. 核心问题：为什么单体 Agent 不够用
当前 LLM Agent 的运作模式本质上是扁平执行——即便套上 AutoGPT、CrewAI 等脚手架，底层模型并未被训练去管理自身的子进程。
这导致两个致命缺陷：
| 缺陷 | 表现 | 后果 |
|---|---|---|
| 上下文崩溃 | 任务步骤增多后 prompt 被填满 | 模型"丢失思路"，后面的步骤开始胡说 |
| 泛化天花板 | 在 5 步任务上训练的模型 | 面对 50 步任务完全失败，因为缺乏分解策略 |
RAO 的范式转变：推理时的脚手架不应只是围绕模型设计的外部工具，模型本身应被训练去使用这些脚手架。
2. 方法论：一个模型，既是管理者又是执行者
2.1 整体架构
RAO 训练单一 LLM 策略（single policy）同时具备三种能力：
原始任务 │ ▼ [RAO Agent] ──判断──→ 能直接解？→ 直接输出答案 │ ├─ 不能直接解？→ 分解为子任务 │ │ │ ├─ async spawn(子Agent1, 子任务描述1) │ ├─ async spawn(子Agent2, 子任务描述2) │ └─ async spawn(子Agent3, 子任务描述3) │ │ │ ▼ （子Agent 是自己的新实例，可继续递归） │ [子Agent1] → 结果1 │ [子Agent2] → 结果2 │ [子Agent3] → 结果3 │ ▼ 聚合结果 → 最终答案关键设计：
- 一个模型两个角色：同一个模型权重既当"管理者"（分解+委派），又当"执行者"（直接解决）
- 动态执行树：不是预定义的固定层级，而是运行时根据任务复杂度自动展开
- 异步并行：独立子任务通过
async launch_subagent并发执行
2.2 训练：用 RL 教会三个核心能力
RAO 的 RL 训练让模型学会三件事：
| 能力 | 对应决策 | 训练信号 |
|---|---|---|
| 何时委托 | “这个任务我能直接做，还是该拆？” | Self-Success reward |
| 如何沟通 | “子任务描述写什么？要给哪些上下文？” | Delegation Bonus |
| 如何聚合 | “子结果回来后怎么合成最终答案？” | Root Reward |
2.3 奖励函数设计（核心创新）
RAO 不仅看最终结果（Root Reward），还引入了局部节点奖励：
Total Reward = Root_Success + λ × Σ(Node_Self_Success + Node_Delegation_Bonus)| 奖励维度 | 含义 |
|---|---|
| Self-Success | 这个子任务被正确解决了吗？ |
| Delegation Bonus | 我生成的子 Agent 完成任务了吗？ |
为什么需要局部奖励？如果只有 Root Reward，中间节点收到的信号太稀疏——一个深度为 5 的执行树，叶节点根本不知道自己做对了没。
2.4 深度级逆频率加权
执行树中叶节点远多于根节点（一棵二叉树深度 5 就有 32 个叶节点但只有 1 个根）。如果不加权，模型会被海量底层信号淹没，忽略宏观决策能力。
RAO 的解法：按深度层级做逆频率加权——根节点虽然只有 1 个，但权重跟 32 个叶节点一样大。
3. 实验：三个维度的突破
3.1 评测基准
| 基准 | 类型 | 挑战 |
|---|---|---|
| TextCraft-Synth | 合成制作树 | 多步骤层级依赖 |
| Oolong-Real | 长文档 DnD 日志 | 超长上下文（220K tokens） |
| DeepDive | 多跳网页研究 | 步骤间强依赖关系 |
3.2 突破一：打破上下文窗口限制
在 Oolong-Real 上：
- 训练时上下文窗口：32K tokens
- 测试时需处理：220K tokens（接近 7 倍）
- 单 Agent 系统：完全失败（看不到完整文档）
- RAO：成功处理——学会了将输入分块委托给子 Agent，创造出"无限工作记忆"
3.3 突破二：涌现的并行性
RAO Agent 自然学会了判断哪些子任务可以并行：
- Medium/Hard 难度任务上，RAO 的wall-clock time 显著低于单 Agent
- 这不是人为设计的，是 RL 训练自动涌现的行为
3.4 突破三：零样本难度泛化（最惊艳的结果）
| 训练难度 | 测试难度 | RAO 成功率 | 单 Agent 成功率 |
|---|---|---|---|
| Medium（深度 4-6） | Hard（深度 7-9） | 88% | 0% |
在训练时从未见过的高难度任务上，RAO 达到 88% 成功率，而单 Agent 直接归零。
为什么？递归结构天然具有自诱导课程学习效应——解子任务的过程就是在练习主问题的简化版本。子 Agent 解深度 3 的子树，父 Agent 解深度 6 的主树——但它们用的是同一个模型。
4. 局限性：Token 成本是代价
| 优势 | 代价 |
|---|---|
| Wall-clock 时间更短 | 总 Token 消耗显著增加（每个子 Agent 都要完整 prompt） |
| 独立子任务可并行 | 步骤依赖任务（B 依赖 A 的结果）无法并行，反而因 spawn 开销更慢 |
DeepDive 基准（强依赖链）上，RAO 反而比单 Agent 慢——因为子任务不能并行，但每次 spawn 都有通信开销。
工程启示：RAO 最适合可分解为独立子任务的场景（文档分析、数据处理、批量搜索），不适合强序列依赖的场景（多轮推理链）。
5. 工程意义：Inference-Time Scaling 的第四条路
| 扩展策略 | 怎么扩 | 适用场景 | 局限 |
|---|---|---|---|
| 增大模型 | 训练时堆参数 | 通用 | 贵、慢、边际收益递减 |
| CoT/ToT | 推理时多想 | 推理题 | 线性/指数开销 |
| Multi-Agent | 多角色协作 | 复杂项目 | 架构固定，不自适应 |
| RAO（递归） | 推理时递归分治 | 可分解任务 | Token 成本高 |
RAO 的核心贡献不是"递归"这个想法（任何程序员都能想到），而是证明了可以用 RL 训练 LLM 学会何时递归、如何递归——把人类的直觉变成了可学习的策略。
6. 总结
RAO 用一句话概括：与其训练一个更大的模型来解决更难的问题，不如训练模型学会把难问题拆成简单问题交给自己的副本。
它打开了 inference-time scaling 的新思路：不靠增大模型，靠递归结构。就像 MapReduce 之于分布式计算——核心不是单台机器更快，而是学会怎么拆任务和合结果。
原文: arXiv:2605.06639
作者: Apurva Gandhi (CMU) et al.
关键词: Recursive Agent, Reinforcement Learning, Inference-Time Scaling, Divide-and-Conquer, Multi-Agent
Agent 记忆三阶段进化论：从"存"到"悟"的系统性综述（ACL 2026）
论文: From Storage to Experience: A Survey on the Evolution of LLM Agent Memory Mechanisms
来源: arXiv:2605.06716 [cs.AI] · 录用于 ACL 2026 Findings
机构: 香港浸会大学 × 华南师大 × 港科大 × NUS × 北科大
一句话: Agent 记忆不是一个技术点，是一条从被动记录到主动进化的演化路径——Storage → Reflection → Experience。
0. 为什么这篇综述值得读
Agent 记忆论文今年井喷——MemGPT、Mem0、A-Mem、HippoRAG、Memory-T1、DeMem… 每篇都说自己创新，但它们之间是什么关系？处在记忆演化的哪个阶段？没人说清楚。
这篇 ACL 2026 综述做了一件事：给整个领域画了一张进化地图。它提出的三阶段框架（Storage → Reflection → Experience）不是简单分类，而是按照信息密度递增、认知抽象递升的逻辑排列的演化路径。
读完这篇，你会知道：
- 你正在用的记忆系统处于哪个阶段
- 下一步该往哪个方向升级
- 前沿在哪里（主动探索 + 跨轨迹抽象）
1. 三阶段框架全景
Stage 1: Storage Stage 2: Reflection Stage 3: Experience "忠实记录" "反思精炼" "经验抽象" τ → M_raw τ → F_ref(τ|φ) → m' T_batch → F_exp(T) → K 被动存储 单轨迹精炼 跨轨迹归纳 线性/向量/结构化 内省/环境/协作 显式/隐式/混合 代表：MemGPT, RAG 代表：Reflexion, CLIN 代表：FLEX, SkillRL关键区分：Reflection vs Experience
很多人把这两个混为一谈，论文给了精确的形式化区分：
| 维度 | Reflection | Experience |
|---|---|---|
| 函数签名 | F r e f ( τ i ∣ ϕ ) = m i ′ \mathcal{F}_{ref}(\tau_i \mid \phi) = m'_iFref(τi∣ϕ)=mi′（单轨迹→精炼记忆） | F e x p ( T b a t c h ) = K \mathcal{F}_{exp}(\mathcal{T}_{batch}) = \mathcal{K}Fexp(Tbatch)=K（多轨迹→通用知识） |
| 输出 | 精炼后的记忆单元，仍绑定原始任务上下文 | 通用规则/技能，脱离特定场景 |
| 检索依赖 | 推理时需要检索相似过去任务 | 作为策略先验直接适用，无需轨迹级匹配 |
| 类比 | 考试后对错题本做修改 | 从 100 次考试中总结出"遇到XX类型题直接用XX方法" |
2. Stage 1: Storage——“先记下来再说”
三种存储模式
| 模式 | 核心思想 | 优势 | 局限 | 代表 |
|---|---|---|---|---|
| 线性 | 按时序 FIFO 管理 token 流 | 简单，保持顺序 | 窗口有限，旧记忆被挤掉 | StreamingLLM |
| 向量 | 编码至高维空间 | 容量大，支持语义检索 | 检索质量依赖 embedding | Generative Agents, Mem0 |
| 结构化 | 关系数据库/层级/图 | 保留关系和结构 | 构建成本高 | ChatDB, MemGPT |
Storage 阶段的核心矛盾：有限上下文窗口 vs 不断扩展的交互历史。所有方法都在这个矛盾里做 tradeoff。
3. Stage 2: Reflection——“记下来不够，还要想”
三种反射模式
| 模式 | 机制 | 反馈来源 | 代表 |
|---|---|---|---|
| 内省 | LLM 自我批评，找出错误并修正 | 自身推理 | Reflexion, AgentFold |
| 环境 | 用外部环境信号（执行结果/人类反馈）锚定 | 外部世界 | SWE-agent, WebArena |
| 协作 | 多 Agent 互相审核，角色分工 | 同伴 Agent | Multi-Agent Debate |
Reflection 解决的核心问题：记忆不只是"存了什么"，还有"存的对不对"。
4. Stage 3: Experience——“从 100 次经历中提炼出普遍智慧”
这是论文最重视的阶段，也是当前研究前沿。
4.1 显式经验：人类可读的规则/技能
| 形式 | 特点 | 代表 |
|---|---|---|
| 自然语言策略 | “遇到XX类型问题，先做A再做B” | FLEX |
| 可执行技能 | 封装为函数/代码片段，可直接调用 | MemSkill |
| 可演化技能库 | 技能之间有依赖关系，可组合 | Voyager |
4.2 隐式经验：内化到模型参数
通过微调将经验"刻进"模型权重——不需要检索，模型"天然就会"。
代表：SkillRL 通过 RL 训练将高阶技能内化为决策直觉。
4.3 混合经验：显式缓存 + 周期性内化
最前沿的方向——用显式经验做高容量缓存，攒够了就微调一轮内化到参数里。
类比人类：白天学到的新知识先放在"工作记忆"里，晚上睡觉时大脑会把有价值的部分固化到长期记忆中。这正是"做梦"机制。
5. 两大前沿机制
5.1 主动探索（Active Exploration）
传统 Agent 是被动记录者——环境给什么就记什么。主动探索把 Agent 变成目标驱动的经验收集者。
| 探索维度 | 目标 | 效果 |
|---|---|---|
| 广度探索 | 好奇心驱动，探索陌生状态空间 | 扩大经验覆盖面 |
| 深度探索 | 在垂直领域提取高阶技能 | 从"会做"到"精通" |
| 策略探索 | 动态优化决策路径 | 增强长期规划能力 |
5.2 跨轨迹抽象（Cross-Trajectory Abstraction）
从多条独立的交互轨迹中，提炼出跨场景可复用的经验模式。
| 抽象机制 | 操作逻辑 | 代表 |
|---|---|---|
| 对比归纳 | 比较成功/失败轨迹的差异 | 精确划定策略边界 |
| 多粒度聚合 | 细粒度动作 → 高阶思维模式 | 层级化经验 |
| 代码封装 | 重复模式封装为可复用函数 | 组合性最强 |
| 参数内化 | 微调进模型权重 | 零检索开销 |
抽象粒度三层：
| 层级 | 形式 | 特点 |
|---|---|---|
| 浅层 | 自然语言规则 | 可读性好，但冗余 |
| 中层 | 模块化执行骨架 | 去冗余，保结构 |
| 深层 | 模型参数 | 最高效，但不可解释 |
6. 与 DeMem 的对话
有趣的是，DeMem（同周发布的论文）恰好在 Experience 阶段提供了一个精确的理论框架：
| 本综述（宏观视角） | DeMem（微观方案） |
|---|---|
| Experience 阶段需要"跨轨迹抽象" | DeMem 提供了信息论意义上的最优抽象——按"决策区分度"而非"描述相似度"组织记忆 |
| 需要解决"什么该记什么该忘" | DeMem 给出了精确的"遗忘边界"定理 |
| 需要理论保证 | DeMem 证明了近极小极大遗憾保证 |
这两篇论文是互补的——本综述画地图，DeMem 在某个具体坐标上打了一口深井。
7. 五大未来方向
| 方向 | 核心思想 | 当前缺口 |
|---|---|---|
| 主动记忆感知 | Agent 自主判断"我现在需不需要额外记忆" | 当前无差别检索，浪费且引入噪声 |
| 工作记忆组织 | 动态分配注意力的记忆间隔 | 缺少可塑性机制 |
| Experience 阶段基准 | 评估抽象和泛化能力的专用数据集 | 现有基准只测 Storage/Reflection |
| 分布式共享记忆 | 多 Agent 的共识记忆系统 | 个体 vs 集体记忆同步 |
| 多模态记忆 | 视觉+语言+其他模态的统一记忆 | 对具身智能至关重要 |
8. 工程落地指南
如果你正在构建 Agent 系统，这张表告诉你该看哪个阶段：
| 你的场景 | 建议阶段 | 推荐方案 |
|---|---|---|
| 简单 QA Bot，对话 <10 轮 | Storage | RAG + 向量存储够了 |
| 客服/工单，对话 10-50 轮 | Storage + Reflection | MemGPT + 环境反射 |
| 私人助理，长期陪伴 | Reflection + Experience | Reflexion + 显式经验库 |
| 任务型 Agent（代码/迁移/分析） | Experience（核心） | SkillRL / FLEX + 跨轨迹抽象 |
| 多 Agent 协作系统 | 全三阶段 | 分布式共享记忆 + 协作反射 |
9. 总结
这篇综述的核心观点用一句话概括：Agent 记忆的演化不是存储容量的扩展，而是信息密度的提升和认知抽象维度的跨越。
Storage: 我记住了你说的每一句话 Reflection: 我知道哪些话是对的、哪些需要修正 Experience: 我从 1000 段对话中总结出了"遇到这类情况就这么做"的通用策略三个阶段不是替代关系，而是递进关系——每个后一阶段都建立在前一阶段的基础上。
对 Agent 开发者最大的启示：别急着堆 Storage 容量，先问问你的 Agent 有没有 Reflection 能力；别急着做 Reflection，先问问你有没有 Experience 级别的经验沉淀机制。
原文: arXiv:2605.06716
GitHub: FeishuLuo/Evolving-LLM-Agent-Memory-Survey
录用: ACL 2026 Findings
关键词: Agent Memory, Storage, Reflection, Experience, Active Exploration, Cross-Trajectory Abstraction