games-development-ai/docs/agent-specs/_archive/2026-06-20-OpenGame对照分析与复刻缺口.md

date, topic, status

date	topic	status
2026-06-20	OpenGame 对照分析与复刻缺口	分析 · reference

产出方式:clone OpenGame 真源码(github.com/leigest519/OpenGame,CUHK MMLab,arXiv 2604.18394)到 /root/oss/OpenGame,5 个 agent 分片深读真代码(agent核心/子agent · 游戏生成工具 · Game Skill 经验进化 · MCP+环境 · OpenGame-Bench/端到端/GameCoder-27B),综合成本档;6c6g 编排 + 可读性打磨。结论锚在真源码。 三部分:我们是什么(SAA graph 配置式)→ OpenGame 怎么生成游戏(深析主体)→ 要复刻它我们 SAA 缺什么。 定位更新(2026-06-20):本档现作 OpenGame 外部标杆 prior-art 深析参考——“我们要做什么”的复刻缺口已并入单一 SoT 生成主线架构演进路线.md(去那份拿统一 to-do)。本档保留供查 OpenGame 内部机理与逐项缺口的来龙去脉。

造梦AI 生成主线架构分析:我们是什么,OpenGame 怎么生成游戏,以及要复刻它我们还缺什么

一、我们现在是什么

造梦AI 的游戏生成主线,本质上是一条用便宜通用模型驱动、用确定性的图编排约束控制流、用九门 harness 兜底验收的流水线。它不是一个让强模型自由发挥的开放式编码 agent,而是一台被刻意设计成可靠的、固定相位的生成机器。

具体来说,它的骨架是 Spring AI Alibaba(SAA)的裸 StateGraph,一共 16 个节点——从 render(渲染入口)、classify(分类)、design(设计)、generate(生成)、validate(校验)、scaffold(脚手架)、asset(资产)、build(构建)、play 与 player(试玩与玩家视角)、nreview(评审)、modify(修改)、escalate(升档)、repair(修复),到 emit(产出)与 giveup(放弃)。需要强调的是,这些节点不是声明式的 YAML 配置,而是一段段实打实的 Java NodeAction 代码;控制流是由图的节点和边预先固定下来的,而不是由模型在运行时自由决定"下一步该调什么工具"。模型层面,我们硬编码了 11 个便宜通用模型(以 deepseek-v4-flash 打底),没有任何一个是为游戏代码专门训练过的;成本策略明确是"便宜模型 + harness 门兜底",而不是去训一个专用的大模型来扛质量。

围绕这条主线,有几个当前状态值得讲清楚。Prompt 目前是 Java 硬编码常量(SaaPrompts),虽然 Prompt Registry(contracts/prompts/registry.yaml)作为第 8 类契约已经存在,但还没有接线进生成链路。验收分两层:底层是九门确定性 harness(A 到 I 的机制地板——装载、未捕获异常、掌帧、渲染、活性、真接线、输入有效、机制进展加 latch 终态、控制跟手),上层是 player 软门(M3 视觉/文本 LLM 的判断)。生成态是 gameDefinition 结构化源(双证已经成立但尚未 cutover)与 iife 双轨并存,引擎用的是 LittleJS 而非 Phaser。当便宜模型连续失败时,有一条救场阶梯:升档到 stage2,再不行就 giveup。

还有几件"规划了但 MVP 阶段简化掉"的事,正是本次对照 OpenGame 的重点:Debug Skill 我们规划过但 MVP 做了简化;Template Skill 那种"从完成的游戏项目反向生长品类骨架库"的能力我们完全没有。接法上,我们走的是接法 A——单发节点,没有 subagent;接法 B 与 ReactAgent.asNode 延到了 Phase 1.5;MCP 框架虽然 SAA 支持但没用起来。

一句话定调:我们已经有了一条结构正确、控制流确定、底层验收很硬的流水线,但生成质量的"经验复利"层(Template/Debug Skill)和资产/设计的工具厚度,还很薄。 而这恰恰是 OpenGame 值得我们深读的地方。

二、OpenGame 是怎么生成游戏的

它的出身:不是新框架,是 Qwen-Code 的二次 fork

读 OpenGame 源码,第一个、也是最重要的认知矫正是:它不是从零写的 agent 框架,而是 Gemini-CLI → Qwen-Code → OpenGame 这条二次 fork 的产物。 证据是硬的:geminiChat.ts 顶部注释自承是 js-genai chats.ts 的逐行拷贝改版,subagent.ts 的版权头写着 Qwen,系统 prompt 里自述"built on top of the Qwen Code agent framework by Alibaba Group",shell 执行时注入 QWEN_CODE=1 环境变量,MCP 客户端名还残留着 qwen-cli-mcp-client、OAuth 客户端名是"Gemini CLI MCP Client"——三处铁证并存。

这个出身决定了 OpenGame 的能力分布:MCP 接入、shell 沙箱、会话持久化、配置面、OAuth 这一整套执行基座是从上游成熟代码完整继承的,OpenGame 自己真正写的,只有 tools 层的四个游戏专用工具(classify/generate-gdd/generate-assets/generate-tilemap)、音乐合成服务,以及 agent-test/templates 下那套 Phaser + Vite 工程模板。换句话说,要"复刻 OpenGame 的引擎",本质是复刻 Qwen-Code,而不是发明什么新架构——而我们已经选了 SAA 图这条不同的路。这一点先记下,它会贯穿整个对照。

它的主循环:三层权力分配的 ReAct

OpenGame 的 agent 主循环,核心不是一段编排脚本,而是一个经典的 ReAct/工具循环,但被干净地拆成了三层,值得细看它的"权力是怎么分配的"。

最外层是非交互 CLI 里的 while(true)(nonInteractiveCli.ts)。每一圈做四件事:用当前消息调一次流式模型;消费事件流,把模型发起的工具调用请求累积起来,把文本和思考直接打到标准输出;流结束后,如果有工具请求,就逐个真正执行,把每个工具的返回打包成一条 role 为 user 的 functionResponse 消息,回灌到循环顶部——这就是"喂回结果再循环"的本质;而如果这一圈模型只说话、没发起任何工具调用,就终止。所以它的收敛条件极其朴素:模型这一回合只说话不调工具,就算完成了。

中间一层是 client.ts 的 sendMessageStream,它负责把"一个回合"武装起来:压缩历史、检查会话 token 上限、注入 IDE 上下文增量、注入 system-reminder、跑循环检测,然后才进入真正的单回合。最内层是 turn.ts 的 Turn.run,它只负责调一次 chat.sendMessageStream,把模型吐出的 chunk 翻译成事件(内容/思考/工具请求/完成/错误)——关键设计是:Turn 自己绝不执行任何工具,它只发出"我要调这个工具"的请求事件。

这个"权力分配"是整个设计的精髓:模型回合只有发起权,执行权牢牢握在外层循环手里;工具结果统一以 user-role functionResponse 回灌。三层职责清晰,可移植性很好。围绕这条主循环,它还打了好几个护栏:MAX_TURNS=100 硬顶、会话级回合上限、token 上限、LoopDetectionService 检出复读直接退出。最有意思的一个补丁叫 checkNextSpeaker——当模型说了"接下来我要做某某"却没真去发工具调用时,它会用一次额外的 LLM 判定 next_speaker,如果判定该轮到模型,就自动注入一句"Please continue."把它顶回正轨。这是专门用来对付"模型话痨但不动手"的早停问题的,而便宜模型恰恰最容易犯这个毛病。

它的韧性:把一切错误降级成喂回模型的 functionResponse error

如果说主循环是骨架,那 CoreToolScheduler 就是让这副骨架在脏数据下不散架的关节。它把每个工具调用建模成一个状态机:validating → scheduled →(可能 awaiting_approval)→ executing → success/error/cancelled。调度语义可以一句话概括为:批内并行、批间串行、确认门齐开才执行——同一批工具调用先全部发起再一起 await(并发),但不同批次之间严格串行排队;而且要等这一批所有调用都到了 scheduled 或终态,才统一开始执行。

但对我们最有借鉴价值的,不是它的并发语义,而是它的容错哲学:幻觉工具名、参数非法、被用户拒绝、工具执行失败——这些统统不让它崩溃,而是降级成一条 functionResponse error 喂回给模型,让模型自己读着错误去纠正。尤其当模型造了个不存在的工具名时,它会用 Levenshtein 编辑距离算出"你是不是想用 X"的建议,一并塞回去。便宜模型最大的问题就是输出脏——乱造工具名、参数对不上——而这一层"错误即上下文"的兜底,比模型本身更决定成败。 这是 OpenGame 给所有想用便宜模型的人上的第一课。

它的子 agent:一层深的"上下文隔离 + 只回吐结论"

OpenGame 的 subagent 是一等公民,而且设计得很克制。主 agent 把 task 当成一个普通工具来调;系统 prompt 里明确教模型"做文件搜索这类活优先用 task 工具以减少上下文占用",每轮请求前还会动态注入一段 system-reminder 把可用的子 agent 名字塞进去、怂恿模型去委派。

机制上,子 agent 会开一个全新的 GeminiChat,只继承环境历史,system prompt 由模板占位符渲染(主 agent 只通过 task_prompt 注入任务描述),并且自带一个独立的 while(true) mini-loop。最关键的两个设计:一是子 agent 的工具集被裁剪,而且强制剔除 task 工具本身——所以子 agent 不能再派生子 agent,隔离深度只有一层,这不是任意深度的 agent 树;二是子 agent 跑完几十轮探索后,只把最后一轮的纯文本结论回吐给主 agent,中间过程全吞在自己肚子里。这正好兑现了系统 prompt 里说的"减少上下文占用":主 agent 不会被子任务的探索噪音污染。代价是委派靠 prompt 怂恿而非硬路由,委派质量死死绑在主模型的判断力上——便宜模型在这里大概率不会主动、聪明地委派。

它的系统 prompt:静态人格 + 环境分支 + 模型方言,动态信息走 system-reminder

OpenGame 的系统 prompt 拼装很能体现工程成熟度。一个 getCoreSystemPrompt(userMemory, model) 函数顺序拼接:可被外部 .md 文件整体覆盖的基座大模板(身份、Core Mandates、强制频繁用 todo 的任务管理、软件工程的 Plan/Implement/Verify 工作流,甚至写死了"2D 游戏用 HTML/CSS/JS、3D 用 Three.js"的技术默认);按 SANDBOX 环境变量三选一注入的沙箱段落;按是否 git 仓库追加的 Git 守则;然后是一个很妙的细节——按模型名切换三套 few-shot 工具调用示例方言(通用自然语言、qwen-coder 的 XML 风格、qwen-vl 的 JSON 风格),去适配不同模型对工具调用语法的偏好。

这里藏着两个对我们有用的工程判断。第一,真正每轮变化的动态信息不进系统 prompt,而是作为 user 消息或 system-reminder 在每轮注入(IDE 上下文、subagent 提醒、plan-mode 提醒)——这样系统 prompt 可以被缓存,省钱。第二,"按模型切 toolcall 方言"是支撑多便宜模型的关键工程点:换一个便宜的 Qwen 系或别的模型,主要改的就是这套方言示例和底层的 ContentGenerator(它支持 OpenAI/Anthropic/Gemini/Vertex/Qwen 五种认证,baseUrl/model/apiKey 全是 env + config 双层可配,还带 retryWithBackoff 和 429 回退到 flash),而循环骨架完全不动。"用便宜通用模型"在 OpenGame 里是一等公民,开关早就铺好了。

它真正怎么把一句话变成游戏:四个原子工具 + 六阶段 SOP 接力

现在进入最核心的部分——OpenGame 的工具集刻意地小,只有四个游戏专用工具,没有一个"端到端生成游戏"的大黑盒。生成逻辑全靠 agent 用这堆原子工具,按相位一步步串起来。而最反直觉的发现是:这条端到端流水线没有任何中央编排文件(全仓 grep 不到驱动相位的 workflow 代码),它是靠两样东西驱动的:一份叫 custom.md 的确定性 SOP 系统 prompt,以及每个工具返回内容末尾注入的 <system-reminder> 接力指令。

让我顺着六个相位讲一遍,这是整篇分析最该被吸收的部分:

Phase 1,物理优先分类 + 脚手架。 agent 调 classify_game_type,把用户那句话归入五个 archetype 之一:platformer、top_down、grid_logic、tower_defense、ui_heavy。它的分类规则刻意"不看品类名,只看物理"——重力方向、视角、移动方式,系统 prompt 里还专门列了易错例(Terraria 是 platformer 不是 top_down)。这个工具的容错解析很务实:先剥 markdown 代码围栏,JSON 解析失败就退化成在字符串里找关键词,再不行默认 platformer。但它真正的产出不在分类结果本身,而在它返回内容里塞的一段 system-reminder——直接给 agent 下一步要跑的 cp 命令(把 templates/core 和 templates/modules/{archetype} 拷进工作区,把对应文档拷进 docs),并指示"下一步调 generate-gdd"。这是整条链的路由器:archetype 一旦定下,后面用哪套 GDD 规则、什么视角的资产、COPY 哪套模板,全被决定了。分类错,后面全错。

Phase 2,把一句话编成六节技术规格书。 agent 调 generate_gdd,它会向上递归找 docs 目录,动态拼三层规则——通用 GDD 格式、该 archetype 的设计视角规则、该 archetype 的 template_api.md(可用的代码能力/hook 清单),找不到文件就回退到内置规则(内置规则本身极其详尽,光 grid_logic 那段就有上百行讲三相回合管线、cell 类型、undo、AI)。它真发一次 LLM 请求,产出一份六节的 GAME_DESIGN.md。这份 GDD 的精髓在于:它不是给人看的文案,而是一份"每一节都硬绑一个下游工具入参或代码文件"的契约——Section 1 的资产表喂给 generate_game_assets,Section 4 的 ASCII 布局喂给 generate_tilemap,Section 2 的数值合并进 gameConfig.json,Section 3/5 去改 LevelManager 和 main.ts。它把开放式的"做个游戏"收敛成了一张结构化、可被便宜模型逐项落地的待办清单。而约束便宜模型不跑飞的,是它的三条铁律:Config-First(数值只能进 gameConfig)、Zero Custom Code(只用模板已有行为)、Hook Integrity(绝不许编造 template_api.md 里没有的 hook)。返回内容末尾又是一大段 system-reminder,命令 agent 存盘后逐 Phase 往下走,还专门写了"DO NOT STOP. CONTINUE TO PHASE 3 NOW"。

Phase 3,多模态资产流水线——这是最重、最难抄的一块。 generate_game_assets 不是简单调个文生图,而是一整套"生成 → 抠图 → 视频抽帧 → 多级回退 → Phaser 清单装配"的流水线。背景图强制"纯场景无人物无文字";角色图文生图后过抠图服务去白底;动画是亮点——先生成 idle 基帧,然后优先走图生视频(I2V)再用 ffmpeg 本地抽帧逐帧抠图,如果没有 ffmpeg 或失败,回退到图生图(I2I)逐帧编辑;音频则是三级回退——文生视频抽音轨,失败就让模型产 ABC 记谱法再用 Python 的 symusic 库离线合成 WAV,再失败就纯程序生成占位音。瓦片集强制"先画 3×3 九宫格再扩成 7×7 blob"。所有产物登记进一份 Phaser 能直接 load.pack 的 asset-pack.json。这块每个模态都有降级路径保证不空手而归,但它依赖视频模型 + ffmpeg + 抠图服务——便宜的文生图模型替不了动画质量,这是真壁垒。

Phase 3 配套,确定性贴图——OpenGame 最聪明的工程判断之一。 generate_tilemap 把"AI 画不好整张地图"这个老问题,拆成了"AI 只画 3×3 材质 + AI 只写 ASCII 布局",中间用一个确定性的 8 邻域 bitmask 自动贴图算法(根据上下左右及对角是否实心,算出 47-tile blob 里的精确瓦片 id)来补全墙体接缝和拐角。这等于用确定性算法绕开了模型的空间推理能力,极大降低了对模型的要求。而且它有个关键的架构判断:只对 platformer/top_down 用瓦片地图;grid_logic/tower_defense/ui_heavy 故意走代码定义网格,理由是这类逻辑游戏运行时 cell 会变(门会开、洞会填),用瓦片地图会造成双数据源不同步。

Phase 5,落地代码——靠 smart_edit 把规格变成模板里的真实代码。 前面 GDD、资产、tilemap 产的都是"规格和素材",真正把游戏代码写进模板文件,靠的是 agent 反复调 smart_edit(注册名就叫 edit)。它的三级匹配很能说明问题:精确字面替换 → 柔性匹配(逐行 trim 后比对、自动套用目标缩进)→ 正则匹配(把 token 用 \s* 串起来容忍空白差异);三级都不命中时,还会拿 instruction 和原始错误喂给 LLM 重算一遍 search/replace 再试。这套三级匹配加 LLM 自纠错,完全是为了对抗便宜模型给出的 old_string 经常对不上(空白、缩进、转义不一致)——这是"改源不改包、按 GDD 实现每个文件"这套范式能跑通的工程保障。

把这六个相位串起来看,OpenGame 的核心洞察就清楚了:它不靠图编排,靠的是"预建模板 + archetype 路由 + GDD 把任务结构化成填空题 + system-reminder 单线接力 + 工具内置降级与自纠错"。生成质量不是来自强模型自由发挥,而是来自把开放问题收敛成填空题。 不过这条 system-reminder 单线接力是它的软肋:它靠"DO NOT STOP"这种口头督促来推进相位,便宜模型很容易在中途断流。

它的三大支柱:经验进化、专训模型、VLM 验收——以及论文与代码的落差

OpenGame 论文卖的是三大支柱,但深读源码后必须诚实区分哪些是真代码、哪些只是 README 宣称。

第一支柱,Game Skill 经验自进化——这是仓里真正能跑、也是真正的护城河。 它由两套同构的离线进化机制组成,两者都遵循同一个闭环:完成一个任务 → 抽取经验 → 去具体化 → 沉淀回持久库 → 下次先查库命中复用 → 重复达到阈值再升格成可执行规则。而且都做成"LLM 优先 + 规则兜底"的双轨,库本身是纯本地 JSON——零向量、零 embedding。

Template Skill 从一个 game-agnostic 的 Phaser 元模板 M0 出发,每完成一个项目跑五段流水线:Collector 读文件树、Classifier 用 LLM 加启发式判物理 regime(注意它是"library-aware"的,会把库里已有家族的物理画像塞进 prompt,让 LLM 判断新项目是命中旧 archetype 还是新物种,而 archetype 是 LLM 自创的 snake_case 物理标签,不是预设枚举)、Extractor 纯规则抽类继承树和 hook、Abstractor 用 LLM 把具体代码泛化成模板(角色名→Player、硬编码值→config 引用,并给每个文件打 role:base_class 是 KEEP 不可改、copy_template 是待复制改)、Merger 决定建新家族还是并入旧家族。命中复用的匹配键是物理三元组(重力/视角/移动)加 archetype 名,而不是文本相似度;复用单位是整个 family;还有个 stability 信号 = min(1, 贡献项目数/5),五个项目贡献过就算满稳定。所以这套"经验记忆"本质上是 case-based reasoning,不是 RAG。

Debug Skill 是论文 Algorithm 1 的"REPEAT...UNTIL"实现,也是一本活协议 P。它的数据结构是 (signature, cause, fix) 三元组,signature = stage + errorCode + 正则化的 messagePattern + fileContext。协议分两类条目:reactive(失败后诊断用)和 proactive(执行前预校验用),种子里有 7 条 reactive 加 7 条 proactive 的 Phaser 常见错。它的循环是:先跑 proactive 预校验,然后 build → test,失败就 diagnose(先用 signature 加权打分匹配已知错,errorCode 权重 0.5、messagePattern 0.35、fileContext 0.15,阈值 0.8,命中就直接 applyKnownFix,未命中才走 LLM 诊断)→ repair → 重跑同 stage 验证 → 记录结果。进化最实的一环是:reactive 的事后修复在重复出现 3 次后,会被自动升格成 proactive 的事前预校验规则——经验从"救火"升级成"免疫"。而且只有跑通验证的修复才进库,这是它唯一的质量门。

但要诚实:这套自进化"是真的,但很轻"——只有单调累积、计数强化、阈值升格,没有遗忘、淘汰、冲突消解;模板冲突用"保留更长文件"这种启发式;规则一旦生成就不回收。更重要的是,Template Skill 侧完全没有"这个沉淀的骨架真能编译、真可玩"的回验门,带病的骨架可能直接沉进库。 还有一个关键短板:Debug Loop 只验证到 build + test 层,完全不验证可玩性。

第二支柱,GameCoder-27B 专训模型——README 宣称,但权重、训练码、数据都不在仓。 它被描述成一个为游戏定制的 27B 代码模型,三段式训练:游戏引擎语料持续预训练 → 在引擎 API 和 bug-fix 轨迹上 SFT → 用真实可玩性当奖励信号的 execution-grounded RL。但仓里只有集成点和文字描述。反过来看,这恰恰证明了框架被刻意设计成 model-agnostic——实测代码里默认接的是 openrouter 上的 claude-opus-4.6 而不是 GameCoder,设个 OPENAI_MODEL 就能换。专用模型不是跑通的必要条件,模型这层可以被便宜通用模型替换,质量缺口靠模板约束加 Debug Skill 兜底。

第三支柱,OpenGame-Bench 三轴 VLM 验收——README 宣称,但代码库里根本不存在。 README 把它描述成动态启动生成的游戏、headless 浏览器执行加 VLM judging,沿 Build Health(能否构建运行)、Visual Usability(画面是否可用)、Intent Alignment(是否符合意图)三轴打分,跨 150 个 prompt。但 README 自己写着"evaluation pipeline will be released soon",全仓 grep puppeteer|playwright|VLM|screenshot|judge 在源码里零命中。仓里真实的"验收"只有两层:生成 driver 的 success 仅取 SDK 返回的 subtype,根本不打三轴分;debug-loop 只跑 build + test。 所谓的 headless 是 Phaser HEADLESS 类型跑在 jsdom 下,canvas 用 node-canvas 的 Image 桩,不渲染真实像素、无真实浏览器、无 VLM。 把 README 当代码现状,会严重误判。

它的执行基座与 MCP:从上游继承的重型沙箱,以及一个被误读的扩展插槽

最后补两笔执行环境。OpenGame 的 shell 执行是重型的:PTY 优先(node-pty 加 @xterm/headless 把 ANSI 输出解析成结构化数据),拿不到 PTY 就用 child_process 兜底,detached 让命令独占进程组,中止靠对进程组发 SIGTERM 再 200ms 后 SIGKILL,还用 pgrep 回收后台子进程 PID,外加 docker/podman/seatbelt 沙箱和 HITL 白名单。这是 agent "写代码→跑构建→看报错"闭环的物理基座,深度绑定 Node 生态。

至于 MCP,必须澄清一个常见误读:OpenGame 自身零内置 MCP server。 它的 MCP 客户端是从上游完整继承的成熟管线(四种 transport、OAuth 全套、把 MCP tools 经 mcpToTool 降维成 Gemini FunctionDeclaration),但 getMcpServers 默认是空的——没有任何硬编码的 cocos/figma/playwright server。MCP 在 OpenGame 里只是一条"用户在 settings 里配什么就连什么"的通用扩展总线,游戏生成能力根本不来自 MCP,而来自内置确定性工具加工程模板。 谁要是以为复刻 OpenGame 得复刻一堆 MCP server,就彻底读反了。

三、要在 SAA 图上复刻 OpenGame,我们到底缺什么

把 OpenGame 看透之后,落到我们 SAA 配置式生成的现状上,我把缺口分成四类来诚实交代:能直接抄的设计、得换底座重写的、我们其实已有等价物的、以及我们刻意不走所以抄不动也不必抄的。

先说一个贯穿性的范式判断,它决定了"抄"的边界。OpenGame 是命令式自主循环——while(true) 里模型自由决定下一步调什么工具,控制流由模型驱动;我们的 SAA StateGraph 是声明式有向图编排——节点、边、条件预先固定,控制流由图驱动。这是两种正交范式。所以 OpenGame 的 client.ts/turn.ts 那套主循环,我们不该嫁接进来——硬塞就成了项目 CLAUDE.md 明令反对的"缝合设计"。 务实的态度是:把 OpenGame 的控制流交给 SAA 图来表达(我们本来就这么做的,而且对卡 80% 成功率门而言,图的确定性比"DO NOT STOP"的口头督促更稳,这是升级不是抄);把 OpenGame 的工具层、韧性兜底、防脏脚手架当成零件库,原样落进 SAA 节点内部的工具执行环节。 一句话:抄它的工具与兜底,不抄它的"模型自由驱动主循环"。

下面逐项对照。

能力	OpenGame 有	我们的现状	优先级	能不能上 SAA 图
物理优先分类	classify 工具 + 5 archetype + 易错例 prompt	有 classify 节点,但 archetype 体系/物理优先 prompt 待补	高	直接做成 classify 节点
GDD 结构化契约	6 节硬绑下游 + 三铁律 + 三层规则	design 节点存在,契约化程度待补	最高	直接做成 design 节点
确定性贴图	bitmask 自动贴图 + 3×3→7×7	无(且引擎是 LittleJS 非 Phaser)	中	纯算法,直接搬
smart_edit 自纠错	三级匹配 + LLM 重算	gameDefinition 结构化生成弱化了文本编辑需求	中	落进 generate/modify 节点
Template Skill 骨架库	五段流水线 + family 自进化	完全没有	高	离线进化,SAA 外挂库
Debug Skill 活协议	(sig,cause,fix) + 升格规则	规划过、MVP 简化	高	diagnose/repair 节点 + checkpoint
资产流水线	I2V/抠图/多级回退/装配	走 mmx-cli	中	asset 节点接 mmx
可玩性验收	论文宣称三轴 VLM,代码未开源	机制层=九门真机 CDP(强);语义层=player 软门 M3 截图判(弱)	机制已领先·语义待补强	机制已有;语义软门待做厚
专训模型	GameCoder-27B(权重不在仓)	便宜通用模型 + harness	不抄	路线不同

第一类,设计可直接抄进 SAA 节点(价值最高):

物理优先分类的 system prompt(含易错例)加五 archetype 体系,本质就是一个 classify 节点加 JSON 容错解析,可以直接照搬。GDD 的"六节每节映射下游"契约加三铁律加按 archetype 动态拼三层规则,是 OpenGame 最值钱的产物——它把开放问题结构化成填空题,这正是我们用便宜模型卡 80% 成功率门最需要的杠杆,做成一个 design 节点,内置规则可以整段移植。确定性 bitmask 贴图是纯算法,与模型无关,直接搬。smart_edit 的三级匹配加 LLM 自纠错对便宜模型尤其必要,务必移植(虽然我们走 gameDefinition 结构化源会弱化纯文本编辑的需求,但 modify/repair 节点里仍用得上)。

这里有个范式级前提必须点破:OpenGame 整条链能跑,根本前提是它有一套预建 Phaser 模板和每个 archetype 的 template_api.md hook 清单当"填空靶子"。Hook Integrity 这条铁律之所以能约束便宜模型,是因为有一份明确的 API 清单让模型不能编造。 我们要复刻,就必须先有等价物:一份"LittleJS 增强发行版 + 插件库公开 API 清单"当我们的 template_api。 没有这个,便宜模型一定会编造 API。这一块 OpenGame 抄不来、必须我们自建——而它恰好和创始人 06-17 定的"游戏 = 长生命周期结构化源项目"基座、以及"玩法模板 = 品类框架"的定位是同一个东西。

第二类,设计可抄但得换底座重写:

Template Skill 和 Debug Skill 是我们当前最大的能力缺口,也是最该补的。Debug Skill 几乎可以整体移植思想——验证驱动的 REPEAT 循环加 (signature, cause, fix) JSON 账本加分组阈值升格,正好对应 SAA 裸图里一个 diagnose 节点加 repair 节点加 checkpoint 持久化;签名匹配是纯算法零 LLM,便宜模型只在"诊断 novel 错"和"归纳规则"两处兜底调用,每次命中都省一次 LLM 调用,对便宜模型尤其划算(把高频错变成确定性查表)。 种子协议里的 Phaser 错误码要换成我们自己的 LittleJS 运行时和九门错误码,但结构原样可用。

Template Skill 可以抄它的范式(结构化源项目模板的 KEEP/copy/hook 分层、经验计数、离线蒸馏),但实现得整体重写两处:它的物理信号正则和 hook 命名约定死绑了 Phaser 和 OpenGame 自家模板的类名,我们是 LittleJS 加结构化 gameDefinition,得换成"对 gameDefinition 结构做 archetype 分类、对源项目模块做抽取";更重要的是,它的 Abstractor 泛化对便宜模型是质量重灾区,而原版入库前没有任何回验门,照抄会把坏骨架沉进库——我们必须给它加一道"入库前过九门/可构建校验"的质量门,这恰恰是我们的强项。 另外要预警一个原版的硬缺口:这套进化没有遗忘、淘汰、冲突消解,也没有向量检索,family 一多线性扫加物理三元组离散匹配会退化;等品类规模上来,我们可能需要补一层真正的检索(上 embedding 或按 gameDefinition 字段索引)。

资产流水线属于这一类里"换替代方案"的:OpenGame 的 I2V 抽帧、T2V 抽音轨、抠图后端依赖视频模型加 ffmpeg,便宜文生图模型替不了动画质量——我们的 asset 节点接王蓝莓投资人版已经拍板的 mmx-cli 即可,大幅降级的部分(静态帧 + 程序音)也照 OpenGame 的多级回退思路兜底。

第三类,我们其实已有等价物、甚至更强:

OpenGame-Bench 那套三轴 VLM 验收,有个必须点破的事实:它在开源代码里根本不存在——README 描述得很全(headless 浏览器跑生成的游戏、VLM 沿 Build Health / Visual Usability / Intent Alignment 三轴打分),但全仓 grep VLM|screenshot|judge 零命中,只留一句“will be released soon”。所以单比已经开源出来的东西,我们确实更硬:我们有真机 CDP 真玩的九门加 M3 截图判,OpenGame 放出来的只有 build + test、并不验证可玩性。

但这里要分清两层、别就此自满——这也正是不该把“九门”简单当成 VLM Bench 等价物的原因。九门判的是机制:能不能装载、跑不跑帧、响不响应输入、到不到终态,全是确定性的,这一层我们确定性地领先,没有疑问。可 VLM 的另外两轴——Visual Usability(好不好看)、Intent Alignment(是不是用户要的那个游戏)——九门根本判不了;这两件事在我们这边对应的不是九门,而是 player 软门(M3 视觉模型看截图),而 player 软门是软的、跑便宜模型、不成体系,这恰恰是我们的弱项而非强项。所以正确的动作不是“把九门结果套个三轴外壳就交差”(九门产不出“好不好看”“对不对”这两轴),而是把 player 软门那条做厚:让“是不是要的游戏、好不好看”有更系统、可复现的判定——独立于生成方的交叉校验,甚至一个离线 bench。OpenGame 论文那套三轴设计,正是这一层值得我们抄的蓝本,即便它代码并没放出来。

第四类,刻意不走、抄不动也不必抄:

GameCoder-27B 专训模型——权重、训练数据、RL 代码都不在仓,而且我们的路线明确是"便宜通用模型 + harness 兜底",不自训模型。OpenGame 框架自身的 model-agnostic 设计反而印证了我们这条路走得通:专用模型不是跑通的必要条件。这一项无需复刻。

OpenGame 的命令式自主主循环、重型 PTY 沙箱、@google/genai 的 MCP 适配层,都是 Node/TS 生态产物,且与我们 SAA 图的控制流范式正交。主循环用 SAA 图替代;PTY 沙箱如果将来需要,Java 侧得用 ProcessBuilder/pty4j 自建等价物(工作量不小,但 MVP 阶段我们的 build 节点未必需要这么重);MCP 走 SAA v1.1.2.2 自带的 MCP 支持,别试图移植那套 JS 适配。

---

收口结论。 我们和 OpenGame 走的是两条路,但终点一致:都靠"把开放式游戏生成收敛成受控填空"来让不够强的模型也能稳定产出。OpenGame 用命令式 agent 循环加 system-reminder 接力来收敛,我们用 SAA 图来收敛——在这一点上我们不是落后,而是用了更确定的范式。 真正的差距集中在三处:一是生成约束的厚度(物理优先分类 + GDD 契约 + template_api 清单,这是设计可直接抄的最高价值项,且与"结构化源项目"基座天然契合);二是经验复利层(Template/Debug Skill,我们几乎从零,但设计可抄、且能用九门当原版缺失的质量门);三是资产线(接 mmx 替代)。至于 OpenGame 论文最响的两个卖点,得分开说。专训 GameCoder-27B 我们刻意不走——走便宜通用模型加 harness 兜底,而它自己框架的 model-agnostic 设计反而证明了专训模型不是跑通的必需。VLM Bench 则要说准:它的三轴验收在开源代码里其实没放出来、只在论文里,所以单比已开源的,我们的真机九门已经更硬;但别把“九门”当成 VLM 的等价物——九门更强的只是“能不能跑”这一层(Build Health),而 VLM 的“是不是要的游戏、好不好看”那两轴九门判不了,对应的是我们偏弱的 player 软门,那是待补强的缺口,不是已经赢了的项。

最该立刻动手的,按优先级是:① 把 template_api(LittleJS 插件库公开 API 清单)和 GDD 契约补上,这是一切约束的靶子和最高价值杠杆;② 把 Debug Skill 的"签名→已验证修复→重复升格"活协议落成 diagnose/repair 节点加 checkpoint;③ 把 Template Skill 的骨架进化库按 gameDefinition 重写,并强制加入库前过九门的质量门。 这三件做完,我们这条 SAA 配置式流水线就补齐了 OpenGame 真正值钱的那部分,而且是用我们自己更确定、更可验收的方式补齐的。