Recuris：递归进化记忆，让 Agent 越做越强

Agent 的经验记忆存了，但用不好。NUS、Stanford、Oxford、Princeton 四校联合提出的 Recuris，用精心设计的实验揭示了原因——技能内容不是瓶颈，调用时机才是——并在四个长序列基准上把 Claude Opus 5 从 72.4% 拉到 87.9%。

长序列任务中记忆为什么失效

Agent 在短任务里表现不错，一旦任务拉长到几十步交互，性能就断崖式下跌。不是模型变笨了，而是信息管理出了问题。

两个具体症状：一是「幻觉完成」——Agent 声称任务已完成，但数据库里根本没改，比如和用户达成一致后就直接报告「已处理」，实际上零次写入操作。二是「遗漏写入」——该执行的操作从头到尾没被执行过。在 τ²-Retail 上，基础 Agent 有 42% 的需要写入的 episode 完全没执行任何写入操作。

根源在于：当交互历史变长，模型面对的上下文充满噪音——已完成的步骤、过时的中间状态、无关的工具输出。在这种条件下，单纯把「好的经验」塞进 prompt 基本无效，因为模型不知道什么时候该用它。

经验记忆的价值不取决于它包含什么，而取决于有没有一个机制在正确的时刻把它调出来。

从「怎么用记忆」到「用证据管理记忆」

Recuris 认为现有 Agent harness 在记忆使用上有两个根本缺陷（Figure 2）。

Figure 2：Recuris 与现有方法的两个关键区别——从初始指令检索 vs. 从验证状态检索；从最终结果学习 vs. 从结构化执行痕迹定位修复。

第一，大多数 harness 在任务开始时从初始指令检索经验，但长任务中真正需要技能的时刻往往在十几步之后——那时候初始指令的上下文早就被中间步骤淹没了。Recuris 改为从动态维护的、经过验证的工作状态检索，让技能调用始终锚定在「当前还差什么」。

第二，大多数方法从任务最终的成功/失败信号学习，但这个信号只告诉你「坏了」，不告诉你「哪里坏了」。Recuris 记录每一步的结构化执行痕迹——状态、调用的技能、动作、环境反馈、提议的更新、检查器是否接受——把一次执行变成一份可诊断的病历。

Figure 3：Recuris 架构总览。(a) 任务内循环：工作记忆 w_t 跟踪每个目标的验证状态，调用策略 ρ 在执行事件触发时从经验记忆 E 检索匹配技能，检查器集 C 只在观察结果支持时才接受状态变更。(b) 跨任务循环：固定 Meta-Agent 从结构化痕迹定位失败组件，定向修补，验证门决定是否采纳。

EM–WM 耦合机制

Recuris 把经验记忆（EM）和工作记忆（WM）绑定成一个有验证闭环的系统。

工作记忆维护一个结构化的任务状态——每个子目标有明确的内容、状态（pending / done / blocked）、支持证据和阻塞原因。状态不靠模型「回忆」来维护，而是靠观察到的环境反馈来推进。

经验记忆存储可复用的技能包，每条技能包含触发条件和执行步骤。

耦合的核心逻辑：工作状态决定何时调用哪个技能，执行结果决定状态如何更新。Agent 想标记一个目标为「完成」？必须有工具返回的证据支持，否则检查器拒绝。这不是多了一层检查——这整个闭环把执行变成了「结构化证据」，让后续的失败定位成为可能。

消融：技能内容 vs. 调用时机

作者做了一个极其漂亮的消融实验（Table 2, Figure 5），直接回答了「经验记忆到底有没有用」这个问题。

Figure 5：EM–WM 耦合消融。单加 EM 仅 +2.0pp，单加 WM 就有 +23.9pp，完整耦合 +25.4pp。技能的内容不是瓶颈，调用的时机才是。

同样的技能库，模型控制调用（每轮全部注入让模型自己决定何时用）只有 +7.5pp，Recuris 的状态驱动调用 +25.4pp——高出 18 个百分点。技能完全相同，差异只在「谁决定何时调用」。

经验记忆是调用条件性的（invocation-conditional）：它的价值不取决于包含什么，而取决于有没有什么东西知道何时需要它。

递归进化：从执行痕迹到定向修复

跨任务层面，Recuris 的进化循环更精彩。

每次任务执行产生一条结构化轨迹 Γ，记录每一步的 (w_t, E_t, a_t, o_t, 提议更新, 检查器决策)。固定 Meta-Agent（Claude Code，全程不修改）分析失败轨迹，将问题定位到四个记忆组件之一：

定位后只修补被涉及的组件，其余原样复制。修补后通过验证门：修复源任务的同时不退步于 held-out 开发集才被接受，否则丢弃。

这个循环是递归的：修补改变了记忆 → 改变了后续执行行为 → 产生新证据 → 支持下一轮更精准的修补。但递归是有界的——基础模型、Meta-Agent、定位/修补/验证程序全部固定，只有 M_k = (E, W, ρ, C) 在进化。

Figure 9：递归进化的 held-out 增益一致性。(a) 不同进化轮次和随机种子下，held-out 增益高度一致。(b) 第二轮进化在第一轮基础上继续叠加增益。

关键实验结果

Figure 1：Recuris 在从 3B 开源模型到前沿模型上的全面增益。左：任务成功率；中：按交互长度的成功率（越长增益越大）；右：六种长序列失败模式的下降幅度。

在 τ²-Retail 上，Recuris 把 GPT-5.6 Sol 从 58.3% 拉到 76.1%（+17.8），Claude Opus 5 从 72.4% 拉到 87.9%（+15.6）。后者比不使用 Recuris 的任何模型都高出 9.7 个百分点。在 SkillFlow 上，Qwen3.6-27B 从 42.2% 提升到 58.7%（+16.6）。37 个模型-基准对中 35 个有提升。

Figure 4：长序列失败是执行问题，不是检索问题。左：任务成功率随交互轮次下降；右：必需写入的召回率下降，但读取召回率保持稳定。

最关键的趋势：优势随任务长度增长而扩大。在最短任务（≤15 轮）上增益 +12.5pp，到最长任务（>31 轮）达到 +32.2pp。Recuris 不是在简单任务上锦上添花，而是在最需要它的地方发力。

失败定位的精准度

Figure 7：状态驱动的调用恢复遗漏的写入操作。(a) 各配置在轮次 T 之前发出正确写入的比例；(b) 已有错误后后续写入不匹配的概率——Recuris 最少进入错误级联。

结构化轨迹带来的直接收益：从完整任务结果判断「哪里出了问题」，准确率只有 13.0%。从 Recuris 的结构化轨迹判断，准确率达到 64.8%——五倍提升。这是整个定向修补机制能够运转的前提。

Figure 6：不同领域最关键的 WM 机制不同。τ²-Airline 中「写入审查」去掉 -13.5pp（关键），τ²-Retail 中去掉仅 -0.7pp（无关）；反过来「状态面板」在 Retail 去掉 -17.3pp。双重分离。

更反直觉的发现：不同领域最关键的 WM 机制不一样。τ²-Airline 中「写入审查」最重要（-13.5pp），τ²-Retail 中「状态面板」最重要（-17.3pp）。这个双重分离说明，你不能在设计时预先决定优化哪个组件——需要像 Recuris 这样从执行痕迹中动态诊断。

作者还验证了：把 Meta-Agent 从 Claude Code 换成 DeepSeek Harness，最终效果和进化终点高度一致。增益不依赖特定 Meta-Agent，而是架构本身的有效性。

局限与评价

Recuris 的工程哲学非常干净：不动模型，只进化记忆控制层。每一次改进都是可解释的——你修补的是一个具体的技能、状态字段或触发条件。而且进化一次的记忆可以直接跨模型复用，在 doubao-2.0-pro 上进化出的记忆加载到 GPT-5.6 和 Opus 5 上同样有效，进化成本只需付一次。

和昨天的 Prime Agent 相比，核心关切一致——如何让 Agent 在长任务中保持有效。Prime Agent 走 REPL + 持久化执行的路线，Recuris 走结构化记忆 + 递归自修复的路线。一个偏向运行时灵活性，一个偏向离线积累的可靠性，两者互补。

局限方面：进化依赖固定的 Meta-Agent，验证门在单轮内统计功效有限，单任务适应模式（Terminal-Bench 2.1）的增益与纯重试差异不显著。但 37 对中 35 对提升的一致性、跨领域跨模型的迁移能力，以及「越长越强」的特性曲线，都很有说服力。

Recuris 证明了一件事：递归自改进不需要修改模型权重。在记忆控制层内部实现有界递归进化，足以让 Agent 把积累的经验持续转化为更有效的长序列行为。