平台定位与要解决的问题
FastSim 可视为机器人仿真应用的控制平面，其运行模型包含以下六个环节：
- 声明描述这次要运行什么；
- 编译在启动仿真器前解析版本、资源、插件、能力和权限；
- Application按不可变计划建立唯一运行边界；
- 插件实现任务、模型、遥操作、录制、服务等可选产品能力；
- UniRoboSim Provider把稳定世界合同映射到具体仿真后端；
- 输出与接口让人、程序和离线工具在不绕过 Runtime 的前提下使用结果。
这张图同时解释了为什么 FastSim 不是单独一个 Python 包的功能列表。开箱即用的工程能力来自 Core 与官方插件仓库的组合：Core 提供编译、生命周期、服务和授权边界，插件提供面向具体工作流的能力，Provider 负责真实物理世界。
一个仿真脚本在单机上跑起来并不难；困难的是，当项目出现多个机器人、资产版本、后端、控制源、数据消费者和远程客户端后，仍能回答下面的问题：
- 这次运行真正选择了哪个组件版本和哪份物理资源？
- 配置中的值来自 Run、Project、组件默认还是一次临时覆盖？
- 某个插件为什么能读取相机，却不能控制机械臂？
- reset 后，旧订阅、旧控制指令和仍在计算的规划结果是否已经失效？
- 更换 Isaac Lab、MuJoCo 或 PyBullet 时，应用是否仍使用同一套实体和控制语义？
- 录制失败后，磁盘上留下的是完整产物还是误导性的半成品？
FastSim 通过编译期解析、稳定身份、generation、能力授权、Operation 和事务输出，把这些隐含约定变成可检查合同。
平台由哪些部分组成
| 部分 | 主要职责 | 不负责 |
|---|---|---|
| FastSim Core | Run 编译、Project/Registry 解析、ExecutionPlan、Application 生命周期、公共服务、授权、Operation、输出边界 | 具体任务语言、模型推理算法、遥操作设备协议 |
| 官方插件 | Mission、Model、Teleop、Record、Replay、Server、TUI、MCP、Visualizer、Interactive Debug 等产品能力 | 私自拥有后端生命周期或绕过公共服务 |
| UniRoboSim | 统一 Scene、Entity、Frame、State、Control 等后端中立合同 | 决定某个应用应该选择哪个后端 |
| Provider | 把统一合同实现到 Isaac Lab、MuJoCo、PyBullet 等仿真器 | 定义跨后端的业务流程 |
| 离线工具 | 检查、可视化、转换和分析已封口产物 | 修改正在运行的世界或原始数据 |
平台采用明确的职责边界：领域语义留在插件，运行权威留在 Core，物理实现留在 Provider。 例如，“抓取杯子”由 Mission 插件解释；插件读取 Scene/Frame/Geometry，调用规划或模型能力，最后提交后端无关的控制 Chunk。Core 不解释任务语义，但会检查控制所属的 generation、目标有效性与权限。
一次运行如何形成
第一步：作者编写可审查声明。 Run 选择后端、runtime 参数、Scenario 与插件实例；Project 声明 Registry、可信根和解析策略；组件 Manifest 描述稳定身份、版本、语义、后端 variant 与资源摘要。三者各自承担不同生命周期的事实，避免把整套工程塞进一个 YAML。
第二步：Compiler 产生不可变计划。 Compiler 验证结构，解析组件版本与资源，选择与后端匹配的 variant，绑定插件与实体，并计算能力与权限。任何仍依赖当前工作目录、Python import 顺序或未锁定远程内容的关键事实，都不应悄悄进入 Runtime。
第三步：Application 建立运行权威。 Application 在 owner loop 上组织 prepare、start、pause、reset、stop 和 close。服务、插件 hook、操作状态和输出终结都服从同一个生命周期，因此 UI、Server 或插件不会各自维护一套互相冲突的“运行状态”。
第四步：服务承载稳定交互。 调用方读取的是带 run、generation、revision 或 tick 的值对象；提交控制时使用稳定实体、joint、frame 与 group 身份。Provider 的 Prim path、对象地址和自由度数组顺序可以作为诊断信息，但不是跨后端应用合同。
第五步：结果被检查并发布。 日志、事件、metric、Operation 终态和输出回执共同构成运行证据。Record 等插件写入私有 staging，校验后才由 Core 原子发布；Viewer 与导出工具只读取已封口产物。
平台边界与脚本式集成的差别
适合进入平台合同的内容通常满足至少一项：需要跨后端保持语义、需要被多个插件共享、需要受 lifecycle/generation 约束、需要进入复现证据，或需要由统一权限边界保护。
不适合进入 Core 的内容包括特定任务状态机、模型提示词、某种设备协议、某个求解器的内部参数搜索以及面向单一业务的成功条件。这些内容可以由插件实现，并通过公共服务与 Runtime 协作。
归属规则：移除具体 Mission、Model 或 Teleop 插件后仍由所有应用共享的运行事实，才属于 Core 的候选范围。
| 脚本式约定 | FastSim 合同 |
|---|---|
| Python import 顺序决定插件是否生效 | 安装元数据负责发现，Run 明确选择实例 |
| 资产路径散落在代码与环境变量中 | Registry/Manifest 解析稳定组件与资源摘要 |
| reset 后继续使用旧对象引用 | generation 明确使旧句柄、Operation 和订阅失效 |
| 算法直接操作后端对象 | 算法通过 Scene、Frame、Geometry、Control 等稳定服务 |
| 多个控制源“最后写入者胜出” | 编译后的 authority 与 precedence 执行准入和抢占 |
| 进程退出后猜测数据是否完整 | staging、校验、原子发布和终态回执给出事实 |
如何继续阅读
第一次接触平台，依次阅读平台架构和核心设计原则，随后使用安装与首次运行生成与你的平台和 Provider 对应的 Conda 流程。
准备开发应用时，从Run、ExecutionPlan 与 Lock开始，再阅读Project、Registry 与 Component和Scenario 与 Scene。这些页面解释配置为什么这样组织，之后再进入具体指南。
准备开发插件时，重点阅读Plugin 与能力边界、Application 生命周期和状态、控制与 Operation。最后使用Python SDK核对当前签名。
本页的阅读目标是区分 Run 与 Runtime 状态、插件安装与启用、reset 与 generation，以及稳定应用身份与具体 Provider。需要进一步确认这些边界时，应先阅读平台架构，再进入 API 参考。