# tier2 实现详设

> 🚧 设计中 · tier2 是待 0号 spike 验证的假设,尚未落代码;过了 spike 才进建设。

> **这是什么**:tier2 自治富游戏轨的实现详设 —— 怎么对接、怎么建、怎么部署、怎么跑、怎么测、怎么验。
> **给谁看**:要动手搭 tier2 的工程师,以及拿这份去跑 0号 spike、据结果裁 go/no-go 的人。

## 第一批工程定义:源项目契约

先看现在的游戏怎么进浏览器,因为 tier2 要在这条路上接第二种产物。现在一款生成好的游戏不是仓库里的代码,而是一份存进库的数据:游戏代码被打成 `engineBundle`,内嵌在它那份 GamePackage 的 manifest JSON 里(整包带一个 sha256 校验)。玩家在 feed 点开,后端把这份 manifest 下发,浏览器取出 `engineBundle`、挂到 `window.__GameBundle`,`bootGameHost` 在沙箱 canvas 上把它跑起来,之后每帧回调游戏的 update / render。每款游戏就是库里一条 GamePackage,不是仓库里一份源码。

tier2 的产物也走"存进库、按需取来跑"这条路,但形态不同。它不是 Tier0/1 那种声明式数据壳 + 固定运行时,而是一个真 Phaser 引擎工程 —— 多个源文件、一份构建脚本、一套依赖,要先 esbuild 构建出 bundle 才能玩。这两条装载路不通用、解耦并存,所以 tier2 立项要补的第一件工程,就是给真引擎工程新写一套源项目契约。

这套契约要钉住七样东西,分四组。先是身份:一个**源项目类型标记**,让装载侧一眼分得清这是 ECS-lite 数据壳还是 tier2 引擎工程、走对应的装载分支。再是工程骨架:**文件树 manifest** 记下有哪些文件、各自什么角色(入口、场景、资产、配置),**入口文件**标出 build 从哪个文件起手,装载和寻址都按它们走。然后是构建可复现:**构建 profile** 固定这一款用什么命令、什么 esbuild 配置打包,**依赖锁**钉死引擎和插件的版本,免得上游一升级历史游戏就构建不出来。最后是落库取回:**内容哈希**给整个工程算一个指纹,做缓存命中和完整性校验;**落库与寻址 API** 定义工程怎么存进 MySQL 加对象存储、怎么按 id 取回来重建。

这条边界要再讲死一遍:这套源项目契约是 tier2 自己的,绝不碰 Tier0/1 廉价线在生产上跑着的 ECS-lite 装载契约。两条装载路解耦并存,tier2 这边怎么改都不许回归现有产线。这也正好接上项目早定下的产品基座 —— 游戏是长生命周期的结构化源项目,改源不改包、重新构建,真·多文件 Phaser 工程本身就是一个可维护的源项目。

## 统一 trace 契约的实现接点

tier2 这条 ReAct 轨每跑一次,要把"想一步、调一个工具、看结果"的全过程写进观测仓:每一步推理、每一次工具调用、每一次模型输入输出、每一道门的裁决、每一笔成本。这跟 SAA 那 16 个节点的阶段裁决不同构,所以两条线的轨迹不强求字段对齐 —— 强求对齐是错的。正确的做法是同一张表,一个公共核心子集加各轨自己的扩展段。

落到实现,接点有三处。**公共核心子集**是两条线都必有的最小集 —— traceId、step、cost、verdict、timestamp,tier2 老老实实把这五样填上。**扩展段**是一个 JSON 列,tier2 把自己独有的推理、动作、观察塞进去,SAA 那边塞它的阶段、修复轮次、门裁,各写各的、互不编造。**写不进去时的策略**默认 best-effort —— 轨迹写失败不阻塞主生成流程,但计入告警,不能让一次落库抖动把整局生成废掉。

这份契约落在 `contracts/trace/` 下,对齐契约组里已命名的轨迹契约位,additive 地演进,内容包括字段定义、schema 版本、敏感字段脱敏规则、两条线各自的 adapter 怎么映射。tier2 这边只管"按这份契约把自己的轨迹写进去",它的 adapter 把 ReAct 三段映射成契约字段。轨迹契约的完整治理口径 —— 为什么消灭 split-brain 指的是"诚实镜像各自字段"而非"强求对齐"、两条线接口层对称内容层不对称怎么成立 —— 写在《agentic 生成架构:tier2 富游戏自治轨 + 控制/管理面治理层》(下文简称集成架构档),本档只交代 tier2 这一侧的实现接点。

## 建设五步与 0号 spike 生死门

建设按创始人给的五步走,在第三步之前插一道便宜的 0号 spike 门。一条贯穿的原则定调:最深的赌注要在最便宜的时候验,别等平台和引擎都搭漂亮了,才发现便宜模型生成不出富游戏。

```mermaid
flowchart TD
    S1["第一步 · 搭 AgentScope 完成集成<br/>(从 L2 studio 编排演进,非 L1 裸 openai 主线)"]
    S2["第二步 · 配置外置做实<br/>(prompt/编排/模型可配不发版 · 归线A阶段2-3 · 本档引用不重排)"]
    SPIKE{"0号 spike 生死门<br/>便宜模型能否自治写出那 56% 表现层?<br/>最小 AgentScope + 硬编码配置即可先验"}
    RETREAT["按退路树走<br/>(绝不滑成无限调参)"]
    S3["第三步 · 以 Phaser 为范例搭生成引擎<br/>边搭边反哺第一二步"]
    S4["第四步 · Phaser 自治生成一款过人审<br/>(对标肥鹅美食街)"]
    S5["第五步 · 完善 Cocos 生态 + 推进 Phaser 渠道 adapter"]

    S1 --> S2 --> SPIKE
    SPIKE -- "过(go)" --> S3 --> S4 --> S5
    SPIKE -- "不过(no-go)" --> RETREAT

    H3["隐藏硬工作:验收地板 / Goodhart 安全 / 成本强制 / 源项目契约 / 可观测早建"]
    S3 -.补齐.-> H3
    H4["隐藏硬工作:终审判据 / 终审吞吐模型 / player panel 减负"]
    S4 -.补齐.-> H4
```

**第一步,搭起 AgentScope、完成集成。** 这是 agent 和循环的运行时底座。它从仓内已有的那条 L2 studio 编排演进,而不是从 L1 裸 openai 主线起 —— 仓内实际是两条线,L1 生产主线明确不引 AgentScope(框架的 token 膨胀会吃掉便宜档单价),AgentScope 是 L2 的叠加依赖,体现在 `agent_loop/studio.py` 那条多角色 studio 编排里。所以 tier2 演进的对象是 L2 那条 studio,躯干七成已在,是演进、不是重写。这层地基值得建,而且它和下一步的配置外置回头还能服务现有 Tier0/1 线。

**第二步,把配置外置做实。** 让 prompt、编排、模型这些模型的全部输入都可配置、不发版可改(声明式为主、带脚本逃生口),并把一切挂上可回溯的轨迹。这一步的实现归线A的阶段2-3,本档引用、不重排。

**第三步之前,先插 0号 spike 门。** 原来的顺序是先搭引擎(大投入)再出肥鹅人审过(才验它能用),但便宜模型真正要现写的是那约 56% 的表现层,这是整轨最深、也最没证过的风险。所以在把全引擎生态铺开之前,先用一个最小、可丢弃的 spike 把这个赌注便宜地证一遍。关键是这道门不必等第一二步全做完 —— 最小的 AgentScope 加硬编码配置就能先验。它的可跑工程规格在下文第四节展开。spike 不过,就按退路树走,绝不滑成无限调参。

**第三步,spike 证成后,以 Phaser 为范例搭起生成引擎,边搭边反哺第一二步。** 这一步表面是搭引擎,底下藏着五块必须显式排进去、不补就埋雷的硬工作。验收地板 —— 把九门泛化到 Phaser、为经营品类补确定性 driver、加跨表语义门,没有它"人审通过"是空的。Goodhart 安全 —— agent 自产的取证 driver 必须过平台白名单加独立评审,写者不能写判自己游戏的那张卷子(九门是绘境现行那套"在真浏览器里真玩一遍判能不能玩"的确定性验收门;Goodhart 指优化代理指标反而偏离真目标)。成本强制 —— 四道熔断加三层预算现在只是 best-effort,自治多轮不强制会烧钱,规模化前必须落地。真 Phaser 工程的源项目契约 —— 也就是本档开头那套,文件树 manifest、构建 profile、依赖锁、落库寻址,这步要真接上。可观测要早建 —— 轨迹仓加成本台账,spike 调试和对账当下就要,这也是复利中台唯一该在这个阶段建的部分。

**第四步,用 Phaser 自治生成一款质量极高的游戏,对标肥鹅美食街,过确定性地板加人工终审。** 这里要把"人审"做实,而不是创始人亲玩一票:要有终审判据(把"好玩"拆成可复核的几条、压个人品味方差)、一个终审吞吐模型,并让 player panel 去判有没有明显劣化信号(可达性、空内容这些确定性可逼近的)给人门减负,否则 premium 量一上来,人审会变成瓶颈或橡皮图章。产物是一个可维护、可回头改和扩的 Phaser 源工程(改源不改包),不是生成完就完的一次性产物。

**第五步,完善 Cocos 生态,同步推进 Phaser 的渠道 adapter。** Cocos 放在 Phaser 证成之后是对的 —— 它是另一条轴(编辑器、人在环,服务 3D、复杂、渠道导出),进不了 tier2 的自治循环,不该和 Phaser 并级、更不该在核心赌注证成前就铺。渠道 adapter 走仓内 W-CH-α 已实证到 P0 的那条"轻 H5 引擎加自研 adapter"路,待补是 P1 真机门,卡在创始人的三件套那道日历闸门上,不是技术阻断。

## 0号 spike 可跑 runbook

这个 spike 是为了在最便宜的时候,把"便宜模型能不能自治写出那 56% 的表现层"这个最深的赌注证伪或证成。集成架构档的相关章节写的是判据哲学 —— 测什么、为什么分两段、退路怎么走,不是可跑的工程规格。一个工程师拿那份跑不起来这个 spike:靶子游戏没有确切规格、模型没点名、过门没有数字阈值、两段没有步骤、采集指标没有字段。补齐这五块,spike 才能照着跑。

### 靶子游戏:mini-肥鹅

spike 的对照组("人工预建骨架加人工预建 driver")得有一个确切的靶子游戏才能预建。这里把它钉死 —— 一个砍到能证、又保住三个本质难点(多系统耦合、重 UI 表现层、数值经济闭环)的最小经营游戏,代号 mini-肥鹅,结构参照仓内 `wanglanmei-ref` 但更小。砍掉任务弹窗、背包深度、上百物品,留三个联动系统。

```mermaid
flowchart LR
    subgraph 合成系统["合成系统(重 UI 表现层主承载)"]
        M["3×3 棋盘 · 点两个相同物品合成上一级<br/>mergeChains 6 条链 / 覆盖 12 物品"]
    end
    subgraph 资源系统["资源系统(读写交汇点)"]
        R["金币 + 食材库存<br/>{ coins, ingredients }"]
    end
    subgraph 订单系统["订单系统"]
        O["3~5 个顾客订单 · 要物品给金币<br/>orders 5 个模板 / 有 patience"]
    end

    M -- "合成产出进库存<br/>consumeIngredient 扣食材" --> R
    O -- "完成订单扣物品<br/>addCoins 加金币" --> R
    R -- "金币门控解锁第 4/5 摊位、更高合成链" --> M
    M -- "产出物品须满足订单 requires<br/>(跨表可达性)" --> O

    WIN["赢 = 金币达 100(开局 20 攒上去)"]
    LOSE["输 = 连续 3 个订单流失"]
    R --> WIN
    O --> LOSE
```

资源系统维护两种货币 —— 金币和食材库存,它是其余两个系统的读写交汇点:合成消耗食材、订单产出金币、解锁花金币,状态就是一张极小的表 `{ coins, ingredients: { [id]: number } }`。合成系统是一块 3×3 棋盘,玩家点两个相同物品合成上一级,合成链是数据表 `mergeChains: [{ from, to, cost }, ...]`,给 6 条链覆盖 12 个物品,产出进资源系统的库存,这块是重 UI 表现层的主要承载(棋盘格渲染、点击命中、合成动画)。订单系统是一个面板列 3~5 个顾客订单,每个要一组物品给一笔金币,数据表 `orders: [{ id, requires, reward, patience }]`,完成订单从库存扣物品、给资源系统加金币,耐心耗尽订单流失。

系统间的确切耦合点是这 spike 的考点,不是三个孤岛:订单的 `requires` 必须能被合成系统产出的物品满足(跨表可达性);完成订单调资源系统的 `addCoins`;合成消耗调资源系统的 `consumeIngredient`;金币门控解锁(攒够金币解锁第 4、5 个摊位和更高合成链)。胜负条件 —— 赢是金币从开局 20 攒到 100(经"合成→交单→收金币"的正循环),输是连续 3 个订单流失(只合成不交单、或经济崩盘),两条路径都要能被 harness 真输入驱动跑到终态并 latch。内容量定在 12 个物品、6 条合成链、5 个订单模板、2 种货币,足够证数据驱动而不至于让 spike 本身变重。这份规格就是第一段里"人工预建骨架"和"人工预建 driver"的施工图 —— 骨架按这三个系统加耦合点预建(平台代码),driver 按"点合成格→凑齐订单物品→交单→看金币涨"的确定性序列预建。

### 模型矩阵与样本量

"便宜/中等模型"是个集合不是一个值,过门率、成本、收敛步数这三个产出数必须有归属对象,否则"60% 是哪个模型的 60%"无法回答。spike 跑这个矩阵:

| 角色档 | 模型 | 说明 |
|---|---|---|
| 主力便宜档 | deepseek-v4-flash | 现行 Tier0/1 打底模型,tier2 自治的主力候选 |
| 强便宜档 | deepseek-v4-pro | 现行救场档,测"贵一档便宜模型"是否显著抬过门率 |
| 中等 agentic 档 | MiniMax-M3 | 用对它 = Anthropic /v1/messages 原生加 agentic 工具循环;这批最能打,**先用它证路**(见下"跑序") |
| 强模型基线 | Opus / Fable | 只跑 1~2 款作"路通不通"的上限基线,不进成本评估 |

样本量上每个便宜/中等档跑 n ≥ 30 真跑(承袭"先跑 n≥30 真基线、别拿单次当基线"的硬教训),强模型基线 n = 2~3。题面用 5 个一句话变体(美食、水果、咖啡、面包、糖水店),每变体每档跑 6 次凑够 n≥30。跑在 mini-desktop —— 权威构建加 e2e 门、x86 同构;禁本机 6c6g 跑 chrome。

**跑序:先用 M3 证路,再用便宜档比成本(2026-06-21 创始人定)。** 不一上来就把整张矩阵 × n≥30 全铺开。先用 MiniMax-M3 把路跑通 —— 它是这批便宜/中等档里最能打的一个(能力比 Sonnet 略强、且接得通),用它在全流程上自治产出一款 mini-肥鹅,创始人亲玩、判它确实是个有肥鹅味的可玩雏形。这一步证的是"便宜模型自治这条路到底走不走得通";走不通,就别在更便宜的模型上空耗。证通之后,再用 deepseek-v4-flash 和 deepseek-v4-pro 各跑一轮(n≥30)做对比,看把模型降到主力便宜档、过门率和单款成本各掉多少 —— 这一步证的是"便宜到什么程度还守得住"。Opus/Fable 那档仍只作路通不通的上限基线,不进成本评估。

### 过门判据与精确阈值

没有数字阈值,go/no-go 必然滑成"再调一轮",退路树也悬空。标 ★ 的是建议值、需创始人和实测校准,其余是承袭现行线的硬约束:

| 维度 | 阈值 | 来源 |
|---|---|---|
| 过门率(九门 + 三联动门 + 经济门全绿 + latch) | ★ ≥ 50% 起评、≥ 70% 算强信号 | 对照现行 factory 路 60%、cutover 门 80%;tier2 富游戏更难,spike 阶段先看是否显著大于 0、能否随档升 |
| 单款成本 | ★ ≤ ¥3 / 成功款 | 现行 L1 ≤¥0.15、L2 ≤¥5;tier2 premium 取 L2 偏下,留自治多轮空间 |
| 收敛步数 | ≤ max_iters(★ 单系统 ≤ 8 轮、整局 ≤ 40 轮) | 防靠运气擦边;超 max_iters 即判不收敛 |
| 长程一致性 | 12+ 文件工程过程中无 checkpoint 丢失、半轮副作用幂等无脏 | 采集字段 |
| 人锚 | 创始人试玩判一句"是不是个有肥鹅味的可玩雏形" | 软门,不可替代 |

### 两段实施步骤

变量隔离的逻辑落成可执行的两段,每段有输入、跑法、采集、gate。

```mermaid
flowchart TD
    subgraph stage1["第一段 · 纯模型变量(driver 是人预建的、不让 agent 碰)"]
        P1["预建(人投入):mini-肥鹅 经营骨架工程(三系统+耦合点,先天过 boot)<br/>+ 确定性 harness driver(点合成/凑单/交单序列)<br/>+ 数据表 schema(留空给 LLM 填)+ 资产池占位图"]
        P2["跑:便宜模型在骨架上填数据表 + 写表现层<br/>(场景渲染/事件接线/特色规则)<br/>自治循环 写源→build→headless 快检→九门→读 verdict→改"]
        P3["采集 + gate:过门率/成本/收敛是否达阈值"]
        P1 --> P2 --> P3
    end
    G1{"第一段 gate"}
    P3 --> G1
    G1 -- "纯模型变量就崩 → 不开第二段(开放自治只会更糟)" --> R["进退路树"]

    subgraph stage2["第二段 · 开放自产 driver(测自治上限 + Goodhart 安全)"]
        Q1["放开:让 agent 自产/扩 driver<br/>走三层隔离 ①agent 提议 driver →②平台 schema/白名单编译 →③独立 adversarial 评审<br/>(查它是否覆盖真实玩家路径、是否读作弊字段)"]
        Q2["跑 + 采集:额外采 自产 driver 被打回比例 / driver 修改次数<br/>(防它用改 driver 逃避卡死探测)"]
        Q1 --> Q2
    end
    G1 -- "过" --> stage2
    G2{"第二段 gate:自产 driver 不降过门可信度、自治不烧穿成本闸"}
    Q2 --> G2
    G2 -- "挂在 driver 安全" --> RG["判 Goodhart 防线设计问题(不是模型问题)"]
```

第一段是纯模型变量,固定人工骨架加人工 driver。先预建(人投入,Opus 或人写):按上面 fixture 规格,预建 mini-肥鹅 经营骨架工程(三系统加耦合点的平台代码,先天过 boot)加经营品类的确定性 harness driver(点合成/凑单/交单序列)加 12 物品/6 链/5 订单的数据表 schema(留空给 LLM 填值)加共用资产池占位图。再跑(便宜模型自治填那 56%):对每个模型档乘每个题面变体,跑 `worker/agent_loop/studio.py` 演进版(max_iters 放开),便宜模型在骨架上填数据表加写表现层(场景渲染、事件到表现的接线、特色规则),自治循环写源→build→headless 快检→九门→读 verdict→改。然后采集加 gate:按字段表采每款的 pass/repairs/¥/wall/出错系统/长程指标,第一段 gate 就是过门率、成本、收敛是否达阈值。这一段只测"填差异"的纯模型变量,driver 是人预建的、不让 agent 碰。

第二段开放自产 driver,测自治上限加 Goodhart 安全。在第一段证通的基础上放开,让 agent 自产或扩 harness driver,但走三层隔离:agent 提议 driver,平台按 schema 和白名单编译,独立 adversarial 评审查它是否覆盖真实玩家路径、是否读作弊字段(adversarial 评审指一个不向着被评对象、专找漏洞的独立评审)。跑加采集同上,额外采集"自产 driver 被独立评审打回的比例"和"driver 修改次数"(防它用改 driver 逃避卡死探测)。第二段 gate 是自产 driver 不降过门可信度(独立评审通过率高)、自治不烧穿成本闸。

两段之间的 gate 卡得很清:第一段不过(纯模型变量就崩)直接进退路树,不开第二段(开放自治只会更糟);第一段过、第二段挂在 driver 安全,判 Goodhart 防线设计问题,不是模型问题。step 模板复用仓内 `game-e2e-cdp-harness.md` 的四件套证据编排(render→截图时序→驱动→verdict),每款产出四件套证据可审计。

### 采集指标字段表

spike 的产出就是这几个数,无字段定义则跑完拿不到可对比的数。轨迹仓加成本台账最小版记这些列,每款一行(run 级):

| 字段 | 定义 / 取处 |
|---|---|
| run_id / model / stage(1 或 2)/ brief_variant | 标识 |
| pass | 九门 + 三联动门 + 经济门 + latch 是否全绿(确定性,取 verdict.pass) |
| repairs | 自治循环轮数(取 studio 的 attempt 计数) |
| fail_stage | 挂在哪(extract/validate/build/seven_gate/三联动门/经济门;承袭 studio 的 stage_fail) |
| fail_system | 挂在哪个系统(resource/merge/order/表现层;经营品类特有) |
| cost_rmb / tokens_by_model | per-model token 折¥(取 new-api quota 口径,cost.py) |
| wall_s | 墙钟 |
| file_count / total_loc | 产物工程的文件数、总行数(长程一致性) |
| ctx_compressed / checkpoint_recovered / idempotency_clean | 长程:是否触发上下文压缩、checkpoint 恢复是否无损、半轮副作用是否幂等无脏 |
| driver_authored / driver_rejected_by_review / driver_edits(仅第二段) | 自产 driver 的安全指标 |

汇总到矩阵级,每个模型档的过门率 = pass 款数 / n、¥/成功款 = Σcost / pass 款数、收敛中位数、fail_system 分布 —— 这三张图就是 go/no-go 的直接输入,对照阈值与退路树触发线判。

### 前置物清单

spike 开跑前这六样必须就位:mini-肥鹅 经营骨架工程(按 fixture 规格,Opus 或人预建);经营品类 harness driver(点合成/凑单/交单,确定性)加九门对 Phaser 的两钩子参数化(canvas 选择器、帧计数源);三联动门加经济门加 latch 的 assertAfterPlay 规格(订单引物品可达、合成 DAG 无环、经济可盈利可破产);studio.py 演进版(max_iters 放开,写源/build/headless 快检/跑九门/读 verdict/查资产注册进 toolkit);数据表 schema(12 物品/6 链/5 订单,留空给 LLM 填)加共用资产池占位图;成本计量接 new-api quota(per-model 折¥)加轨迹仓最小版。

## 退路树

spike 跑出来的过门率和失败集中处,按三条数字触发线分流到不同退路,让退路树真能被触发、不悬空。

```mermaid
flowchart TD
    START["spike 跑完,看矩阵级的 过门率 + fail_system 分布"]
    Q1{"最强便宜档 v4-pro 过门率<br/>是否仍 < 40%?"}
    Q2{"失败是否集中在表现层<br/>(render / 事件接线)?"}
    Q3{"是否失败集中在某个系统装不出<br/>(如合成棋盘命中几何反复错)、<br/>其余系统能过?"}
    Q4{"是否便宜档全线 < 20%、<br/>而强模型基线 Opus/Fable 能过?"}

    GO["go:过门率达阈值 → 转第三步以 Phaser 铺引擎"]
    R1["退向更模板化:更多预制表现模板、少 LLM 写<br/>(判 56% 自治承重太重)"]
    R2["补骨架再试:补该系统的骨架/driver 缺口<br/>(判骨架缺口,不是范式问题)"]
    R3["便宜模型天花板:换更贵模型重估经济性<br/>(撞 ¥3/款 上限就缓行),或整轨缓行"]
    KEEP["留观:既非全线崩、也非天花板 → 据具体数微调前置物再跑"]

    START --> Q1
    Q1 -- "是(< 40%)" --> Q2
    Q2 -- "是,集中表现层" --> R1
    Q2 -- "否" --> Q3
    Q1 -- "否(≥ 40%,达阈值)" --> GO
    Q3 -- "是" --> R2
    Q3 -- "否" --> Q4
    Q4 -- "是" --> R3
    Q4 -- "否" --> KEEP
```

第一条:最强便宜档 v4-pro 过门率仍 < 40%、且失败集中在表现层(render 和事件接线),判 56% 自治承重太重,退向更模板化 —— 更多预制表现模板、少 LLM 写。第二条:失败集中在某个系统装不出(比如合成棋盘命中几何反复错)、但其余系统能过,判骨架或 driver 缺口,补骨架再试,不是范式问题。第三条:便宜档全线 < 20%、而强模型基线(Opus/Fable)能过,判便宜模型天花板,要么换更贵模型重估经济性(撞 ¥3/款 上限就缓行)、要么整轨缓行。

## 现在证到哪,下一步真动作

已证的是产物形态:`game-runtime/games/wanglanmei-ref/` 是一款真存在过的、12 文件约 180KB 的多系统经营游戏,过了真输入 harness、赢和输双路径都可达,它证伪了"声明式数据壳之外的真引擎工程装不下肥鹅级富游戏"。Phaser 这条路能过确定性门也有独立证据 —— 2026-06-11 那次走廊小卖部样本在 Phaser 上过了五门。这两份证据各钉死一个点:前者钉死产物形态(与引擎无关),后者钉死 Phaser 这条路能跑真 harness。

没证的是 tier2 真正押的那一半 —— 这两次都是最贵的模型(Fable)加重人工编排做到的,不是便宜模型自治。最大的赌注是:便宜或中等模型的自治 agent,在经营骨架、玩法模板、资产池、RAG、九门兜底这套约束下,能不能稳定地把那 56% 的表现层写出来、过确定性门。赌注的来龙去脉在《自治富游戏引擎》那份引擎设计里,本档只接"怎么验"。

下一步三件:备齐上面第五节的前置物清单;在 mini-desktop 上跑两段 runbook;据采集字段与退路树触发线裁 go/no-go,决定 tier2 的正式投入与建设顺序。

## 验证状态

本档是 tier2 的实现详设(评审版),未落代码。它把 0号 spike 的 runbook(靶子规格、模型矩阵、阈值、两段步骤、采集字段、退路树)与 tier2 立项要补的源项目契约、统一 trace 契约实现接点收成一份可照跑的工程详设;阈值标 ★ 的需创始人和实测校准(尤其 ¥3/款 premium 预算、50%/70% 过门率门)。轨迹契约与控制面的完整治理口径在集成架构档,本档交叉引用、不重排。