Pajama Engine

01 · 愿景与产品方向

让世界持续演化的基础设施

Pajama Engine 是我们正在构建的 AI 原生 MMO 游戏引擎，面向可持续运行、可编程的共享世界。 Rust 运行时连接权威模拟、物理、渲染与内容交付；结构化创作接口让开发者和 Agent 通过明确的验证与发布流程扩展世界。原生客户端采用 winit 与 wgpu，规划中的观测层将这套基础连接至学习模型。[1] [2] [3]

我们的愿景是让世界在使用中不断发展：玩家改变地形，创作者引入新机制，新的视觉系统赋予世界不同的表现形式。这些变化应当建立在共同历史之上。内容更新后，一个对象仍然是原来的对象；服务器重启后，玩家的行动仍然留下后果。

空间也应能随探索持续扩展：玩家远行、返回，仍能找到此前建造的建筑和挖开的地形。这里的“无限世界”指在有限运行预算内持续扩展、可重访的世界。当前实现仍有有限地形域；地形现状与目标及扩展验收说明尚需完成的工作。这项扩展服从现有 Package 与持久世界目标。[1]

世界模型研究通过学习得到的表示支持预测与控制。Pajama 提供可执行环境，并为此类模型设计接口。首个集成方向是以引擎状态为条件的学习式视觉输出；学习世界本身的状态转移规则，则是另一项研究能力。[R1]

一个世界，两种表现路径

Pajama 的研发结合传统引擎系统与模型生成表现。引擎维护实体、碰撞、玩法及持久状态；传统渲染让这些状态成为可即时交互的体验；规划中的模型路径将同一状态的同步观测转化为生成画面，候选按任务比较：Wan 优先验证适配与成本，H3 对照条件控制与画质，SANA-Streaming 测试视频转换。[3]

以玩家炸毁一堵墙为例：模拟确定缺口并改变碰撞，持久化保存结果，渲染器呈现对应几何。状态条件视频模型接收由相同几何与相机产生的观测，生成外观；评测再检查生成的缺口是否符合世界状态。这样的分工，为不断演进的视觉系统提供稳定的模拟参照。

从内容创作到持续运行的世界

引擎以版本化内容包作为扩展单位，将资源、可复用对象与有明确边界的行为组织在一起。作者准备内容包，服务器验证并激活，客户端获取匹配资源，恢复流程保存相应的世界与行为状态。这条生命周期让人和 Agent 都能沿着统一路径，将创作转化为世界中持续存在的能力。[4] [5] [6]

平台面向开发多人体验的团队、制作可复用内容的创作者，以及研究交互模型的开发者。长期价值来自同一套世界表示对内容创作、可靠运行与视觉生成的连接。

以下架构说明这套基础如何工作；随后介绍已实现系统与当前集成重点，最后给出通往完整运行时和模型输出层的发展路线。

本文中“AI 原生 MMO”的含义

Agent 可以通过普通授权玩家动作在世界里行动，也可以通过类型化、可审查的 Package 候选为世界创作能力。这两个循环汇合于同一个服务器权威。模型、工具与生成器位于模拟 tick 之外，只有经过准入的能力或发布事务才能产生世界效果。

MMO 表达产品方向：共享历史、持久对象、多方参与和持续内容交付。当前演示证明的是本地多客户端行为，尚未证明生产 MMO 容量、无缝世界分区或公开托管 SLA。第一方游戏 trenchline 是运行时的验证环境；世界模型表现继续作为独立研究路线。[1]

02 · 总体架构

架构连接三项职责：创作内容、运行世界、呈现状态。内容包将作者的修改带入服务器，服务器执行已接受的行为和物理交互，产生供客户端显示、供检查点保存的状态。规划中的模型输出层也接入这一表现边界。

三个协同的系统层面

模拟面拥有运行中的世界，负责实体身份、玩法决策、物理集成与复制。控制与内容面协调已准入的发布、权威租约、不可变对象和持久元数据。表现面将客户端复制状态与已验证资源转换成动画和图像。Rust 负责模拟，TypeScript Edge 原型承担控制与内容协调。[7] [8] [9]

服务器权威与客户端表现的分离，是已有的多人游戏架构选择；Unreal Engine 文档在状态、碰撞和视觉效果之间明确了这类分工。Pajama 将这一边界扩展至规划中的学习式表现服务，同时继续由服务器决定玩法结果。这是架构参考，Pajama 自身的实现依据在下文单独列出。[R2]

这种划分对应不同任务的时间特征：模拟 tick 需要确定的执行顺序，下载可能等待或重试，内容更新可能比发起它的请求活得更久。通过精确身份与有界交接连接这些任务，各部分可以按照自身调度约束推进。图中表示逻辑责任归属，具体线程安排由各子系统分别定义。[10] [6] [11]

模块定义及入口：[12] [13] [14] [15] [16]。

两条流程在权威世界中汇合

正常游玩时，被接受的输入和已安装行为推进世界状态，物理等系统产生派生结果，复制模块向每个客户端发送相关变化。发布内容时，准备好的包候选状态进入 tick 边界激活流程，改变后续玩法使用的定义，以及客户端解析表现时使用的 catalog。两者共同遵循权威生命周期。[8] [17] [18]

两个 Agent 循环，一个提交权威

快速反馈闭环留在原生运行时。远程推理选择有界驾驶动作，服务器控制器使用当前物理反馈；布局搜索留在冷阶段编译器，服务器消费已验证的 prefab。新的轮式车配方可以复用已安装的车辆适配器；全新的原生物理或渲染能力则需要引擎修改和兼容验收，不能靠 Package 任意加载原生代码。

因此需要区分数据与有界行为扩展、已注册原生能力扩展和拟议中的外部模型表现。注明日期的实现文档说明各自边界。MCP 工具与创作 Agent 都不持有第二个世界写入权威。

架构收敛重点

这套架构的优势在于：世界结果有唯一责任方，内容具有精确身份，模型可以沿既有表现边界接入。下一步的工程价值集中在跨系统契约及其验证：先让一个可玩 Package 完整经历发布与恢复，再将同一段世界历史导出为可信的模型输入。[1] [19]

这些是下文 M1–M6 的集成重点；具体实现状态仍以运行证据和各阶段完成标准为准。

03 · 当前进展

1.19 版 · 证据审查日期：2026 年 9 月 25 日。 运行时已有真实物理驾驶、行驶中新增车辆、有界约束建造、真实地形修改、准备式候选发布、并发作者冲突和检查点恢复的录制证据。下方八段新产品短片通过相同的 Package 边界运行，并统一提升了原生画面的资产、灯光与镜头。

架构引用保留核心基线 026acf9（2026-09-12）及各自后续版本。9 月 24–25 日新增能力来自已有未提交引擎工作区，分别保存源码及产物摘要。这是注明时间的集成快照，不能把全部新实现归到一个旧提交中。[19] [20] [21]

当前契约与规划边界集中列于架构证据。

八个实际应用场景

每段短片来自一次独立真实原生运行，包含权威服务器、真实本地 Edge 服务和两个原生观察客户端；发布画面为主相机。场景使用确定性创作配方及普通客户端驾驶输入，没有重新调用实时 Jev 模型。此前实时模型车队演示仍在下方单独标明来源。

视频按 1.0× 采集时间播放，60 fps 编码，时长约 32–42.5 秒。主相机实测 59.772–60.005 fps，各次运行最大记录间隔为 24–63 ms。漏采槽位保留上一帧；恢复演示包含两段录制和明确标注的重启卡片。这些数值描述本地采集工作负载，不代表生产性能 SLA。

原生客户端中的真实运行世界

这座研究站在持续运行的多人世界中逐步建成。版本化 Package 提供可复用结构件、Luau 建造策略与玩家技能，原生渲染器呈现生成的实体、地形、植被和已连接玩家。后文案例沿着同一次运行，展示从空场地到建造与受击破坏的过程。

内容包在共享世界中运行

9 月 21 日演练的原生客户端画面，展示已完成建筑及其所在的可游玩世界。下方记录展示这座建筑逐步形成的过程。

查看原图 ↗

证据来源

原始 1920 × 1080 交换链截图，从 construction/live-build/left_007.png 原样复制。配套公开回执记录相机、采集时间与复制 tick。画面内 FPS 为当时的诊断读数，不作为性能基准。

下载证据文件 1

• station-complete.png ↓图片 · 2.5 MB

  内容包构建完成后的原生客户端：多层建筑、观察塔、地形与两位已连接玩家。

  SHA-256

  694d8465d5118b380758cbfbceb2509b2db839389108bba816062981f1b1c01f

证据清单 ↗

此前的实时 Agent 与生命周期演示

十组独立执行的场景，将实时 Jev 决策、Package 生成、玩家操作、建造、协作创作与恢复连接到实际结果。四车、双车与 Jev 视频保持 1.0 倍原速；Jev 视频分别标注模型往返和服务器回执耗时。后六段原生录像以 1.25 倍速呈现；最后一段明确为生命周期截图证据回放。这些独立演练不代表同一服务器的一段连续运行。请手动播放；源码下载需要兼容引擎仓库及依赖，总指南提供讲解稿与复现命令。

实现与集成依据：[22] [8] [19] [23] [24] [25] [9] [7]。

已有集成结果

9 月 12 日的原生客户端记录使用 A1 → B2 → A3 流程。A、B 表示内容定义，1、2、3 表示连续的部署代次。A3 恢复 A 的定义，但部署历史继续向前。后续运行增加了关闭 HTTPS 源站、利用磁盘热缓存重新加入、故意损坏必需资源，以及恢复到新服务器权威 epoch 等情况。地形场景还对比了同一个检查点中的权威笔刷状态与类型化脚本状态。[23] [24]

这些结果验证了多个生命周期变化之间的连续性：客户端认同精确内容身份，保留实体仍能找到对应资源，恢复过程能够重建记录中的世界与内容组合。后续建造实录进一步包含玩家触发技能和匹配的表现事件回执；完整产品验收需要将这些结果与更新、恢复汇入统一流程。架构基线中的历史表现保留范围是正在使用的版本与紧邻回滚版本，更完整的历史版本管理另行推进。[25] [26] [21]

下一步集成重点

当前重点是按实例生命周期管理保留内容、建立持久观察屏障、稳定 Agent 契约，并通过准备式发布完成创作到玩家的交接。世界模型研发从观测边界开始，逐步扩展至生成表现。发展路线说明这些工作如何衔接。[19] [27]

本版架构记录

准备式创作回执证明了独立脚本发布之外的具体 Package 工作流，使用基础预制体和两个协议客户端。八段原生短片在独立世界中补充表现与应用证据，不能把不同演练拼成一个已经通过的通用生命周期证明。

04 · 设计原则

让稳定语义跨越实现变化

世界的持久身份由文档、稳定实体 ID、精确包引用和权威状态组成。重建物理对象、更换解码网格或重新分配 GPU 缓冲区，都应保留这些身份。分离持久语义与运行时表示，才能在优化执行效率时继续兼容已有存档。[22] [1]

为每次权威修改明确责任方

一个模拟权威负责排列世界变更的顺序。在租约模式中，epoch 标识当前写入者的生命周期，并隔离过期写入者。玩法、发布与持久化因此可以用共同依据判断一次操作是否仍有提交资格，存储与交付服务则在其外围独立扩展。[28] [7]

将发布作为完整生命周期管理

一次可用的内容发布包含验证、授权、激活、客户端交付和恢复。这些阶段分别回答：字节是否合法、目标世界是否有权使用、当前生效哪个定义、客户端能否呈现、服务器能否恢复。显式区分这些状态，使失败可以定位，也让调用者准确理解发布进度。[17] [6] [10]

显式记录资源身份

包版本及其资源摘要决定客户端需要什么，交付地址则可以独立变化。缓存负责验证字节，表现协调器负责公开一组完整兼容的资源代次。异步加载因此可以继续推进，同时准确识别迟到任务及其所属版本。[29] [9]

让扩展行为有边界、可观察

人与 Agent 都需要发现支持的 schema、在明确权限范围内操作并接收结构化结果。沙箱行为读取不可变输入，返回类型化命令。资源预算与校验位于系统边界，使引擎能够在形成运行时矛盾之前，给出可解释的拒绝原因。[30] [14]

05 · 世界数据与对象生命周期

用文档描述世界，用运行时结构执行世界

WorldDoc 保存可序列化世界数据，包括实体和地形。运行时 World 补充索引、变更跟踪与执行所需的生命周期信息。EntityId 在对外契约中识别实体；求解器、ECS 和渲染器内部句柄，则服务于分配它们的子系统。[31] [22] [32]

共享的是语义：存储实体、复制更新和创作操作，指向同一个实体及其组件含义。各系统适合的内存布局则不同。物理需要碰撞结构，渲染需要批次和资源句柄，持久化需要稳定可解释的数据。从明确身份派生这些视图，使存储模型能够独立于逐帧优化演进。[22] [15] [16]

持久化与内容包契约定义了上述区分。[1] [6] [9]

变更跟踪连接修改与复制

World::touch 推进世界级变更序列，并标记完整变化。因此，变更标记表示一次更新在世界修改历史中的位置，而不只是某个实体被编辑了几次。脏状态分类随后为相关客户端安排所需复制工作。[33] [18]

模拟层使用 bevy_ecs 承担存储／调度工作，跨系统执行顺序仍以真实服务器 tick 为准。这允许各子系统逐步采用面向数据的组织方式，同时维持清晰的运行顺序。[34] [8]

06 · 内容包身份与发布流程

内容包究竟标识什么

内容包绑定 ID、精确作者版本和摘要，manifest 引用资源、预制体、行为以及精确依赖。依赖闭包指解释这次发布所需的全部包集合。激活前解析整个集合，可以避免发布结果取决于稍后碰巧找到的某个版本。[4]

多个版本号并存，是因为它们回答不同问题：包格式决定如何解码字节，包 revision 标识作者内容，部署 generation 记录激活历史，行为 ABI 和组件 schema 定义执行／数据契约，catalog 协议决定客户端收到什么。固定旧文档的解码语义，并用显式适配层承接新格式，可以在引擎演进时保留这些含义。[4]

从已审查字节到可用世界能力

当前准备式、带 fencing 的 Package 路径是：冻结源码与预期代次 → 冷阶段暂存精确字节 → 检查候选摘要 → Realm 准入与语义预检 → 准备组合检查点并执行带 fencing 的 head CAS → 核对结果并在权威 tick 激活 → 观察精确 Catalog 与各客户端就绪情况。交互流程图对应这条包含内容交付的路径。[13] [5] [17] [6] [8] [35]

authoring_prepare_package 绑定请求 ID、规范化输入、编译器摘要与目标；authoring_candidate_status 重新校验封存产物清单；authoring_publish_prepared_package 校验指定候选摘要并提交原字节，不重新编译。兼容的一步式发布复用同一实现。准备不改变在线世界，不等于世界准入 dry-run、物理预演或视觉预览。准备式创作契约。

运行器使用有上限的可恢复尝试和不可变提交意图。响应丢失仍属于未知结果：按相同请求和摘要核对或重试，复用既有发布去重。修改候选或预期代次需要新请求。submitted 不代表 active；精确代次已经激活，也不等于每个客户端资产已经就绪。

两位作者同时修改时会怎样

假设两位作者都从部署代次 12 开始准备。如果其中一次发布先推进了代次，另一个请求的基础就已经过期。正确流程是读取新状态，重新判断候选内容是否适用，再提交新的授权请求。这样可以显式处理协作，避免迟到请求悄悄覆盖更新的决定。共享发布服务负责执行代次检查。[17]

当前本地 package_put V1 输入使用组合检查点写入者，但不携带 Delivery Index。带交付信息的发布输入，还需要包含精确资源位置，才能构成完整客户端依赖闭包。路线图分别跟踪输入能力与共享提交机制。[36]

07 · 持久化、恢复与回滚

恢复一个真实存在过的状态

内容定义、执行它的脚本状态，以及产生的世界效果互相关联。如果分别加载每个子系统自己的最新记录，就可能组合出不兼容的时刻。Pajama 用组合检查点，为对应的世界、包／准入和可恢复脚本状态提供统一恢复根。协调器负责捕获、不可变对象准备、head 比较交换与结果核对。[6] [37]

检查点 head 是已提交引用，用于选定恢复所使用的持久快照。准备或上传另一个快照，并不会自动推进这个引用。区分对象准备与 head 提交，既为重启提供明确起点，也使中断后的写入者能够判断自己的精确候选是否已成为权威结果。[38] [37]

本地运行与租约运行

在本地进程模式下，一个存储实例在服务器生命周期内拥有目录与操作系统锁。不可变对象和不含 epoch 的本地 head 组成恢复命名空间。已提交状态优先于作者提供的初始数据，数据损坏则作为恢复错误报告。[38] [39]

在租约模式下，权威绑定世界／分片／服务器主体与 epoch。Epoch 标识一次写入者生命周期；替代权威获得新的 epoch，存储和协调层便可拒绝前任发出的操作。Edge 原型串行协调租约与 head 决策，Rust 服务器执行模拟。[28] [7]

回执丢失也是一种需要处理的状态

存储操作可能已完成，但响应在网络中丢失。此时协调器比较观察到的 head 与保留的精确基础、候选状态：匹配候选表示预期写入已提交；基础未变化可以进入规定的重试路径；第三种状态、缺失或损坏则需要进一步核对或失败处理。结果不确定期间，系统仍保留准备操作的所有权，使调用者能够依据状态作判断。[38] [37]

回滚仍然沿着部署历史向前

这个例子区分内容版本与部署历史。恢复 A 时，可能需要把当前类型化行为状态迁移到 A 的契约。已经提交的世界效果仍然保留；要修改它们，必须执行独立授权的迁移或补偿命令。这样可以保留玩家历史，同时改变后续行为采用的定义。[1] [40]

当前历史表现保留 active 与紧邻 rollback 两个一致快照。M2 将进一步处理历史实例策略、恢复来源保留和持久垃圾回收。[26]

为持久实例声明演进策略

M2 将把产品契约中的 pin／rebase 选择落实到每类 Package 实例。Pin 保留创建时的精确版本及资源；rebase 按已验证策略采用新定义，涉及状态变化时，必须声明源／目标 schema、类型化迁移及回滚兼容性。预检失败不能留下部分迁移结果。[1] [14]

例如，修改墙体的默认生命值，需要明确现存受损墙体继续使用旧规则，还是按指定转换保留受损程度。该决定不能由重新下载资源或重建物理对象隐式作出。资源回收也必须保留存活实例及受支持恢复点仍引用的版本；A1 → B2 → A3 后的重启与清理测试将检验这项契约。[26]

可见状态与持久状态是两种观察

普通世界变化可能先被客户端看见，随后才进入周期检查点。新恢复夹具读取带 fencing 的检查点 head，验证引用 blob 的摘要与长度，并确认 15 个场景实体的身份和变换后才停止权威进程；新客户端在 epoch 2 观察到相同场景。仅有截图或 Package 的 active 回执，不能证明后续建造已经存盘。

正式支持的持久观察屏障仍是优先项：调用方应能把所需世界结果关联到持久切片，无须检查内部存储。临时驾驶会话和意图不进入检查点；恢复保留车辆／道路内容引用，但必须重新授权并读取新观察。演示不宣称驾驶员自动续接。恢复证据。

08 · 内容交付与客户端就绪

从创作内容到画面，需要三种身份

包引用标识作者定义，内容摘要标识所需字节，表现代次标识某个客户端当前公开的一组兼容资源。分别记录三者，才能在更换下载位置、复用验证缓存或重建 GPU 资源时，继续指向同一份作者内容。[4] [29] [9]

客户端链路为：catalog → Delivery Index 与文档 → 有界下载 → 验证后的内容寻址缓存 → CPU 解码 → 不可见 GPU 暂存 → 完整表现代次。Delivery Index 为选中包闭包提供精确资源描述；只有属于当前选择状态的资源，才能推进这次选择的就绪进度。[10] [41] [9]

每个阶段分别判断完成

这些责任边界已经体现在缓存、解码器与表现协调器中。[29] [41] [9] [42]

字节上限、队列容量、并发和时间预算限制加载工作量。迟到响应仍绑定到发起请求时的选择状态；缺失资源使用有界诊断占位，终态失败可以观察。导入资源未命中时，也不会误用无关的旧形状。[10] [43]

原子发布作用于每个客户端自己的资源集合。不同客户端可以在不同时间完成加载，随后收敛到相同内容身份。服务器继续独立决定物理和玩法结果，不以某台客户端的网格是否加载完毕为依据。[9]

已有热缓存离线实验和定向损坏测试验证了这种分离。常规 Catalog V2 开放仍等待更完整的生命周期与历史保留工作完成。[23] [9]

旧资源可见性与新版本就绪分别管理

此前车辆变粉的回归暴露了生命周期耦合：旧 GPU 资源仍然存在，但精确保留授权要等后继版本 hydration 完成，解析器才能使用。修复后，已持久准入的精确保留授权可以维持已验证驻留资源可见；新资源代次仍须完整校验及暂存。查找不会退回不同版本的模型或材质。四客户端证据。

更广的生命周期问题仍然存在：第三次替换可能使旧存活 GLB 的来源落到 active／previous catalog 联集之外，此时引擎会正确拒绝发布；该次替换之后发布无关包也可能触及同一限制。新扩建演示保持核心 A1 不变，单独演进扩展包 B1 → B2。这是现有范围内的有效工作负载，不代表任意历史版本问题已解决。

下一步需要有预算的保留内容闭包，以存活实例、行为状态、支持的恢复／回滚切片及在途工作为根，并验证回收过程。新字节交付、定义激活和实例迁移始终是不同决策。当前架构发现。

09 · 模拟、物理与地形

执行顺序也是模拟契约

Tick 先获得权威操作，在拿到共享世界状态后再次核验。待发布内容包在边界激活，已安装脚本先于后续物理／姿态处理和最终复制运行。因此，内容切换与使用该内容的玩法之间有明确先后关系。[8]

这一顺序也处理等待中的状态变化：请求开始时有资格执行，等待锁期间却可能失效。在即将推进权威状态的位置重新核验，可以识别这种情况。[8]

物理拥有独立接口与时间策略

Physics 隔离求解器专用表示。Rapier 是默认实现，Box3D 保留为兼容实现。Box3D world 由专用线程拥有，默认 Rapier 路径则直接执行。两者遵守接口，同时保留各自数值行为。[15] [44]

Rapier 使用 4 ms 内部子步，每次调用最多推进 16 步；达到上限后丢弃剩余累计时间。这限制了一次卡顿之后的补算工作量，以部分经过的模拟时间为代价，避免恢复工作持续阻塞实时响应。评估该取舍时，需要一起观察错过的 deadline、物理表现和服务器耗时。[45]

一次地形修改有多个使用方

地形修改通过共享入口更新权威文档、标记碰撞数据失效，并产生相应因果事件与网络更新。渲染和碰撞从该状态派生各自表示，因此分别拥有就绪生命周期。画面出现新表面，只能说明对应表现已经更新，碰撞重建还需要自己的完成证据。[46]

已记录的内容包地形场景验证了客户端与恢复检查点之间的笔刷／状态一致性。几何碰撞精度和玩家技能表现，则分别需要专门验收。[24] [25]

复制系统对变更分类，并应用兴趣范围预算；客户端移动预测改善响应速度，再根据权威回传校正。这些机制需要放在一起理解：模拟耗时决定真值何时推进，复制决定客户端何时得知变化，预测决定等待期间如何呈现。[18] [47]

动态载具与持续驾驶

四轮组件声明车身尺寸与质量、车轮位置／半径、悬挂刚度与阻尼／行程、加速度、转向以及精确车身／车轮资产。每个实例持有物化配方和 Package 引用；新定义影响后续实例，行驶车辆不会默默换质量、碰撞或车轮几何。Rapier 提供车身物理、射线车轮、悬挂、力与碰撞，转向及稳定辅助服务于可玩的越野驾驶，不作为汽车工程模型。车辆与驾驶契约。

Jev 从有界观察中选择带期限的动作，原生服务器控制器完成反馈闭环。会话身份包含权威 epoch、驾驶员、车辆 incarnation 和相关内容引用。观察过期、意图超时、控制权丢失或碰撞未就绪，需要重新观察或制动。实时车队视频中四个 Jev 驾驶，第五个选择地形技能攻击；Package 发布由录制运行器编排，视频没有证明两个 Jev 分别自主创作了新车。

修改地形，同时保持无关车辆前进

爆炸卡顿的一部分根因在服务器调度：Accepted 与终态持久化切片曾等待整个模拟，车辆会同时停住，即使客户端仍在渲染。对于隔离的纯地形技能批次，引擎现在保留当前可用地形，同时准备私有候选和持久组合切片。移动与复制继续使用旧地形，效果在激活前保持私有。

最多四个受影响碰撞块可以在后台与持久化并行准备，精确来源指纹绑定派生结果。到 tick 边界后，持久提交与派生结果就绪共同允许安装碰撞、发布地形并释放回执／特效。混合实体／伤害批次仍保留较广的等待边界，更大的地形批次使用有预算的流送回退。这是有本地实测依据的具体延迟修复，不代表任意编辑都绝无卡顿。实现与连续驾驶测量。

新桥梁场景把挖掘地形、安装桥面碰撞与普通控制车辆过桥串起来；地形训练场另外检查双方一致的笔刷及新碰撞安装确认。粒子爆炸本身不能证明存在物理坑洞。

当前地形为何仍有边界

当前引擎尚未实现可持续扩展的无缝世界。 对 d96cddf 的源码核对显示，TerrainParams.extent 是 X/Z 方向的可玩半边长；引擎默认值为 250 米，即 500 × 500 米的正方形域。参数校验接受 64–4,096 米的半边长范围，这是配置上限，不是已测容量。具体演示实例可以采用其他配置。[48] [49] [50]

服务器移动路径把坐标限制在 ±extent 内，物理地面调度也按该范围限制 tile 键。因此，分块加载已经存在，但它服务于有限世界。单独放大 extent 仍留下有限域和更大的资源需求。[51] [52]

可见边缘需要分三层判断：世界域边界决定可以到哪里；驻留／可见范围决定当前加载和显示哪些块；持久化范围决定离开后什么还能恢复。看到截断地平线本身不足以定位是哪一层。验收应记录实际相机、世界参数、渲染块与碰撞块，分别修复硬边界、远景缺失及流送迟到；雾效与远景只能改善表现。

2026 年 10 月更新： 上述数值保留其历史源码核对日期；本轮新增的 40 公里地形远景扩展的是视觉驻留范围，未宣称消除可玩域、碰撞或持久化边界。

持续扩展世界的目标契约

以下是待实现的设计要求，尚无无限地形验收记录：

这些要求延续地形的统一修改入口及内容恢复契约。存档保留的是已接受的世界事实；原生远景、生成画面与缓存都从它派生。[46] [6] [53]

World Labs 的 Spark 2.0（2026-04-14）展示了视点相关 LOD、渐进流送和固定 GPU 页池。Pajama 可借鉴其按视图管理驻留的方式；该资料研究 3D Gaussian Splatting 渲染，不提供本引擎的可破坏地形、碰撞或存档实现。[R3]

10 · 渲染与动画架构

提取渲染真正需要的状态

RenderSnapshot 向渲染器提供相机、实例及其他渲染相关状态，模拟和网络仍拥有自己的数据。这样，渲染器可以调整批次、资源布局或 GPU 执行方式，同时保持世界修改职责清晰。[16] [11]

Bevy 从主世界只读提取数据至渲染世界的方式，提供了相关架构参考。对 Pajama 而言，这支持在普通渲染之外设置独立的观测提取器：模型适配器消费已捕获的视图，不持有可修改模拟状态的访问权。[R4]

在逐帧执行前编译配置

渲染架构依次区分版本化管线文档、字段与拓扑验证、类型化资源依赖编译，以及不可变已编译管线的执行。例如，一个 pass 使用某项资源时，需要存在兼容的生产方和明确顺序；这些关系应在帧执行器使用计划之前完成验证和编译。[11] [54]

代码提供已注册 GPU 能力，数据负责组合与配置。创作接口因此有明确词汇，性能敏感的执行实现也能保持专用优化。内容包发布继续遵循自己的准入边界；更广的渲染器配置与内容包权限是需要分别管理的接口。[11] [1]

按资源代次管理替换与回收

包资源完成 CPU 解码与 GPU 暂存后，协调器才公开完整代次。导入资源采用渲染器自己拥有的身份，而不借用旧资源名称。表现切换时按身份退休资源，避免新选中的内容包意外查询到上一代分配的对象。[9] [42]

复制动画意图，在客户端计算姿态

动画把权威意图与客户端骨骼求值分开。服务器可以决定实体动作或动画意图，客户端则采样和混合当前帧需要的姿态。这样，玩法决策能够跨客户端保持一致，而每个渲染器仍按自己的帧率求值。[55]

渲染快照、已编译管线和资源代次共同定义后续演进方式：在稳定输入之后增加渲染能力，测量其成本，并继续满足内容交付依赖的生命周期规则。

最新渲染进展与证据

截至 2026 年 10 月 1 日，原生渲染已把清澈湖水、岸边泡沫、距离自适应云细节、天气、水下光学与 40 公里地形远景接入现有渲染管线。下面的图片均为引擎输出的原始截图；功能验证、画面比较和性能测量分别保留各自的范围。源码依据固定到 e2134b8 所在的记录版本，运行证据另行标明实际构建与配置，包含 UTC 10 月 2 日的测量记录。[56]

水面、岸边泡沫与云的细节

水面现在使用两组有界的 128×128 GPU 逆 FFT 斜率场。远处无法解析的小波纹转化为反射粗糙度中的方差，长波、河流和交互涟漪继续沿已有路径工作。湖水输运同时考虑入射和出射光的衰减，并使用斯涅尔折射与介质菲涅耳反射，让浅处可见湖底、深处逐渐吸收光，而不是仅靠更换水色获得深浅感。[57] [58]

岸边白水按波浪拍岸、回流和衰减分布；孔洞及大尺度断续区域避免形成一圈均匀白边。泡沫覆盖在已照明的水面之上，斜视时仍可见，间隙中保留天空反射与太阳高光。它是有界的实时表现近似，不是岸边流体求解器。[59]

清澈湖水与断续岸边泡沫

岸边泡沫细化前后的相同机位画面。

查看原图 ↗

查看原图 ↗

证据来源

原始 1280×720 原生渲染 PNG。湖泊、配置、机位与时间一致；该测试场景省略厨房道具及角色。这是画面对照，不是完整玩法帧率测试。

下载证据文件 3

• render-shore-before.png ↓图片 · 1.2 MB

  之前：原岸边泡沫。

  SHA-256

  880ea3cbd113e0e50bc19e123c2cdae3b063896d875097457f2fb5e25fb914f6
• render-shore-after.png ↓图片 · 1.2 MB

  之后：泡沫覆盖在水面反射上方，岸线保留大尺度间隙。

  SHA-256

  31d437f161bf70d945bc1be50ba8b94d5520949c0d68a7a416e04ad751699d91
• render-progress-proof.json ↓数据 · 26.6 KB

  六项渲染记录的公开测量回执、原图／来源哈希与明确测试范围。

  SHA-256

  e0ea9e1825d8bba0d33c4e7a0e4e89542243f9f5d8b745eb88a77a07a12f6739

证据清单 ↗

云细节按距离、视角和实际投影得到的像素足迹过滤。远处逐步收敛到噪声的平均侵蚀量，避免直接关闭侵蚀后把云的凹槽重新填满；窄视场也保留其像素确实能分辨的细节。三个固定视角中，640×360 与 1280×720 缩小结果之间的平均 RGB 误差下降约 49.7%–64.2%。这衡量分辨率一致性，不是写实评分，也不构成优于 Tidewater 的整体结论；局部条带与棉絮状结构仍有改进空间。[60]

云细节随像素足迹变化

窄视场地平线的相同机位截图，展示远处云结构变化。

查看原图 ↗

查看原图 ↗

证据来源

原始 1280×720 原生 PNG，垂直视场角 30 度。天气、曝光和配置固定；数值对照衡量分辨率一致性，不代表整体写实程度或优于其他渲染器。

下载证据文件 3

• render-cloud-before.png ↓图片 · 631.3 KB

  之前：原云细节过滤。

  SHA-256

  08cf9436ec4419f6bf0ce9aa8dc935ccaacb3e5da543afc3fe782421b7895110
• render-cloud-after.png ↓图片 · 610.4 KB

  之后：考虑投影并保留平均侵蚀量的细节过滤。

  SHA-256

  da303878fc7bca83ee061e6b0e5067d78ebd2876653e4cfd569d7044709137f1
• render-progress-proof.json ↓数据 · 26.6 KB

  六项渲染记录的公开测量回执、原图／来源哈希与明确测试范围。

  SHA-256

  e0ea9e1825d8bba0d33c4e7a0e4e89542243f9f5d8b745eb88a77a07a12f6739

证据清单 ↗

风、雨、雪与雷电的共同天气状态

天气支持晴、多云、阴、雾、雨、雷雨、雪和暴风雪，可自动演变，也可手动从当前状态平滑切换。服务器提供共同天气时钟；风影响云层位移、植被、水波和降水。雨产生落地／落水涟漪与湿润表面，雪逐步积累并融化；静态屋顶遮蔽近处降水。闪电的固定空间光源同时作用于云、雾、地表与水面，雷声按距离延迟。所有控制仍沿既有的版本检查与渲染发布路径进入。[61]

降水与闪电有明确预算，新增细化复用现有 pass；湿地水洼、遮蔽和云内闪光使用实时近似。当前证据验证环境表现与声音逻辑，不包括雷击伤害、洪水、结冰碰撞或风力推动权威物体。[61]

同一湖泊中的天气变化

雷雨与雪景展示天空、水面和降水的共同变化。

查看原图 ↗

查看原图 ↗

证据来源

来自天气细化记录的原始 960×540 原生 PNG。两图是不同天气预设，不是同条件 A/B；静态图片不证明声音效果、玩法伤害或帧率保证。

下载证据文件 3

• render-thunderstorm.png ↓图片 · 629.3 KB

  雷雨：闪电与受风影响的湖面。

  SHA-256

  ce92ec45ec143f7e974504fd86837022136ae1797175dc583501250ba751eb53
• render-snow.png ↓图片 · 597.2 KB

  雪：飘落降水与地表积雪。

  SHA-256

  828e711d97f4476493ccf75598049aee7ebe291d7a8420aed46515570040d830
• render-progress-proof.json ↓数据 · 26.6 KB

  六项渲染记录的公开测量回执、原图／来源哈希与明确测试范围。

  SHA-256

  e0ea9e1825d8bba0d33c4e7a0e4e89542243f9f5d8b745eb88a77a07a12f6739

证据清单 ↗

从水面进入水下

水下效果根据已发布的实际水面三角形与局部水深判断相机是否在水中，排除湖底以下的干燥位置。体积输运复用水节点，使用四段照明／阴影采样，呈现随距离变化的吸收与散射、近似焦散，以及向上看时的斯涅尔窗口和全反射。它保持已有场景运动与时序响应，不给渲染器增加模拟权限。[62]

RTX 4090 / DX12、960×540 的六视角对照中，新增水下工作的水节点中位耗时增量为 0.115–0.180 ms；水面上方启用／禁用该功能的 RGB 像素完全一致。另有 1,440 个 GPU 数值案例和 forward 路径检查。该记录不包含完整多次散射、流体模拟、游泳玩法或水下音效，也不是浏览器／移动设备帧率保证。[62]

水下输运与水到空气的界面

既有厨房湖泊中的湖底与斯涅尔窗口视角。

查看原图 ↗

查看原图 ↗

证据来源

来自六视角光学验收的原始 960×540 原生 PNG，场景仅隔离水与地形。焦散为实时近似，游泳和水下音效不在本次改动范围。

下载证据文件 3

• render-underwater-bed.png ↓图片 · 418.7 KB

  湖底视角：衰减、散射与近似焦散。

  SHA-256

  9551d647c1e534a3f3acd541682a777d93645f705ef11b15c42274b56bc0cb10
• render-underwater-snell.png ↓图片 · 412.6 KB

  向上视角：斯涅尔窗口内折射的天空与窗口外的反射。

  SHA-256

  f4e149b8decdf4950a7b98e502f7e8a78038ab5b406deea8752d5b572418c4c8
• render-progress-proof.json ↓数据 · 26.6 KB

  六项渲染记录的公开测量回执、原图／来源哈希与明确测试范围。

  SHA-256

  e0ea9e1825d8bba0d33c4e7a0e4e89542243f9f5d8b745eb88a77a07a12f6739

证据清单 ↗

40 公里视觉远景与流送预算

地形采用近处精细、远处分层变粗的网格与异步生成；相邻层级接缝、反向相机深度、旧布局保留和完整新布局的发布共同支撑远景。40 公里描述地形的视觉驻留范围，不是同样范围内的米级模拟、植被驻留或无缝 MMO 世界。 地形编辑仍进入同一权威入口，碰撞失效、脚本空间事件和网络观察随该编辑更新。[63] [46]

同一原生渲染测试中，视距从 4 公里增至 40 公里，分层 patch 从 984 增至 1,202，CPU 网格字节增加 8.4%；近处 1 米层保持 528 个 patch，地形与草 GPU arena 分配保持约 704 MiB。另一个异步流送测试的冷启动约 13.8 秒，移动 64 米后的布局阶段约 6.25 秒，阶段时间包含约一秒稳定采样。远景已可见，但这些数值仍显示冷启动和移动生成的后续优化空间，不能据此宣称高速移动全程无等待。[63]

4 公里与 40 公里的地形驻留

相同世界与高空机位展示多分辨率地形的可见范围。

查看原图 ↗

查看原图 ↗

证据来源

原始 960×540 原生 PNG，机位高度 8 公里。距离扫描在同一程序中仅改变地形视距；它展示视觉覆盖范围，不证明可玩域大小或实时移动性能。

下载证据文件 3

• render-horizon-4km.png ↓图片 · 318.3 KB

  高空机位下的 4 公里地形视距。

  SHA-256

  6e3a0d5b66c41c4d5eeaa8afb54be4513dea0272b847aab17370a2786a757b69
• render-horizon-40km.png ↓图片 · 606.1 KB

  采用远处分层粗网格的 40 公里地形视距。

  SHA-256

  8ee90de99f39a91e26b157de0e0b4726b027b51a557b488aec8f328deff123f5
• render-progress-proof.json ↓数据 · 26.6 KB

  六项渲染记录的公开测量回执、原图／来源哈希与明确测试范围。

  SHA-256

  e0ea9e1825d8bba0d33c4e7a0e4e89542243f9f5d8b745eb88a77a07a12f6739

证据清单 ↗

四开性能：先确认真正运行的配置

最近一次厨房四客户端记录约为 23 FPS／窗口。日志显示旧客户端拒绝了 40 公里配置，实际停在引擎默认 revision 0，未应用服务端请求的 revision 35。默认草地和草地阴影显著增加了每窗口工作量。配套更新两端后，使用同一套新二进制、相同镜头与场景，分别重建旧回退配置并加载现有作者配置 revision 36：[56]

条件为 RTX 4090、DX12、每窗口 960×540、60 FPS 上限、固定镜头与冻结视觉时间，预热 20 秒、采集 20 秒。FPS 取约 19.5 秒的全部呈现帧，包含截图帧；PNG 采样仅为 2 Hz。四开正确配置共复核 4,501 帧，帧间隔 p90 均小于 17.9 ms。GPU 列取各窗口中位数，并发时间戳包含调度影响。该构建含已记录的并行任务未提交代码，两组实验使用同一构建；它与此前动态厨房录制不是同一次运行。[56]

正确配置保留 40 公里远景、当前水／云和水下支持，没有追加后台限帧或降低输出分辨率。录制就绪条件现在要求应用成功且实际版本等于请求版本，避免再次把回退画面当成正常结果。这证明了当前固定场景的改进，不等于任意战斗、移动流送或长时四人游戏都已通过 60 FPS 验收。下一步继续验证移动连续性、低内存设备、浏览器表现和完整玩法负载。[56]

应用正确作者配置的四客户端

两组四开控制实验中的窗口 0：重建旧回退配置与作者配置 revision 36。

查看原图 ↗

查看原图 ↗

证据来源

原始 960×540 窗口呈现 PNG。两组使用相同新版二进制、固定机位、冻结视觉时间和 60 FPS 上限。公开回执保留完整帧统计、构建哈希及含并行未提交代码的构建来源。此为短时静态实验，不是长时完整玩法验收。

下载证据文件 3

• render-four-fallback.png ↓图片 · 914.3 KB

  重建回退配置：高开销的默认草地和阴影。

  SHA-256

  2ec5188857a943249defcfe52fc16c0a4b1980d00568bb5b1179bf25427a2502
• render-four-authored.png ↓图片 · 1.1 MB

  作者配置 revision 36：保留 40 公里远景和当前水／云设置。

  SHA-256

  ce29b635406a9d8692afaec8a0fee987599f35b11a351e2e774c5bf07c112be1
• render-progress-proof.json ↓数据 · 26.6 KB

  六项渲染记录的公开测量回执、原图／来源哈希与明确测试范围。

  SHA-256

  e0ea9e1825d8bba0d33c4e7a0e4e89542243f9f5d8b745eb88a77a07a12f6739

证据清单 ↗

11 · 人与 Agent 的创作流程

发现所连接运行时的真实契约

Registry 描述受支持命令与组件，MCP 基于契约暴露限定范围工具，并通过实时发现识别当前服务器实际接受的能力。默认 scope 为只读 core,scripting,content，写 scope 由操作者显式选择。编译进工具的 registry 可用于离线查看；实时调用则要求重新验证运行时契约。[64] [65] [30]

这对长期维护的项目很重要：创作工具和世界服务器可能在不同时间升级。能力发现使工具能够选择受支持操作、理解预算，并在尝试修改前报告不匹配。

MCP 规范工具发现、输入 schema 与调用方式；世界自身的授权、事务语义和资源限制，仍由引擎及其宿主负责。因此，Pajama 将工具连接到既有的准入与发布规则。[R5]

让生成行为可以检查

Luau 读取不可变帧，并返回由 host 检查的类型化命令。可恢复 ABI2 还显式描述行为状态：初始化、迁移和执行都跨越有预算的类型化边界。恢复过程因此可以把行为状态与精确代码产物、世界效果绑定，而不依赖不可解释的 VM 堆。[14]

Luau 的沙箱指南支持限制暴露的库与隔离脚本，同时将内存限制、中断机制和宿主 API 的安全性交给嵌入它的应用负责。Pajama 的类型化命令与执行预算约束这一宿主边界；语言沙箱本身并不能确立玩法权威。[R6]

Agent 通过与人工工具相同的受限接口提出内容和行为，引擎负责准入、版本检查、执行预算及权威效果。这是项目中 AI 原生创作能力的具体含义。[1] [14]

单次脚本预算约束一次执行，持续创作还需要控制累积结果。M5 计划补齐按包及世界统计的存活实例、持久状态字节与待处理工作预算，并在提交类型化命令时预留和核对。额度不足应返回可归因的拒绝结果；配额记账需要覆盖删除、迁移和恢复。验收将让低频持续建造运行到预算边界，并验证多个包共享世界时仍受总量约束。[14] [1]

约束生成是一条编译流水线

LayoutSpecV1 → 有界搜索 → 独立校验布局 → 普通 Prefab → 准备式 Package。当前语言使用整数网格，强制边界和不重叠，并支持邻接、间距、组连通和禁建矩形。编译器身份、规格摘要、种子与精确位置属于创作来源信息；恢复直接加载已提交结果，不重新运行求解器。

当前上限为 64 × 64 网格、32 个节点／原型、128 条规则和 1,000,000 次候选放置尝试。BudgetExceeded 表示搜索未完成；Unsatisfiable 表示有限搜索空间已穷尽。声明占地并不能证明任意模型净空、可行走性、结构稳定性或实时地形支撑。营地演示针对自己的资产集合补充了占地净空检查。生成契约与原生应用。

后续按领域分别加入类型化硬约束、软目标、预算和有用诊断，优先解决地形支撑、净空、可达性与道路坡度。依赖世界状态的输入需要绑定快照，并在实际放置前由权威端重查前置条件。昂贵求解留在模拟锁之外。这是一条可扩展的编译路线，不宣称一个通用 DSL 已解决所有生成系统。

将观察结果纳入操作流程

已有脚本 author runner 会发现实时 ABI，将请求命令与操作者权限上限求交，执行 dry-run，通过 revision 检查发布，再以新连接验证持久激活。当前准备式 Package 运行器已经补充冷阶段准备、精确候选发布与权威核对；预演、持久编排和完整生命周期验收仍属于 M5。[66] [67]

网络响应丢失会产生显式状态：not_sent 可以进入安全自动重试，outcome_unknown 则需要观察与核对。视觉捕获提供另一类证据：原生无窗口渲染帧能暴露占位或表现错误，权威查询验证状态，恢复测试验证持久化。有用的审计记录会将这些观察绑定到同一个发布身份。[68] [69]

当前准备式运行器关联候选和发布身份；更完整的集成契约还需要用操作身份与候选摘要，关联权威生命周期、预期／实际部署代次、激活 tick、持久检查点，以及各客户端的 catalog／资源就绪回执。已接受、已激活、已持久化、客户端已就绪分别回答不同问题，trace 会保留每一步的结果及缺失证据。超时后查询同一操作的结果；任何重试仍须通过既有的去重与版本检查。激活后响应丢失、持久化前中断及一个客户端延迟就绪，将成为故障验收场景。Package 持久激活的回执，也不能替代随后玩法结果的恢复验证。[17] [6] [67]

Agent 创作并激活一个新行为

9 月 21 日的一次新运行中，AI Agent 读取实时脚本契约，编写了有明确边界的三阶段救援平台组装行为。记录工具通过引擎 WebSocket 管理接口发现能力、执行 dry-run、携带版本检查发布同一候选，再从新连接查询结果。保留的 trace 包含实际请求与响应，也提供本次生成的 Luau 源码。

观察结果依次为 0、1、2、3 段已组装平台。运行时记录 3 批已提交命令、共 6 条命令、零故障、零宿主拒绝。激活产物与预检摘要匹配，内存与持久化部署代次均为 2，disk_state: exact。这些记录验证了本次创作行为的实际执行及持久激活。

{"schema_version":1,"seq":5,"at":"2026-09-21T13:47:13.855Z","kind":"request","phase":"describe","request":{"cmd":"describe"}}
{"schema_version":1,"seq":6,"at":"2026-09-21T13:47:13.861Z","kind":"response","phase":"describe","response":{"ok":true,"data":{"engine":"pajama-engine","version":"0.1.0"}}}
{"schema_version":1,"seq":7,"at":"2026-09-21T13:47:13.862Z","kind":"request","phase":"script_describe","request":{"cmd":"script_describe"}}
{"schema_version":1,"seq":8,"at":"2026-09-21T13:47:13.865Z","kind":"response","phase":"script_describe","response":{"ok":true,"data":{"runtime_mode":"process_local_abi1","command_contract_v2":{"commands":[{"kind":"set_data_number","capability":"entity_data"},{"kind":"build_prefab","capability":"build"}]}}}}
{"schema_version":1,"seq":9,"at":"2026-09-21T13:47:13.866Z","kind":"request","phase":"script_status","request":{"cmd":"script_status"}}
{"schema_version":1,"seq":10,"at":"2026-09-21T13:47:13.868Z","kind":"response","phase":"script_status","response":{"ok":true,"data":{"runtime":{"active":null},"deployment":{"enabled":true,"disk_state":"exact","generation":0}}}}
{"schema_version":1,"seq":11,"at":"2026-09-21T13:47:13.869Z","kind":"request","phase":"target_discovery","request":{"cmd":"query","tag":"agent-proof-controller","limit":1}}
{"schema_version":1,"seq":12,"at":"2026-09-21T13:47:13.871Z","kind":"response","phase":"target_discovery","response":{"ok":true,"data":{"count":1,"entities":[{"id":1,"name":"rescue-assembly-controller","data":{"assembled_sections":0}}]}}}
{"schema_version":1,"seq":13,"at":"2026-09-21T13:47:13.872Z","kind":"request","phase":"prefab_discovery","request":{"cmd":"prefabs"}}
{"schema_version":1,"seq":14,"at":"2026-09-21T13:47:13.873Z","kind":"response","phase":"prefab_discovery","response":{"ok":true,"data":{"prefabs":[{"doc":"One bounded rescue-platform section.","entities":1,"name":"rescue-span"}]}}}
{"schema_version":1,"seq":15,"at":"2026-09-21T13:47:51.953Z","kind":"authored_candidate","goal":"Author and publish a new bounded Luau rescue-platform mechanic from the live runtime contract; observe three typed build steps and a controller counter.","command_ceiling":["build_prefab","set_data_number"]}
{"schema_version":1,"seq":18,"at":"2026-09-21T13:47:51.958Z","kind":"request","phase":"dry_run","request":{"name":"ai-rescue-platform","revision":1,"tick_interval":20,"capabilities":["build","entity_data"],"cmd":"script_put","expected_revision":0,"expected_active_artifact_digest":"","expected_deployment_generation":0,"dry_run":true}}
{"schema_version":1,"seq":19,"at":"2026-09-21T13:47:51.962Z","kind":"response","phase":"dry_run","response":{"ok":true,"data":{"dry_run":true,"revision":1,"source_hash":"4b0a8d45998eac26","artifact_digest":"13c449bb0780d769898656cd22a78eb4573f2501b256402f121a7bb67aef29c6","bytecode_bytes":521}}}
{"schema_version":1,"seq":20,"at":"2026-09-21T13:47:51.962Z","kind":"request","phase":"publish","request":{"name":"ai-rescue-platform","revision":1,"tick_interval":20,"capabilities":["build","entity_data"],"cmd":"script_put","expected_revision":0,"expected_active_artifact_digest":"","expected_deployment_generation":0,"dry_run":false}}
{"schema_version":1,"seq":21,"at":"2026-09-21T13:47:51.973Z","kind":"response","phase":"publish","response":{"ok":true,"data":{"dry_run":false,"revision":1,"source_hash":"4b0a8d45998eac26","artifact_digest":"13c449bb0780d769898656cd22a78eb4573f2501b256402f121a7bb67aef29c6"}}}
{"schema_version":1,"seq":23,"at":"2026-09-21T13:47:51.975Z","kind":"response","phase":"observe_progress","response":{"ok":true,"data":{"count":1,"entities":[{"id":1,"data":{"assembled_sections":0}}]}}}
{"schema_version":1,"seq":47,"at":"2026-09-21T13:47:53.033Z","kind":"response","phase":"observe_progress","response":{"ok":true,"data":{"count":1,"entities":[{"id":1,"data":{"assembled_sections":1}}]}}}
{"schema_version":1,"seq":65,"at":"2026-09-21T13:47:53.831Z","kind":"response","phase":"observe_progress","response":{"ok":true,"data":{"count":1,"entities":[{"id":1,"data":{"assembled_sections":2}}]}}}
{"schema_version":1,"seq":89,"at":"2026-09-21T13:47:54.892Z","kind":"response","phase":"observe_progress","response":{"ok":true,"data":{"count":1,"entities":[{"id":1,"data":{"assembled_sections":3}}]}}}
{"schema_version":1,"seq":93,"at":"2026-09-21T13:47:54.896Z","kind":"response","phase":"activation","response":{"ok":true,"data":{"runtime":{"active":{"artifact_digest":"13c449bb0780d769898656cd22a78eb4573f2501b256402f121a7bb67aef29c6","bytecode_bytes":521,"capabilities":["build","entity_data"],"name":"ai-rescue-platform","revision":1,"source_hash":"4b0a8d45998eac26","tick_interval":20},"metrics":{"commands":6,"committed_batches":3,"committed_commands":6,"consecutive_faults":0,"faults":0,"host_rejections":0,"last_committed_tick":820,"last_run_us":53,"max_run_us":235,"memory_bytes":649784,"runs":3}},"deployment":{"disk_state":"exact","generation":2,"persisted_generation":2}}}}

本次运行使用独立 ABI1 脚本发布接口，局部进度变量尚不构成重启续跑证据。下方 Package 案例验证版本化内容及包内行为；将 Agent 创作接入完整内容生命周期，是 M5 的工作方向。[66] [67]

12 · System 1 与 System 2：Agent 分工、协作与接入

Pajama 将 Agent 分成两类工作角色：System 1 从现有能力中选择下一步，System 2 规划任务并创作新的能力。 两者通过版本化 Package、有限的玩家意图和可核对回执协作。这里的 System 1／System 2 是工程分工，不是对模型内部认知机制的判断，也不承诺固定推理速度。当前 System 1 接入采用 Jev；System 2 以 Codex 和其他可调用工具的规划 Agent 为接入方向。[70] [R7]

两类 Agent 分别能做什么

当前 Jev 适配器最多配置八个技能，额外保留 wait 和 plan。它不会生成 Luau、发明技能或理解完整画面。更广泛的 NPC 战术、技能排序和目标选择可以另行扩展，但需要独立的输入契约与验收。System 2 的能力也受已连接工具和授权范围限制；“能写出代码”不代表该代码已经在世界中生效。[71] [72] [73]

面向未来 Agent 的稳定契约

准备式工具已经提供可用基础；下面的统一第三方 Agent 契约仍是规划。它需要在重连前后保留 Agent／世界／会话身份、授权能力、允许观察范围、观察时间与摘要、相关精确 Package 引用、动作期限、取消状态和预算责任。动作结果必须区分已接受、已提交／失败、未知，以及已观察到后置条件。

无关 Package 的加入不应取消仍有效的已固定版本驾驶动作；授权撤销、相关定义改变或观察过期，则必须重新观察或拒绝。推理、资产生成和编译需要有界持久任务，不能占住世界 tick。世界提交后的取消不意味着撤销已经发生的结果。

下一项集成证明应由一个创作 Agent 制作能力，经既有事务发布，再由另一个单独授权的行动 Agent 发现并使用，加入候选冲突、丢失回执和协调器重启。实时驾驶视频与确定性八场景分别提供其中的基础，尚未完成自主“创作者到玩家”的编排闭环。方案与准备式实现。

如何协作：共享契约，逐步交接

用户目标
  ├─ 已有技能能完成 → System 1 → 类型、置信度、状态检查
  │                              → 普通玩家意图 → 权威服务器
  └─ 需要新能力／多步骤 → System 2 → 候选代码、资产和 Package
                                  → 校验、准入、CAS、检查点、tick 激活
                                                     ↓
                          新鲜 Catalog + 经批准的技能配置
                                                     ↓
                                  System 1 再选择可用技能

权威结果 → 复制、表现事件、结构化回执 → 下一次观察或规划

这是两类 Agent 的目标协作流程。当前两个入口已经存在，needs_planning 仍是返回给调用方的结构化结果；自动拉起 Codex、跨进程交接队列和恢复中的任务续接尚未接通。[70]

以“建造一座可破坏城堡，再打开入口”为例，分工分为五步：

1. 发现与规划。 System 2 读取 world_script_describe 和相关内容契约，明确构件数量、资源预算、破坏方式与完成条件。没有新能力需求时，可以直接使用已批准技能。
2. 创作与验证。 System 2 生成 Luau 与 Package 候选文件，调用已有资产生成服务并核对绑定结果。Luau 读取不可变帧，返回类型化命令；网络请求和资源生成在沙箱外完成。
3. 发布与确认。 候选走既有冷暂存、准入、代次 CAS 和组合检查点路径，在 tick 边界激活。作业 completed 或发布 submitted 都不足以证明世界已更新；需要查询精确包身份的权威 active 结果。
4. 交接现有能力。 调用方刷新 Catalog，按授权策略更新技能配置。System 1 仅在新鲜观察上选择已经批准的入口破坏技能；旧包版本上的迟到决策必须丢弃。
5. 执行与复核。 服务器验证玩家意图，运行包内行为，提交碰撞／地形／实体变化，再复制到客户端。System 1 消费匹配的执行回执；System 2 根据失败原因或用户新目标修订方案。

这段案例说明协作设计，并非一次已经完成的“Codex 建城堡 → Jev 破门”联合验收。已有建筑、角色创作和 Jev 技能证明来自各自的运行记录。[73] [20] [74]

拟议的交接记录应携带：原始目标／意图、任务 ID、world 与玩家会话标识、观察时间及摘要、精确 Package 引用、批准动作范围、剩余时间／调用预算、前序请求 ID 和权威结果。它属于调用方编排层的新契约，不是当前服务器已有的消息 schema。模型输出和网页／聊天内容不能扩大动作权限。

System 1 当前会复查会话、服务器身份、角色、Catalog、活跃包闭包、地形和公开观察摘要，并拒绝过期或被新意图取代的决策。置信度是路由依据，权限仍由引擎决定；高置信度不保证语义正确。[71] [72] [R8]

接入 System 1：OpenRouter／Jev

已有接口。 在引擎仓库运行，需要 Node 22+、支持 Catalog V2 的游戏服务器，以及已经发布并激活的角色和技能包。先复制 scripts/system-one/config.example.json 到被 Git 忽略的运行目录，把 game_url 改成实际游戏地址，并配置 character 与 skills。示例技能使用 studio.generated.meshy-hero 包中的 ground-pulse；配置清单不会创建或发布这个包。[70]

# OPENROUTER_API_KEY 由进程环境提供；密钥不放进 JSON 或模型上下文。
node scripts/system-one/cli.mjs target/my-jev-demo/system-one.json target/my-jev-demo/intent.txt

intent.txt 可以写“在脚下的地面挖一个小坑，只用一次地面脉冲技能。”CLI 作为独立玩家连接，等待角色选择复制完成，最多调用一次模型，然后输出 JSON 结果。远程游戏连接要求 WSS；本机允许 loopback WS。可复用的 Node 接口为 JevProvider、GameClient 与 SkillDirector.decide(intent)。[70]

适配器调用 OpenRouter 的原生 POST /api/alpha/decisions，请求 typesafe/jev-1.13，限定 TypeSafe 提供方且禁用回退；响应必须为验收版本 typesafe/jev-1.13-20260917。普通 Chat Completions 不能替代这里的请求／响应契约。当前默认超时 1.5 秒、观察有效期 2 秒，选择概率至少 0.85、置信度至少 0.65；这些阈值仍需按实际任务校准。[75] [R9]

接入 System 2：Codex／MCP

已有接口，客户端发布验收仍有缺口。 Codex 先连接只读引擎 MCP 发现能力，再显式连接 authoring MCP 提交候选内容。下面是 config.toml 示例；将所有 G:/pajama-studio/engine 路径替换为实际绝对路径，并先启动相应服务器和 authoring host。[73] [R10]

[mcp_servers.pajama-engine]
command = "cargo"
args = ["run", "-q", "-p", "pajama-mcp", "--", "--require-live", "--scope", "core,scripting,content"]
cwd = "G:/pajama-studio/engine"

[mcp_servers.pajama-authoring]
command = "node"
args = ["G:/pajama-studio/engine/scripts/authoring/mcp.mjs"]
startup_timeout_sec = 30
tool_timeout_sec = 120

[mcp_servers.pajama-authoring.env]
PAJAMA_AUTHORING_CONFIG = "G:/pajama-studio/engine/target/my-authoring-demo/config.json"

在同一环境先运行 cargo build -p pajama-mcp，避免首次编译占用握手时间；用 codex --version 记录当前客户端版本，在 Codex 的 /mcp 中检查连接。若管理员端口不是默认的 9101，在只读 MCP 参数中加入 --admin 与实际 loopback 地址。[76]

当前本地创作接口提供七个工具：authoring_generate_character、authoring_character_status、authoring_prepare_package、authoring_candidate_status、authoring_publish_prepared_package、authoring_publish_package、authoring_release_status。三个准备式候选工具扩展了历史引用中的四工具接口，当前契约见准备式创作记录。规划 Agent 可以准备文件、检查封存摘要、提交精确候选并轮询激活结果，再通过授权查询检查世界。角色生成产物经绑定验证后进入普通 Package；带行为的包必须沿组合检查点发布路径，不应拆成独立内容写入与脚本写入来模拟原子发布。[73]

9 月 21 日记录中的 Codex CLI 0.155.1 已完成 MCP 握手与工具发现，该次实际发布调用被客户端自动审批拒绝。后续准备式创作测试验证了独立 stdio MCP 进程与真实发布，不能反过来证明那个客户端的审批路径已经通过。引擎状态查询、原生客户端画面和模型视觉输入也是三种不同能力；当前 MCP 配置不会自动向 Codex 直播画面。[73]

自定义 Cloudflare Agent：编排在外，权威在引擎

已有远程作业桥。 services/pajama-author-agent 使用 Agents SDK 管理持久作业；你的规划 Agent 经作者凭据提交 POST /jobs，用 GET /jobs/<id> 获取结果。本机 scripts/authoring/remote-bridge.mjs 主动领取任务并调用同一 AuthoringRuntime，管理员端口保持在本机。作者和桥接器使用独立凭据；任务使用幂等 ID 和有时效的领取凭证。[77]

{
  "id": "observe-agent-demo",
  "name": "world_observe",
  "args": {}
}

上面是现有观察作业的请求体，不包含凭据。发布作业的 name 使用 authoring_publish_package，args 使用已核对的 Package 输入；任务完成后仍须调用 authoring_release_status 确认权威激活。Cloudflare 作业服务本身不会自动运行 LLM，也未承载 Jev 的玩家 WebSocket 决策循环。让它自动调度 System 1 与 System 2，是编排层后续扩展，需要补齐任务交接、玩家身份授权和恢复策略。[77] [73]

成本、证据与下一步验收

降本先从任务分流开始：明确等待或可由确定性规则处理的事件无需调用模型；简单现有技能由 System 1 处理；只有新能力、歧义和复杂目标进入 System 2。当前实现已限制观察大小、技能数、调用频率和生命周期调用数；跨进程预算、持久任务队列和通用规则路由仍需编排层实现。包发布与物理 tick 不等待模型推理。[71]

9 月 21 日的最后一轮 Jev 验收，等待、中文复杂目标转规划、中文技能执行三次真实请求耗时约 180–415 ms，接口返回的费用合计 $0.000070938。技能由真实服务器执行，两条玩家连接收到相同位置、半径 2 m 的挖掘笔刷，观察者收到匹配的施放／命中特效事件。首轮英文技能描述的选择概率只有 0.78，适配器阻止了施放；补充中英文技能说明后达到 0.99，执行阈值保持不变。[74]

这份证据覆盖一次有边界的技能闭环，不是多 Agent 持续自治的证明。后续本地 Wrangler 断连使服务器在续租失败后退出；该环境故障也保留在记录中。要完成两类 Agent 的联合验收，还需验证：Codex 实际发布成功、needs_planning 自动交接与预算控制、进程重启后未完成任务对账、发布期间旧决策失效、双原生客户端画面一致，以及故障恢复后的持续运行。[70]

13 · AI 辅助引擎自我演化

架构提案。 Pajama 应支持一个持久闭环：从观察到的问题出发，形成经验证的改动，再把有用的经验带入下一轮改进。外部演化控制层负责实验与发布，权威服务器继续负责世界状态。这是在现有产品边界上扩展能力，不需要在 tick 内增加优化器。[78]

Duan 等人在 9 月 15 日修订的论文中，区分了“改进产物”和“改进产生下一代产物的方法”。修改后的改进器被后续轮次复用，才形成结构上的递归；同等预算下，后继版本经独立评估确实更好，还需要进一步证明。这篇综述为设计提供参考，并不证明无限制的自我改进已经实现。[R11]

五类演化对象，各有发布边界

共同账本可以关联不同发布，但不把它们变成同一种激活机制。Package 不负责装载原生 Rust 代码。 旧二进制读取新持久化格式，需要显式兼容适配。内容回滚恢复定义与经验证的类型化状态，不会抹掉世界中已经提交的破坏。现有 V1／ABI2 发布边界仍需收敛。[78] [4]

在模拟循环之外闭合改进流程

世界／原生客户端／CI／创作回执
              |
       可复现案例 + 精确版本
              |
       System 2：假设与有预算的计划
              |
       隔离候选 -> 测试／回放／性能测量
              |
       独立判定 -> 保留失败或无定论的证据
              |
       现有发布路径 -> 测试世界 -> 限定范围发布
              |
       权威结果 + 保留改进方法 -> 下一案例

System 1 执行获准技能、提供有边界的结果，也可以用普通玩家意图驱动测试场景。System 2 定位问题、选择应修改的层级并创作候选。可执行检查与独立管理的评估器决定候选是否进入发布。创作者模型自己生成的“通过”结论，不能替代世界回执、回归测试或原生画面。[78] [70]

首版可以是仓库旁的执行器，加上不可变产物和只追加的实验日志。Cloudflare 后续可协调持久任务认领与预算；原生编译、GPU 实验由适合的工作节点执行。目前的 Cloudflare 创作桥接并不是引擎构建或模型训练执行器。起步无需新增常驻微服务。

每个角色如何作出工程决策

采用版本化的决策协议。 每轮给 Agent 当前目标、已授权范围、负责模块、精确源码／运行时身份、相关契约、少量历史决策和实际证据。区分硬约束、有适用条件的实践和未经验证的假设。仓库 Agent 现在可以从 AGENTS.md 路由到 docs/ENGINE_DECISIONS.md，并使用其中的决策模板；自动强制执行仍属于提案。[79] [80]

这是职责划分，不要求运行六个模型。同一个 System 2 Agent 可以依次承担多个阶段，受保护的评估和发布权限另行管理。System 1 仍负责有边界的技能选择。未来的快速路径可以在前提吻合、必要检查仍执行时复用已验证的工程方法；当前 Jev 适配器不会选择架构或修改引擎代码。[79]

对有实质影响的选择，拟议协议按以下顺序执行：

1. 确定产品结果与负责模块。 读取对应路径，不先加载整个仓库。代码、文档和测试不一致时，记录为需要调查的缺口。
2. 区分事实与未知。 根因不明时，选择最便宜且有边界、能够改变决策的观测；不编造置信度百分比或精确收益。
3. 比较可行备选。 包含当前基线、现有接口内的局部改动，以及确有意义时的较大方案。先取证也是有效选择；小修复不必虚构替代方案。
4. 先筛除，再比较。 排除违反范围、权威、兼容、硬预算或恢复要求的方案。其余方案比较产品相关性、证据、收益、完整成本、影响范围与可逆性。
5. 决定下一步动作。 输出 measure、experiment、implement、promote、defer 或 escalate，附简短理由与失效条件。进入发布需要对精确候选的独立验收。
6. 根据结果停止或重规划。 门槛已达到、预算耗尽或下一实验缺乏决策价值时停止；基线变化或出现反例时重新规划。已获授权的常规选择直接推进，只有确实缺少范围、权限或产品取舍时才升级处理。

若方案各有优势、没有一个明显占优，就做能区分它们的小实验，或取得缺失的产品偏好。协议让选择可检查，不保证得到全局最优方案。保留可审阅的解释和证据，不要求保存模型的私人推理过程。[79]

最佳实践必须带适用条件

Epic 的性能指导把预算与目标硬件关联；Godot 9 月 15 日的渲染报告说明，缓存等直觉上的优化可能因内存访问反而变慢；Google 的灰度发布指导强调限定发布范围、对照组和有代表性的评估。这些来源提供方法，以下具体应用属于 Pajama 的设计。[R12] [R13] [R14]

每条规则应有 ID／版本、来源、负责人、适用条件、必要证据、验证器和失效触发条件。“总是缓存”“总是加线程”“总是分片”都不是有效规则。原生性能继续采用现有 A/B/A 与保真门槛，架构调整不能免除这些检查。[79] [81]

示例：地形边界究竟要求哪种改动

同一个症状，在不同真实目标下可以支持不同选择。下表是实验前的方案比较，不是新增测量：

对于连续世界目标，先选 measure：固定场景／源码身份，观察边界行为、碰撞／地形驻留和帧／tick／内存成本，再选择能测试穿行、编辑与恢复的最小流式实验。若用户只要求展示效果，第一种方案可以合理。这样，选择由目标和证据决定，而不是由流行技术决定。[79]

每项重要决策应把备选、未选原因、约束、证据、总预算、选定动作、停止条件和后续结果保存在版本化记录中；小修复可直接写进变更说明。拟议调度器检查版本、预算与权限，受保护的执行器将证据绑定到真实产物和评估器。Agent 自填的 passed: true 不是有效证明。新增指南／模板今天即可使用，调度器和证明服务尚未实现。[79]

AI 可以通过独立实验提出最佳实践规则的修订。获授权的策略负责人在独立验证后，把修改用于后续轮次；候选不能削弱当前测试来帮助自己通过。决策协议本身也要在保留的引擎任务上对比固定基线，检查错误发布、不必要的升级处理、不行动、回归和总成本，而不只是检查表格是否填满。[79]

持久证据、预算与中断恢复

两类存储各有职责：世界检查点保存玩法事实，演化账本保存实验与决策。 它们通过精确身份关联。拟议的协调器记录包括：

这些是拟议的编排记录，不是已有 MCP 工具或服务器消息。派发前持久预留预算，用任务认领与日志版本挡住过期工作进程。重启后，按原始身份对账结果未知的发布或技能请求，再决定下一次有副作用的尝试；已花预算不能恢复。基线改变后需要重新评估。[78]

实验将获准的检查点复制到独立世界身份、存储命名空间和写者租约中。保留随机种子、意图／事件序列、tick 策略、精确内容、模型响应与硬件／运行时身份。记录的响应帮助复现失败，真实提供方实验另行测量模型漂移与延迟。不能假设物理与 GPU 跨机器逐位一致：契约要求精确的文档／事件身份就精确比对，其余使用事先声明的语义／视觉容差。证据导出不携带凭据或原始私人对话。

如何确认变好，同时保住原有能力

每轮开始前固定验收标准。候选作者可以提出新测试，但不能在同轮评估中删除受保护案例、降低门槛或改写保留集评分。正确性、权威性、兼容与恢复是硬条件。完成率、回归、尾延迟、内存和成本分别比较；更高的综合分数不能抵消状态损坏。[78]

原生性能复用已有 tools/perf/baseline.py 与 tools/perf/compare.py。A/B/A 对照固定源码、二进制、负载与表现状态，并检查视觉保真。默认接受条件是中位数至少改善 3%、p95 回退不超过 2%、对照漂移小于 8%。无定论的结果不能支持发布。常规 CI 检查引擎正确性，验收级计时需要稳定执行节点；缺失的私有样例覆盖仍属于未验证。[81] [82]

通过复现去重、不可变构建缓存、先小型确定性测试再昂贵原生／提供方实验、按事件触发诊断和限定候选搜索来降本。记录每次有效改进的总成本，包含失败尝试、评估、模型调用、计算和人工复核。若修改的是改进器本身，就从相同引擎基线出发，在未见任务上以相同模型权限和总预算比较新旧版本。还要确认保留的经验改变了后续决策，仅仅存下笔记并不够。[78]

首批证明：Agent 策略与连续世界工程

Jev 的双语技能描述修复适合作为种子案例：小规模运行记录中，选择改善了，执行门槛没有降低。这是人工指导的修复，不是自主演化证明。可建立独立标注的案例族，覆盖中英文改写、否定、等待、复杂计划、过期 Catalog、取消与结果未知的激活。既比较动作是否正确，也比较是否正确地不执行，再用两个玩家连接验证获准选择。保留获胜策略，并证明新案例确实复用了它。[74] [78]

引擎层案例可以从走向地形边界开始，区分有意设置的世界范围、碰撞缺失、区块缺失和视觉截断。连续世界候选必须验证穿行、编辑、重访、双客户端一致性及重连／重启，同时限制内存与尾延迟。仅遮住地平线不能通过；坐标／范围变化需要显式兼容工作，Agent 不能简单删除移动限制。这把世界扩展方向转化为一系列可测试的改动。[78] [48] [51]

同一个精确状态场景也可用于世界模型实验，按世界／场景／轨迹划分数据，避免相邻帧泄漏。测量支持时先改善采集选择、缓存或服务策略；新权重训练仍是离线候选，有自己的成本与因果一致性检查。H3／Wan 选型继续遵循同场景比较。

按验收证据逐步增加自治

引擎已有可利用的权威状态、Package、CI、性能和有边界的 Agent 基础。统一演化协调器、受保护评估服务、自动课程选择及自主二进制发布仍未实现。本章提出它们的契约，不增加运行验收声明。先选择明确的产品门槛问题或实测瓶颈，继续优先交付一致的 Package 生命周期。[78]

14 · 通过版本化 Package 引入动态玩法

研究站案例将 Package 边界落实到可见结果：一次发布把结构件、建造策略、伤害规则与表现事件带入正在运行的世界。 记录中的内容包为 studio.generated.meshy-hero，版本 2，摘要前缀 93d02749。新建筑开始生成前，两个原生观察客户端已经连接。[83] [20]

创作可复用构件与可执行规则

内容包定义了 17 类结构件，包含楼板、立柱、墙体、楼梯和塔楼部件。每类构件携带基础图形、静态碰撞与可破坏方块组件。build-fortress Luau 策略根据少量尺寸参数计算布局，再分批返回有数量上限的 build_prefab 类型化命令；可恢复状态记录建造进度。运行时通过已准入的精确包版本解析每个构件。[83] [14]

这体现了动态玩法创作的具体范围：作者提交数据与有边界的策略，运行中的引擎将其转化为可交互世界状态，生成系统也可以提出同样的文档。研究站展示已编写内容包的运行结果，独立的 Agent trace 则展示 AI 根据实时契约创作并发布脚本的过程。

向运行中的世界发布

验证从只有角色内容的版本开始，先记录尚未建造的场地。创作服务携带预期代次提交新 Package，后续权威状态查询记录部署代次 2、catalog 版本 2 及精确的包版本摘要。建造历史包含内容包方块从 0 → 399 的变化和中间采样，把发布身份与实际世界变化连接起来。[20] [17]

从内容包行为到可建造、可受损的对象

同一原生视角记录空地、基础与逐步生成的结构。内容包共创建 399 个建筑部件；同次运行中的 breach-wall 交互将指定墙体从 180 HP 降至移除，两个协议客户端均收到对应事件。

查看原图 ↗

查看原图 ↗

查看原图 ↗

证据来源

记录于 2026 年 9 月 21 日，来源为 target/complex-building-evidence/construction。图片保留原始字节；JSON 为明确限定字段的公开摘录，Luau 文件为 build-live.json 中原样提取的源码。该确定性演练有别于 LLM 工具调用对话。实现可参考 fe4d401；原始证据未嵌入可执行文件的精确提交。

查看证据节选

Formatted summary derived from package-rehearsal.json / 根据公开回执整理的摘要
2026-09-21 · deterministic package rehearsal / 确定性内容包演练
package: studio.generated.meshy-hero @ revision 2
publication: request build-live → generation 2 / catalog 2
construction history: 0 → 399 parts
typed behavior: build_prefab batches; persisted cursor
breach-wall requests: 91001 / 91002 / 91003
target 994 HP: 180 → 120 → 60 → removed
building parts: 399 → 398
requesting and observing protocol peers: cue events and remove 994 recorded
Not an LLM conversation or raw tool-call log / 非 LLM 对话或原始工具调用日志

下载证据文件 6

• station-before.png ↓图片 · 2.6 MB

  发布前：同一原生客户端中的空地；采集视图内共有 27 个实体。

  SHA-256

  504884b9db59939fb73929a024cbce1e0f010f460e31967b1435c76dd6d2f6ce
• station-foundation.png ↓图片 · 2.6 MB

  构建开始：客户端保持连接，内容包行为在场地上逐步放置基础。

  SHA-256

  fd94695eed81e9501c59df2f3ec0a1f687d7904b4eaafd5f1ae0c994a71a2115
• station-in-progress.png ↓图片 · 2.6 MB

  构建过程中：楼板、立柱与墙体通过有界批次的类型化建造命令进入世界。

  SHA-256

  2cbe867c7653cac3e92a018d69093534b421cc7a1717d1cddd0ed8a98f012610
• package-rehearsal.json ↓数据 · 21.7 KB

  已记录发布、构建、伤害、提示事件与移除回执的公开字段摘录，附截图元数据与来源文件哈希。

  SHA-256

  510f28691846a31a3de06cc717fa6ed07796ec0289fcff8236710fd2b18efee1
• build-fortress.luau.txt ↓轨迹 · 4.4 KB

  从本次提交的内容包中原样提取的 build-fortress Luau 源码：程序化布局、类型化 build_prefab 命令与持久化构建游标。

  SHA-256

  892c8f84d4817844a966f04474e8207713e6c0a964923e8bfcf42222a6280e8c
• breach-wall.luau.txt ↓轨迹 · 1.2 KB

  从同一内容包中原样提取的 breach-wall Luau 源码：校验权威目标并返回 60 点伤害的类型化命令。

  SHA-256

  15d2fb24760ce376a657fcaea7e6efe1daf627c7e3d3a87f611f0dbfa6c8b6cf

证据清单 ↗

让生成结构参与玩法

同一内容包将 breach-wall 技能绑定到受限行为。玩家发送技能意图，由服务器目标判定路径选中命中对象；行为检查不可变事件和帧，再向符合条件的方块提出 60 点伤害。方块初始生命值为 180。配套探针通过玩家协议发出请求，不持有世界编辑权限。[83] [21]

可下载的回执节选保留包身份、建造采样历史、三次技能结果及两个客户端的相关消息。表现事件回执说明事件已送达，建造截图说明场景实际出现；特效的逐像素归属和完整更新／恢复发布验收另行检查。

将新能力纳入完整生命周期

生成的机制要持续可用，其内容、行为状态与已发生效果就需要经历发布变化、重连和恢复。9 月 12 日的地形／检查点运行与后续建造／技能运行提供不同环节的证据。M1–M3 将这些能力汇入可重复的正式流程，继续覆盖历史实例与精确版本表现。[24] [23] [26] [40]

15 · 验证与性能方法

在性质真正发生的层级验证

发布目标是一个可重复黑盒场景：真实渲染资源、预制体、权威机制和对应表现，一起经历更新、重连、重启与回滚。组件测试建立局部规则，集成与原生客户端测试验证这些规则能否在真实生命周期中协同。[19]

该矩阵把产品验收条件与已有原生场景整理为可执行的检查方法。[1] [23] [25] [53]

原生验证入口为 services/pajama-edge/test/native_catalog_v2_two_client_e2e.mjs。记录覆盖两个独立原生客户端、更新／回滚、离线重连、损坏输入和服务器恢复。运行回执计数、截图与人工查看分别提供不同证据；路线图还单独跟踪更强的逐实体像素归属验证。[84] [23]

建立可重复的性能基线

性能运行应固定引擎版本、内容摘要、工作负载、配置与机器／系统／GPU。首次加入的空缓存和重复加入的热缓存分别测量；稳定游玩、游玩中发布与恢复也分阶段记录，让加载和持久化成本能够被定位。

这些测量重点来自产品目标。容量目标与预算应由记录完整的工作负载支持；当前白皮书尚不发布玩家容量或延迟 SLA。[1]

文档依据

核心架构说明引用引擎 026acf9（2026-09-12），建造／技能演练引用后续创作实现 fe4d401，Agent 接入专章固定到 382ca36，世界模型架构引用独立的规划提交。原生截图、创作轨迹与 Jev 协议验收分别保留来源和文件摘要。源码位置与版本集中列于第 18 章，证据清单列出可下载产物。视觉世界模型接入仍属于规划工作。

本版增加了对 d96cddf 地形域、配置校验、移动限制和地面调度的源码核对。这是有限范围的实现审查，没有把核心基线整体推进到该版本，也没有产生新的无限世界运行证据。外部研究查阅截至 2026-09-21；下文保留各资料的发表日期及适用范围。

最新视频测量的是什么

八组主相机录制达到套件事先定义的实测至少 59 fps、单次采样间隔不超过 100 ms 门槛，保留帧清单，并将实测采集节奏与 60 fps MP4 编码率分开。主视角为 1600 × 900，恢复片段为 1440 × 810；第二个原生观察者以 15 Hz 采集。交付时通过完整 MP4 解码和文件字节身份检查。

桥梁视频有七个未采集槽位，车队有三个，因此不能把全部入选片段描述成零掉帧。恢复有两段分别验证的 1,200 帧采集；失败或被替换的运行仍保留为诊断证据。可选无损暂存格式和录制收尾停止额外渲染降低了录制开销，不作为通用多人规模测量。

原创倒角建筑／设施模型、统一材质与日光、减少地面视觉噪声、明确镜头与叙事字幕改善了原生表现。车辆保留 Kenney CC0 素材归属；建筑使用外部实体碰撞，本组不宣称可行走室内或树木生态模拟。视频摘要与注明日期的记录。

本版复用已经记录的验收，网站及公开产物另行验证；没有重跑付费推理，也不把剪辑视频当作新引擎基准。历史引用保留原提交，当前源码审查显式绑定摘要。外部研究仍按此前审查日期引用，没有悄悄改成刚刚核验的新结论。

16 · 世界模型集成

显式状态，生成表现

规划中的集成有明确的职责边界：引擎计算权威世界的状态转移，输出模型根据获准使用的条件合成视觉观测。 这里的 world-model-friendly 指向一套接口与评测策略。对接层将动作、物理结果、相机视点和生成画面，与明确的状态历史对齐。[3]

预期的数据流可以写成三个操作：

S(t+1) = EngineStep(S(t), accepted_actions(t))
C(t)   = Observe(S(t), camera(t), view_permissions, content_revision)
I(t)   = Model(conditions_available_by(t), appearance, session_history)

S 是权威状态，C 是按声明范围提取的观测，I 是生成图像。引擎步进还依赖固定的代码、配置和数值行为；记录结果并不意味着能在不同平台上逐位重现求解器轨迹。模型可能近似表达外观或运动，但其像素不提交世界变更。生成的玩法提案仍通过类型化命令或内容包准入流程进入世界。[15] [4] [85]

原生路径通过 RenderSnapshot 与 wgpu 提供即时表现；规划中的模型路径在异步服务中消费同步记录。因此，视觉路径的研究可以建立在持续可用的引擎之上。视频模型物理泛化能力的研究为这一边界提供了依据：受控运动与碰撞实验发现，模型在未见过的物理条件下仍存在泛化缺口。这支持以明确状态检验输出，而不能仅凭视频看起来合理就判断其物理正确。[11] [R15]

近期研究如何改变设计选择

本次检索到胡渊鸣关于 GPT-6 Astra 的近期署名文章，授权转载日期为 2026-09-16，讨论对象的拼写是 Astra。作者认为代码／空间理解与精细 3D 生成互补：前者有助于组织场景与机制，后者提供资产细节。这是作者的技术判断，文中的模型对比不能作为 Pajama 的性能或产品验收。对本引擎的启示是将 Agent 编排能力与资产生成服务分别接入、分别评估。[R16]

Meshy 团队的 Mora 原文（2026-09-09）将代码、3D 控制信号和视频输出组合起来。其早期实现也披露了传送门视图缺失、角色细节和延迟问题。我们采纳这一职责分工作为设计参考，保留原生路径与分层验收；公开演示不代表已有可供 Pajama 直接接入的兼容 SDK。[R17]

其他路线提供了不同的接口启示：

因此，Pajama 的模型接口应同时容纳内容提案、动作提案与生成观测，按各自的生命周期接入。学习式状态预测可先用于离线测试、规划或提出候选；若未来参与权威执行，还需要明确状态格式、预算、恢复和一致性协议。这是本项目的工程选择，不是在断言模型永远只能渲染。

将代码、资产与视觉反馈接成创作循环

目标流程是：Agent 读取实时能力和获准观察的状态，编写有预算的 Luau 机制与构建规则，调用专用 3D 服务或建模工具准备资产，再发布可审查的 Package。激活后的引擎产生可查询结果和原生画面；规划中的观测适配器提供模型表现及评测输入。Agent 据此提出下一版修改。这个循环复用已有准入和版本检查，完整集成仍需验收。[14] [4] [85]

以一座可破坏研究站为例：代码描述楼层布局、构件关系和技能规则；资产定义外形、骨架、动画及碰撞候选；服务器接受发布并决定建造、命中和破坏结果。生成场景或 3DGS 也需要可支持的资源格式、单位、碰撞和预算校验，视觉上完整不等于已具备可交互语义。观测输出应绑定已激活的内容及世界身份，Agent 的后续修改带上所依据的版本，防止过时观察覆盖新状态。[5] [83] [17]

这里的三个完成标准分别是：内容能被接受并执行、世界结果能持久恢复、生成表现忠实且可用。 任一外部模型升级，都可以改善相应环节；它不会自动替代其他环节的证据。

H3 还是 Wan：按任务选择扩展起点

截至 2026-09-21，优先以 Wan 2.2 TI2V-5B 的因果少步路线验证适配与成本，保留 H3 作为复杂条件与画质基线；生成表现首轮同时比较 SANA-Streaming。 这是实验投入顺序，尚不是本引擎的性能结论。引擎已有明确世界状态，最先要解决的是如何忠实表现这些状态，而不是让模型重新猜测一次碰撞和破坏。

最关键的适配缺口是持续几何变化。SolarWM 论文的实验使用固定场景提示词，时变外部控制是相机轨迹；能移动相机探索，不等于能准确呈现服务器刚创建的楼层、刚炸开的墙洞或资源版本切换。Pajama 需要明确支持连续 RGB／几何条件的适配器与配对数据，或将候选限定为相机探索研究。[R26]

前沿路线怎样处理交互、记忆与成本

以下选择可核查且与引擎接入有关的路线，不作为跨任务排行榜。第三方结果均保留其硬件、测量范围与发布状态。

ReWorld 与 LingBot-World 2.0 当前标注 CC BY-NC-SA 4.0，应作为研究参考，不能自动进入本平台的商业部署清单。每个实际候选还要分别核对基础权重、适配权重、数据和依赖的条件；代码许可不能替代这些检查。[R27] [R28]

MiniMax H3：条件控制与质量基线

H3 保留为条件控制与质量基线，不再是唯一的首个接入候选。 已发布的 FL2VA 与 Ref2VA 基础权重，为条件视频生成提供起点。官方发布说明区分了本地 768p 基础输出，以及完整流程中的托管 Context-IR 和发布时尚未提供的本地 Regenerate-2K 权重。初期实验必须固定所用权重、许可证、条件输入方式和部署依赖。公布的 24 FPS 指输出视频播放帧率，并不代表推理吞吐或输入响应速度。[R31]

两篇近期预印本提供了更具体的依据：

这些结果支持开展复现与适配实验，并不代表 Pajama 已经完成相应集成。[R32] [R33]

这两项原型的限制不能泛化为 H3 骨干的永久限制：后来的 SolarWM-H3 已提供因果流式路线，但也没有替 Pajama 证明持续几何条件、多客户端一致性或目标部署成本。选型记录必须区分基础 H3、H3-World、SolarWM-H3 与托管 H3 Max。[R22]

Pajama 计划补充独立视频片段流程所缺少的持久环境、已接受动作与版本化内容。适配工作包括对齐训练样本、确认支持的条件通道、模型适配及评测。只有接口明确支持相应条件输入时，深度数据才能通过该路径发挥作用，不能假定普通视频生成接口会理解任意附加通道。

视觉目标由外观参考与对齐的目标图像具体定义，并记录相关权利与来源。引擎代理描述结构和运动，本身不会提供更丰富的视觉风格。因此，实验需要同时衡量输出对状态的遵循程度，以及相对原生渲染基线的视觉收益。

首个应用是已记录世界的视觉回放。完整记录轨迹可以为视频片段提供条件，其中包含相对于首帧而言的未来信息；这衡量的是视觉条件控制能力。另设因果评测，将每次生成请求限制在其声明的决策时刻已经可用的输入范围内。延迟观战需要声明前瞻范围与显示延迟；实时评测则必须在片段准备和条件输入两个环节，都排除未来动作与状态。

从状态到观测的接口

现有边界提供了起点，但时间语义各不相同。PhysicsFrame 发布动态物体与车辆姿态，也可能返回标记为 fresh=false 的缓存帧。OwnedRenderSnapshot 保存表现输入与提取代次，并不携带权威 tick／epoch 身份。对接层必须协调权威快照、实际物理发布，以及相机和表现的采样时间；仅将这些结构拼接起来，不能建立时间对齐。[15] [16] [85]

每个推理会话只接收获准查看的观测。 更完整的参考状态可以单独保留用于评测。观测导出器必须遵循玩家／观战者的可见性与关注区域规则，避免隐藏实体或内部状态通过模型条件泄露。

可行的首项交付是有界记录器与离线读取器：包含片段清单、带时间戳的状态／动作／事件记录，以及对齐的参考图像。离线或无窗口渲染器可以生成额外通道，无需把推理放进 tick；队列压力、丢弃样本和时间缺口均显式记录。配对采集通过验证后，再进行深度与语义 ID 适配；其他通道属于需要协商的能力，不能预设候选模型已经支持。[69] [85]

观测还需区分采样进度与持久化进度。规划中的记录同时保存采样 tick、权威生命周期，以及已知持久检查点身份与覆盖范围；先看见一个效果不等于它已进入恢复根，缺少持久化回执也不等于写入失败。采集器不等待检查点而阻塞模拟。恢复后建立新的记录片段和模型会话，从恢复出的状态重新生成条件；以实际恢复的检查点核对历史尾部，标记已纳入、未纳入或仍无法确认的记录。已有观测记录不能反向充当世界存档。[6] [85]

模型输出的接纳条件

拟议适配器将每个请求绑定到片段／会话、权威生命周期、内容身份、获准视图版本、相机条件和输入范围。输出仅在接收端仍认可这些条件、并处于声明的显示窗口内时可用。内容切换、恢复、视图权限变化或不兼容的相机跳变，需要检查在途任务及缓存历史；普通相机运动按声明的条件序列处理。取消请求不能保证后台已经停止，因此迟到结果仍必须经过同一接纳检查。

这项检查验证来源和时效，像素是否遵循几何仍由独立评测判断。首项测试可以使用故意乱序、延迟返回的模拟适配器，验证失效输出无法进入显示路径、原生回退持续可用，然后再接入实际模型推理。[85]

质量与运行效率

评测关注输出能否保留交互中可见的事实，以及相应成本。Physion 提供了按场景检验物理事件的参考；VBench 将视频质量拆分为时序、运动和外观等维度。Pajama 需要将这两类测量与引擎参考状态结合；任何一项基准都不能单独证明交互游戏的正确性。[R34] [R35]

以原生参考渲染为共同真值，分别比较 Wan／H3 的受支持条件适配和 SANA 视频转换；输入能力与应用范围分别标明。训练和评测按场景与轨迹分开，避免相邻帧泄漏；使用未参与训练的交互和多个随机种子，并公布样本量、失败率与不确定性。几何评分需要可见性掩码与经过校准的提取方法；风格化图像使自动测量产生歧义时，应人工复核。在运行比较之前，为目标工作负载确定验收阈值。

共享实体 ID 与正确的输入回执只能确立协议身份，不能证明生成像素符合状态。多视角几何、外观与事件的一致性，仍是需要测量的研究目标。推理进程不持有可修改世界的句柄；超时、错误 epoch 或过期会话可按确定规则拒绝，并触发原生渲染回退，而可靠地自动检测视觉偏差还需要进一步研究。回退保留可用性与权威玩法，切换体验也需要验证。初期设计中，精度敏感的瞄准和 UI 继续由引擎渲染。[85]

这条路线延续引擎已有的设计选择：显式版本、有界接口，以及每个世界一个模拟权威。原生发布就绪、内容连续性和分布式运行，继续构成模型路径的基础。[1] [26] [86] [53] [67] [27]

推理降本：先减少任务，再优化计算

成本优化按以下顺序推进，每一步都重新检查状态遵循与视觉收益：

1. 复用引擎已知结果。 用实际状态产生低成本参考画面与受支持的几何条件，优先测试表现转换；碰撞、破坏、瞄准和 UI 仍由原生路径提供。资产与静态外观能通过 Package 复用时，无需在每个玩家的每帧重新生成。
2. 缩小在线工作量。 比较较小骨干、较低工作分辨率与短生成块；将高成本细化放到回放或非即时场景。分辨率、压缩和块长度必须一起报告；大块可提高吞吐，也会增加收集输入和等待首帧的时间。低频模型输出的重投影只是显示策略，不能算作新生成帧或掩盖状态过期。
3. 因果少步蒸馏与有界记忆。 复用已发布蒸馏权重，减少每块去噪次数；单纯加 LoRA 并不会自动降低骨干推理计算量。缓存只保留必要历史，按空间与修订检索；世界恢复、权限变化、破坏或内容切换触发失效。缩短步数后的收益必须用全链路耗时衡量。
4. 优化整个生成链路。 逐项计量条件编码、DiT、VAE、传输和显示；再选择适配硬件的低精度、融合算子、编译与缓存。SANA-Streaming 的端到端／DiT 吞吐差异说明，只优化去噪器不足以保证整体收益。量化后重测细小构件、运动边界和事件时序。[R25]
5. 按延迟目标调度。 区分冷启动与热请求；以截止时间约束批处理、并发和队列，取消失效工作。热池降低启动等待，也产生空闲费用。不同相机或可见权限不能直接共享生成帧；可共享资源和编码结果必须满足同一身份与权限契约。

核算单位是每分钟合格、及时送达的模型输出成本，其中“分钟”按每个接收视图累计；同时报告每个活跃玩家分钟的总成本和模型覆盖率：

单位有效输出成本 = (全部 GPU 计费 + API + 传输等服务成本) / 合格且按时送达的模型视图分钟

GPU 计费包含热池空闲、失败、重试及取消后仍运行的工作；同一费用不得重复计入 API 和自托管 GPU。分母排除过期、拒绝、重复和插值填充的片段；原生回退单独统计。没有合格输出时，该候选未通过，不能报告为零成本。训练／适配开销另列，并按预计使用量说明摊销，避免用单次推理省下的费用掩盖训练投入。

决定模型去留的同场景实验

首轮固定一组可破坏建筑轨迹：转身、遮挡、建造、拆墙、离开后返回、双相机，以及内容版本切换。先验证观测与模拟适配器，再比较 Wan 因果版本、H3 条件／因果版本和 SANA 视频转换。接口不能表达实时变化的候选只参加离线组，不混入在线排名。

每次运行保留引擎／权重／适配器版本、输入通道、分辨率、精度、去噪步数、块长度、缓存预算、GPU 型号及数量、并发和完整时间戳。分别公布文件播放 FPS、新鲜生成 FPS（含编解码）、首帧时间、输入到实际显示延迟；后者包含采集、组块、排队、网络与呈现。预先提供整条未来轨迹的运行只能证明离线能力。

先按声明的状态一致性和响应门槛淘汰候选，再比较合格输出成本。单视图与多视图负载分开；超时／显存压力／迟到输出下检查原生路径仍可用。本次完成的是资料核验与实验设计，尚无 Pajama 的 H3／Wan／SANA 推理实测，因此不发布单用户价格、实时帧率或胜出模型的承诺。

17 · 发展路线

双路线，共同基础

研发沿两条相互连接的路线推进：运行时路线让持久世界更易于创建、运行和扩展；模型路线将世界状态转化为可控制的生成表现。两者建立在共同的身份、内容版本和恢复契约之上。[19] [27]

根据新证据排序的后续工作

这些优先项细化 M1–M5，不取代单权威产品目标，也不承诺交付日期。先扩展一个经过验收的权威，再依据测量决定分片。模型表现保留在 M6，不能绕开世界契约。架构评估。

M1 · 可玩内容包

将已展示的玩家操作、内容包行为与匹配表现整合为完整发布流程。地形／检查点证据和建造／破墙演练提供起点，集成验收将请求处理、持久去重／冷却、精确版本表现、更新与恢复纳入同一次运行。[24] [25] [21]

完成标准： 两个原生客户端在更新、回滚和恢复后，仍观察到相同的已接受操作与效果；重复请求只产生一次世界结果。这将成为扩展更多玩法能力的参考流程。

M2 · 内容连续性

将资源保留从当前版本与紧邻回滚版本，扩展到持久实例的完整生命周期需求。明确哪些实例保留原版本、哪些可以迁移，以及历史资源如何保留和回收。[26] [23]

完成标准： 保留实例在更新与重启后仍能解析正确内容，发布与清理过程维护全部必需引用。

M3 · 原生发布就绪

将玩法和内容连续性整合进客户端／服务器的正常启动路径，完善目录顺序、兼容处理、平台验证，以及基于具体工作负载的性能测量。[35] [86] [19]

完成标准： 正常应用流程通过双客户端发布、更新、重连、重启和回滚场景，覆盖资源缺失或损坏，形成可重复的原生发布基线。

M4 · 持久世界运行

在租约权威与检查点基础上，连接玩家身份、世界发现、准入与恢复；完成持久写入隔离及玩家资料副作用 outbox，并演练故障权威的替换。[7] [53] [40]

完成标准： 替代权威能够恢复一致世界、接纳重连玩家，并拒绝前任权威的迟到写入。后续扩展由容量测量指导。

世界扩展：连接 M3 与 M4 的验收

先在单一权威下实现空间契约，再决定是否需要跨服分区。以下均是新增待完成的验收工作：

这组验收分别证明空间扩展、持久世界和视觉连续性；在通过之前，演示应标明当前地图范围。持续扩展仍受地址空间、存储配额和运营容量约束，没有一次加载或永久保存无限资源的承诺。

M5 · 人与 Agent 的内容创作

在已实现的准备式候选流程上补齐隔离预演、持久任务／取消预算、稳定第三方契约及创作到玩家的交接。按精确摘要发布、核对丢失回执及拒绝冲突代次已有本地证据。生成服务通过相同准入流程提供候选资源与行为。[66] [67] [1]

完成标准： 作者能够沿着统一、已文档化的流程引入可玩能力，检查效果并管理其生命周期；回执关联发布各阶段，持续生成在累计预算内运行，响应丢失后仍能核对结果。

M6 · 模型生成的世界表现

开发不绑定供应商的观测与表现层，按 Wan 优先适配、H3 质量对照、SANA 视频转换比较的顺序推进实验。同步采集可以与核心运行时集成共同推进；生产表现依赖可靠的内容和恢复生命周期，分布式模型会话建立在 M4 之上。[3] [85]

初期场景覆盖刚体落地并停稳、角色遮挡后返回、持续存在的地形或墙体缺口，以及双相机观察同一交互。这些场景将视觉质量与决定世界可玩性的事实连接起来。[27]

规划中的可执行证据包括观测写入／读取一致性验证器、离线比较工具和会话故障注入测试，扩展已有的原生生命周期验证工具。回放结果支持回放应用；观战与实时应用需要分别通过对应的因果性、延迟和一致性门槛。如果适配器未达到这些门槛，它仍可用于回放或创意输出，同时原生游戏路径继续发展。

贯穿生命周期的验证

每个里程碑通过交付能力与可复现集成结果评估。已有原生内容包 runner 提供生命周期基线；规划中的采集、模型对比和会话故障工具，将同步观测与真实模型测量纳入其中。路线从回放走向观战，再随着控制质量、延迟与运行效率满足体验要求，推进实时输出。[84] [85]

18 · 术语与阅读指南

了解项目概况，按 愿景 → 架构 → 进展 → 路线图 阅读；理解架构，按 执行链路 → 世界数据 → 发布 → 恢复 阅读；进行创作或客户端集成，再继续阅读 交付 → 渲染 → 创作 → 完整示例。后附引用标识各项实现说明所依据的源码与设计记录。

19 · 参考资料与实现依据

实现依据与规划文档分别固定到各自的源码提交，第 15 章说明其范围；外部研究及其对设计的支持在下方单独列出。

实现依据采用仓库路径与行号，仓库访问权限单独管理。

1. Product goal and durable boundarydocs/PRODUCT_GOAL.md:10 @ 026acf9
2. Native client dependenciescrates/pajama-client/Cargo.toml:21 @ 026acf9
3. Planned direction: world-model interoperabilitydocs/PRODUCT_GOAL.md:28 @ bf13e81
4. Permanent package formats and identitydocs/CONTENT_PACKAGES.md:15 @ 026acf9
5. Realm-owned package admissiondocs/CONTENT_PACKAGES.md:595 @ 026acf9
6. Composite checkpoint coordinatorcrates/pajama-server/src/authority_checkpoint_coordinator.rs:1 @ 026acf9
7. Backend scope and production gatesdocs/BACKEND_ARCHITECTURE.md:3 @ 026acf9
8. Real authoritative tick orderingcrates/pajama-server/src/lib.rs:4025 @ 026acf9
9. Atomic client presentation coordinatorcrates/pajama-client/src/content_presentation.rs:1 @ 026acf9
10. Bounded client delivery ownercrates/pajama-client/src/content_runtime.rs:1 @ 026acf9
11. Render layers and execution ownershipdocs/RENDERING_ARCHITECTURE.md:41 @ 026acf9
12. Workspace ownership mapCargo.toml:3 @ 026acf9
13. Bounded package archive stagingcrates/pajama-content/src/lib.rs:323 @ 026acf9
14. Immutable frames, typed commands and budgetscrates/pajama-script/README.md:17 @ 026acf9
15. Solver interfacecrates/pajama-physics/src/lib.rs:297 @ 026acf9
16. RenderSnapshot boundarycrates/pajama-render/src/snapshot.rs:246 @ 026acf9
17. Package publication servicecrates/pajama-server/src/package_publication.rs:1 @ 026acf9
18. Interest-managed replicationcrates/pajama-server/src/replication.rs:1 @ 026acf9
19. Completion gate and implementation frontierdocs/ROADMAP.md:8 @ 026acf9
20. Native observers and live Package construction rehearsalscripts/authoring/building-rehearsal.mjs:1 @ fe4d401
21. Player-intent breach test, authoritative damage and replicated removalscripts/authoring/building-probe.mjs:1 @ fe4d401
22. WorldDoc persistence schemacrates/pajama-world/src/lib.rs:489 @ 026acf9
23. Recorded native update, rollback and recovery evidencedocs/ROADMAP.md:294 @ 026acf9
24. Recorded durable package terrain evidencedocs/ROADMAP.md:371 @ 026acf9
25. Skill binding and remaining playable gatedocs/ROADMAP.md:419 @ 026acf9
26. Historical instance policy and V5 boundarydocs/ROADMAP.md:437 @ 026acf9
27. Planned P6 stages and evidence gatesdocs/ROADMAP.md:476 @ bf13e81
28. Authority lifecycle and fencingcrates/pajama-server/src/authority.rs:24 @ 026acf9
29. Verified content-addressed cachecrates/pajama-client/src/content_cache.rs:1 @ 026acf9
30. Read-only defaults and explicit write scopescrates/pajama-mcp/README.md:32 @ 026acf9
31. Entity documentcrates/pajama-world/src/lib.rs:384 @ 026acf9
32. Runtime world and change trackingcrates/pajama-world/src/lib.rs:533 @ 026acf9
33. World mutation stampcrates/pajama-world/src/lib.rs:796 @ 026acf9
34. Standalone ECS dependencycrates/pajama-sim/Cargo.toml:10 @ 026acf9
35. Catalog ordering evidence and open gatesdocs/ROADMAP.md:173 @ 026acf9
36. Local V1 input and composite publicationdocs/ROADMAP.md:104 @ 026acf9
37. Closed checkpoint backend ownershipcrates/pajama-server/src/authority_checkpoint_backend.rs:1 @ 026acf9
38. Local immutable store and head CAScrates/pajama-server/src/local_checkpoint_store.rs:1 @ 026acf9
39. Process-local checkpoint lifetimecrates/pajama-server/src/process_local_checkpoint.rs:1 @ 026acf9
40. Rollback integration and production boundarydocs/ROADMAP.md:135 @ 026acf9
41. Generation-bound CPU decodercrates/pajama-client/src/content_decode.rs:1 @ 026acf9
42. Imported GPU resource generationscrates/pajama-render/src/skinned/asset_generation.rs:1 @ 026acf9
43. Exact asset extraction and placeholderscrates/pajama-client/src/package_asset_presentation.rs:1 @ 026acf9
44. Rapier default and Box3D compatibilitycrates/pajama-physics/src/lib.rs:402 @ 026acf9
45. Fixed substeps and bounded catch-upcrates/pajama-physics/src/rapier_backend.rs:60 @ 026acf9
46. Authoritative causal terrain editcrates/pajama-server/src/terrain_sync.rs:232 @ 026acf9
47. Client movement prediction and echo reconciliationcrates/pajama-client/src/app_runtime.rs:541 @ 026acf9
48. Finite terrain domain contractcrates/pajama-world/src/terrain.rs:35 @ d96cddf
49. Default terrain half-size: 250 metrescrates/pajama-world/src/terrain.rs:310 @ d96cddf
50. Accepted finite extent rangecrates/pajama-world/src/terrain.rs:362 @ d96cddf
51. Authoritative movement clamps to terrain extentcrates/pajama-server/src/lib.rs:4556 @ d96cddf
52. Extent-bounded physics ground tile schedulingcrates/pajama-server/src/ground_schedule.rs:214 @ d96cddf
53. Distributed authority roadmapdocs/ROADMAP.md:452 @ 026acf9
54. Compiled render pipelinecrates/pajama-render/src/pipeline.rs:389 @ 026acf9
55. Animation architecturedocs/ANIMATION.md:1 @ 026acf9
56. Four-client render profile regression and controlled measurementsdocs/evidence/four-client-render-profile/README.md:1 @ e2134b8
57. Spectral water and consistent cloud radiancedocs/TIDEWATER_ROUND3.md:1 @ e2134b8
58. Lake transport and oblique wave filteringdocs/LAKE_REALISM.md:1 @ e2134b8
59. Shoreline foam implementation and acceptancedocs/SHORE_FOAM.md:1 @ e2134b8
60. Cloud detail footprint filtering and evidencedocs/CLOUD_DISTANCE.md:1 @ e2134b8
61. Native weather implementation and limitsdocs/WEATHER_SYSTEM.md:1 @ e2134b8
62. Underwater optics numerical and native acceptancedocs/evidence/underwater-optics/README.md:1 @ e2134b8
63. Native 40 km terrain horizon and streaming acceptancedocs/evidence/terrain-horizon-lod/README.md:1 @ e2134b8
64. Command/component registrycrates/pajama-world/src/registry.rs:1 @ 026acf9
65. Live registry discovery and authorizationcrates/pajama-mcp/README.md:3 @ 026acf9
66. Existing audited script runnercrates/pajama-mcp/README.md:61 @ 026acf9
67. Package authoring and generation roadmapdocs/ROADMAP.md:465 @ 026acf9
68. At-most-once send and uncertain outcomescrates/pajama-mcp/README.md:52 @ 026acf9
69. Native headless rendering pathcrates/pajama-client/src/headless.rs:951 @ 026acf9
70. Jev integration scope, controls and acceptancedocs/SYSTEM_ONE_AGENT.md:7 @ 382ca36
71. Approved skill choice, budget, freshness and receipt policyscripts/system-one/skill-director.mjs:35 @ 382ca36
72. Ordinary player observation and authoritative skill receiptsscripts/system-one/game-client.mjs:46 @ 382ca36
73. Authoring tools, Codex client acceptance limit and remote integrationdocs/AGENT_AUTHORING_DEMO.md:118 @ 382ca36
74. Real Jev decisions and bilateral authoritative terrain evidencedocs/evidence/jev-system-one-2026-09-21.json:82 @ 382ca36
75. Jev native Decisions transport and version validationscripts/system-one/jev.mjs:98 @ 382ca36
76. Explicit authoring MCP adapter to the existing runtimescripts/authoring/mcp.mjs:1 @ 382ca36
77. Durable Cloudflare job queue, bounded tools and claimsservices/pajama-author-agent/src/index.ts:31 @ 382ca36
78. Proposed engine evolution control plane, contracts and acceptance gatesdocs/ENGINE_EVOLUTION.md:7 @ bb964ad
79. Engineering decision roles, conditional practices and proposed enforcementdocs/ENGINE_DECISIONS.md:9 @ e1dc2c0
80. Repository agent routing to the engineering decision guideAGENTS.md:33 @ e1dc2c0
81. Existing controlled performance comparison and retained verdictsdocs/PERFORMANCE_LOOP.md:156 @ bb964ad
82. Engine correctness CI and stable-runner performance boundary.github/workflows/ci.yml:10 @ bb964ad
83. Versioned building kit, procedural behavior and player skill bindingscripts/authoring/complex-building.mjs:7 @ fe4d401
84. Native two-client test runnerservices/pajama-edge/test/native_catalog_v2_two_client_e2e.mjs:9 @ 026acf9
85. Planned observation, provider and presentation contractsdocs/WORLD_MODEL_BRIDGE.md:8 @ bf13e81
86. Platform cleanup and CI scopedocs/ROADMAP.md:70 @ 026acf9

外部研究与设计参考

这些公开研究为拟议设计提供依据。其成果属于所引用的系统，并不代表 Pajama Engine 已经验证的能力。

参考资料核对日期: 2026-09-21.

1. [R1] World ModelsDavid Ha and Jürgen Schmidhuber · 2018 · 研究论文

   通过学习环境的压缩时空表示支持预测与策略训练，帮助区分学习式环境模型与执行环境；物理引擎或观测导出接口本身不等于已训练的世界模型。

2. [R2] Networking OverviewEpic Games · Accessed 2026 · 引擎官方文档

   说明权威服务器、客户端状态复制与视觉表现的分工，为权威边界提供工程先例；Pajama 的实现、网络性能和生成画面一致性仍需自身验证。

3. [R3] Streaming 3DGS worlds on the webWorld Labs · 2026-04-14 · 渲染器官方工程文章

   说明 3DGS 的视点相关 LOD、渐进流送及固定 GPU 页池，为有界驻留提供参考，不提供可破坏地形、权威碰撞或持久化。

4. [R4] Extract in bevy::renderBevy contributors · Accessed 2026 · Bevy 0.19.1 API 文档

   说明从模拟世界只读提取到渲染世界、并行处理模拟与渲染的机制，为观测边界提供工程先例；不直接提供序列化回放、模型条件接口或跨机器确定性。

5. [R5] Model Context Protocol — ToolsModel Context Protocol contributors · 2025 · 协议规范，2025-06-18

   定义工具发现、JSON Schema 输入、可选输出模式、结构化结果及服务器校验要求，为类型化创作接口提供依据；领域权限、资源预算、版本检查和世界原子激活仍由引擎实现。

6. [R6] Embedding a sandboxed Luau virtual machineLuau contributors · Accessed 2026 · 语言官方文档

   说明受限标准库、受保护环境及宿主中断机制，为有预算的脚本执行提供依据；内存限制和暴露 API 需由宿主配置，沙箱并非任意宿主绑定安全性的形式证明。

7. [R7] System One introductionTypeSafe AI · 2026 · 模型官方文档

   说明类型化决策模型的用途，为有边界的决策角色提供依据；不代表 Pajama 的延迟、自治或完整视觉理解能力已获验证。

8. [R8] ConfidenceTypeSafe AI · 2026 · 置信度官方文档

   解释置信度和决策分布。阈值需要针对任务评估；置信度既不授予权限，也不证明结果正确。

9. [R9] Jev 1.13 APIOpenRouter · 2026 · 提供方官方 API 文档

   记录 OpenRouter 上的 Jev 接口。引擎适配器固定原生 Decisions 契约并验证实际响应版本；实测成本以关联运行回执为准。

10. [R10] Model Context ProtocolOpenAI · 2026 · Codex MCP 官方文档

    说明 config.toml 的 MCP 配置、stdio 命令／参数／目录／环境变量及超时。配置正确不等于 Pajama 发布验收通过，也不应绕过客户端审批。

11. [R11] The Last AI Built by Humans: Toward Genuine Recursive Self-ImprovementYi Duan et al. · 2026-09-15 (v2) · 综述预印本

    支持区分产物改善与被后续轮次继承的改进器改善。Pajama 控制层设计属于提案，没有据此宣称自主演化成果。

12. [R12] Introduction to Performance Profiling and ConfigurationEpic Games · 2026 (accessed) · 引擎官方文档

    将帧时间和性能预算与目标硬件关联，为测量方法提供依据，不代表 Pajama 性能成果。

13. [R13] Optimizing CPU-side Rendering CodeClay John / Godot Engine · 2026-09-15 · 引擎官方工程报告

    展示性能分析、诊断和重新测量，并给出直觉式缓存优化的反例；报告中的收益属于 Godot 测试场景。

14. [R14] Canarying ReleasesAlec Warner and Štěpán Davidovič / Google SRE · 2018 · 发布工程一手指导

    支持限定发布、对照比较、代表性样本和绝对健康指标；Pajama 应在同一世界不出现并发写者的前提下应用。

15. [R15] How Far is Video Generation from World Model: A Physical Law PerspectiveBingyi Kang et al. · 2025 · ICML 2025 研究论文

    在受控二维视频预测实验中发现分布外物理泛化不足，为状态真值与未见条件测试提供依据；结论限于实验模型与设置，不代表视频生成的普遍能力上限。

16. [R16] GPT-6 Astra and the value of 3D generationYuanming Hu (Ethan); authorized republication via Founder Park / BAAI · 2026-09-16 · 作者署名观点，授权转载

    论述代码／空间理解与精细资产生成的互补关系。属于作者判断，不作为独立模型基准或 Pajama 验收结果。

17. [R17] Mora: Beyond the “World Model”Meshy Research Team · 2026-09-09 · 官方架构与原型说明

    结合代码、3D 控制信号与生成视听输出，并披露早期视觉及延迟限制。支持模块化集成方向，未证明存在兼容 Pajama 的 SDK。

18. [R18] A Functional Taxonomy of World ModelsWorld Labs · 2026-06-03 · 官方研究观点

    以观测、状态、动作输出区分渲染、模拟和规划，并讨论能力融合。支持按输出制定契约；生成几何仍需校验。

19. [R19] Atlas: A World Model for Spatial IntelligenceWorld Labs · 2026-09-01 · 模型官方发布说明

    介绍具有空间定位的多模态上下文、相机控制及显式 3D 输出。Early access 发布支持接口研究，不构成 Pajama 接入或实测性能依据。

20. [R20] Project Genie: Experimenting with infinite, interactive worldsDiego Rivas, Elliott Breece and Suz Chambers (Google) · 2026-01-29 · 官方原型发布说明

    介绍响应动作的探索体验，以及发布时原型的物理、控制与 60 秒生成限制。支持区分探索和持久世界验收；限制属于当时原型。

21. [R21] Wan2.2: Open and Advanced Large-Scale Video Generative ModelsWan team · Accessed 2026-09-21 · 模型官方仓库

    说明 5B 基础模型与卸载式 24 GB 推理起点，不证明交互延迟或持续状态条件适配已达标。

22. [R22] SolarWM: release status and model familyJunchao Huang et al. · 2026-09-13; checked 2026-09-21 · 研究官方仓库

    记录 Wan 5B、H3 三阶段发布物及 9 月 13 日流式 H3 更新；发布状态不等于实时引擎接入。

23. [R23] SolarWM Wan2.2 TI2V-5B backend guideSolarWM contributors · Accessed 2026-09-21 · 官方推理指南

    提供单 GPU Stage2 推理示例；启动示例不是硬件下限，也不是同负载成本对比。

24. [R24] SolarWM MiniMax-H3 backend guideSolarWM contributors · Accessed 2026-09-21 · 官方推理指南

    列出 H3 各阶段权重与 8 GPU 推理示例，不据此推算八倍成本或最低配置。

25. [R25] SANA-Streaming: Real-time Streaming Video Editing with Hybrid Diffusion TransformerYuyang Zhao et al. · 2026-05; released 2026-06 · 研究预印本 v1

    研究以源视频为条件的流式编辑，并区分全链路与去噪器吞吐；引擎几何保真与输入响应仍需单独测量。

26. [R26] SolarWM: Open Data and Scalable Training for Long-Horizon Video World ModelsJunchao Huang et al. · 2026-09-02 · 研究预印本 v1

    说明跨骨干因果适配与蒸馏；7.1 节采用固定提示与时变相机控制，未验证任意实时几何更新。

27. [R27] ReWorld: An Interactive World Model with Long-Horizon MemoryReWorld authors · 2026-08/09; checked 2026-09-21 · 研究官方仓库

    说明有界缓存、地标检索与少步生成；当前仓库注明非商业条款，模型记忆不能替代引擎的版本化持久状态。

28. [R28] LingBot-World 2.0: Infinite Worlds with Versatile InteractionsRobbyant / LingBot-World team · 2026-07; checked 2026-09-21 · 模型官方仓库

    提供因果模型与多 GPU 示例；非商业条款及未发布部署代码限制直接复用，宣传吞吐不等于单玩家延迟。

29. [R29] SANA-WM: Efficient Minute-Scale World Modeling with Hybrid Linear Diffusion TransformerHaoyi Zhu et al. · 2026-05-14 · 研究预印本 v1

    研究混合注意力与相机条件生成；RTX 5090 分钟视频结果衡量去噪，不是输入到显示延迟。

30. [R30] H3 Max: Built with fal Inference and Trainingfal · 2026-09-17 · 服务方工程报告

    说明快速片段生成、多节点服务与启动优化；服务方速度报告不证明持续控制或单玩家成本。

31. [R31] Open General Intelligence: MiniMax H3 Is Now Open SourceMiniMax · 2026 · 模型官方发布说明

    说明已发布的 FL2VA、Ref2VA 基础权重与多模态条件接口。文档中的完整 2K 流程还依赖托管组件；24 FPS 是播放帧率，不是生成吞吐或交互延迟。

32. [R32] H3-World: Turning Language Understanding into World ControlDanze Chen et al. · 2026 · 研究预印本

    以按时间对齐的语言指令适配 H3 的角色与相机控制，支持短时可控生成的研究方向；尚未展示持久状态、实时交互、规划或策略学习，控制可靠性仍需更广泛评估。

33. [R33] Code World Model: Coding Agent as World BrainYiwen Chen, Guosheng Lin, and Chi Zhang · 2026 · 研究预印本

    将可执行世界演化与视频合成分离，并用深度和语义代理条件适配 H3 Ref2VA。定性结果支持探索该接口；原型未实现自回归实时生成，控制对比未计入推理延迟。

34. [R34] Physion: Evaluating Physical Prediction from Vision in Humans and MachinesDaniel M. Bear et al. · 2021 · 研究论文与评测基准

    提供接触、稳定、滚动等可复现物理预测场景，为按场景评测提供方法参考；其任务是从观测预测物理结果，游戏生成画面仍需另行对照权威几何、事件时序和玩法状态。

35. [R35] VBench: Comprehensive Benchmark Suite for Video Generative ModelsZiqi Huang et al. · 2023 · 研究论文与评测基准

    将视频质量分解为身份一致性、运动平滑、闪烁和空间关系等维度，为视觉评测提供依据；感知质量高分本身不能证明碰撞精度、事件一致性、多人一致性或交互延迟达标。