RoboRSI：机器人失败之后，应当修改技能树的哪一层？

如何把一次机器人失败归因到可维护的技能分支，并验证修复能够被后续任务复用？

1. 1

   把目标组织成有契约的技能图

   任务族分解为可观察完成条件的原子任务，原子技能调用感知/控制基础技能；多处可共享同一节点。Manager管理目标、版本和发布，Planner生成计划，Engineer执行，Reviewer根据图像与工具轨迹独立检查结果。

2. 2

   沿返回顺序定位最早失败节点

   被调用节点先于调用者检查后置条件，重试每次单列；从最早不满足条件的节点限定修改分支。接口若必须改变，先扩大到受影响调用者；不仅看这次实际走过路径，也看所有可能调用依赖。

3. 3

   隔离候选，验证后再对后续运行发布

   仿真候选先经基础技能功能测试、原子任务至少两个声明种子成功和Manager审查；真实机器人主要回放最近四个合格记录。失败补丁不发布且不得原样重交；调用返回成功不等于任务成功，最后动作之后要有新观察核对后置条件。

4. 4

   将稳定序列压成参数化代码技能

   至少三次成功、工具序列最长公共子序列至少60%、公共骨架至少三步才提出复合技能；运行时重新感知所有参数，不保存旧场景坐标。复合调用失败可回到逐步推理，执行轨迹也可训练ACT后作为技能接入。

全文及附录A–D、图2、代码仓库、Apache许可证与评估文档已读；未运行机器人或模型API。

nssmd/RoboRSI仓库有roborsi实现、scripts、tests、Docker及CLI/Web入口，Apache-2.0许可证已核对。公开复现脚本运行当前冻结版本，不重演论文在线累计轨迹；README部分数字属于旧的adaptive口径。

LICENSE代码Apache-2.0，论文与图2 CC BY 4.0。外部模型服务、仿真基准与第三方组件有独立条件，仓库开源不等于全部实验环境或模型权重可自由复现。