一句话结论
多模态智能体自进化卡在两处：异构且可验证的环境造起来太贵，人工迭代 Harness 的速度追不上任务多样性的增长。Trinity 的做法是不再按「表面类别」（模态、题型）组织任务，而按「底层能力需求」重组任务树，让世界生成和 Harness 进化互为输入，最终在 28 个训练基准上把平均表现提升 34 分、18 个未见基准上提升 26 分，其中包含两项真实具身任务。论文见 arXiv:2610.36077。
方法要点
核心观察：模态和表面形式不同的任务，可以共享同一套底层能力需求。既然如此，就没有必要为每个任务单独造环境、单独调 Harness —— 应该先在能力层面把任务归并，再让环境生成和模块进化在归并后的节点上收敛。
关键设计：
- 能力树（Evolver）。使用已经验证成功的执行轨迹，把原始任务树从「表面类别」的划分基准切换到「共享需求」，重组成分层能力树。这一步是整个框架的支点：树的结构错了，后面的仿真世界和模块继承都会跑偏。
- Capability-Driven Real2Sim2Real（Creator）。对同一节点下的异构任务，Creator 把它们的共性需求抽象成简化、可验证的仿真世界，供能力学习；训练完再回到原始任务上评测，测的是迁移效果，不是仿真分数。
- Harness 树（Explorer）。Explorer 沿能力树逐层进化可复用能力模块，采用选择性继承，在固定拓扑内让已验证的更新跨迭代累积 —— 也就是拓扑一旦定下就不改，只让节点上的模块越迭代越强。
- 能力感知路由。进化出的 Harness 各自擅长不同能力，因此配一个 Capability-Aware Harness Router，只用公开的任务信息（不看标注、不看答案）从树里挑兼容的模块配置。
伪代码（按摘要机制重组，非原文实现）：
# The Trinity 一轮迭代
cap_tree = evolver.reorganize(task_tree, verified_traces) # 任务树 -> 能力树
harness_tree = seed(cap_tree)
for node in cap_tree.walk_top_down():
sim_world = creator.abstract(node.tasks) # 共性需求 -> 可验证仿真世界
module = explorer.evolve(
node,
sim_world,
inherit=harness_tree[node.parent].module, # 选择性继承
)
harness_tree[node] = module # 固定拓扑内累积更新
module.score = eval_on_original(module, node.tasks) # Real2Sim2Real 的 Real 端
router = CapabilityAwareRouter(harness_tree, use_public_task_info_only=True)
config = argmax(router.compatible(public_info), key=lambda c: c.score)
注意伪代码里那行 eval_on_original：仿真世界里学得再好，只有回到原任务上不掉分，这次更新才算「已验证」，才能写回 Harness 树。这条闸门是整套递归自进化不至于自嗨的前提。
关键数字
| 数据集 | 指标 | 对比基线 | 提升幅度 |
|---|---|---|---|
| 28 个训练基准 | 平均表现 | 未在摘要中点名，需查正文表格 | +34 分 |
| 18 个未见基准 | 平均表现 | 同上 | +26 分 |
| 两项真实具身任务 | 含在上述评测内 | 同上 | 未见单独拆分数字 |
需要说清楚的地方：论文摘要只给了「平均提升」这一个口径，没有给分任务明细、方差和失败率；「34 分」是均值，长尾任务的表现可能被均值掩掉。训练集与未见集之间从 34 分掉到 26 分，这个衰减幅度本身值得在选型时盯一眼 —— 泛化是有的，但没有满格迁移。
局限与前提
- 固定拓扑是硬约束。摘要明确说更新是在固定拓扑内累积，意味着结构本身不自演化。能力树一旦切分错了，后面只能靠模块补丁，不能改树。这省了搜索成本，也封死了结构层面的上限。
- 仿真世界的保真度就是天花板。Creator 做的是「简化」抽象，简化必然丢约束；丢了哪个约束、影响多大，摘要没有给消融。如果抽象掉了任务的关键难点，模块在 Real 端的迁移会直接崩，而这条链路只有一道评测闸门兜着。
- 环境构建成本没有被消除。作者把「构造异构可验证环境代价高」列为瓶颈之一，Trinity 是用抽象仿真去缓解，但 Creator 本身的构建开销、以及每轮都要在原任务上回归的评测开销，摘要里没有任何成本数字。
- 路由依赖公开任务信息的质量。线上任务描述残缺、带噪声或者刻意误导时，模块选择会退化成一个随机选择器。
- 具身任务样本太少。「两项真实具身任务」不足以支撑泛化结论，只能算方向性证据。
作者自己承认的不足集中在两个瓶颈上；而失败案例清单、单任务方差、算力与时间成本，在这份摘要层面都拿不到。
能不能用
开源情况：信息源中未见代码仓库、权重或数据集的发布链接，arXiv 页面只提供 PDF、HTML 实验版与 TeX 源码，Hugging Face 相关链接也没有指向本项目的产物。也就是说当前只能读方法，不能拉代码跑。
本地复现需要什么：
- 一个能批量执行 28 个训练基准的沙箱，且每个任务都要有可自动判定的成功信号 —— 没有验证器，Evolver 的「已验证轨迹」这一环就断了；
- 可回滚的 Harness 版本管理，因为写回是累积式的，某个节点退化必须能退回上一版；
- 按能力树节点切分的模块缓存与索引，否则路由每次都要重新装配；
- 真实成本不在模型推理，在评测次数：每轮迭代都要在原任务上全量回归，这一项会主导你的账单。
值不值得用：
- 值得：任务集异构但能力重叠、并且能自动判对错。这类场景下把任务重组成能力树，能省掉大量「一个任务造一个环境」的重复投入。
- 不值得：任务无法自动验证（只能人工打分），或者任务分布单一 —— 后者会让能力树退化成一条链，整个框架的收益趋近于零。
上手建议：先拿少量共享能力的任务跑通最小链路 —— 任务树 → 能力树 → 抽象仿真世界 → 模块选择性继承 → 原任务回归，确认这套闭环在你的验证器上不塌，再决定要不要把规模铺到论文那种基准数量级。