任务分类可能是错的：The Trinity 用"能力树"重构多模态智能体的自我进化

你有没有发现一个现象：现在的 Agent 自我改进工作，几乎全扎堆在编程和数学这种纯文本任务上？不是大家不想做更广的，而是一换到多模态、异构任务的场景，整套进化逻辑就开始散架——给每个任务单独进化一套脚手架（Harness），泛化差得要命；只用一套全局 Harness，又压不住任务之间互相冲突的需求。

这篇论文给了一个我觉得相当漂亮的回答：别再按任务分类了，按能力分类。

核心摘要

The Trinity 是一个面向多模态智能体的能力驱动递归自我改进框架。它把"世界生成"和"Harness 进化"耦合成一个闭环，由 Creator、Explorer、Evolver 三个角色轮转驱动：Evolver 从已验证的执行轨迹里归纳能力需求，把原来的任务树重组为一棵层级化的能力树；Creator 为同一能力节点上的异构任务生成简化但可验证的模拟世界（Capability-Driven Real2Sim2Real）；Explorer 沿着能力树通过选择性继承进化出可复用的能力模块，形成一棵 Harness 树；最后再加一个能力感知路由器，给新任务自动挑选合适的 Harness 配置。效果上，进化后的 Harness 在 28 个训练基准上平均提升 34 个点，在 18 个未见基准（含两个真实机器人任务）上提升 26 个点。这不是底层模型突破——骨干模型 Claude Opus 5 全程冻结——但它把 Harness 层的自我改进从"单任务手搓"推进到了"成体系进化"，工程价值很实在。

论文信息

  • 标题：The Trinity: Capability-Driven Recursive Self-Improvement for Multimodal Agents
  • 链接：https://arxiv.org/abs/2610.36077
  • 发表时间：2026 年 10 月 26 日
  • 作者：The Trinity Research Team。核心贡献者 Weidong Tang、Ruiheng Wang、Jingxuan Zhang、Hexin Wang；通讯作者 Pengfei Zhou、Odin Zhang、Yang You
  • 机构：InfRec、西安电子科技大学、同济大学、新加坡国立大学、UC Berkeley、香港中文大学、香港科技大学、香港大学、上海创智学院

🎯 问题：为什么任务驱动的自我进化走不远

先交代一下背景。这里说的 Harness，就是裹在冻结大模型外面的那层控制框架——怎么规划、怎么调工具、怎么管理上下文、怎么自检。Lilian Weng 今年在博客里有个判断我挺认同：近期内递归自我改进的主战场不在模型权重，而在脚手架。改权重需要训练资源和决心，改 Harness 只需要一个能动文件的 Agent 加一个能打分的环境，循环便宜、快、可审计。之前的 Darwin Gödel Machine 就是这条路线的代表：冻结 Claude 3.5 Sonnet，让编程 Agent 改自己的代码，SWE-bench 从 20% 干到 50%。

但这条路线有个隐含假设：任务是同构的。编程任务之间共享大量工作模式，单任务进化出来的 Harness 多少能迁移。换成多模态异构任务——开车避险、玩 Among Us、谈判、操作机器人——任务特定进化立刻过拟合，而单一全局 Harness 又调和不了冲突需求（比如具身任务里性能和效率的权衡）。

论文的关键洞察其实一句话就能说完：表面形式天差地别的任务，底层能力需求可能是同一个。 ARC-AGI-3 和 Micromouse，一个认格子、一个走迷宫，看起来毫无关系，但都依赖精确感知与状态追踪。

这个洞察一旦成立，整个组织方式就变了。

图1：The Trinity 总览——左侧是多模态任务空间的扩张，中间是 Creator/Explorer/Evolver 三位一体的共进化循环，右侧是能力驱动的 Harness 进化家族，下方依次是任务树构建、能力树构建、Harness 树构建与能力感知路由器

🧠 方法：三位一体，绕着能力树转

The Trinity 的核心结构是一棵能力树，三个角色围着它各司其职：

角色 干什么 一句话理解
Evolver 归纳能力需求、重组任务树为能力树、诊断节点级改进、设计训练关卡、指导模块更新 大脑，负责"该学什么"
Creator 把 Evolver 设计的简化关卡实现成可验证的模拟世界 造环境的
Explorer 收集轨迹、沿能力树选择性继承并精炼能力模块、筛选难度合适的世界 练兵的

能力树怎么长出来

这块的设计挺克制。独立 Agent 先对每个训练任务提出能力需求，judge 整合、reviewer 核查，每个任务得到一个固定需求集 \(K_\tau \subseteq \mathcal{K}\)。然后按一个预先固定的确定性能力顺序 \(\prec\) 排序，塞进 Trie：

\[p_\tau=\operatorname{sort}_{\prec}(K_\tau),\qquad \mathcal{T}=\operatorname{Trie}\bigl(\{p_\tau:\tau\in\mathcal{B}_{\mathrm{tr}}\}\bigr)\]

Trie 的好处是跨域公共前缀自动合并——需求前缀相同的任务聚在同一子树下，共享祖先节点上学到的模块。注意一个细节：能力树只用训练任务构建，全程固定。未见任务的能力标签是事后标注的，只用于路由器的回顾性评估。这个设计避免了树在评估过程中被偷改，挺严谨的。

Harness 树与选择性继承

Explorer 的 Harness 树和能力树对齐，每个节点从 Base Harness \(\mathcal{H}_0\) 出发。Harness 本身被结构化为六个控制流协议：感知、记忆、推理、规划、编排、循环，即 \(\mathcal{H}_{\phi}=(\Pi_{\mathrm{er}},\mathbf{M},\mathbf{I},\mathbf{P},\mathbf{F},\mathbf{L})\)，骨干模型冻结，进化的只是模块配置。

真正有意思的是继承方式。子节点不是无脑拷贝父节点，而是做一次右偏并集——局部模块优先，父节点的更新只填补空缺：

\[(P\oplus L)[m]=\begin{cases}L[m],&m\in\operatorname{dom}(L)\\ P[m],&m\in\operatorname{dom}(P)\setminus\operatorname{dom}(L)\end{cases}\]

而且父节点的更新要被保留，有个硬门槛：在相同验证任务、相同试验数和预算下取得严格更高的性能，否则继续用旧注册表。这个"严格更高才继承"的设计很关键——没有它，递归改进很容易在几轮迭代里被一次坏更新带崩，之前 SICA 那类工作就报告过路径依赖导致的方差问题。

Capability-Driven Real2Sim2Real

这是我个人觉得全文最值钱的一段。同一个能力节点上的异构任务共享需求，Evolver 就为这个节点设计一个简化的训练关卡——剥离目标任务的布局、私有证明和解题轨迹，只保留核心决策过程。Creator 把它实现成可验证的模拟世界，Evolver 的验证器池检查节点绑定、执行、状态转移、渲染和完成条件，Explorer 再来做难度筛选：只有性能落在预定中间区间的世界才被录取，太难或太易都让 Creator 调整。

你想想看，这其实是在给能力造"健身房"：不在真实任务上死磕，而是在保留了决策内核的简化环境里反复练，然后回真实任务测迁移。这比直接在原始环境里训练便宜得多，也避免了把私有解法直接喂给模型造成的泄题。

图2：完整流水线——上排是任务树构建（收集基准、独立审查、分组拆分）与世界探索；中排是能力树构建（需求落地、独立 Agent 提议能力、整合审查）与世界创造（验证器池、宿主验证、难度筛选）；下排是 Harness 树构建（执行观察、诊断、模块配置、验证应用）与能力感知路由

图 3 给了一个很直观的例子：Euro NCAP 自动刹车（噪声测距下该刹车还是保持）、Among Us（供词冲突时该信谁）、GLEE 谈判（买家反馈矛盾时发哪条消息）、PInVerify（隐藏细节该检查还是直接决策）——四个八竿子打不着的任务，共享同一个能力需求：先验证证据再承诺（Evidence-Gated Commitment），而不是拍脑袋过早决策。

图3：四个异构任务共享同一能力需求的例子——证据门控承诺 vs 过早承诺

能力感知路由器

树建好了，推理时怎么用？一个 Router 按"上下文–动作–反馈"循环工作：

\[h_n=\pi\!\left(x_n,\mathcal{C},R(x_n,\mathcal{M}_n),S(\mathcal{M}_n)\right),\qquad \mathcal{M}_{n+1}=\operatorname{Append}\!\left(\mathcal{M}_n,(x_n,h_n,f_n)\right)\]

输入只有任务的公开信息（目标、初始观测、元数据、图像），候选池是版本化的 Harness 集合，记忆用已验证的训练侧轨迹初始化，余弦相似度 \(\geq 0.5\) 检索最多 10 条。技术失败记零分、无效选择无回退——评估做得相当不留情面。

🧪 实验：数字说话

设置：28 个训练基准 + 18 个未见基准，覆盖规则发现、约束求解、感知控制、多智能体交互、长时程环境五大需求域。骨干是冻结的 Claude Opus 5，Base Harness 是 Prime Agent。

组织结构对比：能力树赢在哪

这张表（Table 3）是全文的核心证据：

方法 课程 Train Unseen 训练成本(M tokens) 推理 Train(M) 推理 Unseen(M)
Base (\(\mathcal{H}_0\)) – 39.06 37.45 – 582.54 613.07
Global（单一全局 Harness） Real 53.04 42.92 582.54 531.81 567.68
Task-Domain（15 个域） Real 51.17 40.82 278.25 540.36 577.33
Capability-Domain（扁平） Real 49.25 39.43 136.94 562.32 596.58
Capability Tree Real 53.44 42.31 211.56 526.53 563.90
Capability Tree Sim 56.95 47.26 405.70 514.42 549.07

几个点值得掰开看。

一，树结构本身有用。Capability Tree（Real）比扁平的 Capability-Domain 高 4.19/2.88 个点，说明沿共享前缀的选择性继承确实带来了增量，不是分类标签的功劳。

二，Sim 课程再叠一层。换成 Real2Sim2Real 的模拟世界训练，再涨 3.51/4.95 个点，同时推理成本反而是所有方案里最低的。用更少的真实环境换来更强的迁移和更省的推理——作者把这个总结为"less is more"，数据上站得住。

三，有个略尴尬的细节：扁平 Capability-Domain 训练 token 最省（136.94M），但性能反而低于 Global。说明光按能力分组、不给层级继承结构，是打不过粗暴的全局方案的。层级结构才是那味药引子。

递归迭代：增益是持续的，但第一轮吃大头

从 Base 到第 4 轮迭代：Train 均值从 39.1 爬到 73.2，提升 34.1 个点；Unseen 从 42.1 到 64.1，提升 22 个点。第一轮迭代增益最大，第 2–4 轮还额外贡献 9.4（Train）和 6.4（Unseen）——递归改进没有立刻饱和，这是"recursive"三个字成立的关键证据。

最终 Unseen 均值 64.1，超过 Codex 参考均值 47.5 和 DeepSeek 参考均值 46.2。不过我得多嘴一句：这种跨系统对比的公平性存疑，Codex 和 DeepSeek 的参考数是各自默认配置跑出来的，而 Trinity 是在 28 个训练基准上"见过世面"的。真正干净的证据是 Crafter 和 DiG-bench 这两个基准上 Trinity 仍然落后——作者老实写出来了，加分。

图4：训练成本随迭代的变化——第一轮 Creator 环境构建占 321.6M token 的大头，后续迭代复用世界后总成本大幅下降，而 Train 性能曲线持续爬升

成本侧的故事也顺：第一轮训练 405.70M token，其中 Creator 造环境占 321.6M，是绝对大头；但世界建好之后被后续迭代反复复用，第 2–4 轮的总成本降到 110–150M 级别，性能曲线还在往上走。环境构建是一次性投资，这个账算得过来。

路由器消融：接近 Oracle

路由方式 能力定义 经验记忆 Train Unseen
Random – – 52.74 46.23
Self-Routing ✗ ✗ 65.79 52.36
Self-Routing ✓ ✗ 70.34 58.27
Self-Routing（完整） ✓ ✓ 71.27 60.96
Oracle（上界） – – 73.16 63.61

完整路由距离 Oracle 只差 1.89/2.65 个点，而且 token 成本随信息增加单调下降。能力定义和经验记忆各自都有贡献，叠加最大。这个消融做得干净。

能力–模块相关性：解释性的意外收获

热力图（Figure 7）展示了 Iteration-4 的 29 个模块里，能力标签与协议模块的使用频率相关性：

图7：能力-模块相关性热力图——HCI（假设与对手推断）与推理协议相关性 0.744，GVT（目标承诺与价值权衡）与循环协议 0.444，而 GVT 与感知呈最强负相关 -0.361

HCI（假设与对手推断）和推理协议相关 0.744，直觉上对——玩 Among Us 这类博弈可不就得疯狂推理。更有意思的是负相关：GVT（目标承诺与价值权衡）和感知协议是 -0.361，说明重权衡的任务反而要少堆感知模块。作者还做了个干预实验验证因果性：给 Base Harness 加相关模块涨 19.39 个点，加无关模块只涨 1.02 个点；从进化好的 Harness 里移除相关模块掉 2.74 个点。相关不是玄学，是能换成性能的。

具身迁移：从 0 到 60

最后是最吸睛的部分——真实机器人。两个具身任务映射到能力树节点，经 Real2Sim2Real 学技能后实测：SOON（Unitree G1 导航到风扇旁的桌子并够取物体）和 CaP-X（AlohaMini2 掀开杯子找隐藏方块）。

Harness SOON (Sim) CaP-X (Sim) SOON (Real) CaP-X (Real)
\(\mathcal{H}_0\) 0 10 0 0
\(\mathcal{H}^{(1)}\) 20 20 20 20
\(\mathcal{H}^{(3)}\) 80 40 60 40
\(\mathcal{H}^{(4)}\) 80 60 60 60

成功率从 0 到 60（真实环境）。数字漂亮，但冷静看：每个格子的样本量应该很小（成功率都是 10 的倍数，估计每项就 10 次试验），方差会很大。作为概念验证足够，当成稳定结论还早。

图8：具身任务 Real2Sim2Real 流程——真实场地与任务（REAL）→ 5 次试验提炼技能的仿真环境（SIM）→ 用固定 Harness 加预学技能回真实机器人测试（REAL）

🤔 我的判断

最值钱的地方：能力树这个抽象是真的好。它把"哪些任务该共享训练信号"这个此前靠拍脑袋的问题，变成了一个有验证器背书的数据结构问题。选择性继承里的"严格更高才保留"和右偏并集，是递归自我改进系统里最缺的那类防崩设计——DGM 靠开放式存档兜住探索方差，Trinity 靠树结构和硬门控，思路不同但都在解同一个问题。

要泼的冷水：

第一，能力分类本身也是模型提的。独立 Agent 提议 + judge 整合 + reviewer 核查，流程上很讲究，但分类质量的上限还是被分类模型锁死。如果底层模型对某类任务的能力需求理解错了，整棵树的对应分支就建在沙滩上。论文没给分类准确率的直接评估，只说 reviewer 核查——这块我觉得可以再硬一点。

第二，对 Claude Opus 5 单一骨干的依赖。之前 Self-Taught Optimizer 的教训摆在那：GPT-4 上有效的自我改进方案，换弱模型反而更差。Harness 进化是在"放大模型能力"，不是在替代它。这套 Harness 树换到更弱的骨干上还剩多少增益，论文没答。

第三，成本。第一轮 405.70M token 的训练开销，按 Opus 级别的 API 定价粗算是笔不小的钱。作者论证了它能被后续迭代摊销，但"一次性投资"对大多数团队来说门槛依然不低。

工程启发：如果你在做 Agent 产品，就算不搞递归进化，有两个思想可以直接拿走。一是按能力而不是按任务表面形式组织你的工具/提示词模块库，检索时收益会很直接；二是任何模块的合入都要过"严格更高才保留"的门控，别让 Agent 的自改悄悄劣化线上表现。这两条都不需要造世界，今天就能落地。

更远的展望上，作者提到要把这个范式扩展到模型参数训练——Harness 层的进化目前只是在调度一个冻结的脑袋，如果能力树能反过来指导数据配比和训练信号，那才是真正的闭环。那一步会比现在难得多，但也值钱得多。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我