场景示例（Ontology scenarios）
前面学了"对象、动作、本体容器"。这一篇看一个很实用的能力：场景（scenario）—— 在本体之上开一个"沙盒"，安全地做 what-if 推演，想清楚了再合并回生产。
https://www.palantir.com/docs/foundry/ontology/overview-ontology-scenario/
原始标题：Overview · Ontology scenarios
一句话速览
场景示例（Ontology scenarios）：前面学了"对象、动作、本体容器"。这一篇看一个很实用的能力：场景（scenario）—— 在本体之上开一个"沙盒"，安全地做 what-if 推演，想清楚了再合并回生产。
什么是 Ontology scenario（场景）
一个在本体之上、用动作生成编辑的"隔离沙盒"。
场景（scenario）让你能用对象（objects）和本体里的模型（model）概念，创建并比较"what-if"分析。 本质上，它就是一个沙盒（sandbox）：在你在本体数据之上，通过应用一个或多个动作（actions）来叠加编辑。
关键区别：场景不是数据版本工具。它不能给你一份"历史某个时间点的本体快照"，也不该被当成那个用途。
四种常见用途
从假设分析到 agent 评估，都靠它。
生命周期：30 天 TTL + 每 10 分钟自动 rebase
场景是"临时"的，要懂得它的保质期与同步机制。
场景（scenario）vs 全局分支（Global Branching）
一个给构建者测流程，一个给用户试改动。
一句话：分支是"开发者隔离环境"，场景是"使用者试算环境"。两者互补，不是替代。
用执行上下文治理动作，再合并回主本体
在沙盒里可以更宽松，合并时依然收紧。
动作提交标准（action submission criteria）里的执行上下文（execution context）能区分： 一个动作是"在场景里执行"，还是"对主本体执行"。这是个安全护栏—— 规划者和 agent 在场景的隔离沙盒里测试动作时，可以用更宽松的提交标准； 而不会因此获得把动作应用到主本体的权限。
把审核通过的场景改动写回主本体，是单独通过"合并动作（merge action）"的提交标准来控制的。 也就是说：沙盒里随便试，合并那一步才需要真正的授权。
函数与场景、以及要注意的限制
大多数函数能直接在场景上跑，但合并有上限。
所有函数（AIP Logic 函数除外）都能原样在场景上运行：如果函数读本体，它读的是场景版本的本体的状态； 如果函数改本体，它改的也是场景上的版本。想在场景上用 AIP Logic 函数，需要为它及其调用的所有嵌套 Logic 函数开启暂存写入（staged writes）。
- 合并场景用的是动作，因此同样受动作的规模/属性上限约束；
- 场景固定每 10 分钟自动 rebase 到基础分支；
- 场景不能按需 rebase，也不能自定义 rebase 间隔。
一页带走
延伸阅读 · 相关页面
按主题横向跳转，不必顺着目录一篇篇读。
常见问题速答 · FAQ
关于「场景示例（Ontology scenarios）」，读者最常问的几个问题。