docs(analysis): OpenGame 对照分析与复刻缺口(散文·5 agent 读真源码综合)

clone github.com/leigest519/OpenGame(CUHK MMLab)真源码,5 agent 分片深读→综合人读散文。结论:OpenGame=Qwen-Code二次fork+4原子工具+六阶段SOP(system-reminder接力);我们SAA图比其命令式循环更确定、核心不落后;真缺3处=约束厚度(template_api+GDD契约)/经验复利层(Template+Debug Skill)/资产线(mmx);27B专训刻意不走、VLM Bench九门已更强。_index加★指针。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

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

@@ -0,0 +1,148 @@
+---
+date: 2026-06-20
+topic: OpenGame 对照分析与复刻缺口
+status: 分析 · 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 缺什么。
+
+# 造梦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 |
+| 可玩性验收 | README 宣称,代码是空的 | **九门 harness + 真机 CDP + VLM 截图** | 已领先 | 已有 |
+| 专训模型 | 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)。而我们的九门 harness 加真机 CDP 真玩加 VLM 截图 judge,**实际上比 OpenGame 开源出来的更完整、更硬**——OpenGame 的 Debug Loop 只验证到 build + test 不验证可玩性,而真玩门正是我们的强项。所以这块**别照抄它的弱验证**,我们要做的顶多是补一个"三轴打分"的形式化呈现(把九门结果归纳成 Build Health / Visual Usability / Intent Alignment 三个轴的评分形态),让验收报告对外更可读,仅此而已。
+
+**第四类,刻意不走、抄不动也不必抄:**
+
+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 论文最响的两个卖点——专训 27B 和 VLM Bench——一个我们刻意不走,一个我们其实已有更强的等价物。
+
+**最该立刻动手的,按优先级是:① 把 template_api(LittleJS 插件库公开 API 清单)和 GDD 契约补上,这是一切约束的靶子和最高价值杠杆;② 把 Debug Skill 的"签名→已验证修复→重复升格"活协议落成 diagnose/repair 节点加 checkpoint;③ 把 Template Skill 的骨架进化库按 gameDefinition 重写,并强制加入库前过九门的质量门。** 这三件做完,我们这条 SAA 配置式流水线就补齐了 OpenGame 真正值钱的那部分,而且是用我们自己更确定、更可验收的方式补齐的。

docs/agent-specs/_index.md

@@ -26,6 +26,7 @@
 
 ### 生成主线设计链（现行架构）
 - ★ `2026-06-19-生成平台架构演进-review.md` — **多架构师综合·架构演进总方案（review·待创始人评审）**：**零 rewrite/大面积 keep**；病根=策略下沉机制层(多源漂移)+生成质量未达门+验收 oracle Goodhart；演进=策略外置(数据驱动·prompt/模型/品类提为契约)+九门去自评闭环(**latch 胜利/弃守区分=P0**+fail-closed)+单轨化,全程 flag-off 不破灰度；迁移序列挂 plan-001/002 不另起。承 [[agentic编排-SAA]]+固定架构设计链。
+- ★ `2026-06-20-OpenGame对照分析与复刻缺口.md` — **OpenGame(CUHK MMLab,Qwen-Code 二次 fork)真源码深读 + 复刻缺口**(散文·5 agent 读真码综合)：它靠 4 原子工具+六阶段 SOP(system-reminder 接力·无中央编排)+物理优先分类→GDD 契约→多模态资产→确定性贴图;**我们 SAA 图比它命令式循环更确定,核心不落后**;真缺 3 处=①约束厚度(template_api+GDD 契约·最高价值)②经验复利层(Template/Debug Skill)③资产线(走 mmx);它两卖点(27B 专训/VLM Bench)一个刻意不走、一个九门已是更强等价物。源码 clone 在 `/root/oss/OpenGame`。
 - `2026-06-17-固定游戏架构与SAA-agentic-studio-execution.md` — **ACTIVE · 当前生成主线架构 execution**（固定游戏架构=轻量声明式领域模型+2D 适配器 / SAA studio 9+1+1 agent / 8 契约 / 救场阶梯 / 缓存三段式；**两 spike 已绿**：缓存经 new-api 透传 76-93%、classify tickModel 100%）
 - `2026-06-17-固定游戏架构与SAA-agentic-studio-review.md` — 配套**设计 review**（含深析 §10 + 创始人决策；承原 v2 生命周期原则）
 - `2026-06-12-游戏生成系统总体架构-review.md` — 生成系统总体架构纲领（三级生成 / W-G0~G4 路线 / 意图矩阵）