模型不动、记忆进化：Recuris 用递归记忆演化把前沿模型推上长程任务 SOTA
你有没有遇到过这种情况：让智能体帮你处理一个稍微复杂点的客服请求——退两件货、再换个商品规格——它满口答应"好的，我来处理"，对话看起来一切顺利，结果一查后台，什么操作都没执行。
这不是段子。在 τ²-Bench 这类长程客服基准上，基线智能体在需要写操作的任务里，有 42% 的 episode 以"一次写都没执行"告终。模型越来越大了，GPT-5.6 Sol、Claude Opus 5 都上了，可这类"确认 ≠ 执行"的低级失败依然大面积存在。
这篇 Recuris 论文（arXiv:2608.24876）给了我一个挺意外的答案：问题不在模型，在于没有一个紧凑可靠的任务状态，让经验记忆和当前执行需求持续对齐。作者不动模型权重一根手指头，只在外层 harness 里加了一套递归演化的记忆系统，就把 Claude Opus 5 在 τ²-Retail 上从 72.4% 推到 87.9%，比所有不用 Recuris 的模型的最好成绩还高 9.7 个点。说实话，看到这个数的时候我愣了一下——一个外挂系统，增益比换一代模型还大。
核心摘要：长程任务里，交互历史越滚越长，智能体要么丢失未完成的子目标，要么调用与当前状态脱节的技能——递归自我改进（RSI）也因此卡壳，因为最终的成败信号根本说不清该修哪里。Recuris 的思路是：用 Working Memory 显式追踪每个子目标的状态（pending/done/blocked），让技能调用锚定在当前状态上而非整个历史；这个耦合又把执行过程变成结构化证据，一个固定的 Meta-Agent 据此把失败定位到具体的记忆组件，做局部补丁、过验证门再入库，形成有界的递归记忆演化循环。结果：4 个长程基准 × 10 个模型，37 个已完成组合里 35 个提升；GPT-5.6 Sol 在 τ²-Retail 涨 17.8 个点，Qwen3.6-27B 在 SkillFlow 涨 16.6 个点；任务越长优势越大，最长任务上拉到 32.2 个点，常见长程失败模式最高减少 80%。我的判断：这不是又一篇"加个 RAG 记忆"的工程堆料，而是把 RSI 的递归边界收束到记忆控制层的一次认真尝试，批判性实验做得比大多数同类工作扎实。
论文信息
- 标题：Recursive Experiential-Working Memory Evolution for Long-Horizon Agent Harnesses
- 作者：Zhaochen Yu、Yingcheng Wu、Zhenfei Yin、Kaiyuan Chen、Zhe Zhao、Mengdi Wang、Shuicheng Yan、Ling Yang
- 机构：NUS、Princeton、Stanford、Oxford 等
- 链接：https://arxiv.org/abs/2608.24876 （2026 年 8 月 25 日提交）
- 代码：https://github.com/Gen-Verse/Recuris
🎯 为什么长程任务上的"记忆"一直在帮倒忙
先想清楚一个问题：给智能体外挂经验记忆（存技能、存流程、存教训），为什么经常越帮越忙？
论文把现有记忆方案的病根拆成两条，我觉得拆得很准：
第一条，记忆的使用方式错了。 大多数方案是"从初始指令或完整历史里检索技能"。可任务跑到第 50 步，初始指令早就不反映当前该干什么了；而完整历史里混着过时信息、已完成的步骤、未解决的需求和执行噪声——上下文越长，检索越不可靠。结果就是模型拿着三个月前的"经验"处理现在的问题。
第二条，记忆的演化方式也错了。 自我改进类方法通常只拿最终成功/失败信号学习，然后重写整个记忆库。但一个二值信号根本回答不了：问题到底出在存的技能不对、任务状态没跟上、调用机制失灵，还是进度验证器放水？定位不了病灶，更新只能是粗放式的。
用论文原话讲，瓶颈不是缺少有用的经验，而是缺少一个紧凑可靠的任务状态，把经验和当前执行需求持续对齐。
动机总览图：上半部分是"之前怎么做、错在哪"——静态记忆使用导致丢失未解决目标、检索随上下文变长不可靠、技能调用错位；仅结果驱动的演化导致修复目标不清、更新粗放。下半部分是 Recuris 的两个转变——用 EM-WM 耦合做状态接地的记忆使用，用结构化轨迹驱动有界递归记忆演化，每次只给被定位的组件打局部补丁，过验证门才接受。
🏗️ Recuris：四块记忆、两个循环、一个不动的 Meta-Agent
一句话讲清核心 idea：把"任务状态"从对话历史里拽出来，显式维护成 Working Memory；技能什么时候上、上哪个，由状态决定；任务跑完留下的结构化证据，交给一个固定的 Meta-Agent 做归因和局部修补。
Skill Memory 是个四元组
演化到第 \(k\) 轮时，Skill Memory 定义为：
- \(\mathcal{E}_k\)，Experiential Memory：可复用技能库，agent-skill 格式
- \(\mathcal{W}_k\)，Working Memory 规范：状态 schema 和更新提议规则；任务级实例 \(w_t\) 追踪每个目标的内容、状态（pending / done / blocked）、支撑证据
- \(\rho_k\)，调用策略：决定在哪些执行事件触发检索、哪些技能条目进上下文
- \(\mathcal{C}_k\)，checker 集合：检验观测是否真的支持一次状态变更——checker 不过，目标不许从 pending 翻成 done
任务内循环：EM-WM 耦合
每个执行步骤是：
注意 \(w_t\) 和 \(\mathcal{E}_t\) 的位置——模型做决策时看到的是当前状态和由状态检索出来的技能子集 \(\mathcal{E}_t = \rho_k(x, w_t, e_t, \mathcal{E}_k)\)，而不是整个记忆库。
状态更新是三步走：先提议 \(\widetilde{w}_{t+1} = U_{\mathcal{W}_k}(w_t, a_t, o_t)\)，再检验 \(c_t = \mathcal{C}_k(w_t, \widetilde{w}_{t+1}, a_t, o_t)\)，最后按固定规则提交 \(w_{t+1} = K(w_t, \widetilde{w}_{t+1}, c_t)\)。有一条规则我很喜欢：调用技能、或者发起工具调用，都不构成完成证据——必须有回执类的观测支撑才算数。这就直接掐死了"嘴上说办了、实际没办"的那类失败。
技能投递有两种已实例化的方式，设计上挺务实的：
| 方式 | 触发时机 | 关键机制 | 用在哪 |
|---|---|---|---|
| Call-time invocation | 模型起草状态改变型工具调用时 | 起草的调用不执行，harness 返回合成的 not-executed 结果，技能在动作发出前送达 | τ² 两个域 |
| Boundary invocation | 轮次边界按状态谓词触发 | 如 first_turn 谓词，只在尝试开始时给一次技能 | Terminal-Bench 2.1 |
Call-time 那个"拦截草稿调用、先塞技能再放行"的设计，本质是把技能注入做成了事前审查而不是事后纠错。后面的消融会证明，这个选择极其关键。
跨任务循环：有界递归演化
这是全文真正的新意所在。连接两个循环的桥梁是结构化执行轨迹：
跟原始轨迹不同，\(\Gamma_k\) 把每个"动作-观测"对跟"触发技能调用的状态、提议的状态更新、接受/拒绝的证据"绑定在一起。Meta-Agent 拿到的不是一坨聊天记录，而是一份带归因线索的病历。
之后的流程是：
- 失败定位：\(D_k = \mathcal{A}_{\text{fixed}}(\Gamma_k, \mathcal{M}_k) = \{(f_j, z_j)\}\)，每个失败归因到 \(z_j \in \{\mathcal{E}, \mathcal{W}, \rho, \mathcal{C}\}\) 中的一个组件
- 局部打补丁：\(\mathcal{M}^+_k = \mathcal{M}_k \oplus_{Z_k} \{\Delta m_z\}\)——只改被归因的组件，其余原样复制
- 验证门准入：补丁既要修复目标失败，又要在留出开发集（含锚定任务）上无回归，否则 \(\mathcal{M}_{k+1} = \mathcal{M}_k\)
所谓"有界递归"，是说基础 LLM、Meta-Agent、定位/打补丁程序、验证门全部固定，递归只发生在外部化的记忆控制层内。Meta-Agent 本身（基于 Claude Code 构建）从不修改，也从不看测试集。这个收束我觉得是全文最值钱的工程判断——无界递归自我改进听着性感，但没法归因、没法验证、没法复现；把递归边界画清楚，每一轮的增益才能被干净地测量。
方法架构图：a) 以"把下周三的航班改到周五"为例，Working Memory 里 Goal1 改签为 Pending、Goal2 延误补偿为 Authorized，调用策略根据"当前步骤：Goal1 未解决"检索改签技能，fare_class_policy 技能匹配并拦截"basic-economy 票不可改签"的坑，checker 验证观测后才提交状态更新。b) 跨任务循环：录制诊断轨迹，红色步骤标记失败，Meta-Agent 把失败归因到 WM 或 EM 的具体条目，只做组件级补丁，held-out dev set 和历史轨迹双重检查通过才准入，否则保持原记忆。
🔬 一个案例看清两套循环
光讲机制有点干，论文给了两个案例，拼起来刚好一个任务内、一个跨任务。
任务内（τ²-Retail Task 91）：用户要退两块滑板和一块智能手表、把电子书阅读器换成 32GB 版本。传统智能体确认完后一个工具都没调——两个未解决的写操作在长历史里"不可见"了，任务失败。Recuris 这边，Working Memory 里挂着"return: pending、exchange: pending"，调用策略读 pending 目标依次触发退货技能和换货技能，每次 checker 校验回执匹配后才把目标翻成 DONE。
任务内推理案例：左边是"Confirmation ≠ execution"的典型死法——对话走到了确认，但两个写操作在长历史里丢失，终态两个 NO RECEIPT。右边 WM 让当前需求始终可见，\(\rho\) 只调用与当前 pending 目标相关的技能，checker 拿到验证下一次状态更新所需的证据。整个流程像一条装配线，状态是传送带。
跨任务（Task 18，沉默的同款换货）：用户说"换一把一样的椅子"，智能体调了 exchange(chair_A, chair_A)，工具返回成功，但数据库状态根本没变——工具级成功、任务级失败，\(y = 0\)。Meta-Agent 从结构化轨迹里把失败归因到 EM 的 workflow 缺口，生成了一个四步补丁：读原商品 product_id → 查可用变体 → 用返回的 variant item_id 作为新商品 → 确认后立即执行。补丁在修复集上从 0.25 提到 0.50、14 个 held-out 任务 +10.7 个点、通过验证门。然后这个补丁在新任务上原样迁移成功——基础 LLM、工具、Meta-Agent、验证门全程没动。
跨任务演化案例：左栏"工具级成功、任务级失败"的隐蔽错误；中栏 Meta-Agent 只修被诊断出的组件而非整个 agent，修复集 +10.7pp 且 up 3 / down 1 后 ACCEPT；右栏更新后的技能迁移到新任务，匹配回执后 exchange 变 DONE。注意红字标注：Else reject——不通过就保持原记忆，这是"有界"的具体含义。
📊 实验：35/37 提升，前沿模型被"外挂"推上 SOTA
实验设置的几个关键数字先摆出来：4 个基准（τ²-Retail 114 任务、τ²-Airline 50 任务、SkillFlow 166 任务 / 20 个任务家族、Terminal-Bench 2.1），10 个模型（从 Granite-4.1-3B 到 Claude Opus 5），temperature 0，每任务独立尝试 4 次取平均，每次尝试上限 200 步。有个设计挺反直觉：部署模型刻意选了中等规模的 doubao-seed-2-0-pro，演化循环在它上面跑完，记忆再原样迁移给前沿模型——这是在说"经验可以在便宜模型上攒，到贵模型上用"。
主表（avg@4 成功率 %，† 表示 bootstrap 95% CI 不含零）：
| 模型 | τ²-Retail | τ²-Airline | SkillFlow | Terminal-Bench 2.1 |
|---|---|---|---|---|
| Granite-4.1-3B | 9.7 → 23.0（+13.4†） | 34.3 → 39.8（+5.5） | 0.3 → 0.0 | 0.6 → 3.1（+2.5） |
| Qwen3.5-9B | 77.6 → 79.6（+2.0） | 75.5 → 78.4（+2.9） | 15.1 → 18.4（+3.4） | 17.4 → 20.5（+3.1） |
| GPT-OSS-20B | 50.6 → 60.8（+10.2†） | 54.8 → 59.3（+4.5†） | 7.8 → 10.4（+2.6†） | 3.9 → 6.7（+2.8） |
| Qwen3.6-27B | 62.8 → 71.2（+8.3†） | 79.0 → 80.0（+1.0） | 42.2 → 58.7（+16.6†） | 38.8 → 42.1（+3.3） |
| Qwen3.6-35B | 78.2 → 78.5（+0.3） | 80.3 → 81.5（+1.3） | 35.3 → 48.8（+13.5†） | 33.1 → 36.4（+3.3） |
| Gemini 3.7 Flash | 73.5 → 78.3（+4.8） | 86.5 → 85.0（−1.5） | N.A. | 79.8 → 82.4（+2.6） |
| GPT-5.6 Sol | 58.3 → 76.1（+17.8†） | 79.0 → 86.0（+7.0†） | N.A. | 83.2 → 86.4（+3.2） |
| Claude Opus 5 | 72.4 → 87.9（+15.6†） | 89.5 → 90.5（+1.0） | N.A. | 84.6 → 88.4（+3.8） |
| Doubao-2.0-Pro（部署） | 58.1 → 81.4（+23.3†） | 75.5 → 80.5（+5.0） | 34.6 → 51.4（+16.8†） | 46.1 → 48.9（+2.9） |
几个我读出来的点：
提升最大的地方是共享结构最强的两个基准（τ²-Retail 和 SkillFlow）。这符合方法逻辑——经验要能跨任务复用，任务之间得真有可复用的结构。反过来，Terminal-Bench 2.1 没有共享结构，跨任务演化循环 13 次运行一个补丁都没准入，有效的只剩任务内重试。作者没藏着这个负面结果，加分。
增益不是来自塞更多上下文。 把全技能库常驻 prompt 的方案，比 Recuris 多 3111 个 token，分数反而低 18 个点，每次成功成本高 46%。这直接反驳了"上下文给足就行"的朴素想法。
Opus 5 的 87.9% 是个信号：它比评估中任何裸模型的最好成绩高 9.7 个点——前沿模型在长程任务上远没饱和，缺的可能真不是能力，是 harness。
🔍 消融：钱到底花在哪个组件上
这篇的消融做得相当狠，我觉得比主结果更有信息量。
EM-WM 耦合拆解（τ²-Retail，456 episodes）：
| 变体 | 成功率 | Δ [95% CI] |
|---|---|---|
| Base | 58.1 | — |
| EM only | 60.1 | +2.0 [−4.0, +7.9] |
| WM only | 82.0 | +23.9† [+17.5, +30.3] |
| 模型自行决定调用 | 65.6 | +7.5† [+1.5, +13.4] |
| EM + WM（Recuris） | 83.6 | +25.4† [+18.4, +32.5] |
两个扎心结论。其一，主要增益来自工作状态本身（WM only +23.9，EM only 只有 +2.0 且 CI 含零）——大部分"记忆增强"工作的增益可能被高估了，真正干活的是状态追踪。其二，经验记忆的价值是"调用条件依赖"的：同样一个技能库，交给模型自己决定什么时候用，只有 65.6；由状态驱动调用，83.6。差了 18 个点，CI [+11.6, +24.6]。技能库再好，喂的时机不对就是负资产。
机制级双重分离更有意思。作者拆了四个机制：write review（执行前审查写操作）、truth guard（事后审计完成声明）、status board（状态呈现）、gate termination（终止控制）。结果：
- τ²-Airline 移除 write review 掉 13.5 个点，status board 无影响；τ²-Retail 恰好反过来，移除 status board 掉 17.3 个点，write review 几乎无感
- truth guard 是唯一的事后机制，也是唯一从不重要的机制——尽管它拒绝了 172 个无支撑的完成声明。原因很直白：写操作已经执行了，事后审计只能记录，无法撤销
等等，这个发现其实挺反直觉的——很多工作在做"事后验证器"，而这篇用数据说：事后机制救不了已经发生的错误，钱要花在事前审查上。而且关键机制因域而异，设计时根本预先分配不了——这反过来论证了跨任务演化的必要性：让演化自己去发现哪个机制在哪个域重要。
失败定位的受控实验（注入已知故障，54 个判决）：用结构化轨迹 Γ 时 macro 定位准确率 64.8%，用原始轨迹只有 37.0%，只用结果信号 13.0%（常数基线 33.3%）。调用策略类故障（\(\rho\)）在没有 Γ 的条件下一次都没被识别出来——"该调没调"是个非事件，没有状态-技能绑定记录根本无从察觉。这个实验直接证明了结构化轨迹不是装饰，是归因的前提。
递归演化的收益与边界（86 个 held-out 任务）：Run A（Claude Code）两轮后从 54.07 到 65.99（+11.92†）；Run C（progressive）第二轮复合增加到 71.51（+17.44†）。但 Run B 第四轮掉到 57.85，原因不是收益递减，而是 reach 0/86——记忆从没被调用，"绑定失效"。还有一个我喜欢的细节：字节相同包重跑对 dev 锚任务的破坏率是 25.9%，而门控接受的更新只破坏 9.5%——验证门拦下的是噪声，不是增益（被拒的 18 个候选里 17 个的 dev 区间落在自身噪声带内）。
Meta-Agent 可替换吗？ Claude Code +11.92，DeepSeek Harness +10.47，差值 −1.45 且 CI [−7.85, +4.65] 落在仪器自身噪声带里。更妙的是，两个不共享代码的 Meta-Agent 把同样的 16 个失败蒸馏到了同一组件族——归因结果收敛，说明信号在轨迹里，不在 Meta-Agent 的个体能力里。
📈 任务越长，优势越大：+32.2 背后的真相
摘要里"最长任务 +32.2 个点、常见失败最高降 80%"这两个数，我特意去正文翻了出处。
按任务内在完成长度分四分位后，Recuris 在全部四个四分位领先基线 17.0 到 44.7 个点，优势不随长度衰减。为什么？作者拆得挺漂亮：read-action recall 在所有变体、所有四分位都保持 88.0–97.9%——长度根本没破坏"查信息"的能力。差距全在写路径：Recuris 的 required-write recall 比基线高 26.7 个点；基线 42% 的写任务 episode 一次写都没执行，Recuris 只有 16%。
还有一个细节：首次正确写的中位轮次（第 18 轮）在所有变体中完全相同。也就是说 Recuris 改变的不是"何时行动"，而是行动与否这件事。再配上另一个观察——一旦某个 required write 失配，后续写失配概率超过 60%，错误在 episode 内复合——就能理解为什么优势随长度滚雪球了：长任务里错误的复合机会更多，而 Recuris 从源头上更少进入失配状态。
至于"失败降 80%"，要泼点冷水：这是六类长程失败模式按"agent alone = 100"重标定后的相对削减上限，不是任务成功率的绝对提升。宣传时容易被误读，正文其实写得很克制。
🤔 我的判断
亮点：这篇最值钱的地方，在我看来不是某个具体数字，而是把 RSI 从一个口号落成了一个可测量、可归因、可拒绝的工程系统。递归被刻意关在记忆控制层里，每一轮演化有明确的准入/拒收记录，消融甚至做了"字节相同包重跑"来估计仪器噪声——这种自我怀疑的实验态度在 agent 论文里不多见。WM 才是主要增益来源、事后验证无效、关键机制因域而异，这三个发现单拎出来都有独立价值。
问题也得说。其一，整套系统对 checker 质量的依赖很重，而 checker 本身还是 LLM——论文自己也承认在 τ²-Retail 上移除 checkers 影响为零，说明这个组件在某些域其实是摆设，那它的失效模式在更难环境里没有真值可考。其二，验证门需要一个有代表性的 dev 集和可靠的程序化验证器，τ² 和 SkillFlow 都自带验证脚本，可现实里大多数长程任务没有现成的 oracle——方法的可迁移性在这一点上存疑，Terminal-Bench 上零补丁准入既是诚实也是警示。其三，每任务 k=4 次尝试、200 步上限的评测协议下，Recuris 的 token 成本虽然低于全技能库方案，但相比裸模型仍有额外开销，论文对绝对成本的报告可以更完整。其四，跟同期记忆类工作（如各类经验库 + reflection 方案）的横向对比偏弱，作者选择了跟自己的消融变体比而不是跟外部 SOTA harness 比，这样结论更干净，但读者很难判断 Recuris 在整个赛道里的相对位置。
工程启发：如果你在做 agent 产品，有两条可以直接抄——把"任务状态"从对话历史里显式抽出来维护，别让模型在一堆聊天记录里自己找待办；技能注入做事前拦截，别指望事后审计。这两条都不需要递归演化，成本极低，收益可能是大头。
收尾
Recuris 让我看到一个越来越清晰的趋势：当基础模型的能力溢价变缓，harness 层的系统工程——状态管理、经验组织、演化机制——正在成为拉开差距的主战场。模型还是那个模型，换一套记忆的组织方式，87.9% 和 72.4% 之间隔着一整个"代际"。
不过还有个更本质的问题悬着：当记忆演化了很多轮之后，它会不会过拟合到特定基准的验证器口味上？验证门能拦住噪声，拦得住"应试"吗？这得等更长线的部署数据来回答了。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我