把递归自我改进的基本演化单位从任务换成能力，这是深圳无尽递归智能科技有限公司提出的一套新思路。按这一思路，RSI 有望摆脱只针对单个任务的局部优化，转向跨任务、跨模态的持续演化。

这家来自深圳的公司给出的方案叫 The Trinity，一个全模态全任务的递归自我改进框架。框架以能力为基本演化单位，靠 Creator、Explorer 和 Evolver 三个角色分工协作，让环境生成和 Harness 一起进化。

具体怎么走？框架先把任务归入 Task Tree，再依据测试轨迹判断每个任务需要哪些能力，据此把 Task Tree 转成 Capability Tree，最后沿 Capability Tree 演化出 Harness Tree。

跑完四轮 RSI 后，The Trinity 在 28 个训练基准上的平均得分提高了 34.1 分，在 18 个未见基准上提高了 26.2 分。它向真实机器人任务迁移的潜力也已初步显现。

对 Agent 来说，这条路子意味着从任务驱动的局部优化，转向能力驱动的跨任务、跨模态持续演化，多了一种可以尝试的探索方向。

实验结果

1. 多模态任务：四轮 RSI，未见任务也在持续提升

在 ARC-AGI-3、buildarena、video mme v2、phyre、SOON、CaP-X 等 28 个跨模态、跨领域训练 Benchmark 上，平均提升 34 分；18 个 Unseen Benchmark 上则平均涨了 26 分。提升最大的是第一轮，但后面三轮仍有进账，未见过的任务成绩也随迭代往上走。

当然，不是每个 benchmark 都一路上涨。有些任务很早就不再进步，个别还小幅回退。整体看，系统能在固定的能力树上多轮积累改进，并把成果迁移到训练之外的任务上。

2. Embodied Transfer：在模拟环境里学到的东西，能否用到真实机器人上？

最后，演化后的 Harness 被用到了两个真实具身任务里。SOON 中，Unitree G1 要在办公室找到风扇旁的目标桌子，并走到能触及的位置；CaP-X 中，AlohaMini2 要检查倒扣的杯子，判断里面有没有方块，再报告方块的颜色与位置。

这两个任务都要求智能体在行动中不断获取环境信息，等证据足够了再作决定。我们用的是能力树对应节点上演化出的 Harness，先通过重建的模拟环境准备任务 Skill，之后在真实机器人上评估。

结果是，SOON 的真实任务成功率从 0% 提升到 60%，CaP-X 同样从 0% 提升到 60%。

一、多模态智能体递归自我改进的瓶颈与挑战

给智能体一个任务，让它执行、拿反馈、调整策略，再重新执行——这是当前不少 Recursive Self-Improvement（RSI）工作的基本思路。围绕几个 benchmark 搭起这样的反馈循环，分析失败轨迹，持续优化提示词、工具和执行流程，性能确实能提上去。

可一旦把这套做法搬到多模态的长程交互任务上，原本还算简单的反馈循环就开始遇到新麻烦。

首先是环境怎么规模化搭建。ARC-AGI-3、交互游戏、GUI 操作、机器人导航与操作，各类任务在观察形式、状态空间、动作规则和成功条件上都不一样。想让智能体持续接触到更多样的任务，就得不断搭建并验证新的交互环境，而靠人工一件件去做，成本显然没法随任务数量一起扩展。Harness 的迭代也卡在类似的地方：智能体表现好不好，不只取决于模型本身，还越来越受提示词、工具配置和执行流程的影响；任务越复杂多样，人工设计和优化 Harness 的速度就越难跟上需求变化。

顺着这个思路自然会想到：既然人工搭环境和优化 Harness 都有瓶颈，能不能把这两件事也交给智能体自己完成？我们提出的环境与智能体协同进化方案，确实能缓解规模化的问题，但也引出了更深一层的疑问。

假设一个系统已经能自动生成一百个任务，并为每个任务演化出更好的 Harness，最后它可能拿到一百套经过优化的解决方案。可这一百次改进，到底是在共同推动系统进步，还是只完成了一百次彼此独立的局部优化？这里有兩個相互关联的问题。一是经验怎么组织：经验若始终围绕单个任务积累，优化结果就容易困在特定环境里，难以迁移到其他任务；可要是把所有经验都塞进同一个 Harness，不同任务的需求又可能互相干扰，反而压住性能。

二是改进怎么演化。即便每一轮都能产出更好的策略，系统仍需要一种机制，让已有改进被保留下来，在后续任务中被继承和复用，并随不同能力需求逐渐调整、分化，而不是每次都从头优化。说到底，任务数量增长，不等于改进能持续积累；局部性能提升，也不必然带来跨任务的能力增长。

真正该想的是：能不能找到一种超越具体任务的组织方式，让不同任务里获得的经验彼此关联，使一次改进成为后续改进的基础，并在持续迭代中不断演化？

这也是我们重新思考 RSI 驱动力的起点。

二、两套机制：协同进化与共享能力

多模态智能的演进，我们更倾向于看作人类引导下 Agent 与 World 的协同进化过程。

在这个过程里，World 负责给出任务和反馈，Agent 则靠交互摸索怎么把问题解决掉。以往这一圈大多靠人来转：任务由人挑，环境由人搭，智能体也要人照着失败轨迹去改。

想让这个循环一直转下去，起码得有两个机制。

机制 1：Agent–Environment Co-evolution，环境与智能体互相推着走

智能体与环境协同进化，就是让环境盯着智能体的表现来生成、调整训练挑战，智能体再拿环境反馈不断优化 Harness。两边彼此驱动，人工搭环境、反复迭代 Harness 的负担随之减少，规模化的递归改进也就有了可能。

机制 2：Shared Capability Requirements，不同任务可能要求同一批底层能力

任务在模态、形式、目标上可以差得很远，背后依赖的底层能力却未必不同。ARC-AGI-3 和 Micromouse 就是例子：任务形式不一样，但都离不开准确的感知与状态追踪。

换句话说，一个任务可能要用上多种能力，同一种能力也可能同时服务好几个任务。围绕这些共同需求去组织经验，原先散落在各任务里的反馈，就有机会变成可共享、可迁移的学习信号。

一旦能从不同任务中识别出共同的能力需求，每个任务就不必再被当作完全独立的学习目标。经验可以按这些共性攒起来，再依照具体任务的需要做组合与特化。

这正是 Capability-driven RSI 的核心出发点。

三、The Trinity：从 Task-driven 到 Capability-driven RSI

在前述观察的基础上，我们推出 The Trinity，把环境生成和 Harness 演化纳入同一套 RSI 框架。系统里一个模型承担三个角色：Creator 负责搭建世界，Explorer 负责探索世界，Evolver 负责分析反馈、指导另外两者的改进。三个角色共用固定的基础模型，改进主要落在 Harness 层面。

不过，最关键的变化不在于把三个角色拼在一起，而在于把系统的学习单位由 Task 换成 Capability。

1. Task Tree → Capability Tree：重新组织经验

第一步，我们收集多种类型的多模态任务，搭出 Task Tree，让初始 Harness 在这些任务上跑一遍，拿到可验证的交互轨迹。Evolver 结合任务定义和实际执行轨迹，判断任务需要哪些能力、失败又出在哪些决策环节。

接下来，这些经验不再按原来的任务类别归类，而是依照共享的能力需求，重新搭成一棵 Capability Tree。同一项能力可以被不同任务共用，一个任务也可能同时依赖多项能力。于是，树上的路径表示的是能力需求的组合，而非任务类别之间的从属关系。

这一步的价值在于：过去散落在不同 benchmark 里的经验，如今有了统一的组织依据。

2. Capability-Driven Real2Sim2Real：围绕能力生成训练环境

有了 Capability Tree，环境该怎么生成？

过去做 Real2Sim2Real，通常得为某个具体的真实任务单独搭一套模拟环境。The Trinity 的思路不同：目标不是把任务复刻一遍，而是学到任务背后共通的能力，这样环境设计就多了一条路。

落到 Capability Tree 的某个节点上，Creator 会先找出这批相关任务共同依赖的决策机制，据此生成一个更精简、也更容易验证的模拟世界。举个例子，若几个任务都要求在动手前先确认证据够不够，训练环境就可以只围绕这个决策过程来搭，没必要把原任务里的视觉细节、场景结构、动作规则整套照搬。

Explorer 就在这类模拟环境里学习，原始 benchmark 则拿来检验学到的能力能不能迁回去。关键并不在于把模拟环境做得越复杂越好，而是要尽量保住那个需要学习的决策机制，把无关的复杂因素压下去，让进化信号更干净。

3. Harness Tree：让已有改进成为下一轮改进的起点

Harness 能拆成 Perception、Memory、Inference、Planning、Orchestration 和 Loop 等协议模块。能力方向不一样，需要配合的模块也不一样。

在 The Trinity 里，Explorer 顺着 Capability Tree 一个节点一个节点地演化 Harness。每个节点既可以有选择地继承父节点已经学到的模块，也能依据本节点的失败轨迹去改动或新增模块。这么一来，任务需要更多能力时，系统不用从零再搭一套 Harness，在现有配置上接着改就行。

各条分支也没必要硬凑成一个全局最优解。它们可以共用已有的模块，同时各自保留针对特定能力需求所做的修改。

迭代若干轮之后，这些模块慢慢长成一棵 Harness Tree。Creator 同样会根据环境验证的失败情况不断改自己的 Harness，每轮收尾时把已验证的模块更新整合进来，供下一轮环境构建使用。

4. Capability-Aware Router：任务不同，Harness 也要换

Harness Tree 铺开之后，一个绕不开的问题随之出现：各个分支已经演化出不同的专业化配置，来了新任务，该挑哪一个？

为此，研究团队加入了 Capability-Aware Harness Router。它会参考任务的公开信息、候选 Harness 的能力描述，还有以往经过验证的执行经验，挑出更匹配当前任务的 Harness。整个过程既不需要预先拿到任务的真实能力标签，也不用把所有模块硬塞进同一个 Harness。

至此，整套方法的链条才算接上：任务给出能力需求，Creator 据此生成训练环境，Explorer 依靠反馈演化模块，Harness Tree 把已有改进留存下来，Router 再把合适的配置搬到新任务上。

四、实验分析

1. Task vs. Capability：组织方式是否真的影响最终学到什么

团队对比了几种不同的经验组织方式，也考察了 Capability-Driven Real2Sim2Real 能带来多少收益。

Sim 首轮构建的成本确实更高，但环境在后续迭代中可以反复使用，推理成本反而更低。按能力组织经验、针对共同能力生成训练环境，跨任务迁移的效果好于单纯围绕任务做优化——用更少的投入换来了更多，less is more 在这里得到了验证。

2. Agent as a Router：专业化之后，Harness 还选得对吗？

Harness Tree 的好处是各分支能各自优化，可一旦用的时候挑错了配置，专业化就白搭了。正因如此，团队又比对了多种 Harness 选择方式。这也是他们不想最后只落得一个越堆越大的统一 Harness 的原因：任务不同，依赖的模块组合可以不同，而怎么选，本身也能变成智能体要学的东西。

3. Capability–Module Relationships：能力划分真的能指导模块设计吗？

团队先看了第四轮 RSI 之后 29 个 Module 与六类 Capability 之间的关系，结果显示，能力不同，对应的模块偏好确实不同。也就是说，Capability 不只可以用来组织任务，还能为 Harness 挑模块、配组合提供依据。

4. 自定义 Capability Tree：从固定拓扑走向结构探索

前面这些实验已经验证了 Capability-driven RSI 有效，但有个问题还值得往下挖：Capability Tree 自己该怎么建？

眼下 The Trinity 是按训练任务的能力需求来搭 Capability Tree，并在固定拓扑下做 Harness 演化。这么设计，能力共享、选择性继承和局部优化各带来多少收益，看得比较清楚。局限也摆在那里：树的结构一旦定下来，后续学习过程中不会再动态调整。换一种能力划分、换一组节点组合、换一套继承关系，最终改进效果会不会变，仍待研究。

于是团队又开源了一个支持自定义 Capability Tree 的探索性实验。研究者可以自己定义能力节点，调整树的层级和分支结构，还能给不同节点配上对应的仿真训练环境，从而在不同能力组织方式下跑 RSI 实验。

这样一来，一些有意思的问题就能接着追：哪些能力适合共享，哪些该独立演化？树结构不同，Harness 的继承与特化会受到什么影响？任务类型越扩越多时，能力树该保持稳定，还是让节点不断分化、合并、重组？

这些问题现在都还没有确定答案。不过自定义实验至少给了探索它们一个起点。

当前这版 The Trinity 已经证明，沿着能力树做递归改进是走得通的。那接下来该往哪走？一个方向是：让能力树自己也变成可以优化、可以演化的对象。

也就是说，从在固定的能力结构上持续改进，转而让能力结构与 Harness 一起演化。这或许会成为 Capability-driven RSI 继续往前推的一条路。

结语：什么在驱动进化，进化又在塑造什么？

回到开头那个问题。RSI 如果一直围着一个个独立任务转，系统就容易困在各自的局部目标里。任务数量加上去，可能攒下更多解法，可这些经验未必能彼此关联，更未必会自动沉淀成可复用的能力。扩大演化范围、优化版本选择与种子任务集，或者让决策 Agent 自己也参与演化——这些做法都在试着提高 RSI 搜索和更新的效率。

但就算系统改进能力够强，也能把历史经验全部记下来、留下来，还有个更根本的疑问摆在那儿：哪些经验该共享？哪些改进得单独保留？不同任务的演化之间又该怎么连起来？

Capability-driven RSI 想换个角度回应这些问题：优化的单位不再只是任务本身，任务背后那些共同的能力需求，成了推动改进的依据。

按这个思路，The Trinity 把环境构建、经验积累和 Harness 演化都放在同一套能力结构下面来组织。一头是用共享的能力需求把不同任务串起来，让经验能跨任务复用；另一头是让 Harness 分支化演化，保住不同能力各自的优化方向，已有的改进因此能被继承、调整和组合。

这样组织的好处是，任务级优化带来的过拟合与 reward hacking 风险有机会得到缓解；同时，局部的性能提升也可能慢慢变成泛化性更强的能力积累。

论文及作者信息

作者介绍：

项目由西安电子科技大学本科生汤维栋牵头，他的研究方向是多模态大模型、递归自我进化与具身智能。同济大学本科生王瑞恒、新加坡国立大学硕士生张景轩、InfRec 首席执行官王和新同为论文主要贡献者。通讯作者则有三位：新加坡国立大学博士生周鹏飞、香港中文大学博士生张昊天，以及新加坡国立大学校长青年教授尤洋。

• 论文题目为 The Trinity: Capability-Driven Recursive Self-Improvement for Multimodal Agents。

• 代码链接：https://github.com/InfRec-Cardinal/The-Trinity

• 论文链接：https://arxiv.org/abs/2610.36077

• 项目主页：https://trinity-rsi.github.io/

• 该论文登上 Hugging Face Daily Paper 第 1 名，链接：https://huggingface.co/papers/2610.36077

• 作者名单：Weidong Tang, Ruiheng Wang, Jingxuan Zhang, Hexin Wang, Haoyuan Chen, Zhengfeiyang Zhang, Yixing Ma, Zichen Jiang, Ziyu Guo, Haodong Li, Zhengbo Jiao, Zhiqing Cui, Xinxiang Yin, Shuo Liang, Zhenglin Wan, Hongzhan Lin, Wangbo Zhao, Kaipeng Zhang, Pengfei Zhou, Odin Zhang, Yang You

• 署名单位包括 InfRec、XDU、TJU、NUS、UC Berkeley、CUHK、HKUST、HKU、SII。