32adda9517
10 张新图经 draw→对抗验证→族汇编 workflow(23 个 opus 子代理)产出,保留首批 3 张手绘样板: - C 单写循环:单写ReAct循环 / M3 Anthropic原生接法 / 四道熔断+预算闸 / 多轮范式承amodel-gen - D 三层校验:富游戏专属门(三联动+经济+latch) / advisory分级+Goodhart隔离 / CDP探针Phaser重写 - E 能力面:引擎能力包五件套 / prompt两阶段角色 / A-model 4插件复用 对抗验证逮修真问题:D3 'P3'命名碰撞(张冠李戴·grep证伪后改)/ D5 半角冒号 / E2 虚实线图例自相矛盾。 全 13 张复验 界内/良构/脚注/ok。3 份族图说带防漂移 commit hash + 人读散文(正反例传下子代理)。 D 族 advisory 跨分支状态校准:A-model 分支已落、未合并 dev/2.0.0,主干视角=接(非现)。 3 份细节图说接进 agentic运行时架构图说.md 看图入口。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
20 KiB
date, topic, status, 映射源档
| date | topic | status | 映射源档 | |||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2026-06-23 | tier2 细节图说 · D 族——三层校验与九门(生成引擎子树·tier2) | 设计中(tier2 待 spike) · 每图映射源档见该图脚注 / frontmatter 记 hash 作防漂移门 |
|
tier2 细节图说 · D 族 —— 三层校验与九门
本篇是绘境AI 架构图集 生成引擎子树 下的 tier2 细节图说,只覆盖 D 族(三层校验与九门验收) 五张图。生成引擎主干、tier2 总览、agentic 运行时各有自己的图说;这里专门把「一款生成出来的富游戏算不算过关」这件事画清楚。
0 阅读约定与同步纪律
D 族讲的是 tier2 富游戏自治生成线的验收骨架——从最顶层的三层校验框架,一路下到现行九门、富游戏专属新门、advisory 分级机制,再到把这套门从 LittleJS 搬到 Phaser 要付的工程代价。五张图映射四份属主设计档加一份探针源码:三层校验的口径出自《tier2 实现详设》和《自治富游戏引擎》(后者已升到三层口径),九门的精确判据和阈值出自《tier2 实现详设》的「过门判据」与「靶子 mini-肥鹅」两节,advisory 分级的真实落地证据出自现行九门探针 play.cdp.cjs,Phaser 重写与沙箱底座的工程序列出自 2026-06-22-003 计划的 U3/U6。frontmatter 记了这五份的当前 commit hash,作为防漂移门——其中任一份动了验收口径,本图说与对应 SVG 必须同步改。
整条 tier2 富游戏线现在 整体待建:0号 spike 还没跑,引擎没搭,门没重写,代码一行没落。所以 D 族里几乎所有「新机制」都是设计已出、尚未落地的状态,绝不能因为图画得齐整就误以为已经建好。有承袭、不全是新建的部分,用实线画,但这里要把两层承袭分清,别一概当「主干现行」。现行九门 harness 在 LittleJS 廉价线上判了大量游戏,是真跑了很久的底座,这部分确是主干现行。它内置的「driven 感知 advisory 分级」却要单独说清出处:这是 A-model 分支(feat/mac-amodel-foundation)近期给九门加的增强,在那条分支上已实现,但尚未合并到 dev/2.0.0 主干——本仓 docs/tier2-plan 的 play.cdp.cjs(frontmatter 记的 9d463f08)还是用各门 SKIP 标志达成同义降级,字面 advisory 块要等 A-model 合并后才进主干。图里 advisory 用实线,表的是「它已被实现」(A-model 线),不是「已在主干」;严格按状态码,从主干看它是「接」(待合并对账),tier2 实现时以 A-model 合并后的版本为准。tier2 自己要做的全是把这套哲学搬到 Phaser、再在九门之上补富游戏专属的几道门,这部分用虚线画。看图时记住这条对照:实线 = 已实现(主干现行的九门,或 A-model 分支已落待合并的 advisory);虚线 = tier2 专属、待 0号 spike 验证后才落代码的新机制。
1 全图通用图例
D 族用一套统一的徽章和线型,先在这里讲清,后面每张图不再重复。
层级徽章标的是一道门落在三层校验的哪一层:绿色 L1 = 硬约束层(编译 / 启动 / 运行错误,必须解决、循环);蓝色 L2 = 设计符合层(玩法 / 关卡 / UI vs 设计,尽量解决);橙色 L3 = 效果层(美观 / 好不好玩,只评分、绝不阻塞)。处置徽章标的是这道门怎么处置:红色 硬 = 硬门(不过即拒发),橙色 无 driver 降 advisory = 条件门(被驱动时致命、没被驱动时只报告)。另有几个生产维度徽章在个别图上点到:质量(绿)、可靠(绿)、安全(红)、可观测(蓝)、数据(灰)。
线型承担状态语义。实线框 = 现行已落,虚线框(短划线)= tier2 专属待建。实线箭头 = 现行已有的转移 / 关系,虚线箭头 = tier2 待建的流程或重写映射。
状态码四个,贯穿生成引擎子树:现 = 现行已建在跑;接 = 设计已出、代码待接线;建 = tier2 立项后要新建、当前待 spike;缓 = 收窄后缓做。D 族绝大多数元素是「建」,九门 harness 与 advisory 分级是「现」。
2 图集
图 D1 · 三层校验全景
一款生成出来的富游戏算不算过关,在 tier2 里不是一个笼统的「过了九门就行」,而是按创始人定的三层校验来判,三层各管一档、处置力度截然不同。这张图把三层并排铺开,关键在于让人一眼看出它们的处置差异,而不是把它们当成同一种门的三个名字。
最底下的 L1 是硬约束层,管的是编译、启动、运行错误这类客观事实——游戏 boot 不起来、跑着跑着抛异常、画面是死的,这些都是真问题,必须解决,而且循环逼到解决为止。判它的全是确定性信号:构建日志、浏览器 console、CDP 错误捕获、九门探针,机器说了算,零 LLM 参与判定。绘境现行那套「在真浏览器里真玩一遍判能不能玩」的九门,绝大多数落在这一层。中间的 L2 是设计符合层,管的是玩法和关卡实现得对不对、UI 有没有缺组件、品类约定有没有违反,处置是「尽量解决」而非死循环,靠的是确定性的设计符合度信号(九门里的机制进展 H_progress 就落这层)。L2 的拒发权不是天生就有,而是 observe → enforce ——先只观测、积累信号,等这道门在真实数据上证明自己判得准,才赋予它拒发权。最上面的 L3 是效果层,管特效、美观、好不好玩,处置是 只评分、绝不解决、绝不阻塞拒发,工具是 M3 多模态视觉软检(看截图打分),产出只进质量趋势、告警、给人工终审减负。
为什么 L3 死活不让它当门,是这张图最该让人记住的设计取舍,底部那条铁律带说的就是这件事。两个极端都不能取:把确定性门扩到能自动判「好不好玩」,会得到一堆能被刷的代理指标——同一套机制门下,精心做的打砖块和「摆三块砖点一下就赢」的退化品都能全绿,门就废了;反过来纯靠 LLM 当玩家裁判判好玩,又踩了 Goodhart 红线(优化代理指标反而偏离真目标),因为模型一旦进验收当裁判,会学会把游戏优化成「让裁判说好」而不是「真的好」。所以效果只评分、不当门,好不好玩最终归人工终审。还有一条迭代原则同样要紧:初期只焊死 L1,L2/L3 渐进做,绝不让效果问题阻塞真问题——一款刚生成的富游戏,先把「能不能运行」这件硬事判死,美不美观是后话;用户也可以经 HITL 主动要求继续解决任意层。整套三层在 tier2 里都还是待建状态,spike 初期只焊 L1。
图 D2 · 九门逐门
L1 那层「确定性归机器」的主体就是九门。这张图把九道门逐道拆开,每道门讲四件事:测什么、用什么探针手段、落 L1 还是 L2、是硬门还是条件门。读这张图的正确方式是把它当成 L1 的施工细节——D1 给的是三层的处置哲学,D2 给的是这套哲学在最底层具体怎么落成九个可机器执行的检查。
九门覆盖的是一款游戏从「能不能起来」到「玩起来正不正常」的完整链条。A_boot 判游戏能不能 boot 起来(navigate 后轮询 boot 信号);B_uncaught 判运行期有没有未捕获异常(console 加 CDP 错误监听);C_frame 判帧在不在推进、有没有卡死(前后两次取帧号差大于零);D_render 判画面有没有真实内容(截图回读亮像素阈值);E_live 判画面在不在变、是不是静止帧(对多帧取 FNV hash 去重);F_wiring 判逻辑是真调引擎还是空桩(查引擎 API 的调用前缀有没有出现);G_input 判注入输入后状态有没有变化(注入 input 再读 gameState 前后对比);H_progress 判核心机制有没有真进展(driver 驱动加玩后断言,含 latch 终态);I_control 判控制响应跟不跟手(输入到反应的时序在阈值内)。九门里只有 H_progress 落 L2(它判的是机制实现 vs 设计,属设计符合),其余八门都落 L1;E_live 和 H_progress 还带一个「无 driver 降 advisory」的条件标记,这正是下面 D4 要展开的分级机制。九门全绿等于机制地板通过、可发。
这套九门为什么对 tier2 重要,在于它把「做完了」这件事钉死在客观证据上,绝不让 LLM 给自己打分——这是防 Goodhart 的机制地板。但要看清一条现行与远期的边界:现在这九门是为 LittleJS 廉价线建的,所有探针钩子都硬编码了 LittleJS 专属取法(#game-engine 选择器、window.__engine.snapshot().frame 帧源、__gameHostEngineInitFired boot 信号)。tier2 复用的是「真玩判定加零自评」这套哲学,不是这套代码——探针要为 Phaser 整个重写,并且在九门之上再补富游戏专属的几道门(跨表联动、经济、latch,见 D3)。图底那条脚带把这件事点明:这是「重写适配层、不是参数化一键切」,而沙箱底座选型(直接复用现有 CDP,还是用 agentscope-runtime 的 BrowserSandbox)是 spike 开跑前必须先出结论的前置阻断项。
图 D3 · 富游戏专属确定性门
九门是为「超休闲单局」量身定的机制地板——它确定性地判一款单场景小游戏能不能玩,但它不查跨系统接线。富游戏的本质难点恰恰在跨系统:像 mini-肥鹅 这样的经营游戏是合成、资源、订单三个系统耦合在一起,光过九门远远不够,还得确定性地证明「三个系统真接上了」「经济的盈利和破产两条路都真能跑到终态」「赢输的终态真落定」。这张图就是在九门之上补的三道富游戏专属门,整图全是 tier2 待建(虚线),待 0号 spike 验证后才落代码。
第一道是 三联动门,管跨系统接线,要证三个系统是真耦合而非三座孤岛。它的判据是确定性的、静态加真玩混合:订单的 requires 必须能被合成系统产出的物品满足(这是一次跨表可达性检查,静态地从 mergeChains 推到 orders),合成链必须是有向无环图(对 mergeChains 做拓扑检查、不许成环),完成订单时必须真调资源系统的 addCoins,合成消耗时必须真调资源系统的 consumeIngredient。第二道是 经济门,管数值经济闭环——一个真正的经营游戏既要能赢也要能输,所以这道门要 harness 用真输入把两条路都驱动到终态:可盈利的路径是金币从开局 20 经「合成→交单→收金币」的正循环攒到 100 判赢,可破产的路径是连续三个订单流失(只合成不交单或经济崩盘)判输。关键约束是这两条路都得能被 harness 的真输入驱动跑到终态,不能只是「在数据表里能算出来」——能算和能玩到是两回事。第三道是 latch 门,管终态落定:赢或输一旦落定就不能回弹,而且宿主要能读到终局。这道门承接现行宿主装载那条已经验过的约束——游戏没有 emit 通道,所以终态必须焊成一个可轮询的 latch,由宿主轮询去读,而不是靠游戏主动 emit。
这三道门和九门的关系,图中间那条「九门(实) + 三门(虚) = tier2 的 L1 机制地板」的式子讲得最清楚:九门是超休闲地板,三门是富游戏接线地板,两者合起来全绿,才算富游戏的机制地板通过。底部那条带把这三道门钉到了一个确切的靶子上——mini-肥鹅。它是 spike 对照组的施工图:3×3 合成棋盘加资源系统(金币加食材库存)加 3~5 个带耐心的顾客订单,内容量定在 12 个物品、6 条合成链、5 个订单模板、2 种货币,砍到能证、又保住多系统耦合 / 重 UI 表现层 / 数值经济闭环这三个本质难点。这三道门的 assertAfterPlay 规格就是照这个靶子写的,driver 也按「点合成格→凑齐订单物品→交单→看金币涨」的确定性序列预建,产出复用 game-e2e-cdp-harness 的四件套证据(render→截图时序→驱动→verdict)。
图 D4 · driven 感知 advisory 分级 + Goodhart 隔离
九门里有两道门——E_live(画面在变)和 H_progress(机制有进展)——只有在游戏真被人驱动起来的前提下才判得公平。一款游戏如果根本没人给它输入,画面本来就该是静的、机制本来就没进展,这时候硬判它 E_live / H_progress 不过,是冤枉它。这张图的上半部分画的就是解决这个冤案的机制:driven 感知 advisory 分级,它承接 A-model 分支、创始人 2026-06-22 裁定,在那条分支上已实现(实线表其已落)。按 §0 那条 branch 说明,它还没合并到主干——从 dev/2.0.0 看是「接」(待合并对账),tier2 以 A-model 合并后的版本为准。
机制是一个两态的判断:当 spec 既没有 driver 也没有非空 inputs 时,driven 为 false——游戏没被驱动,无法公平评判可玩性,于是 E_live 和 H_progress 降为 advisory(仍然跑、仍然报告,但不计入 pass),硬门只剩七道(A/B/C/D/F/G/I);一旦 spec 给了 driver 或给了 inputs 序列,driven 变 true,这两道门自动恢复致命、九门全部计入 pass,而且不用改一行代码。一句话概括就是「driver 缺位则降 advisory,driver 到位则恢复致命」。这个范式对 tier2 不只是搬过来用——tier2 修 latch 门和经营门时复用的正是它:先 observe(只观测、积累信号),等 driver 到位、判据证准了再 enforce(卡死)。把「先观测后卡死」做成可控的状态转移,而不是一上来就硬卡,是这套分级真正的价值。
图的下半部分是 tier2 的第二段「开放自产 driver」,整段待建(虚线),它要解决一个比上半部分更危险的问题。第一段 spike 的 driver 是人预建的,纯测模型变量;第二段要放开,让自治 agent 自己产或扩 harness 的 driver,以测它的自治上限。但这里埋着一颗 Goodhart 雷,就是图底那条红线铁律说的:写者不能写判自己游戏的那张卷子。agent 既造游戏又造判它的 driver,会自然而然地把 driver 写成只盖它走过的路、只读不暴露真实力的字段,然后全绿——假绿。隔离手段是把「写卷人」和「判卷人」拆开,走三层:agent 提议 driver 后,平台先按 schema 和白名单编译(只许声明式合法形态过,非白名单或越界字段直接拒),再交独立 adversarial 评审(一个不向着被评对象、专找漏洞的评审,查它是否覆盖真实玩家路径、是否读了作弊字段以避开真考验),三层全过这个 driver 才入验收,任一层不过就退回 agent 重提。为了让这道隔离可观测,第二段还专门采集两个指标:自产 driver 被独立评审打回的比例、driver 被修改的次数(防它靠反复改 driver 来逃避卡死探测)。
图 D5 · CDP 探针 Phaser 重写 + 沙箱底座
九门的探针机制(真浏览器真玩加确定性判定)在 tier2 里不变,但它的引擎钩子全是 LittleJS 专属的,要为 Phaser 重写。这张图最该破除的一个误解是「换引擎只要改个参数」——它不是。整图待建(虚线),核心是一张「引擎钩子重写映射」表,左边是探针现在硬编码的 LittleJS 取法(实线、已落),右边是 tier2 要为 Phaser 重写的等价钩子(虚线、待建),每一行都要各自重写,中间那条虚线箭头标的就是「重写」而不是「切换」。
要重写的钩子有四条。第一条是 canvas 选择器:现行用 #game-engine 做像素回读和触摸坐标映射,Phaser 自己挂 canvas、id 不同,选择器和坐标映射都得按 Phaser 视口重写。第二条是帧源:现行 C 门读帧 delta、G 门把对照实例推进到同帧号,都读 window.__engine.snapshot().frame,Phaser 的帧驱动机制不同,得另找一个单调递增的帧计数替代它。第三条是 boot 信号:现行 A 门轮询 __gameHostEngineInitFired 判引擎接管完成,Phaser 的 boot 序列独立(scene create 完成),得另置一个「引擎已起、可真玩」的就绪标志。第四条是输入注入加状态读取:现行 tap/key 注入加 __gameState 读取(经 _forensicsView 导出)支撑 G 门和 H 门,Phaser 的输入投递路径和可测性接口要重接,而富游戏的 state 还要走经营门那套约定导出。这四条逐条重写,不是一个参数切过去——这是这张图反复强调的判断。
图底两个框讲的是这件事的两个边界。左下角的沙箱底座框是一道 spike 前置阻断验证:先做个小验证,看 agentscope-runtime 的 BrowserSandbox 暴露的 page.evaluate / CDP 能力够不够(navigate / screenshot / 输入注入逐项可用),够就直接用它跑探针矩阵,不够就回落到自建薄沙箱加复用现有 play.cdp.cjs 的路。这道结论必须在 U7 生成迭代开跑前出来——出不来,整个 spike 跑不起来,所以它是属主标记的前置阻断项。右下角的「第一版克制」框讲的是另一种纪律:第一版只参数化九门 harness 的引擎钩子(canvas 选择器、帧计数源),把 Phaser 的 RAG 和脚手架硬编码进 worker,通用能力包接口(skill / mcp / tool / rag / 脚手架)暂不建满。理由很实在——现在只有 Phaser 一个真实现,接口形状会被它一个人反向决定,等第二个引擎(Pixi)落地、有两个实现做依据,再抽真正的能力包接口才不会白抽。这是一个有意的「先别抽象」决策,不是没做完。
3 图清单与状态表
| # | 图名 | 形式 | 状态 | 覆盖内容 |
|---|---|---|---|---|
| D1 | 三层校验全景 | SVG · 分层卡片 | 建(tier2 待建 · 初期只焊 L1) | L1 硬约束 / L2 设计符合 / L3 效果三层的内容、处置、工具包、谁判;三条铁律(机器判确定性、L3 只评分防 Goodhart、初期只焊 L1) |
| D2 | 九门逐门 | SVG · 九宫格 | 现(九门=LittleJS 现行)/ 建(tier2 Phaser 重写探针) | A_boot/B_uncaught/C_frame/D_render/E_live/F_wiring/G_input/H_progress/I_control 逐门的测什么 / 探针 / 落 L1 还是 L2 / 硬门 or advisory |
| D3 | 富游戏专属确定性门 | SVG · 三门卡片 + 关系式 | 建(tier2 待建 · 经营品类专属) | 三联动门(跨表可达 + DAG 无环) / 经济门(盈利破产双路径到终态) / latch 门(终态落定不回弹);九门 + 三门 = tier2 L1 机制地板;靶子 mini-肥鹅 与 assertAfterPlay 规格 |
| D4 | driven 感知 advisory 分级 + Goodhart 隔离 | SVG · 状态机 + 流程 | 接(advisory 分级=A-model 分支已落·待合并 dev/2.0.0)/ 建(自产 driver 三层隔离=第二段待建) | 上:无 driver 两门降 advisory、有 driver 恢复致命的两态转移(observe→enforce 范式源);下:自产 driver 走编译 / 独立 adversarial 评审 / 通过才用的三层隔离防 Goodhart + 两项采集指标 |
| D5 | CDP 探针 Phaser 重写 + 沙箱底座 | SVG · 重写映射表 + 二分 | 建(tier2 Phaser 重写探针 + 沙箱底座 spike) | 四条引擎钩子(canvas 选择器 / 帧源 / boot 信号 / 输入加 state)的 LittleJS→Phaser 重写映射;沙箱底座 spike 前置阻断(BrowserSandbox vs 回落 CDP);第一版克制(只参数化钩子、不抽满能力包接口) |