Scenario 与 Scene 的职责边界
| 区域 | 拥有者 | 用途 |
|---|---|---|
scene |
FastSim Core | 环境、实体、传感器、灯光及初始物理声明 |
behavior |
选定插件 | 任务、目标、策略或工作流私有输入 |
evaluation |
选定插件 | 成功条件、指标或评价私有输入 |
Core 会解析、规范化并锁定三部分，但只解释 Scene。Behavior 和 Evaluation 必须由 Manifest 声明读取权限的插件解释，因此平台不会被某一种任务语言绑定。
Scene 按稳定身份组织实体。 Scene 以稳定实体 ID 组织 environment、objects、articulations、robots、deformables、fluids、sensors 与 lights。每个实体选择组件，并在 Scenario 中声明本次实例的 pose、参数和必要绑定。
组件 Manifest 决定“它是什么”；Scene 决定“这次把它放在哪里并如何实例化”。这能避免把实例位姿写回共享资产。
编译态与运行态是两种视图。 ScenarioPlan 是编译后的不可变投影。运行时的 Scene Query 则返回 catalog、state 与 delta：catalog 描述实体结构，state 描述某一 generation/revision 的物理状态，delta 表示后续结构或状态变化。
插件应始终使用 FastSim 实体、link、joint 和 frame 身份，不依赖某个后端临时生成的 Prim path 或对象地址。后端原生标识可以作为诊断 provenance，但不应成为跨后端业务合同。
可复用的完整场景与实验条件适合发布为 scenario://...；一次性覆盖可留在 Run。无论哪种方式，编译结果都进入同一 ScenarioPlan。
字段列表见Scenario 配置参考，运行查询见Python Scene API。
从组件到实例
组件 release 描述可复用实体，Scenario 为这一次运行创建实例。以机器人为例，Manifest 提供 joint、frame、资源和 backend variants；Scenario 选择该组件并赋予别名、pose 与本次覆盖；Compiler 最终生成 robots.arm 之类的稳定实体 ID。
这一分离避免两个常见问题：共享组件被某次实验的 pose 污染，以及同一份几何在多个场景中复制后逐渐分叉。需要永久修复质量、joint 或 frame 语义时发布新组件版本；只改变本次摆放位置时修改 Scenario。
运行中的 Scene 语义
Catalog 回答“结构上有什么”：实体 kind、层级、joint、link、frame、sensor 和可用能力。State 回答“当前提交边界是什么状态”：pose、速度、joint 状态等。Delta 表示相对于已知 revision 的变化，便于远程客户端和插件增量消费。
调用者必须同时理解 generation 与 revision。generation 改变意味着 reset 后进入新世界，旧游标整体失效；同一 generation 内 revision 增长表示 catalog 或状态继续演进。只比较 sequence 而忽略 generation 会把两个不同世界的更新错误拼接。
Frame 与坐标语义。 Pose 必须说明相对哪个 frame，四元数顺序、长度单位和角度单位由公共合同确定。插件不应看到三个数字就猜它们来自世界坐标，也不应把 Provider 原生坐标约定直接传给另一个插件。
规划或控制前，先通过 Frame 服务查找稳定 frame 并在同一 generation/revision 上完成 transform。长时间计算完成后再次检查世界是否变化；若目标 frame 或 geometry revision 已更新，旧结果需要重算或明确拒绝。
领域语义与动态一致性
不同产品可能使用任务树、自然语言、模型输入、状态机或自定义约束描述行为。若 Core 解释这些领域语义，平台会被某一种任务体系绑死。Core 只负责保留、锁定并把授权区域交给选定插件；插件 Manifest 声明它读取哪一部分。
Evaluation 同理。成功条件和指标可以属于 Mission 或其他评价插件，但它们不应通过修改 Scene 私自影响物理真值。需要作用于世界的行为仍要调用受控服务。
动态变化必须通过公共服务。 运行时 pose、attachment 或可支持的 scene mutation 必须通过 Application 服务完成，并在权威边界产生新 revision。插件直接修改后端 stage 会绕过状态发布、录制和其他消费者，因此即使画面看起来正确，也不是有效 FastSim 行为。
建模完成后，用下面的清单检查职责有没有混在一起：
- 可复用事实是否在 Component，实例事实是否在 Scenario？
- entity、joint、link、frame 是否使用稳定身份？
- pose 的 frame、单位和四元数顺序是否明确？
- backend variants 是否保持同一组件语义并准确声明能力差异？
- Behavior/Evaluation 是否由明确插件读取，而不是被 Core 或任意插件猜测？
- 动态操作是否通过公共服务产生可观察 revision？
继续阅读Application 生命周期理解 Scene 何时构造、重置与销毁，或进入组织组件与资产查看落地方式。