+
+
+
+
+
+
+
Agent · LLM 调用
+
Harness · 确定性
+
固定 plumbing / 契约
+
净新建（新设计）
+
复用/升级（大半已通）
+
零触碰
+
SAA = Spring AI Alibaba 裸 StateGraph · 进程内编排 · new-api 网关 100.64.0.8:3000
+
+
+
+
+
+
+ ① 全景：一句话 → 一款可入库的游戏 现状
+ 最粗一层。用户一句 brief 进来，SaaGraphDispatcher 进程内提交 SAA 图，图跑完四个阶段（理解&设计 / 生成 / 验收 / 出厂），终态回调入库，studio 前端消费。
+
+
+
+
+
+ ② SAA StateGraph 全拓扑（节点 + 边 + 救场回环） 现状
+ 权威拓扑（来自 SaaStudioGraph.assemble）。蓝=Agent 节点（吃 LLM），绿=Harness 节点（确定性）。amodel 主线：validate-ok 直接短路到 play（跳过 scaffold/asset/build）（代码核实 SaaStudioGraph:502）；factory/gamedef 旧路才走 scaffold→asset→build 链。
+
+
+ 救场预算： maxRepairs=5 · stage2ExtraRepairs=3 · maxPlayerRounds=1 · recursionLimit=120。任何失败门经 repair（带反馈）或 escalate（升强档）回到 generate 重试，耗尽 → giveup。
+
+
+ 现状修正点（双评审 + 代码核实）：amodel 路 validate-ok 直奔 play，跳过 scaffold/asset/build（SaaStudioGraph:502-503）。原图把 asset/scaffold 画进 amodel 主线是误框 —— 它们只在 factory/gamedef 旧路可达；modify 节点同理是 gamedef/factory 专用（regenerate-module→generate / deterministic→guard fail-loud），无 amodel 分支。
+
+
+
+
+
+ ③ generate 放大 ＝ A-model agent 循环（「agent 里面做什么」） 现状
+ generate 节点 shell-out 到 gen.mjs。这是唯一「真 agent」的地方：M3 在一个 ReAct 循环里调 6 个工具，自己读手册、写代码、自检，绿了才 done。harness 终态产单个自包含 bundle.iife.js。check / build / done 门都是 Harness（确定性），M3 只负责思考与写 L3 代码。
+
+
+
+
+
+ ④ 三层代码架构（谁写 / 谁不写 — 这是 agent 的硬边界） 现状
+ 每个游戏 = 三层。L1 固定 plumbing 与 L2 能力库由仓库提供、agent 不碰；agent 只写 L3 游戏本体。入口契约把嵌套摊平成 createGame({plugins,bundle,viewport})，L3 见不到宿主细节。
+
+
+
+
+
+ ⑤ play 放大 ＝ 九门验收 harness（全 Harness，无 LLM） 现状
+ play 节点跑 serve-and-play.sh：静态 serve + Chrome headless（CDP）+ play.cdp.cjs。boot-game-host 把 bundle 启动、注入插件、桥接输入、挂 recHook，然后逐门取证写 verdict.json。九门 = 运行时 + 玩法无关，只验「能玩」（boot/活性/输入/有进展），故意不懂任何品类语义—— 这是它的价值，新设计绝不破坏它。未驱动时 E_live / H 降为 advisory；driven（spec 有 driver/inputs）时九门全硬。
+
+
+ H 门 = per-game 断言的落点：assertAfterPlay 本就支持「score increased」这类断言。design 产的 gatespec 经现成 merge 进 play_spec.assertAfterPlay（SaaStudioNodes:665/674），被 H 门校验 —— per-game 断言管线已存在，新设计的「玩法语义门」就挂在这条现成路上，通用九门一行不改。
+
+
+
+
+
+ ⑥ Agent vs Harness 边界总表 现状
+ 一眼看清：整条链上只有 4 个节点真正吃 LLM（classify / design / generate / player〔+nreview〕），其余全是确定性 Harness。generate 是唯一的「真 agentic」节点。
+
+ | 节点 | 类型 | 模型 | 职责（现状） |
|---|
+
+ | SaaGraphDispatcher | Harness | — | 进程内提交 SAA 图；job 留 RUNNING；终态 → handleCallback |
+ | render | Harness | — | 入参规整、brief 默认值齐全；图入口；分流 create / modify |
+ | classify | Agent | stage1 · classify | brief 玩法品类分类 |
+ | design | Agent | stage1 · design | 富化 brief → 设计稿（K_ENRICHED）+ gatespec；amodel 路经 K_ENRICHED 富化-brief 文本喂 generate |
+ | generate | Agent · 真 agentic | MiniMax-M3（thinking 关） | shell-out gen.mjs；ReAct 循环 6 工具；只写 L3；done 门绿 → staged bundle.iife.js |
+ | validate | Harness | — | 查 K_AMODEL_GEN_OK + staged bundle + __GameBundle；写 play-spec.json；amodel-ok → 短路 play |
+ | scaffold / asset / build | Harness | — | factory/gamedef 旧路专用；amodel 主线被短路跳过（不可达） |
+ | play | Harness | — | serve + Chrome CDP + play.cdp.cjs 九门（玩法无关）→ verdict.json + per-game 断言 |
+ | player | Agent ×2 | 文本=stage1 · 视觉=M3 | VLM 玩家评判（软门）；有体验问题 → repair |
+ | nreview | Agent | stage1 · narrative | 叙事类游戏叙事审查 |
+ | emit | Harness | — | 读 bundle.iife.js → 断 __GameBundle → status=succeeded |
+ | giveup | Harness | — | 超 maxRepairs(5) → status=failed + 落 giveup-dump.json |
+ | repair / escalate | Harness 路由 | — | repair=带反馈回 generate；escalate=升 stage2 强档回 generate |
+ | modify | Harness | — | gamedef/factory 专用：regenerate-module→generate / deterministic→guard fail-loud(END)；无 amodel 分支 |
+ | handleCallback → 入库 → studio | Fixed | — | 建版本→组包→落包→回填；入 game_source_project + engineBundle；studio 前端消费 |
+
+
+
+ 核心数据契约：
+ K_ENRICHED（design 产 → generate 消费，amodel 富化-brief 喂法）·
+ K_PLAY_SPEC（design 产 → play 消费 / 写 play-spec.json）·
+ bundle.iife.js（generate 产 → emit 消费）·
+ verdict.json（play 产）·
+ K_AMODEL_GEN_OK · K_SOURCE_PROJECT。
+
+
+
+
+
+
+
新设计方向 · 让生成「更好玩」 · 求审
+
+
+
+
+
+ ⑦ 核心论点：「能玩」已稳，短板在「好玩」 新设计 · 求审
+ 这是整个新方向的判断锚点。依据 = 2026-06-23-design-agent-audio-asset-line-review.md（§6.8 双评审已收口 + 代码核实）。
+
+
+ 三项决策（求批）：① 策划 agent（升级 designNode）= 低风险、大半已通（design→amodel 富化-brief 喂法已通，主要是把 design 调强）；② 音频/资产线 + ③ modify 双路 = 净新建（双评审 BLOCKER + 代码核实：amodel 跳 scaffold/asset/build，现有 asset 机器与 modify 生命周期都在 gamedef 分支、amodel 根本不走）。
+
+
+
+
+
+ ⑧ 现状 → Phase 1 → 2 → 3 演进总图（哪些复用 / 净新建 / 零触碰） 新设计 · 求审
+ 一张图看清演进。蓝绿灰底=现状不变骨架；青色=复用/升级（大半已通）；紫色=净新建；浅灰描边=零触碰（gamedef/factory 旧路、通用九门）。三阶段彼此独立可交付。
+
+
+ 读图三色：青=复用/升级 design 升级 + per-game 断言 + SFX；紫=净新建 API 静态门 + 好玩机检 + 整条音频/资产线 + modify 双路；灰=零触碰 通用九门 + gamedef/factory 旧路（含其 modify 生命周期）。
+
+
+
+
+
+ ⑨ Phase 1 放大 ＝ 策划 agent（design 升级为 tool-using JS agent） 新设计 · 求审
+ Phase 1 只动 create 路的 design。把它从「Java 单次便宜模型调用」升级为会读 skill 的 tool-using JS agent：read 真 sim-business-game-design.md（守「绝不手抄 skill」铁律）→ 产更丰富设计（进货/库存环 + 节奏目标值 + 好玩自检）+ gatespec。amodel 路 shell-out，gamedef design 一行不动（零回归）。
+
+
+ 喂法零接线：design 产出经现成的 K_ENRICHED 富化-brief 文本喂 amodel harness（create 路已通）；gatespec 经现成 merge 进 play_spec.assertAfterPlay。Phase 1 主要是把 design 调强（prompt + 升 M3），几乎不新接线。design 输出格式（D8）先维持富化散文 brief（今天就能用、零接线），结构化 schema 留后（会扰动刚转绿的 amodel e2e）。
+
+
+
+
+
+ ⑩ 质量门三类 — 门各司其职，通用九门保持玩法无关 新设计 · 求审
+ 这是新设计最关键的边界纪律（采纳创始人纠正）：玩法正确性走 per-game 断言，绝不进通用九门。三类门各管一段，互不污染。
+
+
+ 边界纪律（硬约束）：通用九门 = 运行时 + 玩法无关，绝不加品类/玩法语义。① 是玩法无关的静态门（治幻觉）；② 是玩法语义但走 per-game 断言（挂 H 门现成 assertAfterPlay，九门定义零改）；③ 是设计时机检（不在运行时门里）。三者分立 = 既补「好玩」又不破坏「能玩」门的纯洁性。
+
+
+
+
+
+ ⑪ Phase 2 放大 ＝ 音频/资产线（净新建 · harness 内部，非扩 SAA asset 节点） 新设计 · 求审
+ 定位纠正（双评审 BLOCKER）：asset/audio 必须做进 amodel harness 自己的 scaffold/build/stage，不是扩 SAA assetNode —— 因为 amodel 路 validate-ok 短路、根本不走 SAA asset 节点。这是一条贯穿「插件契约 → host → harness → studio」的新运行时通道。
+
+
+ 体积门（M2 待解）：首屏≤2MB / 总≤10MB 门目前在 amodel 路未真正布防（publish-amgen 只记 bundleSize）。执行版须明确：该门在 amodel 哪里布 + 解 inline-vs-lazy-fetch 张力。这是兔子洞（五处都要动），故 Phase 2 独立交付。
+
+
+
+
+
+ ⑫ Phase 3 放大 ＝ modify 双路（净新建） 新设计 · 求审
+ 现状（B1，代码核实）：无 amodel modify；harness 每次从 _template 全新 scaffold、无「读旧项目 src/」工具；现 modify 节点是 gamedef/factory 专用（regenerate-module→generate / deterministic→guard fail-loud）。要让 amodel 也能「按意图改旧游戏」，必须新建两件能力 + 定语义。
+
+
+ 三阶段独立性：Phase 1（仅 create）不依赖 modify/资产线，可独立验「设计层补料能否更好玩」；Phase 2、3 各自独立执行版。每阶段回归底线 = factory/gamedef 冻结路、studio 现播放路、通用九门、SAA 83 确定性回归、刚转绿的 amodel e2e 全绿。
+
+
+
+
+
+