games-development-ai/docs/architecture/架构/生成引擎/OpenGame对照.md

OpenGame 对照 · 外部标杆深读

🚧 架构演进中 —— 生成引擎子树正处于 gameDefinition→src/ 终态迁移 + 产线化(plan 2026-06-18-001 U1–U4)中,文中标注的现行结论可能随推进变化;以子树 README 与最新裁定 / plan 为准。

这是什么:绘境AI 生成引擎对外部最强开源标杆 OpenGame 的源码级深读,以及由此照出的复刻缺口。它回答两个问题——"OpenGame 到底是怎么把一句话变成游戏的",以及"它身上哪三层东西值钱、我们还没有"。 给谁看:负责生成主线的工程师、做技术选型与对标的架构评审、想看清护城河关键路径上"我们与最强开源系统差在哪"的人。 怎么读:先读 §1 的定位与一张对照全景图;§2 是主体——逐层拆 OpenGame 的真实机理(主循环 / 韧性 / 子 agent / 系统提示 / 六阶段生成 / 三大支柱);§3 落到我们的现状,把缺口分四类诚实交代。想要"往哪走、先做什么"的统一行动项,去生成主线架构演进路线拿——本档只负责把 OpenGame 的内部机理和逐项缺口的来龙去脉讲透。

---

0. 先讲清楚:这份文档在体系里的位置

生成引擎子树的主文档(生成引擎 README)已经在它的 §5 用一页篇幅,概括了"对标 OpenGame 我们缺哪三层"。那是结论。本文档是那一页结论背后的源——把 OpenGame 的源码真正读穿,逐层讲清它每个机制为什么这么设计、对用便宜模型的人意味着什么,再把每一处缺口的取舍依据摆出来。

OpenGame 是什么:一个把"一句话需求"变成"可玩游戏"的开源生成系统(源码在 github.com/leigest519/OpenGame,作者是香港中文大学 MMLab,对应论文 arXiv 2604.18394)。它是当前这一赛道最完整、最值得深读的开源对照物。本档的所有结论都锚在 clone 下来的真源码上,不取信于论文 README 的宣称——这个区分在 §2.7 会变得至关重要。

一句话定位:README §5 给结论,本档给证据与机理。 两者职责不同,不互相重复;当你只想知道"我们要做什么"时读 README,当你想知道"OpenGame 凭什么、以及我们为什么这么取舍"时读这里。

---

1. 一句话与一张图:两条路,同一个终点

在拆 OpenGame 之前,得先把我们自己和它摆在同一张图上,否则后面所有的"抄"与"不抄"都没有坐标系。

绘境AI 的生成主线,本质是一条用便宜的通用模型驱动、用确定性的图编排约束控制流、用一套自动验收门兜底的流水线。它的骨架是 SAA 裸 StateGraph(SAA = Spring AI Alibaba,阿里在 Spring 生态里的 AI 编排框架;"裸 StateGraph"指直接用它的有向状态图原语手写编排,而不是再套一层 agent 框架),一共 16 个节点,每个节点是一段实打实的 Java 代码,节点间的流转由图预先固定,而非由模型在运行时临场决定下一步。

OpenGame 走的是另一条路:它是一个命令式自主循环——在一个 while(true) 死循环里,模型自由决定下一步调用哪个工具,控制流由模型驱动。这是和我们正交的另一种范式。

flowchart TB
  subgraph 我方["绘境AI 生成引擎 — 声明式有向图"]
    direction LR
    HG["SAA 裸 StateGraph<br/>16 节点,控制流由图固定"]
    HN["九门 harness<br/>确定性机制验收(领先)"]
    HM["便宜通用模型 + 门兜底<br/>不训专用大模型"]
  end
  subgraph 对方["OpenGame — 命令式自主循环"]
    direction LR
    OL["while(true) ReAct 循环<br/>控制流由模型驱动"]
    OT["4 个原子游戏工具<br/>+ 六阶段 SOP 接力"]
    OS["经验自进化(护城河)<br/>Template / Debug Skill"]
  end
  对方 -. "抄它的工具层 / 韧性兜底 / 经验复利,当零件库落进 SAA 节点内部" .-> 我方
  对方 -. "不抄它的『模型自由驱动主循环』范式" .-> X["缝合设计红线"]
  style X fill:#f5b7b1
  style HN fill:#a9dfbf
  style OS fill:#f9e79f

这张图先把全篇最重要的取舍钉死:OpenGame 的控制流我们用 SAA 图来表达(我们本来就这么做,而且对卡 80% 成功率门而言,图的确定性比口头督促更稳,这是升级不是抄);OpenGame 的工具层、韧性兜底、防脏脚手架与经验复利机制,我们当成零件库,原样落进 SAA 节点内部。一句话——抄它的工具与兜底,不抄它的主循环范式。把主循环硬塞进来,就成了项目明令反对的"缝合设计"(指把一份为 A 范式写的代码硬粘到 B 范式上当接口,而不从整体架构出发)。

带着这个坐标系,下面进入主体:OpenGame 到底是怎么运转的。

---

2. OpenGame 是怎么生成游戏的

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

读 OpenGame 源码,第一个、也是最重要的认知矫正是:它不是从零写的 agent 框架,而是 Gemini-CLI → Qwen-Code → OpenGame 这条二次 fork 的产物。(fork = 把别人的开源项目拷一份在其上改;"二次 fork"指它本身又是 fork 之上的 fork。)

这个判断有硬证据,不是猜的:

• geminiChat.ts 文件顶部注释自承是 js-genai 的 chats.ts 逐行拷贝改版;
• subagent.ts 的版权头写着 Qwen;
• 系统提示里自述"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——这一整套执行基座,是从上游成熟代码完整继承的。(MCP = Model Context Protocol,模型上下文协议,一种让 agent 接外部工具/数据源的标准总线;OAuth = 第三方授权登录协议。)OpenGame 自己真正写的,只有三样:tools 层的四个游戏专用工具、一个音乐合成服务,以及一套 Phaser + Vite 工程模板(Phaser = 一个成熟的 2D HTML5 游戏引擎;Vite = 前端构建工具)。

换句话说:"复刻 OpenGame 的引擎",本质是复刻 Qwen-Code,而不是发明什么新架构——而我们已经选了 SAA 图这条不同的路。这一点先记下,它会贯穿整篇对照:真正属于"游戏生成"的创新,集中在那四个工具和那套模板里,其余都是继承的通用 agent 基建。

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

OpenGame 的 agent 主循环,核心不是一段编排脚本,而是一个经典的 ReAct/工具循环(ReAct = Reason+Act,指"模型先推理、再调工具、看结果、再推理"的循环范式),但被干净地拆成三层。值得细看它的"权力是怎么分配的",因为这正是它可移植性好的原因。

sequenceDiagram
  autonumber
  participant Loop as 外层 while(true)<br/>(nonInteractiveCli)
  participant Client as 中层 sendMessageStream<br/>(client.ts)
  participant Turn as 内层 Turn.run<br/>(turn.ts)
  participant Model as 大模型
  participant Tool as 工具执行

  Loop->>Client: 用当前消息开一个回合
  Client->>Client: 压缩历史 / 检查 token 上限<br/>注入 IDE 上下文 + system-reminder<br/>跑循环检测
  Client->>Turn: 进入单回合
  Turn->>Model: chat.sendMessageStream(一次)
  Model-->>Turn: 流式 chunk(内容/思考/工具请求)
  Note over Turn: Turn 只『发出工具请求事件』<br/>自己绝不执行任何工具
  Turn-->>Loop: 事件流(含工具调用请求)
  alt 这一圈有工具请求
    Loop->>Tool: 逐个真正执行
    Tool-->>Loop: 结果打包成 role=user 的 functionResponse
    Loop->>Loop: 回灌到循环顶部,再来一圈
  else 这一圈只说话、没发起工具
    Loop->>Loop: 终止(收敛)
  end

读这张时序图,抓住三层的职责切分:

• 最外层是非交互 CLI 里的 while(true)(在 nonInteractiveCli.ts)。每一圈做四件事:用当前消息调一次流式模型;消费事件流,把模型发起的工具调用请求累积起来,把文本和思考直接打到标准输出;流结束后,如果有工具请求就逐个真正执行,把每个工具的返回打包成一条 role 为 user 的 functionResponse 消息回灌到循环顶部——这就是"喂回结果再循环"的本质。(functionResponse = 工具调用的结构化返回,以 user 角色塞回对话,让模型读到上一步工具产出了什么。)
• 中间一层是 client.ts 的 sendMessageStream,负责把"一个回合"武装起来:压缩历史、检查会话 token 上限、注入 IDE 上下文增量、注入 system-reminder、跑循环检测,然后才进入真正的单回合。(system-reminder = 每轮临时注入的一段提醒文本,用于喂动态信息,不进固定的系统提示。)
• 最内层是 turn.ts 的 Turn.run,它只负责调一次 chat.sendMessageStream,把模型吐出的 chunk 翻译成事件(内容/思考/工具请求/完成/错误)。关键设计:Turn 自己绝不执行任何工具,它只发出"我要调这个工具"的请求事件。

这个"权力分配"是整个设计的精髓:模型回合只有发起权,执行权牢牢握在外层循环手里;工具结果统一以 user-role functionResponse 回灌。 三层职责清晰,可移植性很好。它的收敛条件极其朴素:模型这一回合只说话、不调工具,就算完成了。

围绕这条主循环,它还打了好几个护栏:MAX_TURNS=100 硬顶、会话级回合上限、token 上限、LoopDetectionService 检出复读直接退出。最有意思的一个补丁叫 checkNextSpeaker——当模型说了"接下来我要做某某"却没真去发工具调用时,它会用一次额外的 LLM 判定 next_speaker(下一个该谁说话),如果判定该轮到模型,就自动注入一句"Please continue."把它顶回正轨。这是专门用来对付"模型话痨但不动手"的早停问题的,而便宜模型恰恰最容易犯这个毛病。

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

如果说主循环是骨架,那 CoreToolScheduler(核心工具调度器)就是让这副骨架在脏数据下不散架的关节。它把每个工具调用建模成一个状态机。

stateDiagram-v2
  [*] --> validating: 收到工具调用请求
  validating --> scheduled: 参数校验通过
  validating --> error: 参数非法 / 幻觉工具名
  scheduled --> awaiting_approval: 需 HITL 确认
  scheduled --> executing: 确认门齐开
  awaiting_approval --> executing: 用户批准
  awaiting_approval --> cancelled: 用户拒绝
  executing --> success: 执行成功
  executing --> error: 执行失败
  error --> [*]: 降级成 functionResponse error<br/>喂回模型,让它自己纠正
  cancelled --> [*]: 同样喂回模型
  success --> [*]

调度语义可以一句话概括:批内并行、批间串行、确认门齐开才执行——同一批工具调用先全部发起再一起 await(并发),但不同批次之间严格串行排队;而且要等这一批所有调用都到了 scheduled 或终态,才统一开始执行。(HITL = Human-In-The-Loop,人在环路里,指需要人工点一下"批准"的确认门。)

但对我们最有借鉴价值的,不是它的并发语义,而是它的容错哲学:幻觉工具名(模型编了个不存在的工具)、参数非法、被用户拒绝、工具执行失败——这些统统不让它崩溃,而是降级成一条 functionResponse error 喂回给模型,让模型自己读着错误去纠正。尤其当模型造了个不存在的工具名时,它会用 Levenshtein 编辑距离(衡量两个字符串差几个字符的算法)算出"你是不是想用 X"的建议,一并塞回去。

便宜模型最大的问题就是输出脏——乱造工具名、参数对不上——而这一层"错误即上下文"的兜底,比模型本身更决定成败。这是 OpenGame 给所有想用便宜模型的人上的第一课。

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

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

flowchart LR
  Main["主 agent<br/>(完整工具集,含 task)"] -->|task_prompt 注入任务| Sub["子 agent<br/>全新 GeminiChat"]
  Sub --> SubLoop["独立 while(true) mini-loop<br/>探索几十轮"]
  SubLoop --> SubTools["子 agent 工具集<br/>(被裁剪,强制剔除 task 本身)"]
  SubTools -. "不能再派生子 agent<br/>隔离深度只有一层" .-> NoDeep["✗ 不是任意深度 agent 树"]
  SubLoop -->|"只回吐最后一轮纯文本结论"| Main
  SubLoop -. "中间几十轮探索噪音<br/>全吞在自己肚子里" .-> Swallow["主 agent 上下文不被污染"]
  style NoDeep fill:#f5b7b1
  style Swallow fill:#a9dfbf

机制上,子 agent 会开一个全新的 GeminiChat,只继承环境历史,系统提示由模板占位符渲染(主 agent 只通过 task_prompt 注入任务描述),并且自带一个独立的 while(true) mini-loop。最关键的两个设计:

1. 子 agent 的工具集被裁剪,而且强制剔除 task 工具本身——所以子 agent 不能再派生子 agent,隔离深度只有一层,这不是任意深度的 agent 树。
2. 子 agent 跑完几十轮探索后,只把最后一轮的纯文本结论回吐给主 agent,中间过程全吞在自己肚子里。

这正好兑现了系统提示里说的"减少上下文占用":主 agent 不会被子任务的探索噪音污染。代价是委派靠 prompt 怂恿而非硬路由,委派质量死死绑在主模型的判断力上——便宜模型在这里大概率不会主动、聪明地委派。这是一个对我们有直接启示的取舍:我们用 SAA 图把"什么时候该分子任务"固定成边,正好绕开了"便宜模型不会自己委派"这个坑。

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

OpenGame 的系统提示拼装很能体现工程成熟度。一个 getCoreSystemPrompt(userMemory, model) 函数顺序拼接四段:

1. 可被外部 .md 文件整体覆盖的基座大模板——身份、Core Mandates(核心行为准则)、强制频繁用 todo 的任务管理、软件工程的 Plan/Implement/Verify(计划/实现/验证)工作流,甚至写死了"2D 游戏用 HTML/CSS/JS、3D 用 Three.js"的技术默认。
2. 按 SANDBOX 环境变量三选一注入的沙箱段落。
3. 按是否 git 仓库追加的 Git 守则。
4. 然后是一个很妙的细节——按模型名切换三套 few-shot 工具调用示例方言(few-shot = 在提示里给几个示范例子):通用自然语言、qwen-coder 的 XML 风格、qwen-vl 的 JSON 风格,去适配不同模型对工具调用语法的偏好。

这里藏着两个对我们有用的工程判断:

• 真正每轮变化的动态信息不进系统提示,而是作为 user 消息或 system-reminder 在每轮注入(IDE 上下文、subagent 提醒、plan-mode 提醒)——这样系统提示可以被缓存,省钱。
• "按模型切 toolcall 方言"是支撑多便宜模型的关键工程点。换一个便宜的 Qwen 系或别的模型,主要改的就是这套方言示例和底层的 ContentGenerator——它支持 OpenAI / Anthropic / Gemini / Vertex / Qwen 五种认证,baseUrl / model / apiKey 全是 env + config 双层可配,还带 retryWithBackoff(指数退避重试)和 429 限流回退到 flash 模型,而循环骨架完全不动。

一句话:"用便宜通用模型"在 OpenGame 里是一等公民,开关早就铺好了。 这和我们"便宜模型 + 门兜底"的路线判断是一致的——区别在于它用提示方言切模型,我们应当把这层做成外置的 models.yaml 数据契约(见 §3 与演进路线)。

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

这是整篇分析最该被吸收的部分。OpenGame 的工具集刻意地小,只有四个游戏专用工具,没有一个"端到端生成游戏"的大黑盒。生成逻辑全靠 agent 用这堆原子工具,按相位一步步串起来。

最反直觉的发现是:这条端到端流水线没有任何中央编排文件(全仓 grep 不到驱动相位的 workflow 代码)。它是靠两样东西驱动的——一份叫 custom.md 的确定性 SOP 系统提示(SOP = Standard Operating Procedure,标准作业流程),以及每个工具返回内容末尾注入的 <system-reminder> 接力指令。

flowchart TB
  Brief["一句话需求"] --> P1
  subgraph P1["Phase 1 · 物理优先分类 + 脚手架"]
    C["classify_game_type<br/>归入 5 archetype 之一"]
    C -->|"返回里塞 system-reminder:<br/>给出 cp 命令拷模板"| ROUTE["路由器:archetype 一旦定<br/>后面规则/资产/模板全被决定"]
  end
  P1 -->|"接力指令:下一步调 generate-gdd"| P2
  subgraph P2["Phase 2 · 把一句话编成六节技术规格书"]
    G["generate_gdd<br/>动态拼三层规则 → GAME_DESIGN.md"]
    G --> RULE["三铁律:Config-First /<br/>Zero Custom Code / Hook Integrity"]
  end
  P2 -->|"DO NOT STOP. CONTINUE TO PHASE 3 NOW"| P3
  subgraph P3["Phase 3 · 多模态资产 + 确定性贴图(最重)"]
    A["generate_game_assets<br/>生成→抠图→I2V抽帧→多级回退→装配"]
    T["generate_tilemap<br/>AI画3×3 + AI写ASCII<br/>+ 确定性 bitmask 自动贴图"]
  end
  P3 -->|接力| P5
  subgraph P5["Phase 5 · 落地代码"]
    E["smart_edit(注册名 edit)<br/>三级匹配 + LLM 自纠错<br/>把规格写进模板文件"]
  end
  P5 --> OUT["可玩游戏"]
  style ROUTE fill:#f9e79f
  style RULE fill:#a9dfbf

让我顺着这几个相位讲一遍——这是整篇最该被吸收的部分。

Phase 1,物理优先分类 + 脚手架。 agent 调 classify_game_type,把用户那句话归入五个 archetype 之一:platformer(平台跳跃)、top_down(俯视)、grid_logic(网格逻辑)、tower_defense(塔防)、ui_heavy(以 UI 为主)。(archetype = 游戏原型/品类,这里指按"物理形态"划分的玩法大类。)它的分类规则刻意"不看品类名,只看物理"——重力方向、视角、移动方式,系统提示里还专门列了易错例(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(GDD = Game Design Document,游戏设计文档),它会向上递归找 docs 目录,动态拼三层规则——通用 GDD 格式、该 archetype 的设计视角规则、该 archetype 的 template_api.md(可用的代码能力 / hook 清单;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,Image-to-Video)再用 ffmpeg 本地抽帧逐帧抠图;如果没有 ffmpeg 或失败,回退到图生图(I2I,Image-to-Image)逐帧编辑;
• 音频则是三级回退——文生视频抽音轨,失败就让模型产 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 自动贴图算法(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"这种口头督促来推进相位,便宜模型很容易在中途断流。这恰恰反衬出我们用 SAA 图固定相位的价值——图的边不会"忘了继续"。

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

OpenGame 论文卖的是三大支柱,但深读源码后必须诚实区分哪些是真代码、哪些只是 README 宣称。这个区分是本档最重要的"防误判"产出——把论文当代码现状,会严重高估它、也会错配我们的补强方向。

flowchart LR
  subgraph 真["✓ 真代码(仓里能跑)"]
    GS["Game Skill 经验自进化<br/>= 真护城河<br/>纯本地 JSON · 零向量 · 零 embedding"]
  end
  subgraph 半["⚠ 只在 README / 论文"]
    GC["GameCoder-27B 专训模型<br/>权重/训练码/数据都不在仓<br/>实测默认接 claude-opus-4.6"]
    VB["OpenGame-Bench 三轴 VLM 验收<br/>grep 零命中,只留<br/>'will be released soon'"]
  end
  GS -. "真实验收只到 build + test<br/>不验证可玩性" .-> 真相["仓里真实的『验收』<br/>= driver subtype + build/test"]
  半 -.-> 真相
  style GS fill:#a9dfbf
  style GC fill:#f9e79f
  style VB fill:#f9e79f

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

flowchart LR
  Task["完成一个任务"] --> Extract["抽取经验"]
  Extract --> Generalize["去具体化<br/>(角色名→Player,硬编码值→config)"]
  Generalize --> Store["沉淀回本地 JSON 库"]
  Store --> Hit{"下次先查库"}
  Hit -->|命中| Reuse["复用(整个 family / 已验证 fix)<br/>每次命中省一次 LLM 调用"]
  Hit -->|未命中| Novel["LLM 兜底:诊断新错 / 归纳新模板"]
  Reuse --> Count["重复计数"]
  Novel --> Count
  Count -->|"达阈值(如重复3次)"| Promote["升格成可执行规则<br/>救火 → 免疫"]
  Promote --> Store
  style Reuse fill:#a9dfbf
  style Promote fill:#f9e79f

这套机制有两个具体实现:

• 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 的事前预校验规则——经验从"救火"升级成"免疫"。而且只有跑通验证的修复才进库,这是它唯一的质量门。

但要诚实:这套自进化"是真的,但很轻"——只有单调累积、计数强化、阈值升格,没有遗忘、淘汰、冲突消解;模板冲突用"保留更长文件"这种启发式;规则一旦生成就不回收。更重要的是两个硬缺口:

1. Template Skill 侧完全没有"这个沉淀的骨架真能编译、真可玩"的回验门,带病的骨架可能直接沉进库;
2. Debug Loop 只验证到 build + test 层,完全不验证可玩性。

这两点很关键——它们恰恰是我们的强项能补上的地方(我们有真机九门),§3 会展开。

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

第三支柱,OpenGame-Bench 三轴 VLM 验收——README 宣称,但代码库里根本不存在。(VLM = Vision-Language Model,视觉语言模型,指能"看图打分"的模型。)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 当代码现状,会严重误判。

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

最后补两笔执行环境,它们决定了"复刻 OpenGame 要不要搬这些重家伙"。

OpenGame 的 shell 执行是重型的:PTY 优先(node-pty 加 @xterm/headless 把 ANSI 输出解析成结构化数据;PTY = 伪终端),拿不到 PTY 就用 child_process 兜底,detached 让命令独占进程组,中止靠对进程组发 SIGTERM 再 200ms 后 SIGKILL,还用 pgrep 回收后台子进程 PID,外加 docker / podman / seatbelt 沙箱和 HITL 白名单。这是 agent"写代码 → 跑构建 → 看报错"闭环的物理基座,深度绑定 Node 生态。 它之所以这么重,是因为它的自主循环要让模型自由地反复跑命令;我们走图编排,build 节点职责窄得多,MVP 阶段并不需要这么重。

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

---

3. 落到我们身上:要在 SAA 图上复刻 OpenGame,到底缺什么

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

先说一个贯穿性的范式判断,它决定了"抄"的边界——这条在 §1 已经摆过坐标系,这里把它落到具体取舍:OpenGame 的 client.ts/turn.ts 那套主循环,我们不该嫁接进来——硬塞就成了缝合设计。 务实的态度是:把 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	不抄	路线不同

表中名词补注:LittleJS 是我们选定的轻量 H5 游戏引擎(对标 OpenGame 用的 Phaser);gameDefinition 是我们当前实现里便宜模型友好的结构化中间表示;九门 / 九门 harness 是我们在真浏览器里跑的九道确定性机制验收门(CDP = Chrome DevTools Protocol,用来程序化驱动真实浏览器);player 软门 是用视觉模型 M3 看截图打分的软性检查;mmx-cli 是投资人版已拍板的媒体生成命令行工具。

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

物理优先分类的系统提示(含易错例)加五 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 抄不来、必须我们自建——而它恰好和创始人 2026-06-17 定的"游戏 = 长生命周期结构化源项目"基座、以及"玩法模板 = 品类框架"的定位是同一个东西。

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

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 的多级回退思路兜底。

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

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、并不验证可玩性。

flowchart TB
  subgraph 三轴["OpenGame 论文宣称的三轴(代码未开源)"]
    BH["Build Health<br/>能不能构建运行"]
    VU["Visual Usability<br/>好不好看"]
    IA["Intent Alignment<br/>是不是用户要的那个游戏"]
  end
  BH -->|"对应 · 我们确定性领先"| NG["九门 harness<br/>真机 CDP · 确定性机制判定<br/>装载/帧/输入/终态"]
  VU -->|"对应 · 我们偏弱"| PS["player 软门<br/>M3 截图判 · 软 · 跑便宜模型 · 不成体系"]
  IA -->|"对应 · 我们偏弱"| PS
  NG -. "判不了好不好看 / 对不对" .-> 边界["别把九门当 VLM 等价物"]
  PS --> 动作["正确动作:把 player 软门做厚<br/>独立交叉校验 + 离线 bench<br/>蓝本 = OpenGame 论文三轴"]
  style NG fill:#a9dfbf
  style PS fill:#f9e79f
  style 边界 fill:#f5b7b1

但这里要分清两层、别就此自满——这也正是不该把"九门"简单当成 VLM Bench 等价物的原因。九门判的是机制:能不能装载、跑不跑帧、响不响应输入、到不到终态,全是确定性的,这一层我们确定性地领先,没有疑问。可 VLM 的另外两轴——Visual Usability(好不好看)、Intent Alignment(是不是用户要的那个游戏)——九门根本判不了;这两件事在我们这边对应的不是九门,而是 player 软门(M3 视觉模型看截图),而 player 软门是软的、跑便宜模型、不成体系,这恰恰是我们的弱项而非强项。

所以正确的动作不是"把九门结果套个三轴外壳就交差"(九门产不出"好不好看""对不对"这两轴),而是把 player 软门那条做厚:让"是不是要的游戏、好不好看"有更系统、可复现的判定——独立于生成方的交叉校验,甚至一个离线 bench。OpenGame 论文那套三轴设计,正是这一层值得我们抄的蓝本,即便它代码并没放出来。

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

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 适配。

3.5 我们的 Phase 0–4 落地路线:从对照分析到带消融杠杆的执行序列(创始人 2026-06-22 历史回收判定捡回)

上面 §3.1–§3.4 把"OpenGame 哪些设计值得抄、怎么落进 SAA 节点"按价值分了四类,那是对照分析。2026-06-22 把另一份决策记录(docs/plans/2026-06-20-关闭九门判定-全面参考OpenGame-决策与Phase0-4.md,创始人当天拍板、当天把 gamedef 做到 91.7%)的 Phase 路线回收进来,补的是分析之外的另一半——一条有编号、有消融杠杆量化、有达标 flip 条件的执行序列。两份口径不同:对照档回答"抄什么",这条路线回答"按什么顺序抄、每步能抬多少、抬到什么程度就切默认"。

这条路线的起跑线,是验收口径的一次收窄,得先讲清,否则后面的 Phase 没有立足点:生成环的硬门已从"九门全过"收窄成"只认五道客观健康门 A–E"(A_boot/B_uncaught/C_frame/D_render/E_live),G_input/H_progress/I_control 三道 driver 依赖门降为不否决生成的参考门,F_wiring 移出客观硬门、改由 VLM 看截图判其"真用引擎/有特效"的语义。这一收窄是 gamedef 从 all-9 口径下约 50% 做到 91.7% 的直接原因之一(细节见 验收门-W-G1 §2.4)。把九门里"靠 driver 才判得了"的那几道暂时摘出生成环的否决权之后,Phase 路线要补的就是"用别的、更对的东西把那几道门的语义重新接回来"——这正是下面几个 Phase 的主线。

各 Phase 与它们各自的消融杠杆(数字是 06-20 当天实测的 Build-Health 增量贡献):

• Phase 2 · 模板-First + hook,杠杆最大(约 +10.1 BH)。 给每个 archetype 预建一套已验证过的 gamedef 骨架,再让便宜模型在骨架上做 hook 覆写,而不是从零发明结构。这与 §3.1 那条"GDD 契约 + template_api 是最高价值缺口"是同一件事的执行版——预建骨架就是"填空靶子",hook 清单就是约束便宜模型不编造 API 的那份 template_api。它单点贡献最大,所以排在最前。
• Phase 3 · 活调试协议 / 离线 linter(约 +6.9)。 把生成中反复踩的坑沉淀进一个版本化的匹配库,在真玩之前先跑一道静态门把已知错挡掉、并回灌修复。这就是 §3.2 那条 Debug Skill 的落地——(签名,原因,修复)三元组加分组阈值升格,签名匹配纯算法零 LLM。它排第二,因为有了 Phase 2 的骨架打底,剩下的错才收敛到"可被 linter 模式化捕获"的程度。
• 模板族复用(约 +5.8)。 对应 §3.2 的 Template Skill:把完成过的项目按物理三元组泛化成可复用的家族骨架,命中即复用整个家族。它的增量来自"同品类第二款起不必重走 Phase 2 的从头预建"。
• Phase 4 · build-health + VLM 验证替换 driver 判定,并定 flip 达标条件。 这一步把起跑线收窄时摘出去的 driver 门语义正式接回来——但不是接回 driver,而是接回"客观 build-health + VLM 看截图"两条:能不能跑用客观门 A–E 判,好不好看 / 是不是要的那个游戏用 VLM 判(对应 §3.3"player 软门做厚"和论文三轴里的 Visual Usability / Intent Alignment)。配套自修复封顶 T=3(同一道门最多自动修三次),达标后才 flip 成默认。

flip 达标条件(这是 Phase 路线区别于纯分析的关键):gamedef 路在统一口径下成功率真达 80% 门,才把它切成默认产线、二分收敛退役旧 factory 路、并把"失败即拦截"的门翻开。在此之前,新口径与新 Phase 全部默认旁路、只观测、可用 -Dsaa.gen.gateMode=all9 回退对比,绝不一上来就改放行行为。这条 flip 门与生成引擎 README §6 那道 cutover 里程碑、与 SAA编排 §7 的 batch 治理层退役条件是同一道闸的不同视角,落地时挂同一个 80% 达标判据,不各立一套。

口径归属:这条 Phase 路线与起跑线的口径收窄,蒸馏权威源在 .agents/skills/saa-graph-orchestration.md §3.5 与上述决策 plan;"统一的 to-do、阶段序列、cutover 门"仍以生成主线架构演进路线为单一 SoT。本节把消融杠杆量化(+10.1/+6.9/+5.8)与 flip 达标条件回填进对照档,是因为这几个数字决定了"先抄哪一层最划算",而它们此前只躺在那份决策记录里、没进现行架构档。

---

4. 收口结论

我们和 OpenGame 走的是两条路,但终点一致:都靠"把开放式游戏生成收敛成受控填空"来让不够强的模型也能稳定产出。 OpenGame 用命令式 agent 循环加 system-reminder 接力来收敛,我们用 SAA 图来收敛——在这一点上我们不是落后,而是用了更确定的范式。

真正的差距集中在三处——这三处正是 README §5 那一页结论的来源:

1. 生成约束的厚度(物理优先分类 + GDD 契约 + template_api 清单,这是设计可直接抄的最高价值项,且与"结构化源项目"基座天然契合);
2. 经验复利层(Template/Debug Skill,我们几乎从零,但设计可抄、且能用九门当原版缺失的质量门);
3. 资产线(接 mmx 替代)。

至于 OpenGame 论文最响的两个卖点,得分开说。专训 GameCoder-27B 我们刻意不走——走便宜通用模型加 harness 兜底,而它自己框架的 model-agnostic 设计反而证明了专训模型不是跑通的必需。VLM Bench 则要说准:它的三轴验收在开源代码里其实没放出来、只在论文里,所以单比已开源的,我们的真机九门已经更硬;但别把"九门"当成 VLM 的等价物——九门更强的只是"能不能跑"这一层(Build Health),而 VLM 的"是不是要的游戏、好不好看"那两轴九门判不了,对应的是我们偏弱的 player 软门,那是待补强的缺口,不是已经赢了的项。

最该立刻动手的,按优先级是:

1. 把 template_api(LittleJS 插件库公开 API 清单)和 GDD 契约补上,这是一切约束的靶子和最高价值杠杆;
2. 把 Debug Skill 的"签名 → 已验证修复 → 重复升格"活协议落成 diagnose/repair 节点加 checkpoint;
3. 把 Template Skill 的骨架进化库按 gameDefinition 重写,并强制加入库前过九门的质量门。

这三件做完,我们这条 SAA 配置式流水线就补齐了 OpenGame 真正值钱的那部分,而且是用我们自己更确定、更可验收的方式补齐的。

---

5. 源档与去向导航

去向	找什么
生成主线架构演进路线	统一的 to-do 在这里:本档照出的三处缺口已并入那份单一 SoT 的"统一演进路线",含阶段序列、关键路径、cutover 门——要"做什么"去那份拿
生成引擎 README	生成引擎子树主文档,§5 是本档的一页结论版;§3 讲"游戏 = 长生命周期源项目、LLM as 工作室"的范式原则
SAA 编排	我方 16 节点拓扑图、六条不变量、split-brain 两条治理铁律、落地接入坑清单
github.com/leigest519/OpenGame	OpenGame 真源码本体(本档所有结论的锚点,论文 arXiv 2604.18394)

纪律:本档是 OpenGame 外部标杆的深读参考——回答"它的内部机理"和"逐项缺口的来龙去脉"。"我们要做什么"的统一行动项不在这里,在生成主线架构演进路线;两者职责不同,不互相重复。当行动项与本档分析冲突时,以那份演进路线的最新裁定为准。

---

验证状态:本文档为架构对照参考文档,由一份已被《生成主线架构演进路线》吸收的源档(2026-06-20-OpenGame对照分析与复刻缺口.md,status 为"分析 · reference",该档由 5 个 agent 分片深读 clone 下来的 OpenGame 真源码后综合)重写而成,未改任何代码。承重硬事实——OpenGame = Gemini-CLI→Qwen-Code 二次 fork 的三处铁证、四原子工具 + 六阶段 SOP、三铁律(Config-First/Zero Custom Code/Hook Integrity)、MAX_TURNS=100、Debug Skill 加权阈值(0.5/0.35/0.15,阈值 0.8)与重复 3 次升格、stability=min(1,项目数/5)、三大支柱中仅 Game Skill 是真代码而 GameCoder-27B 与三轴 VLM Bench 只在 README、我方 SAA 16 节点 / 九门 / 80% 门 / gamedef 双证、三处复刻缺口与四类取舍——均沿用源档已抽查属实的结论;品牌已统一为"绘境AI"。