攻击动作做对了，游戏规则就对了吗？H3-World 与三条控制路线的分工
作者机制示意或未执行条件对照；不代表模型运行或真实游戏结果。
StatePlay 论文的一张表里，有一个比“谁的画面更好”更值得停下来的结果：同在 state-aware fine-tuning 分组，ReactiveGWM 的攻击准确率是 100.0%，StatePlay 是 95.0%；但在 GPT-5.5 视觉裁判给出的机制一致性上，两者分别是 59.7±0.9% 和 78.3±0.5%。攻击指标领先的模型，没有同时在这项规则评价上领先。
来源原始页面聚焦证据；固定版本与适用条件见图，作者报告未复测。
这些是该论文的作者报告，本次未复测。攻击准确率由专门的动作分类器判断；机制一致性则让视觉裁判检查胜负、必杀技等指定事件。指标判断的对象不同，不能用前一个数代替后一个数，也不能据这张表给所有游戏模型排总名次。StatePlay v1 表1与§4.1
这为交互原型提出了一个具体问题：用户要求角色放必杀技，系统究竟要证明“动作表达进去了”，还是“当前资源允许出招，出招后资源和结果也正确”？围绕 H3-World、Incantation、ABot-World 与 StatePlay 的比较，只有放进这个问题才有实用意义。语言、专用动作表示与显式状态各自解决什么，决定了工程师应从 项目 中借哪一部分能力。
1. 同一句“放必杀技”，可能对应相反的正确结果
作者机制示意或未执行条件对照；不代表模型运行或真实游戏结果。
StatePlay 选择《街头霸王3》作为研究环境。论文描述的规则中，技能条达到条件才能触发必杀技；资源不足时输入同一命令，会形成普通攻击。于是，“输入里出现出招命令，视频里也出现华丽招式”在资源充足时可能正确，在资源不足时反而可能违反机制。
这里最重要的差别是条件。动作描述表达意图，规则还要读取动作之前的资源、生命值与比赛进度。只检查人物有没有做出指定姿势，无法回答这次出招是否合法。StatePlay 因此从模拟器内存采集 timer、双方 HP 与双方技能条，共五个状态量，而不是只用视频估计这些数字；其训练数据同时包含动作和状态。本文引用的是论文的数据构建说明，没有下载或审计实际数据载荷。论文§3.1
对读者而言，这个观察改变了比较顺序。先明确项目要允许什么变化：若只是根据导演指令生成一段战斗片段，正确表演动作可能已经很有用；若用户要在同一场比赛中消耗技能条、判定胜负，并让后续动作依赖结果，就必须留下资源与事件的证据。后一种需求不能靠给 提示词 加上“遵守游戏规则”来完成验收。
这里还要把“动作发生”与“事件成立”分开记录。前者可以检查人物是否做出某个运动，后者要核对这次运动在当前条件下应该造成什么结果。例如，同一个输入被模型稳定表现出来，可能说明动作条件有效；若该初态尚未满足出招前提，稳定出现特殊招式反而值得保留为失败案例。这种判断必须依赖选定环境的规则，不能只看画面是否精彩。
因此，本文的对照单没有预先填入技能条阈值，也没有把“资源不足就一律无动作”当成所有游戏的规则。具体环境可能把命令解释为普通攻击、忽略输入，或存在其他前提。接入者先取得可信规则与状态记录，才能填写期望事件。这里解释的是验证对象，不是本文已经做过的规则实验。
2. H3-World 与 Incantation：语言给谁、何时生效？
固定版本文档/源码忠实摘录与作者职责示意；来源条件见图，官方运行报告未复测。
H3-World 把有限键态转换成角色与镜头动作句，再把句子绑定到视频时间位置。它处理的是语言动作如何在 预训练 H3 主干里获得明确的时间归属。当前固定源码 annotate_from_keys9 的输入是槽级九位状态；输出仍是受规则约束的短句。它不是一个看到任意语言就能执行所有游戏动作的控制服务，也不能直接假定已具备“必杀技资源不足则拒绝”的状态路径。H3固定动作编码
Incantation 把语言接口扩展到同一视角下的多个实体。当前公开示例分别保存 player_actions 与 boss_actions：玩家可以前进、翻滚、挥剑，Boss 可以前进、挥杖或跳起砸地。动作可写成字符串，也可写成“动作名、秒数”一对。下面只节选官方示例中的结构，省略其余动作；这是一份可读输入证据，不是本文执行过的战斗：
{
"player_actions": [["Move forward", 1.5], "Roll forward", "Greatsword thrust"],
"boss_actions": ["Jump and mid-air slam", "Tail swipe"]
}
这里的增量是“谁做什么”得到独立的实体槽位。只用一个笼统场景提示，容易把玩家与对手的动作混在一起；分别给出动作列表，则让接入者有明确对象可以检查。H3-World 解决的逐时间动作归属，与 Incantation 强调的多实体语言控制，因而不应只因同属 language action 就被写成相同接口。
Incantation 的固定 README 也把发布范围写得很具体：它是 蒸馏 因果学生的推理预览，包含预览数据子集与 Margit 权重；训练阶段、完整数据、诊断与评测脚本等未包含在这个预览中。其代码说明用 T5 编码逐实体动作提示，并以带 KV-cache 的因果学生推进生成。本文只审读这些材料，没有试玩在线演示，也没有证明所有实体、所有动作词都已获得同样控制效果。Incantation固定说明
这两条语言路线能帮助应用表达语义、实体与时间，却不因文字可读就自动获得规则正确性。“玩家用大剑刺击”没有携带伤害结算、攻击是否命中、对手是否已经死亡等全部信息。反过来，专用动作向量也并非天生遵守规则；它只给出更明确的输入维度，合法性仍取决于状态与执行机制。
3. ABot-World：控制运行时与状态预测另有分工
ABot-World 当前 README 重点展示的是动作驱动、持续生成与桌面 GPU 运行。它报告在单 RTX 5090 上实现 720p、16 FPS、1.2 秒 latency 、19GB 显存。这是一组有指定设备的官方报告，本文没有在该设备复现；也没有把这个 latency 重新解释为已经测过的浏览器按键到首个受影响画面时间。这里保留这些数字的用途，只是说明其公开交付重心与 H3-World 的动作适配研究不同。ABot固定说明
它的公开运行配置可以进一步对上具体对象：学生 checkpoint 为 ABot-World-0-5B-LF，配置有少步去噪序列、每块帧数、局部注意力窗口和参考槽位。它们指向怎样持续推进与控制资源的运行设计；没有一项参数名能替应用证明技能条结算准确。固定运行配置
因此，在研究怎样把动作送入低延迟连续生成时，ABot 是值得审读的运行路线；当产品承诺“资源不足不能出招”时，还得寻找对应状态输入、转移与评价证据。把其持续 rollout 长度、画面帧率直接拿来回答状态问题，会重复开头那个错误：一个指标替另一个对象作了保证。
这也解释了为什么本文没有并列四个 FPS 排行。H3-World 的输出文件帧率与 ABot 指定运行环境中的生成性能不是同一口径；Incantation 的预览实现范围、StatePlay 的研究任务也不同。没有相同硬件、输入、分辨率、时间统计和质量约束，性能数只能保留各自条件。即使以后获得同场测速，规则事件是否正确仍应单独测量。
比较输入表示时，也要区分它便于表达什么，以及系统已经证明什么。语言槽便于直接检查动作属于哪个实体，专用向量便于检查某个控制维度是否被传入；这些是输入可检查性的差别。实际生成有没有采用这个条件，仍要看对应效果证据；采用后是否产生合法结果，则还需要资源与事件证据。仅凭输入格式，不宜替任何一条路线宣布它更懂游戏规则。
对应用团队，运行路径另有实际价值：一个控制表达清楚、但不符合交付方式的模型，仍可能不适合当前交互产品。研究持续生成配置是在回答如何把观察不断送给用户；研究状态转移是在回答观察和数值为何应当这样变化。两项工作可以互相配合，但不能用其中一项的公开结果替另一项免验。本文没有运行这些路径，保留的是各项目可审读的职责范围。
4. StatePlay：把规则所需数字变成可检查输出
固定版本源码忠实摘录与作者状态用途示意；省略与参考范围见图，未运行数据或模型。
StatePlay 的公开实现把视觉与状态分开表示，再通过联合注意力交换信息。专用动作条件同时进入两个分支；状态分支预测五项归一化状态，视觉分支生成视频。它不是把技能条写进一句全局提示，而是增加一组可对照的数值输出。固定仓库架构说明
源码中的列名直接给出了可检查对象：
STATE_COLUMNS = ("timer", "hp1", "hp2", "meter1", "meter2")
其保存函数在存在参考状态时，为每一列写出 _pred、_true 与 _err。 CLI 将同一 parquet 路径作为动作与状态来源，默认输出 MP4 及相邻的 _state.txt；pipeline 分别加载初始条件与参考状态，初始化其余状态噪声，再产生预测。参考状态用于输出对照，不应被写成“模型凭空知道了真实未来”。状态读写源码 · CLI · pipeline
初始值也值得追到实现。CLI 默认 state_sampling=end；加载函数按输入行数与 latent 数量选择首个分组末端的状态作为初始 token ，并非在所有采样模式下都简单取 parquet 第一行。接入或比较之前，要保存实际采样方式、来源行及归一化规则，确保“同一初态”真有同一含义。本文只静态审读该路径，未运行 parquet 加载或模型。
现在就能把比较缩到一张职责表。它是从已核实接口整理出的工程判断，不是四个系统已成功拼接的 架构 图。
| 本次需求 | 优先审读哪项机制 | 仍需单独证明 |
|---|---|---|
| 让有限角色/镜头动作进入指定视频时间段 | H3-World 动作文本与时间绑定 | 是否覆盖目标动作，生成是否遵从 |
| 分别驱动玩家与对手的语义动作 | Incantation 逐实体语言槽 | 当前权重的实体/词汇范围与实际效果 |
| 将控制接入持续生成运行路径 | ABot-World 因果学生与运行配置 | 本机端到端响应、资源与长时质量 |
| 同时对照生命值、技能条和画面 | StatePlay 状态分支与状态输出 | 数值、可见指示与规则事件能否共同一致 |
最后一格仍不是硬规则引擎。StatePlay 论文附录 C 明确承认：状态预测准确时，画面中的血条或技能条仍可能偶尔不一致；多个机制同时发生，视觉质量也会下降。独立数值头的价值是让错误更可定位，不是宣布规则违规已经归零。论文失败案例
这些输出还提供了一个错误定位顺序。若动作条件没有进入所期望的实体或时间位置，先核输入转换；若动作已发生，但数值变化与可信参考不同，保存预测误差；若数值轨迹看似正确而HUD画法不一致，则把画面一致性问题单独保留。三种情况会影响后续排查方向，因此不应只用一个“看起来能玩”的结果覆盖它们。这个顺序是作者从接口证据整理出的建议，未在实际系统执行。
同样，参考列的存在不代表模型的所有条件都已被公平对齐。比较之前，需要核实参考来自哪里、归一化怎样解释、初始token实际对应哪一行，以及当前输出究竟有哪些字段。如果只看到MP4而没有状态文件，应如实保留信息缺口；若状态与视频不在同一时间位置，先解决对应关系再计算差异。把这些身份与时间关系记录下来，比先汇总一个平均误差更能保护结果的含义。
5. 从一次资源不足的出招开始验证
作者机制示意或未执行条件对照；不代表模型运行或真实游戏结果。
读者最小可带走的产物，是一份“同动作、不同技能条条件”的对照单。以下是作者提出的未执行方案，阈值和期望结果必须从选定游戏的可信规则或引擎记录取得，不是本文实测，也不是上述四个仓库通用的 API。
准备一组资源满足出招条件的初态，再准备一组略低于条件的初态；两组保持目标角色、对手、位置、计时、命令序列和待比较设置一致。若规则涉及生命值、距离、命中或其他前提，也必须控制或记录；不能只改技能条，却把其他前提变化算成状态建模差异。对于带 HUD 的输入，初始图像与数值条件应同步对应各自初态，避免故意给出互相冲突的起点。
记录不必很大：
游戏/规则版本；模型/权重/代码版本；输入图与动作文件身份
初始状态来源；采样方式；实际选中的状态行；技能条条件
实际送入模型的动作表示：键态、实体语言或专用向量
期望事件：允许必杀技 / 按选定规则无法触发
实际画面事件；状态预测；参考引擎状态；首次不一致位置
若只取得动作脚本与视频，数值预测这一格应写“接口未提供”；若没有可信引擎状态，真实扣血与资源结算应写“缺参考”；若动作未触发，先确认输入是否被解析、是否在当前词汇或动作维度范围内，再判断生成失败。三类缺证不能被平均成一个成功率。对 StatePlay 当前示例，先核初态采样与对应文件，才能开始改条件；不能把未修改的 CLI 当成接受任意外部状态对象的服务。
若要量化这组实验，预先固定样本、有效条件与判断方式，保留失败与无法判断的情况。固定 seed 可以减少一部分比较差异，却不能保证两条随机生成轨迹除了技能条之外完全相同。实验最多说明所测场景和条件下的表现；单次出招成功不证明所有技能、所有资源阈值都可靠。
对需要严格得分、资源消耗与胜负的产品，一个更简单的起点是让可信游戏引擎负责状态转移，把生成模型用于它确实支持的视觉或语义部分；代价是必须验证生成输出服从这些状态。若让模型自己预测状态，就接受它是预测值，并保留与规则、画面相互核对的过程。这是工程选择，不是本文已经交付的混合系统。
开头那组指标留下的启示很具体：角色按命令攻击，仍可能没有完成正确的机制事件。比较交互世界模型时，把实体动作、持续运行与状态转移分别追到实际输入输出，再决定哪里需要模型、哪里保留引擎。这样得到的是可验证的集成选择，而不只是一个画质与 FPS 更长的排行榜。
资料与范围
核实日为 2026-10-17。H3-World 固定 f0c7be2acbbde8256b2473f6e7b088f58272acae，Incantation 固定 41fd8321df6ea9cff5d719a3d1c960a06e3bf779，ABot-World 固定 5c3f7260f2346ebb60a49efb81a7db5bfe15d7e5，StatePlay 固定 8355dc956422da4e70f5062be40f511f91e37a66；论文使用 H3-World 2609.01560v1 与 StatePlay 2607.26754v1（2026-07-29）。完整原文、来源 SHA、精确摘录与查重关系随研究包保存。ZIP 第06章只作选题种子，未沿用其全景排名与未核实趋势。本文未下载权重、运行生成、试玩演示、复测裁判或验证四项目互联，性能与评测值保留作者归属。
