AI智能体记不住"进展到哪儿"，一篇论文想教它学会记账

你有没有遇到过这样的情况：跟一个新同事交代一个复杂任务，比如"帮我把这批订单退货，同时给另一批订单换货"，结果聊了半天，对方拍着胸口说"没问题，我都处理好了",可你回头一查系统,数据库里什么都没变。

这不是段子，这是2026年一批研究者在测试AI智能体时反复撞见的真实场景。而且撞见的不是什么弱鸡模型，是当时最顶尖的Claude Opus 5和GPT-5.6这类frontier模型（也就是当前技术最前沿、能力最强的大模型）。它们能把话说得漂漂亮亮，跟用户达成一致,却常常忘了真正去执行那个改数据库的操作。

这篇来自新加坡国立大学、斯坦福、牛津和普林斯顿的研究团队的论文，就是冲着这个毛病来的。他们给这套方案起名叫Recuris,核心思路只有一句话：让AI智能体学会记两种账,一种记"现在事情办到哪儿了",一种记"以前是怎么办成的",然后让前一种账指挥后一种账怎么用。

这事儿难在哪儿

先说说这件事到底有多棘手。

现在主流的AI智能体想要变聪明，靠的是经验记忆（Experiential Memory,简称EM，也就是把过去做任务时积累的技能、流程存起来,供以后复用）。这个思路挺自然，人类不也是这样吗，做过的事情记下来，下次遇到类似的直接抄作业。

问题出在"抄作业"这一步。

现在的做法基本是两种：一种是在任务刚开始的时候，把可能用得上的技能一股脑塞进模型的上下文里，剩下的交给模型自己判断什么时候该用哪个；另一种是让模型去翻整个对话历史，从里面找线索决定要不要调用某个技能。

这两种做法在任务简单、对话短的时候都还凑合。可一旦任务变长,比如需要几十轮对话才能办完的退货、换货、机票改签这类事，麻烦就来了。

任务刚开始的指令,可能早就不能反映当前真正的问题了。用户一开始说"我要退货"，聊了十几轮之后可能变成了"退货加换货，还要申请补偿"，最初的指令早就过时了。而对话历史呢，越往后堆得越多，里面混杂着已经办完的步骤、过时的信息、还有各种执行?错误产生的噪音，模型想从这堆东西里精准挑出"现在到底需要哪个技能"，越来越像大海捞针。

研究者在论文里给出了一个很扎心的对比实验。他们让Doubao-2.0-Pro（一个中等规模的部署模型）去跑τ?-Retail这个零售客服任务基准，任务包括退货、换货这类操作,基线智能体（也就是没有任何改进的原版agent）的成功率只有58.1%。而且失败的原因往往不是不知道该做什么,是知道该做什么，但压根没去做。论文里统计发现，基线智能体有42%的任务，明明需要执行数据库写入操作，结果一次都没执行，光靠嘴上确认就以为完事了。

这就好比你去银行办转账，柜员跟你确认了三遍账户和金额,笑着说"好的，已经帮您处理了"，结果你回家一查余额，钱根本没转出去。柜员的嘴上流程走完了，手上的操作却压根没触发。如果银行系统不强制要求柜员点击"确认执行"按钮，只靠柜员口头承诺，那这种事故就会一直发生,而这恰恰是当前很多AI智能体的运行方式:嘴上答应了，手上却没动。

工作记忆：给AI装一个"任务进度表"

研究团队开出的第一张药方，叫工作记忆（Working Memory，简称WM，指持续追踪当前任务进展和未解决目标的一种状态表示）。

这个想法说起来朴素得很。既然问题是模型分不清"现在到底缺什么、办到哪儿了"，那就给它建一张明明白白的进度表,每个目标记录着它的内容、状态（待办、完成、或者卡住了）、支撑证据，还有卡住的原因。

关键的设计在这里：这张进度表不是模型自己随便写的,它只有在环境真的给出了证据之后才能更新。

论文里管这套机制叫"验证式状态更新"。具体来说，模型执行一个动作、拿到环境的反馈之后，系统里有专门的检查器（checker）会去核对，这个反馈到底支不支持"目标已完成"这个判断。支持，才把状态从"待办"改成"完成"，不支持，状态原地不动,甚至标记为"卡住"。模型自己嘴上说"搞定了"，不算数。

这个设计的必要性,可以拿一个很生活化的场景说清楚。想象你在管一个共享的项目清单，团队里有人负责勾选"已完成"。如果这个人只要嘴上说"我做完了"就能勾选，那清单很快就会失真,因为嘴上说做完和真的做完之间，永远存在一道缝。如果不设这道检查关卡，会发生什么？论文里的答案很直接：智能体会在没有真正执行退货、换货操作的情况下,就误以为任务已经完成，然后错误地告诉用户"已经处理好了"。这道检查关卡存在的意义，就是不让"说了"冒充"做了"。

论文里有个很典型的案例,τ?-Retail的第91号任务，用户要求退两块滑板、一块智能手表，再把一个电子书阅读器换成32GB版本。普通智能体走完了整段对话，双方都确认了要退货换货,可它一个退货工具都没调用，一个换货工具也没调用，两笔数据库更新全部悬空。而配备了Recuris架构的智能体（论文里管它叫Skiller）把"退货""换货"两个目标都记在工作记忆里，标记为"待办"，只有工具调用返回了确认收据，检查器才把状态改成"完成"。结果是,前者任务彻底失败，后者顺利成功。

经验记忆：光有知识库，不知道啥时候用

有了进度表还不够。研究者接着做了一组对照实验，想搞清楚经验记忆（EM）到底值不值钱。

他们设计了四种配置来对比：什么记忆都不加的基线智能体、只加经验记忆（技能库）不加工作记忆的版本、只加工作记忆不加经验记忆的版本，以及两者都加、还互相配合的完整版Recuris。

结果有点出乎意料。单独加经验记忆，在τ?-Retail上只带来2.0个百分点的提升,统计上跟没提升没什么区别。单独加工作记忆，直接带来23.9个百分点的提升。而两者结合起来是25.4个百分点。

也就是说，光有一个技能库,里面存着各种"该怎么处理退货""该怎么处理超额行李"的经验总结，如果没有工作记忆去告诉它"现在该翻哪一页"，这个技能库基本是摆设。

研究者还专门设计了一个更狠的对照实验，来验证这个判断。他们做了一个"模型自主判断调用"的版本:技能库跟Recuris用的完全一样，逐字逐句一模一样，但每一轮对话都把整个技能库塞进上下文，让模型自己决定什么时候用哪个。结果这个版本反而比Recuris低了18个百分点，甚至还比"完全不给技能、只给工作记忆"的版本更差，同时消耗的token还更多，每次成功要多花46%的成本。

这个结果说明什么？说明经验记忆是一种"看情况才值钱"的东西,论文里管这叫invocation-conditional（调用条件性），它值不值钱，不取决于里面装了什么内容，取决于有没有一个机制知道什么时候该把它掏出来。

这里可以用一个更贴切的类比来理解。你想象一个老中医的药柜，里面几百个药方,每个都写得清清楚楚该怎么配。现在有两种用法：第一种,病人一进门，把整柜药方全摆桌上，让病人自己翻,病人不是医生，翻来翻去也不知道该抓哪个;第二种，先诊脉，判断出病人现在到底是哪里出了问题，再精准地从柜子里抽出对应的那个药方。药柜里的内容一点没变，抓药的准确率却天差地别。如果没有"先诊脉"这一步，光把药柜摆在那儿，药方再全也没用,甚至因为选择太多反而添乱。这正是论文里"模型自主判断调用"版本表现更差的原因:选择项越多，判断负担越重，出错概率反而更高。

不同任务，命门不一样

再往下深挖一层，研究者发现一个更细腻的现象：维持这张进度表准确性的几个校验机制里，哪个机制最要命，居然跟具体任务领域有关。

工作记忆背后有四个校验机制在同时运作：写前审查（在一个会改变数据库状态的动作真正执行之前，先检查一遍）、事后核实（对"任务已完成"这类声明进行事后审计）、状态展示（决定进度表怎么呈现给模型看）、以及终止把关（决定什么时候允许结束一轮对话）。

研究者把这四个机制逐一拿掉,分别在τ?-Retail（零售客服）和τ?-Airline（航空客服）上重跑实验。结果出现了一个教科书级的"双重分离"现象：在航空客服任务里，去掉写前审查，成绩暴跌13.5个百分点，而去掉状态展示，成绩几乎没有变化;可换到零售客服任务里，情况整个反过来了,去掉状态展示，成绩暴跌17.3个百分点，去掉写前审查，几乎没有影响。

这个反差挺耐人寻味的。研究者给出的解释是:航空客服的任务往往卡在政策约束上，比如"基础经济舱票不能改签"，这类规则模型只有在真正要发起一个操作之前才需要被提醒，写前审查恰好卡在这个节点上,一旦拿掉，模型很容易撞上政策墙却不自知,直接把不该做的操作做了出去。零售客服则更常见的问题是：任务需要执行的写入操作，模型压根没意识到还没做，状态展示这时候的作用是持续把"还欠着哪些账"摆在眼前，一旦拿掉，模型很容易在漫长的对话里彻底遗忘掉某个还没完成的目标。

有意思的是，事后核实这个机制,不管在哪个领域都几乎没起作用，即便它在实验里真真切切拦下了172次不该被承认的完成声明。原因也很直白：数据库写入操作一旦真的执行了，环境状态已经被改变，事后再去审计已经无法撤销那个错误,能记录问题，但没法挽回损失。

这给整篇论文埋下了一个关键推论：如果连哪个校验机制该被重点强化都得看具体任务领域才能判断，那这件事就没法在设计阶段一次性想清楚、写死在代码里。任何固定的资源分配方案，注定会在某个领域上出问题。这也正是这篇论文接下来要解决的另一半问题：怎么让系统自己去发现,这次失败到底该怪哪个部件。

失败定位：先分清病灶再开药

这里要引入论文里第二个核心概念,技能记忆（Skill Memory，论文里用符号M表示，包含四个组成部分：存储可复用经验的经验记忆E、定义状态该怎么维护的工作记忆规范W、决定什么时候调用什么技能的调用策略ρ，以及负责核验完成情况的检查器集合C）。

传统做法里，一个任务失败了，系统能拿到的信号往往只有一个数字：成功还是失败。这个信号太粗糙了，就像医生看病只看体温计,发烧了，但发烧可能是感冒、可能是肺炎、可能是别的十几种病，光靠体温根本没法确定病灶在哪儿,更别提精准下药。传统的记忆更新方式往往是"重写整套记忆",一旦出问题，把整个知识库推倒重来，这种做法效率低，还容易把原本运作良好的部分也一并破坏掉。

Recuris走的是另一条路。它要求整个执行过程留下一份结构化的痕迹（论文里叫结构化轨迹，Γ），把每一步的工作状态、调用的技能、执行的动作、环境的反馈，全部一一对应地记录下来。这样一来，当任务失败时，有一个固定不变的元代理（Meta-Agent，一个专门负责诊断失败、生成修补建议的LLM智能体，本身在整个演化过程中始终保持不变）去读这份结构化轨迹，判断这次失败到底该归咎于哪个组件,是经验记忆里缺了一个技能，还是工作记忆漏掉了某个目标，还是调用策略没能及时触发正确的技能，还是检查器错判了一次完成状态。

诊断出病灶之后，接下来的修补只针对那个被诊断出问题的组件进行，其他部分原样保留，不动。

这一整套设计的效果，研究者用一个专门设计的实验去验证了。他们人为往某个组件里注入一个已知的错误，然后让一个固定的裁判模型，分别基于三种不同的证据去猜这个错误出在哪个组件：只看最终结果、看原始的对话轨迹、看结构化轨迹Γ。

结果差距相当明显。只看最终结果,准确率13.0%,甚至比"随机瞎猜"（三选一，理论下限33.3%）还低。看原始对话轨迹,勉强爬到37.0%。看结构化轨迹Γ,直接跳到64.8%,接近翻倍。

这里最值得琢磨的一个细节是：不同类型的错误，从Γ里获益的程度天差地别。调用策略的错误几乎是"隐形"的,因为该发生的调用没有发生，对话记录里根本看不出任何痕迹，只有结构化轨迹记录了机制事件才能捕捉到,不看Γ，这类错误的识别率是0%，看了Γ，跳到38.9%。而技能内容本身的错误反而获益最小，从61.1%到72.2%，因为错误的参数早就摆在对话文本里了，本身就相对好找。

这个规律其实揭示了一件更深的事情：结构化轨迹真正的价值，不在于让裁判"变得更聪明"，而在于让本来看不见的东西变得看得见。这就好比你想调查一辆车为什么半路熄火，如果只让你看后视镜里的画面（结果），你猜不出原因，如果给你一段行车记录仪的视频（对话轨迹），你能看到路况，但司机什么时候松了油门、什么时候没踩刹车，这些动作细节还是模糊的,只有仪表盘和踏板传感器的实时数据（结构化轨迹）叠加进来，你才能精确定位到底是刹车片磨损还是油路堵塞。如果不记录这些细节数据，很多故障就永远只能停留在"猜"的阶段。

修补之后：一道不轻易点头的验收关

发现了病灶、开出了药方，接下来还有最后一道关卡：验证门（Validation Gate）。

这道门的逻辑很朴素,也很谨慎。任何一个候选修补方案，都不会立刻直接生效，必须先拿去跟一批留出的开发集（development set，包含一批当前记忆已经能顺利解决的"锚点任务"）做对照测试。只有当这个修补方案既能修好它原本要解决的那次失败，又不会让开发集里那些原本就能做对的任务反而做错，才会被正式采纳,否则，记忆保持原样不变。

研究者在实验里专门记录了一次很有说服力的博弈过程。有一轮修补方案，在训练数据上把某类失败的修复率从0.214提升到0.393，看起来是个明显的进步,可是拿到开发集上一测，成绩的置信区间跨度超过了30个百分点，根本没法判断这个提升是真的还是噪音，于是这个方案被拒绝了。同一条演化线路后面又产生了一个新方案，把修复率提到0.571，同样因为开发集置信区间无法排除零效应，再次被拒绝。

但后来研究者把这两个被拒绝的方案，放到一个专门留出、从未被元代理接触过的86个任务上重新评测，结果第二个被拒绝的方案，居然稳稳地带来了11.92个百分点的提升，置信区间明确不包含零,是个真实存在的效果。

这段插曲说明了验证门的性质：它不是一个能百分百分辨"好方案"和"坏方案"的完美过滤器，在证据量有限的情况下，它做不到这一点。它是一道宁可错杀、绝不放过的保守闸门，只有证据足够扎实的方案才会被放行。代价是有些真正有效的方案会被暂时挡在门外，但换来的好处是被放进系统的东西都是经过反复检验、不会突然带来隐患的。这跟很多严谨的审批流程有点像,比如新药上市前的临床试验，宁可让一些可能有效的药物多等一等，也不能让效果不确定的药物匆匆流入市场。这道门存在的价值，恰恰体现在它"拒绝"的那些时刻上。

论文里还专门做了一次压力测试,验证如果完全撤掉这道验收门会怎样。他们跑了一轮"接受所有通过基本筛选的候选方案"的实验,不设开发集把关。结果三个候选方案里，开发集本该会否决的两个,最后在留出的最终测试集上反而带来了14.5到18.0个百分点的净提升，之前那两次"误判"其实都落在了正常波动范围之内。这说明验证门确实是偏保守的，宁可少收益，也绝不冒进。

这套演化机制反复迭代之后，到底能带来多大的实际提升?研究者给出了一系列跨模型、跨基准的对比数据，这也是整篇论文最核心的实证部分。

|模型|任务|裸智能体成功率|加装Recuris后成功率|提升幅度|

|Doubao-2.0-Pro|τ?-Retail|58.1%|**81.4%**|+23.3|

|GPT-5.6 Sol|τ?-Retail|58.3%|**76.1%**|+17.8|

|Claude Opus 5|τ?-Retail|72.4%|**87.9%**|+15.6|

|Qwen3.6-27B|SkillFlow|42.2%|**58.7%**|+16.6|

|Qwen3.6-35B|SkillFlow|35.3%|**48.8%**|+13.5|

|Granite-4.1-3B|τ?-Retail|9.7%|**23.0%**|+13.4|

|GPT-5.6 Sol|τ?-Airline|79.0%|**86.0%**|+7.0|

这张表格背后有个特别值得说清楚的细节：这些提升不是研究者拿每个模型分别量身定制出来的。整套技能记忆只在一个中等规模的部署模型（Doubao-2.0-Pro）上进化生成，之后原封不动地搬给其他所有模型使用，包括从没参与过这套记忆演化过程的Claude Opus 5和GPT-5.6。也就是说，Claude Opus 5能拿到87.9%的成绩，靠的是一份它自己压根没见过、完全是"别人练出来"的经验包。

这个"跨模型迁移"的结果，是整篇论文里最能打动人的地方之一。它说明这套记忆演化机制学到的东西，不是某个模型的专属小聪明，是任务本身的通用规律。可以想象一个老练的项目经理，把自己十年积累的项目管理流程和踩坑经验写成一本手册,这本手册不是为某个具体的新员工量身定做的，但只要新员工愿意照着做，效率提升是通用的。前提是这份手册记录的是流程和纪律，而不是某个人的特殊习惯。

论文里对这个差异有个特别精妙的观察:在τ?系列任务上迁移效果跟模型能力强弱没有明显关系（最小的3B模型Granite-4.1-3B都能拿到13.4个点的提升，而几个更大的模型反而没测出统计意义上的提升），但在SkillFlow任务上，迁移效果基本跟模型规模成正比，越大的模型获益越多。原因是这两类任务需要的东西不一样:τ?任务要的是"纪律"，什么时候该核实、什么目标还没关闭，这份纪律的价值取决于模型自己本来会犯多少错，模型的固有短板正好就是这份纪律能补上的地方;SkillFlow任务要的是"流程"（procedure），一份严格的执行步骤说明，只要模型有能力照着流程走，流程本身就是通用的,能力越强的模型执行流程越到位，获益自然越大。

任务越长，优势越大，而不是越小

一般人的直觉里，任务越长，越容易出岔子，各种记忆机制的优势可能也会随着任务变长而慢慢被噪音淹没,越往后越拉不开差距。

论文的数据推翻了这个直觉。研究者按任务需要的对话轮数把τ?-Retail的任务切成四个区间，最短的一档任务(19轮以内)，Recuris领先基线17.0个百分点，最长的一档(超过26轮），领先幅度反而扩大到44.7个百分点。

这个结果乍一听有点反直觉，细想又完全合理。真正拉长任务耗时的，往往不是"记不住该做什么"，是"记不住的东西攒得越来越多"。研究者做了个精细的拆解，专门去看模型有没有找到该找的信息（读操作召回率）和有没有真正执行该执行的操作（写操作召回率）。结果发现,不管任务长短，模型找信息的能力都很稳定，保持在88%到98%之间的高水位，完全没有随着任务变长而下降。真正随任务变长而崩掉的是执行力，也就是写操作召回率,基线智能体随着任务变长，写操作召回率明显往下掉，而Recuris始终稳稳保持在80%以上。

这个发现的意义在于，它精确定位了长任务失败的真正病灶：不是"忘了知识"，是"忘了行动"。这就好比一个人记账做得再细，脑子里清清楚楚记得这个月哪些账单该交，可如果每次到了缴费日就顺手把这件事往后拖一拖，欠账照样越滚越多。问题不在记账本身，在于"记住之后要真的去做"这个环节被漫长的日常事务淹没了。工作记忆的价值，恰恰体现在它不会随着时间流逝而模糊掉"还有什么欠账没还"这件事,它每一步都被环境反馈重新核实一遍，不给遗忘留缝隙。

论文里还有一个细节很有说服力：不管是哪种配置的智能体，第一次正确执行写操作的中位时间点都是第18轮，完全一样。这说明Recuris带来的差异不是让模型"更早想到该做什么"，是让模型在"想到之后"更不容易再把这件事漏掉。而错误还会互相传染,论文统计发现，一旦某个必须完成的写操作出错，后面再出错的概率超过60%,前面一步走错，后面容易一路走错。Recuris进入这种"错误滚雪球"状态的次数明显更少。

失败模式的全面收缩

论文摘要里那张失败模式对比图，把六种典型的长任务失败模式拉出来单独统计,幻觉式完成（下降86%）、遗漏写入（下降80%）、零写入回合（下降62%）、首次工具调用错误（下降44%）、错误级联（下降24%）、遗漏读取（下降20%）。

其中降幅最狠的两项,幻觉式完成和遗漏写入，恰好也是本文一直在讲的核心矛盾:模型嘴上说完成了，手上没真正执行。这两项加起来的降幅数字，几乎是整篇论文所有实验数据的一个浓缩版摘要。

单个任务内的自我修复：没有同类任务时怎么办

前面讲的整套演化机制，前提是同一个领域下有很多结构相似的任务，可以从一批任务的失败里总结出通用经验，再迁移到另一批任务上。但现实里总有一些任务是彻头彻尾孤立的，跟别的任务没有任何共享的工具或规则可言。

论文里用Terminal-Bench 2.1这个终端命令行任务基准来测试这种情况。研究者发现，在跨任务演化模式下，这个基准跑了13轮演化循环，一个修补方案都没能被采纳通过,原因很简单，任务之间压根没有可迁移的共性可言。

于是研究者设计了第二种运行模式,测试时自适应（Test-Time Adaptation）。逻辑跟前面几乎一样，只是把证据范围和修补范围都缩小到单个任务本身：一个任务失败了，元代理只能看到这个任务的说明、这次失败的完整轨迹，以及一个"失败了"的信号，绝对看不到正确答案或测试用例,然后针对这一个任务生成一条专属的技能补丁，供下一次重试时使用。

论文里给了一个很直观的例子。有个任务叫"mailman"，要求搭建一套集成邮件服务，第一次尝试失败了。元代理读完失败轨迹后，诊断出的问题是"配置修改不完整，没有验证",于是写下一条名叫"完整配置校验"的技能:每次修改配置文件后，先用grep确认所有必要设置都已经写入，再做完整测试。下一次重试，直接调用这条新写的技能，任务顺利通过。

不过论文在这里表现出了少见的严谨,它没有把这个漂亮的单点案例包装成普遍规律。研究者专门设计了一个"预算对齐"的对照实验，用来剥离"多试几次"本身带来的效果和"真正学到东西"带来的效果。结果发现，光是允许多试几次（不带任何学习），成绩就从34.5%的单次尝试跳到了58.6%,提升26.4个百分点。而在预算完全相同的前提下，加不加自适应学习，只带来2.3个百分点的额外提升，置信区间里包含零，统计上不算显著。

这个坦白挺难得的。很多论文在这种情况下会选择性地突出那个漂亮案例，淡化统计上不显著的整体结果。这篇论文选择把两个数字都摆出来，还专门用"每次尝试的成功率"（而不是"预算内解决了多少任务"）这个更细致的指标去做补充验证,结果发现在56个真正学到了新技能的任务上，平均每次尝试的成功率从17.4%提升到21.9%,方向是一致的，但样本量不够大，置信区间仍然包含零。研究者的结论是"报告一个方向，而不是一个确凿的效应"，这种克制在AI论文里并不多见。

跨实现方式的一致性检验

有一个问题必须被回答：整套机制学到的东西，到底是因为元代理这个"诊断医生"特别聪明，还是因为这套证据结构本身就足够好用，换个诊断医生也一样能学出类似的东西？

研究者做了一次挺硬核的验证。他们把整个诊断流程用完全不同的技术栈重新实现了一遍,原版基于Claude Code构建，新版基于DeepSeek Harness构建，两者代码完全独立，互不共享。

结果两套完全不同的实现，最终收敛到了几乎相同的效果,一个提升11.92个百分点，另外两次独立运行提升10.47和9.30个百分点，三次结果的置信区间高度重叠。更让人意外的是，两套系统各自学到的具体修补内容也高度一致:都学会了在工作记忆里加一个追踪"服务请求授权状态"的字段，都加了一道执行门的检查，都补充了一套防止过度升级的技能。

两个互不知情的"医生"，各自独立诊断同一批病例，最后开出了几乎一样的药方。这说明真正决定学习结果的，是那份结构化证据本身携带的信息量，不是负责读证据的那个模型有多聪明。

写在后面

读完这篇论文，最触动我的其实不是那些漂亮的百分点提升，是那个42%这个数字。42%的失败任务，不是因为AI不知道该做什么,是知道了，说了，却没做。这跟我们平时说的"知行不一"是同一件事，只不过发生在一个被寄予厚望的AI系统身上，格外刺眼。

这也让我意识到一件事：现在大家谈论AI能力的时候，很容易只盯着"模型本身聪不聪明"，但这篇论文用一整套实验说明,决定一个AI智能体能不能把活干成，很大程度上取决于它外面那层"脚手架",也就是论文里反复强调的agent harness（智能体外壳）。而且这层脚手架完全可以脱离模型本身单独进化，不用碰模型的一个参数，光靠改进记忆的组织方式，就能让Claude Opus 5这种顶级模型的表现再往上跳15.6个百分点。这个思路挺让人意外的,大家一直在拼模型规模、拼训练数据,而这篇论文提醒我们，光是让AI学会"记账"这件小事，收益可能比想象中大得多。

还有个细节让我一直在琢磨:论文里说，写好一份技能记忆，代价是昂贵的（要跑演化循环、要花元代理的算力），但用起来是免费的（写好之后可以无限次复用，还能跨模型迁移）。这跟人类社会的知识传承逻辑其实很像，一份操作手册、一本教科书，编写的过程很痛苦，但一旦写成，后来者拿来就用，不用再重新踩坑。AI记忆系统似乎也开始走上这条路了。

那个还没被彻底回答的问题是：如果任务领域之间根本没有共享结构，比如那种彻头彻尾孤立的终端命令行任务，这套跨任务学习的机制就彻底失效了,唯一能依靠的是单任务内的自适应，而这个效果目前统计上还站不住脚。这意味着这套方法目前最擅长的，是那些"内部有规律可循"的任务领域。而现实世界里，有多少工作真的是这样的？又有多少工作，看起来重复，实际上每一次都独一无二？

Q&A

Q1：Recuris是什么？

A：Recuris是一套让AI智能体记忆机制自我进化的架构，核心是让工作记忆追踪任务当前进展，并据此从经验记忆里精准调用合适的技能，同时用固定的元代理诊断失败原因并生成针对性修补方案。

Q2：Recuris为什么能让AI智能体在长任务里表现更好？

A：因为长任务失败的主因不是模型找不到该做什么，而是记不住还有哪些事没做完。Recuris的工作记忆机制持续追踪未完成的目标，并只在环境反馈真正支持的情况下才更新状态，避免了模型嘴上说完成、实际没执行的问题。

Q3：Recuris训练出的记忆能不能用到别的AI模型上？

A：可以。论文里这套记忆只在一个中等规模模型上演化生成，之后原封不动搬给Claude Opus 5、GPT-5.6等从未参与训练的模型使用，依然带来了15个百分点以上的成功率提升，说明学到的是任务通用规律而非模型专属技巧。