多模态RSI框架部署实战

一、部署概述：先把“要部署什么”讲清楚

在讨论任何部署细节之前，必须明确本文的部署对象。这里的部署对象不是单一 Web 服务，也不是一段脚本，而是一条持续运行的递归自我改进流水线。它的特殊性在于：部署完成后，系统不是“跑一次就结束”，而是要按轮次不断产出改进后的执行组件，并把新版本安全地投递给后续任务。

这套流水线的核心思想来自原始工作提出的范式转变：传统 RSI 的做法是“给一个具体任务 → 执行 → 拿反馈 → 调策略 → 再执行”，演化单位是单个任务；由此得到的改进往往是局部最优，换一类任务就可能失效，也很难迁移到视频、空间推理、物理模拟、具身操作等异构模态上。新的做法把基本演化单位从任务换成能力：先把任务集合整理成任务树，再通过轨迹分析反推出“完成这类任务到底依赖哪些能力”，把任务树重写为能力树，最后沿能力树逐节点演化出对应的执行组件（Harness），形成 Harness 树。据原始工作描述，经过四轮 RSI，该系统在二十余个跨模态、跨领域训练基准上平均提升约三十四分，在十八个未见基准上平均提升约二十六分，并把演化后的组件迁移到真实机器人任务上，使两类具身任务的成功率从 0% 提升到约 60%。

对部署者而言，这个结论有直接工程含义：部署的目标不是“跑通一次评测”，而是搭出一条能把能力改进沉淀下来、并可跨任务复用的基础设施。本文要达到的部署效果可以概括为四点：

1. 三类演化角色（任务生成、轨迹探索、策略演化）可被独立调度、独立扩容、互不阻塞；
2. 三类核心资产（任务树、能力树、Harness 树）可被持久化、可版本化、可回滚；
3. 多轮 RSI 可以无人值守连续执行，单轮失败不影响整体资产；
4. 演化出的 Harness 可通过统一入口对外提供服务，供评测任务与真实机器人任务调用。

适用读者包括：算法平台与训练平台工程师、模型服务化工程师、运维与 SRE、以及需要评估该范式是否值得自建的技术负责人。

二、部署场景：这套系统通常部署在什么前提下

这类系统的部署通常出现在三类场景中。

第一类是研发期的自改进实验平台。 团队希望验证“能力驱动”相对“任务驱动”的差异，需要在一个可重复的环境里跑多轮 RSI，并对比每一轮在训练集与未见集上的表现。此时部署重点是实验可复现性：数据版本、配置版本、组件版本三者必须严格绑定。

第二类是面向多模态评测的持续集成流水线。 每个新版本的 Harness 都要在训练基准与保留的未见基准上回归一遍，用于判断是否真的带来跨任务迁移。此场景强调并发调度与结果归档，因为多模态评测本身耗时长、资源占用大。

第三类是面向真实具身任务的推理服务化。 把能力树上对应节点演化出的 Harness，封装成可被上层任务调用的服务，在重建的仿真环境中准备技能，再迁移到真实机器人平台上评估。此场景强调低延迟、稳定心跳、以及在证据不足时能持续采集环境信息的能力。

这三类场景可以共用一套基础部署，差别在于调度策略、资源规格与对外访问方式。

三、架构与组件拆解

3.1 逻辑角色

• 任务生成角色：负责产出与扩充任务集合，并维护任务的分类结构，最终形成任务树。它需要任务模板、领域约束与去重能力。
• 轨迹探索角色：负责执行任务、采集完整轨迹，并从轨迹中反推每个任务实际依赖的能力，是把任务树映射为能力树的关键环节。它需要沙箱化的执行环境与轨迹存储。
• 策略演化角色：沿能力树逐节点演化执行组件，产出 Harness 树。它需要版本管理、回归评测与准入判定。

3.2 三类核心资产

资产	内容	部署要求
任务树	按模态与领域分层的任务集合	结构化存储、可增量导入、支持标签与难度分级
能力树	由轨迹分析得出的能力项及其依赖关系	支持有向依赖、幂等更新、节点级版本号
Harness 树	每个能力节点对应的执行组件集合	镜像化、版本化、带元数据与评测成绩

3.3 基础设施组件

计算资源（任务执行节点、演化训练节点）、对象存储（轨迹与数据集）、结构化数据库（树结构与版本元数据）、消息队列（任务分发与结果回收）、缓存（能力索引与热数据）、日志服务、监控告警、身份认证与访问控制、密钥管理、负载均衡与网关。

3.4 架构示意

                 ┌──────────── 调度与编排层 ────────────┐
   外部调用 ───▶ │  网关 / 负载均衡 → 任务队列 → 调度器  │
                 └───────┬────────────┬─────────────┬───┘
                         ▼            ▼             ▼
                   任务生成服务   轨迹探索服务   策略演化服务
                         │            │             │
                    任务树存储 ─── 能力树存储 ─── Harness 仓库
                         │            │             │
                    对象存储（轨迹/数据集/镜像）   评测执行集群
                         └──── 日志 · 监控 · 告警 · 密钥管理 ────┘

四、前置准备：部署前必须齐备的东西

类别	准备项	说明
账号权限	云账号、计算与存储配额、镜像仓库推送权限、监控创建权限	遵循最小化原则，部署角色与运维角色分离
计算资源	任务执行节点（CPU 密集）、演化与评测节点（加速卡）、调度节点	评测阶段建议按需弹性，实验阶段可预留
存储资源	对象存储桶（轨迹、数据集、中间产物）、结构化数据库实例	轨迹体积大，必须配置生命周期策略
网络资源	内网互通、公网访问入口、域名与证书、访问白名单	数据面走内网，控制面走公网并加认证
依赖组件	运行时环境、依赖包、镜像仓库、消息队列、缓存实例	版本锁定，避免环境漂移
数据准备	训练基准数据集、保留的未见基准集、任务模板、能力本体定义	训练集与未见集物理隔离，防止泄漏
配置准备	环境变量清单、密钥材料、评测参数、准入阈值	密钥统一托管，不入代码库

环境一致性在这里尤其重要。因为多轮 RSI 的结论要靠跨轮对比才能成立，如果每轮的依赖版本、数据集切片或评测参数都不同，观察到的分数变化就无法归因于能力改进。建议的做法是：为每一轮 RSI 生成一个不可变的配置快照，与该轮产出的 Harness 版本一并归档。

五、资源规划：按环节估算，而不是一刀切

• 任务执行环节：以任务并发数与单个任务平均耗时估算核心数与内存；执行环节多为短生命周期进程，适合容器化与弹性伸缩。
• 轨迹采集环节：多模态轨迹（图像、视频、点云、动作序列）体积极大，对象存储与带宽是瓶颈。建议按“单轨迹平均体积 × 任务数 × 保留轮数”估算容量，并对原始轨迹设置较短的保留期、对蒸馏后的能力分析结果长期保留。
• 演化与评测环节：属于典型的长时批处理，建议使用独立资源池，避免与在线服务抢占。可配置抢占式实例降低成本，但要保证任务可断点续跑。
• 在线服务环节：按目标 QPS 与 P99 延迟反推实例数，预留至少一路冗余，配合健康检查与自动重启。
• 容量预留：以历史轮次峰值（而非均值）作为扩容基线，第一轮 RSI 通常是资源消耗最大的一轮，扩容阈值应据此设置。

六、部署流程：从环境初始化到访问验证

阶段 0：环境与权限初始化

创建资源池、网络与存储；配置镜像仓库；建立配置与密钥的注入通道；确认调度节点与执行节点内网互通。此阶段完成的标志是：调度节点能成功拉取镜像、能写入对象存储、能读取数据库。

阶段 1：资产导入

先把任务树导入并做完整性校验：任务是否唯一、标签是否齐全、是否存在无对应能力节点的任务。再把能力树导入，校验依赖关系无环。最后把历史 Harness 版本导入仓库，形成基线版本（通常为未改进的原始组件），作为后续所有轮次的对照。

阶段 2：依赖组件就绪

按“数据库 → 缓存 → 消息队列 → 对象存储 → 监控日志”的顺序拉起依赖组件。之所以是这个顺序，是因为上层服务启动时会做连接自检，依赖未就绪会导致容器反复重启，日志中会出现难以定位的连接超时。

阶段 3：服务编排与配置注入

将三个角色服务与调度器以编排文件描述，明确资源上限、健康检查探针、启动依赖与重启策略。配置通过环境变量注入，敏感项从密钥管理服务读取。

阶段 4：轮次任务配置与启动

设置本轮 RSI 的目标能力节点子集、评测基准清单、并发度、单任务超时与失败重试策略。建议先以小规模子集做一次冒烟轮次，确认链路贯通后再放开全量。

阶段 5：准入判定与投递

每轮结束后，由策略演化服务把新产出的 Harness 在训练基准与未见基准上同时评测，只有满足预设准入阈值（例如未见基准不允许回退）才允许升级为对外服务版本；不满足则保留为实验版本，不进服务流量。

伪代码示意

# 一轮 RSI 的通用流程（示意，非特定产品实现）
def run_one_round(cfg, snapshot):
    task_tree = load_task_tree(snapshot.task_tree_version)
    target_nodes = select_capability_nodes(task_tree, cfg.focus)
    for node in target_nodes:
        harness = build_or_fetch_harness(node, baseline_only=False)
        trajs = executor.run_batch(
            tasks=task_tree.tasks_of(node),
            harness=harness,
            sandbox=cfg.sandbox_profile,      # 资源限额与网络隔离
            timeout=cfg.task_timeout,
            retry=cfg.retry_policy,
        )
        artifact_store.put(trajs, tag=snapshot.id)
        new_node = evolver.evolve(
            capability=node,
            trajectories=trajs,
            constraints=cfg.evolve_constraints,
        )
        metrics = evaluate(new_node, benchmarks=cfg.eval_suite)
        if admission_gate(metrics, baseline=snapshot.baseline_metrics,
                          unseen_no_regression=True):
            harness_repo.publish(new_node, version=next_version(node))
        else:
            harness_repo.keep_experimental(new_node, reason=metrics.report())
    emit_report(snapshot.id, metrics=aggregate(cfg.eval_suite))

七、关键配置项解读

配置项	作用	风险点与建议
焦点能力节点集合	限定本轮演化范围	范围过大导致资源耗尽且归因困难；建议分批
训练/未见基准隔离标志	防止评测泄漏	混用会让迁移能力提升的结论失真
单任务超时与重试	控制长尾任务占用	超时过短会误判失败，过长会拖垮整轮
沙箱资源限额	限制执行环境副作用	无限额时异常任务可能耗尽节点资源
准入阈值	决定是否对外升级版本	阈值过松会把回退版本推向线上
轨迹保留期	控制存储增长	不设生命周期策略会导致存储成本持续攀升
依赖版本锁定	保证跨轮可比	浮动版本会让分数变化无法归因

八、上线验证：如何判断部署是成功的

验证应分四层进行，任一层不通过都不应放行。

第一层，进程与服务层。 三个角色服务与调度器进程存活，健康检查探针返回正常，容器无异常重启记录，日志中无持续的连接超时或权限拒绝。

第二层，链路层。 提交一个最小任务，确认其完整走完“生成 → 执行 → 轨迹落盘 → 能力反推 → 组件演化 → 评测归档”的闭环，且各阶段产物都能在存储中找到、元数据能与版本号对应。

第三层，结果层。 跑一轮小规模 RSI，检查两点：一是本轮内部各能力节点是否都产出了新版本；二是训练基准与未见基准的分数变化是否符合预期方向。这里要注意一个真实特征——并非所有基准都会持续上涨，部分任务会较早进入平台期，个别任务可能出现小幅回退，这属于正常现象，不应据此判定部署失败；判断标准应是整体趋势与未见基准是否同步改善。

第四层，迁移验证层（可选但建议）。 若目标是具身场景，取一个能力节点的演化组件，在重建的仿真环境中准备对应技能，再迁移到真实机器人平台执行一次任务级验证，观察成功率是否显著高于基线。

九、常见问题与排查

现象	可能原因	排查思路
执行容器反复重启	依赖组件未就绪或健康检查探针配置过严	查看启动日志前若干行；放宽首次探测延迟
轨迹写入失败或变慢	对象存储配额、并发过高、单文件过大	检查配额与限流指标；降低并发或分片上传
能力反推结果不稳定	轨迹采样不足或任务定义有歧义	增加样本；收紧任务模板与去重规则
第二轮后收益明显变小	焦点节点已接近平台期	调整焦点节点分布，向未见模态倾斜
未见基准分数不升	演化过度拟合训练任务	检查隔离标志；加入未见集作为准入约束
存储成本快速上升	未设生命周期策略	原始轨迹短保留、分析产物长保留
在线服务延迟升高	评测任务与在线任务共用资源池	拆分资源池，在线优先保障

十、运维与优化建议

• 监控告警：资源层看 CPU、内存、加速卡利用率、存储容量与带宽；应用层看任务成功率、平均耗时、超时率、重试率；业务层看每轮能力节点产出数与基准分数变化。建议对“连续两轮未见基准无改善”单独设告警，它通常意味着演化策略需要调整。
• 稳定性保障：全部执行任务在沙箱内运行并限制资源与网络；任务幂等、可断点续跑；关键资产多副本；数据库与对象存储定期备份并做恢复演练。
• 安全控制：控制面公网入口启用身份认证与最小权限；数据面仅内网可达；密钥统一托管并定期轮换；轨迹数据可能包含环境敏感信息，需做访问审计。
• 性能优化：能力索引与热数据走缓存；多模态预处理改为异步任务；批量评测采用并发与优先级队列；静态资源交给内容分发。
• 成本管理：演化与评测使用按需或抢占式资源；在线服务按峰值预留冗余；对象存储按访问热度分层并设生命周期；对反复执行的同类任务缓存中间产物。

十一、总结

这套系统的部署难点不在于拉起几个服务，而在于把“以能力为演化单位”这一理念落到基础设施上：任务树、能力树、Harness 树三类资产必须可版本化、可比对、可回滚；三个角色必须解耦到可独立调度与扩容的程度；多轮迭代必须无人值守且结论可归因。按上文完成环境准备、资产导入、依赖就绪、编排配置、冒烟轮次与准入投递后，用四层验证（服务层、链路层、结果层、迁移层）确认上线效果，再以监控告警、安全隔离与成本治理维持长期运行，即可获得一条从任务驱动的局部优化走向能力驱动的跨任务、跨模态持续演化的工程通路。