diff --git a/.agents/knowledge/tech-decisions.md b/.agents/knowledge/tech-decisions.md index de4f09ac..f9fc0cea 100644 --- a/.agents/knowledge/tech-decisions.md +++ b/.agents/knowledge/tech-decisions.md @@ -44,7 +44,7 @@ **导出枢纽 = 微信小游戏格式包**：微信=引擎导出官方格式；抖音=自有导出接口；**快手=无专用接口，走"微信格式兼容转换"**（快手开发者工具）。**LayaAir 官方平台清单无快手**，不走 LayaAir CLI 路线。Tier2/3 用 Cocos 官方一键导出微信包；Tier1（LittleJS）渠道 adapter 走 W-CH-α 对比竞标（LittleJS+自研 adapter vs Cocos 导出，HJ-CH-001 §4；~~「Tier1 自研 Canvas 自做 adapter」随自研壳退役~~）。 > 选型依据：Cocos 3.8.8/MIT 一栈覆盖2D/3D/原生导出，故 **3D/原生/渠道导出轴** 选 Cocos；Three.js r184/MIT/113k★ 仅 web3D、与 Cocos 重复故不选；LayaAir 2.1k★、无 AI/MCP 生态、清单无快手（否决）；Unity 启动 7-10s×2-3 与 P75<3s 冲突（否决）。 -> **⚠️ supersession + 纠错（2026-06-21 · tier2 触发）**：上句原作"headless MCP(158 工具) 使 AI 驱动可行"**是事实错**——Cocos 的 MCP 是**编辑器扩展、需 Cocos Creator 在跑、非 headless**（取证级核实），故 Cocos **进不了 tier2 全自治生成 loop**。引擎重定为正交两轴：**自治生成轨（全无头：富 2D=Phaser/Pixi、超休闲=LittleJS）** vs **3D/渠道导出轴（Cocos，编辑器+人在环）**；Phaser 的"spike 落选"只在 Tier1 超休闲冷启动维度、与 headless 自治维度正交。本表其余 Tier2/3=Cocos / Phaser 否决 行均按此口径理解。详见 `docs/agent-specs/2026-06-21-agentic生成架构-tier2与控制面.md` §三(引擎选型)。 +> **⚠️ supersession + 纠错（2026-06-21 · tier2 触发）**：上句原作"headless MCP(158 工具) 使 AI 驱动可行"**是事实错**——Cocos 的 MCP 是**编辑器扩展、需 Cocos Creator 在跑、非 headless**（取证级核实），故 Cocos **进不了 tier2 全自治生成 loop**。引擎重定为正交两轴：**自治生成轨（全无头：富 2D=Phaser/Pixi、超休闲=LittleJS）** vs **3D/渠道导出轴（Cocos，编辑器+人在环）**；Phaser 的"spike 落选"只在 Tier1 超休闲冷启动维度、与 headless 自治维度正交。本表其余 Tier2/3=Cocos / Phaser 否决 行均按此口径理解。详见 `docs/architecture/架构/生成引擎/自治富游戏引擎.md`(引擎选型)。 --- diff --git a/docs/agent-specs/2026-06-21-agentic生成架构-tier2与控制面.md b/docs/agent-specs/2026-06-21-agentic生成架构-tier2与控制面.md deleted file mode 100644 index 3bb3d421..00000000 --- a/docs/agent-specs/2026-06-21-agentic生成架构-tier2与控制面.md +++ /dev/null @@ -1,242 +0,0 @@ ---- -date: 2026-06-21 -topic: agentic 生成架构 · tier2 富游戏自治轨 + 控制/管理面治理层 -status: 设计(review 版) -关联: 2026-06-21-tier2-spike-0-详细设计.md(执行详细设计 · 0号 spike runbook) ---- - -# agentic 生成架构:tier2 富游戏自治轨 + 控制 / 管理面治理层 - -## 这份文档讲什么,以及该用什么心态读它 - -绘境AI 现在已经有一条能跑的游戏生成线。它的工作方式是:一个强模型先搭出一份声明式的脚手架——把游戏拆成实体、场景、数值、规则这层结构化的外壳;然后一个便宜模型往这层外壳里填逻辑;最后由一套确定性的"九门 harness"在真浏览器里把游戏真玩一遍,机器化地判定它到底能不能玩。这条线我们内部叫"Tier0/1 超休闲廉价线"。它最大的价值,是把"能生成代码"和"生成出来真能玩"这两件本来分开的事,用机器手段焊在了一起——这是绝大多数竞品补不上的工程纵深。这里需要先解释两个会反复出现的简称:Tier0 指那条最基础、追求可靠和规模的生成档,Tier1 是它向上略富一点的延伸,两者共用同一套声明式范式和同一套九门验收,本文统称"Tier0/1 廉价线"。 - -但这条线有一道天花板。2026-06-20 我们组织了一场对抗式审查,让四个独立视角去挑它的毛病,审查的结论很关键:**它合理,但够不到天花板。** "声明式数据壳加一坨不受契约约束的自由 JS"这套范式,结构性地只能产出 pong、点击器、躲避、跑酷这一类几何色块的单局小游戏;运行时本身就没有承载多关卡、库存、对话树、敌人状态机、可变 HUD 这类复杂度的形状。审查给创始人的那句话是:愿景必须诚实分层——Tier0 用这套范式吃可靠、吃可验收、吃规模,复杂品类必须另开一条轨。 - -这份文档讲的就是"另开的那一条轨",我们叫它 **tier2**:用一个能自治工作的 AI agent,去生成现有廉价流水线做不出来的富游戏。它分两大块。前半部分是 tier2 这条生成轨本身的架构与决策——引擎怎么选、产物长什么样、agent 自治到什么程度、怎么验收。后半部分是治理层,也就是控制面和管理面——这套自治生成怎么被配置、被看见、被审计、被管起来,正是创始人最早提的那个"要像 Dify 一样能可视化、可追踪、可审计地管 agentic 平台"的诉求。治理层之所以归进这份架构档,是因为它本质上是 tier2(以及现有 SAA 线)的治理叙事,而不是一个独立的产品,把它和被治理的生成轨放在一起讲,边界才清楚。 - -读这份文档之前,请先记住一个前提:**tier2 现在是一份待证的假设,不是一块已经夯实的地基。** 这条轨最核心的架构选择——后面会详细讲的"约束自治"——本身就是一个需要靠一个最小实验去证伪或证成的假设。所以本文把架构讲清楚,是为了给那个实验一个明确的靶子和一棵明确的退路树,而不是为了在实验之前就把工程投入固化下来。凡是能推迟到"实验通过之后"再建的东西,本文都明确地推迟了。请带着"这是在为一次关键验证做准备",而不是"这是已经拍死的施工图"的心态往下读。 - -## 一、为什么需要 tier2 这条轨 - -现有这条生产线擅长的是超休闲小游戏:单一场景、极轻的 UI、一个核心循环。它是对的,该坚持。但凡是"多系统耦合、重 UI、大内容量"的游戏,它的固定脚手架就装不下了。 - -tier2 要越过的就是这道天花板。它瞄准的品类是合成、经营、挂机、经济养成,最典型的对标对象是《肥鹅美食街》那一档游戏:屏幕上有资源栏、合成棋盘、店铺列表、订单面板、任务弹窗、商店背包,内容上有上百件物品、一整套经济数值。这种游戏的难点其实不在画面渲染,而在三件事——重 UI、多个系统互相接线、大内容量。现有那套"一次性填空"的范式吃不下它,原因很具体:这种游戏的生成步数是不可预测的(不像填一个固定的槽位),系统与系统之间是一张稠密的依赖图(合成产出要进库存、订单要读库存、解锁要扣金币),没法靠一次填空一蹴而就。 - -所以 tier2 换了一种生成方式:让一个能自治工作的 agent,拥有一台完整的"游戏工作站"——它能读引擎文档、能写多个源文件、能构建、能跑真玩验收门、能看截图、能查资产——然后在一圈确定性验收门的笼子里反复迭代,一点一点把一款富游戏逼出来。它面向的是价值更高、产量更低的 premium 场景,跟现在那条超休闲廉价线是**解耦、并存**的关系,不是替换。这条"解耦并存"是贯穿全文最硬的一条边界:两条轨各吃各的市场、各跑各的运行时,tier2 的任何工作都不得触碰、不得回归现有的廉价线。 - -这里要先纠正一个会让人误判定位的说法:tier2 不是"在 Tier0 范式上加点功能去够到肥鹅"。审查已经把这条路否掉了,理由是 Tier0 的声明式范式并不是"还不够好",而是"天然站在可靠这一端,够不到复杂那一端"——这是范式层面的张力,不是补个分支能解的。强行让同一套 schema 同时背"可靠"和"复杂"这两个互斥的目标,正是审查点名的唯一范式级误判风险。所以必须另起一轨,而不是改造主轨。 - -## 二、tier2 的核心范式:O2 约束自治 - -定下要另起一轨之后,最核心的问题是:**让这个生成 agent 的自由度给到多大?** - -这件事有一个谱系。谱系的一端是"纯约束"——把游戏的复杂度尽量压成数据表和预制骨架,让 LLM 只填值、不写代码,自治范围收得很窄;另一端是"纯自治"——给 agent 一台工作站,骨架顶多是个可选的起步种子,剩下全靠它自己写。我们在中间摆了三个具体选项,内部叫 O1、O2、O3,创始人拍的是中间那个 **O2,我们给它起的名字叫"约束自治"**。(这三个代号只是当时摆选项时的编号:O1 是纯约束填充,O3 是纯全自治,O2 是两者之间。) - -### 三层拆分:数据表、系统骨架、表现层 - -O2 的做法,是先把一款游戏拆成三层,用这三层去约束 LLM 的自由度。 - -最底下一层是**数据表**——关卡参数、商品列表、合成链、订单模板、经济数值这些纯配置。这一层 LLM 只填值,不写逻辑。 - -中间一层是**系统骨架**——资源结算、合成规则、订单状态机这类系统逻辑。这类东西每个经营游戏长得都差不多,所以由平台预先写成参数化的骨架,不劳 LLM 从零发明。 - -最上面一层是**表现层**——画面长什么样、点下去有什么反馈、这个游戏独有的那些规则。这部分没法预制,只能让 LLM 现写;我们把它和零散的接合代码统称"胶水和主题"。 - -把这三层定下来之后,O2 真正押的赌注,原本可以用一句话概括:富游戏 80% 的复杂度是内容体量和系统接线(可以压成数据表加参数化骨架,不经过 LLM),只有 10% 是真正新颖的逻辑(让 LLM 在很窄的受控面上薄薄地写一点)。 - -### 一个必须诚实交代的校准:80/10 其实是 44/56 - -但上面那个 80/10,是这条轨立项时凭判断拍的,没有实证。我们后来真的去量了一遍,结论是它高估了 LLM 能被省掉的部分。 - -我们拿仓里一个真实的样本来量。`game-runtime/games/wanglanmei-ref/` 是一款已经被造出来的"王蓝莓"经营类多系统游戏,十二个源文件、约 180KB,由我们最贵的模型(Fable)在迭代循环里、配上三轮人工编排造出来,已经过了真输入 harness、赢和输两条路径都能走到。对它那十二个源文件逐个、按字节加权地归类,结果是:**数据表大约占 19%,可参数化的骨架大约占 25%,而一次性的胶水和主题占了大约 56%。** 换句话说,"不经过 LLM"的那一侧其实只有 44%(不是 80%),而"LLM 必须真写"的那一侧是 56%(不是 10%,而是它的五倍多)。占比最大的那一块,是 `render.js` 那种逐像素手画的场景和 UI 层——将近两百处直接调底层 canvas 的代码,几乎不碰任何能力插件 API,它既压不成数据表、也压不成骨架。 - -这里要诚实标注两件事。第一,这是单样本,而且它用的是裸 canvas 的 LittleJS 引擎,这种引擎把"手画"的占比最大化了,换一个自带场景图的引擎,这个数字会往下浮动。所以 44/56 不是一个普适常数,而是一个把立项时的乐观假设打掉的硬数据点。第二,需要点明一处容易搅混的事实:`wanglanmei-ref` 用的引擎是 **LittleJS,不是我们后面为 tier2 选定的 Phaser**(它的源码 `entry.js` 明确写着 `import 'littlejsengine'`)。它在这里扮演的角色,只是"一个真·多文件引擎工程到底能不能装下肥鹅级富游戏,以及那 56% 的手画层有多重"的形状证据,这个证据与具体用哪个引擎无关。后面讲 Phaser 时会用到另一份独立的证据,两者不要混。 - -### 这个校准说明了什么:约束有效的地方,和真正烧钱的地方 - -这个校准没有给 O2 判死刑,但它把 O2 真实的样子讲清楚了,而且这个真相是有用的。 - -一方面,**约束这条杠杆,对"系统加手感"那 44% 是真有效的,而那 44% 恰恰是便宜模型结构上最容易崩的部分。** 经营游戏的那套状态机——顾客队列、耐心、经济账本、结算循环——是可以复用的品类骨架;手感、物理、粒子、音频、存档这些横切能力,全都走受控的插件 API(我们量过,逻辑文件里几乎没有裸 canvas 调用,却有近百处插件 API 调用)。便宜模型最不擅长的事,就是"发明出对的系统结构、把它们正确接线",而这件事被骨架和插件 API 接管掉了。这是约束器真实的、被实测确认了的价值。 - -另一方面,**真正的成本和风险,落在那 56% 的"把这一款游戏画出来、把事件接到表现上"。** 这一层每款游戏都得 LLM 现写,体量最大,也最容易翻车——布局会乱、命中几何和渲染几何会对不上、事件编排会出错。所以 O2 的"自治"那一侧,担子比立项时假设的重得多。这把成本和可靠性的赌注抬高了,也正因如此,后面要讲的那个 0号实验,从"锦上添花的验证"变成了"不证就不能投的硬门"。 - -顺带把 O1 和 O3 为什么被否也讲清楚。O1 是纯填充,模型只填不写——这次实测其实直接排除了它,因为纯填充根本产不出那 56% 的手画场景,它只能做换皮游戏,够不到富游戏。O3 是纯全自治,不加任何约束——它会在那 44% 上烧钱发散,因为富游戏工程的搜索空间太大,便宜模型会在里面反复打转、试错,成本和收敛性都会失控。所以 O2 仍然是对的形状,它只是比立项设想的更靠近 O3 一点(自治承担得更多)。一句话:O2 就是用骨架、数据表、插件 API 把系统层最难的那 44% 锁住,把 LLM 的自治火力集中到不得不写的 56% 表现层,再用四道熔断和确定性门把这股自治关在笼子里。 - -### 谁在写:单写者 ReAct,加上四道熔断 - -驱动这套结构的,是一个**单写者的 ReAct agent**。先解释 ReAct 这个词:它指的是 agent 那种"想一步、调一个工具、看工具返回的结果、再想下一步"的循环工作方式(reason-act-observe 的缩写),而不是一次性把答案写完。"单写者"指的是只有一个 agent 持有对整个工程的全局心智模型,它一个人写,不并行拆给多个 agent。配套的是几个只读的探路子 agent,和一道独立的、被调教得很挑剔的评审回路。 - -之所以坚持单写者、不并行多写,是因为肥鹅这种游戏是"稠密共享上下文"的最坏情形——多个系统共享同一套状态和约定,把它拆给并行的子 agent 几乎必然产生不一致。这里有一个一手教训:曾经把"造一个 Flappy Bird"拆给并行子 agent 去做,结果背景跑成了马里奥。所以富游戏这一档不能并行拆写。 - -这个单写者在门内可以任意迭代,但它的自治被四道熔断守着,任何一道先触发就立刻停下来。第一道是迭代步数的硬顶——每个系统的"构建-修复"轮数有上限。第二道是网关级的预算闸——花到上限就拒绝继续执行。第三道是语义层的卡死探测器——发现模型在原地打转就喊停。第四道是双层超时。其中预算闸和卡死探测器这两条,它们今天的现状和边界需要诚实交代(预算闸目前还不是强制的硬闸,这一点会在治理层那部分专门讲)。 - -### 验证哲学:确定性地板归机器,好玩好看归人 - -O2 的验收被切成干净的两层。 - -第一层是**确定性地板**:游戏可不可运行、玩起来正不正常、产物体积小不小,这三件事由确定性的 harness 当机器门来判。这一层有一条铁律——**绝不让 LLM 给自己打分**。原因是一旦把 LLM 拉进验收回路当裁判,就会触发 Goodhart 效应:模型会学会把答案优化成"能让裁判说好",而不是"真的好",门就废了。这条铁律直接继承自 Tier0 九门的设计哲学(把"做完了"钉死在真浏览器里真玩一遍,而不是模型自夸),是经过验证的工程纪律。 - -第二层是**软门**:游戏好不好玩、好不好看,这两件机器判不了的事,交给人工终审,外加一个 player panel(玩家面板顾问团)辅助参考。 - -这里否掉了两个极端。一个是"把确定性门一路扩展到把好玩好看也自动判了"——它被否,是因为"好玩"本质上是机器判不了的主观体验,硬要用确定性指标去逼近它,最后只会得到一堆能被刷的代理指标(审查里点过这个风险:同一套机制门下,精心设计的打砖块和"摆三个砖块点一下就赢"的退化品,都能全绿)。另一个是"纯靠 LLM 当玩家裁判去判好玩好看"——它被否,是因为这正好踩了上面那条 Goodhart 红线。所以最终是"确定性的归机器、主观的归人"这条混合路线。需要先埋一个伏笔:人工终审这一环,它的吞吐、判据、怎么防止退化成橡皮图章,目前还是一笔明确的待补设计债,后面讲风险时会专门展开。 - -## 三、引擎选型:为什么是 Phaser 和 Pixi - -定下"产物是真引擎工程、范式是约束自治"之后,要回答用哪个引擎。结论是首批选 **Phaser 和 PixiJS**——既不是这条轨之外 Tier1 用的 LittleJS,也不是中文生态最厚的 Cocos。这两个选择都需要把理由讲透,因为它们都推翻了一些直觉,甚至推翻了仓内一份已经锁定的结论。 - -### 一道不可妥协的硬筛:全无头、纯代码、不依赖 GUI 编辑器 - -tier2 的引擎必须先过一道绝对前提的筛子:**它能不能被全无头地驱动——纯代码或纯 CLI 就能构建出游戏,完全不依赖任何图形化编辑器。** 道理很直接:生成游戏的是 agent,不是人,整条"生成-构建-验收"链上没有人坐在编辑器前面点鼠标。任何"必须打开图形化编辑器拖拽才能产出工程"的引擎,agent 根本无从下手。 - -用这把筛子一过,中文生态最厚的两个引擎——Cocos Creator 和 LayaAir——恰恰过不了这道门,因为它们都强制依赖图形化编辑器来组织场景和资源,缺乏成熟可用的无头 CLI 构建路径。再往前一辈的老引擎,Cocos2d-x 和 Egret 确实是纯代码的、过得了无头门,但这两个引擎已经事实性死亡——社区停滞、维护断档,把一条要长期演进的生成轨押在死引擎上是不可接受的。这是一个必须诚实承认的真取舍:做中文市场的游戏生成,直觉上谁都会先想到资料最多、社区最大的 Cocos 和 Laya;但偏偏是"全 AI 可做"这条对自治生成不可妥协的前提,把它们筛掉了。我们不是没看见它们的生态优势,而是这个优势在"无头自治生成"的约束面前用不上——编辑器依赖就是 agent 自治的硬墙。 - -### 为什么排除 Cocos:取证级的证伪,以及一处必须纠正的事实错 - -排除 Cocos 这件事,需要正面处理一个治理冲突,而不是绕过它——因为绕过冲突正是这个项目此前栽过跟头的地方。 - -仓内有一份锁定的 SoT(`tech-decisions.md` 和 `引擎与运行时.md`)白纸黑字写着:Tier2/3 = Cocos Creator 加 MCP,理由是"Cocos-MCP 的 158 个工具让 AI 驱动可行",并据此明确否决了 Phaser(说它"纯 2D、导出弱""spike 竞标落选")。本文选 Phaser、排除 Cocos,直接推翻了这份锁定结论。这种推翻必须被显式标注成一次 supersession(取代),并给出推翻的依据,否则就会留下两份互相矛盾的 canonical 文档。 - -我们对这件事做了取证级的核实(不是推断),结论是 Cocos 过不了那道"全无头、纯代码、不依赖 GUI 编辑器、能在循环里全自治生成"的硬筛。证据是一手的:Cocos Creator 官方 3.8《命令行发布》文档原文写明"从命令行运行时仍需 GUI 环境""不存在独立于编辑器的 CLI 或 SDK",它的命令形态就是直接去调那个数 GB 的编辑器二进制、CI 必须能访问显示服务,纯 Linux 无 GUI 容器根本跑不通。仓内自己的渠道 spike 报告早就撞上过同一堵墙(Cocos 与微信、抖音的开发者工具都没有 Linux 版,真实出包必须 Windows/Mac 加 IDE)。 - -而那个被当成核心理由的"158 工具 MCP",它的上游项目(`cocos-mcp-server`)README 自述是一个 **Cocos Creator 编辑器扩展插件**,要装进项目里跑、自称"实现 99% 的编辑器控制",并明确说"没有 Cocos Creator 编辑器在运行,本插件无法工作"。也就是说,它要求编辑器进程一直开着——SoT 里"headless MCP"这个措辞,与上游的事实直接矛盾,**这是一处需要纠正的事实错。** 至于纯代码的 cocos2d-js 那条路,官方已经弃用(明说"cocos2d-v4 移除了 js"、仓库改名标了 deprecated);`cocos/cocos-cli` 是面向底层引擎的 alpha 工具,覆盖不了 Creator 的场景资产管线,用它等于放弃了当初选 Cocos 的全部理由。 - -正确的收口方式不是"Phaser 取代 Cocos",而是认清它们活在两个正交的轴上。一个轴是**自治生成引擎**——要全无头、纯代码,服务 tier2 那个无人值守的循环,这条轴上是 Phaser 和 Pixi。另一个轴是**渠道导出引擎**——要复杂 3D 加一键渠道导出,人在环里离线作者,这条轴上 Cocos 仍然合适。Cocos 当初为后一个轴被选,并没有错;它只是不能进 tier2 的全自治循环。所以这份文档据此触发 supersession:那两份 canonical 需要更新,把 tier2 全自治生成主线引擎改为 Phaser/Pixi,把旧的"Cocos+MCP = headless 可行"明确纠正为事实错误(MCP 实为编辑器扩展),Cocos 保留在"渠道/App 离线导出加人在环"那条边界上、不进 tier2 循环。这两处文档的同步,作为本文定稿后的一个独立动作执行。 - -### 为什么选 Phaser/Pixi,以及为什么这一档不用 LittleJS - -过了无头门之后,首批落地的引擎包定为 Phaser 加 PixiJS,同时明确这一档(tier2 富游戏)不用 LittleJS。 - -不用 LittleJS 的理由有两条:一是它在富游戏品类上零先例,没有人用它做过有分量的经营、挂机类作品,没有可参照的工程范式;二是它太冷门,冷门到 LLM 的训练语料里几乎没有它的代码,模型根本不会写。LittleJS 的位置留给"超休闲极小包"那一档(也就是 Tier1),不进富游戏轨。 - -而选 Phaser 和 Pixi 的核心依据,是一个被反复确认的判断——**要从"AI 作者"的镜头来看引擎,而不是从"人类工程师"的镜头。** 对人来说,引擎好不好用看的是 API 顺不顺手;但对 AI 来说,引擎能不能用、自治生成稳不稳,第一决定因素是**生态丰不丰富,因为生态丰富约等于训练数据密集**——LLM 见过这个引擎的真实代码越多,它写出来的东西就越对、越不容易在自治循环里漂移。这是整条引擎选型逻辑的中枢。具体到这两个引擎:Phaser 有近四万星、从 2013 年起持续演进,社区里有现成的挂机、经营类先例可参照,而且有 weapp-adapter 这类移植路径能往小游戏渠道走,这些都意味着 LLM 对它"很熟"。Phaser 3.2 以上官方支持 `Phaser.HEADLESS` 无头模式、配 geckos 的 node 适配能在纯无 GUI 的 Node 里跑,构建就用 esbuild——这恰好和仓内 Tier1(LittleJS 加 esbuild)那条"全程 Node/CLI、不开 IDE"的路线同构,可以零摩擦地塞进现有的 worker 循环和九门 harness。PixiJS 则是 Web 2D 渲染器的事实标准,它本身就是一个纯渲染能力层,不绑死一整套游戏框架的世界观,正好作为可组合的能力包加载。 - -还有一处必须澄清的证据归属。前面讲过,`wanglanmei-ref` 用的是 LittleJS,它证的是"产物形态"——真多文件引擎工程装得下经营富游戏,与具体引擎无关。Phaser 这条路本身能不能跑通,有另一份独立证据:2026-06-11 的引擎选型 spike,把同一款"王蓝莓小卖部"在 Phaser 跑道上也做了一遍,过了五门(真输入跑通了赢和输两条路、三十九次真点击、金币从 20 涨到 100、倒闭终态齐全)。所以钉死 Phaser 这条路能跑的,是这次走廊小卖部样本过五门的证据,而不是 `wanglanmei-ref`——别把这两者搅在一起。必须同样诚实地标注:这两次成功都是"最贵的模型加重人工编排"做到的,不是便宜模型自治——它们证伪了"形状做不出"这个悲观假设,却把 tier2 真正要证的那一半(把模型降下来、把人工编排换成自治)留给了那个 0号实验。 - -### 引擎是被动态加载的能力包,底座与引擎无关 - -最后点明引擎在这套架构里扮演的角色:它不是一个一次选定、所有游戏都长在上面的固定底座,而是一套可以**动态加载的能力包**。每一个引擎对应一套给生成 agent 用的 skill / tool / mcp / rag 配套——引擎进入系统的方式,是以"AI 作者能调用的能力"的形态进来的。这样做的好处是,对 agent 来说"换引擎"就降级成了"换一套加载的工具集",而不是一次架构重写,这天然契合 agent 那种"我有哪些工具能调"的工作方式。这里要诚实指出一处会被点名为"投机抽象"的地方:这个"能力包接口"如果一上来就建满(skill/mcp/tool/rag/脚手架五件套),而首批真正全实现的只有 Phaser 一个、Pixi 留桩,那么这个接口的形状会被那唯一的实现反向决定,等真要接第二个引擎时大概率得改。所以方向虽然站得住,第一版却不把抽象建满——实验阶段只做两件最小的事:把九门 harness 的引擎钩子(canvas 选择器、帧计数来源)参数化(这件事无论几个引擎都该做,而且它同时服务"为经营品类补驱动"这件实验必做的事),以及把 Phaser 的 rag 和脚手架直接硬编码进 worker。真正的"能力包接口"这个一等封装,推迟到第二个引擎(Pixi)真要落地、有了两个真实现、接口形状才有依据的那一刻。 - -## 四、渠道发布:放弃 Cocos 不等于丢掉渠道 - -把 Cocos 留在"渠道导出"那条轴上时,留下了一个必须正面回答的疑问:Phaser/Pixi 生成的游戏到底能不能发到微信、抖音、快手小游戏,还是只能留在绘境自己的 web 游戏流里?这一条经过核实,结论是:**Phaser/Pixi 的渠道发布是一项可以建的一等能力,不是一堵墙;放弃 Cocos 并没有丢掉渠道发布能力本身。** - -理由是几个被检验之后大半蒸发掉的"Cocos 优势"。微信官方明确说 weapp-adapter 只是参考实现、不再维护,并钦定"开发者应该基于自己选用的引擎实现自己的 adapter"——也就是说,自研 adapter 本来就是官方正路,Cocos 的"一键"不过是把这件事在引擎内部替你做完了。它一键省掉的那三步(adapter 垫片、分包、拉起开发者工具上传),全都是一次性就能固化进产线的工程脚手架,不是每款游戏都要重写;而且仓内的 W-CH-α 这个 spike,已经为结构完全相同的 LittleJS 把这条路推到了 P0 实证可行(adapter v0 启动起来、收到合成触摸、验证门 6/6 全过,还顺手逮到一个真 bug)。更要紧的是几个"看着像 Cocos 优势、其实平权"的点:变现 SDK(广告、支付、排行榜、登录)是 `wx.*` 这类原生调用,所有引擎都得手动接、Cocos 也不例外;快手没有任何引擎的专用导出,所有引擎都走"微信格式包转快手兼容"的转换、完全平权。甚至有一处反而 Phaser 占优——Cocos 的渠道构建需要 Windows/Mac 构建机,而纯代码引擎(Phaser 加 esbuild)全 Linux 就能打包,对一条要服务器化、无人化的生成产线来说这是反向收益,仓内 W-CH-α 已经实证了全 Linux 出渠道包。 - -诚实的让步只有一处:国内小游戏生态的成熟度和爆款案例,Cocos 明显领先,Phaser 在国内小游戏圈是"能用但非主流",社区方案偏旧、踩坑要自己填。但这影响的是"省多少力",而不是"能不能发"。 - -还有一条必须写进来、与引擎无关的真墙:渠道侧禁止动态生成代码(微信、抖音会剥离远程代码,明令禁止 eval 类的 JS 解释器),只允许"包内固定模板代码加远程纯数据配置"。所以 tier2 自治生成的富游戏要上渠道,必须从 web feed 那种"即时热发任意生成游戏"降级为"精选款固化进壳版本、走平台提审"——这是渠道的本质约束,Cocos 同样会撞上,不是 Phaser 的劣势,但它定义了 tier2 到渠道的产品形态:web feed 拿热发的长尾,渠道拿精选的爆款。落点很清楚:渠道发布不构成保留 Cocos 的理由;真正待补的,是把仓内 W-CH-α 的 P1 真机七门用 Phaser 的真包跑完(首屏、广告回调这些只能在真机上裁定),而它当前卡的是创始人手里的三件套(微信 AppID、Windows/Mac 构建机、安卓千元机测试机),这是日历闸门,不是技术阻断。 - -## 五、控制面与管理面:让这套自治生成被管起来 - -光有"让 agent 自治生成"还不够,平台还得能把这套生成管起来——能配置它、能看见它在干什么、出了问题能追溯、谁改了什么能审计。这正是创始人最早提的那个"要像 Dify 一样"的诉求。这一层就是控制面和管理面,它是 tier2(以及现有 SAA 线)的治理层。 - -讲它之前,要先立一条贯穿全节的纪律:**别把它做成一个从零造的、过度工程的重型平台。** 同目录的对抗审查裁决给过一个对症的范例——某个运行时能力本来需要四处人手同步,正确的解法不是上一个重型注册表,而是加一道一致性测试逼你改齐(从实现反射出真实签名、断言它和注册表相等、对不上就红)。控制面同理:它的内核是"配置即数据加全链可观测",不是从零造一个 Dify。能复用现成件就复用,能用一道一致性门兜住的就不上重型框架。 - -还要先讲清一件影响全局从属关系的事。仓内已经有一份《生成主线架构演进路线》,本文统一称它"线A"——它是生成主线那套地基(配置外置)分期落地的主计划。线A已经逐字把"配置外置"这层地基排进了它自己的关键路径:把 prompt 做成两端同源、解决 split-brain(同一份 prompt 被 Java 和 Python 两处各存一份、会漂移)是它的阶段2;把模型名外置成 `models.yaml` 加跨语言一致性校验,是它的阶段3。所以本节的第一原则是:**配置外置那层地基,本档绝不另立分期,只认领并引用线A;控制面只在它之上做真正的净增量。** 这不是客套,是为了避免两份文档对同一层地基各排一套计划,让接活的 agent 无所适从。本档真正的净增量收窄到几件:配置审计日志这条线、管理面 UI、把两条生成线的轨迹收成一份统一契约、把配置注册表从 prompt 推广到 skill/tool/mcp、以及热加载机制的选型。 - -控制面由四个组件构成,它们对两条生成线(SAA Tier0/1 和 tier2)暴露同一套契约——生成线只管"从配置注册表读配置、向观测仓写轨迹",不感知管理面长什么样。下面逐块讲清:每一块是什么、为什么要它、它今天是已经夯实的地基还是还停留在蓝图。 - -### 第一块:配置注册表——配置的唯一事实源 - -配置注册表要解决的痛点,就是创始人那句"改 prompt、模型、skill、mcp 还要重新部署"。它的内核是一句话:凡是现在"要改就得发版"的东西,都搬进一个版本化、可回滚的配置注册表里。 - -但这里必须把承诺的边界钉死,免得又把半成品当成现成。prompt 和 models 这两层,前面说过,是线A的阶段2-3,本档只引用、不重排。本档对 models.yaml 补一句线A没细化的范围:它要覆盖的是"SAA 的逐角色路由加 tier2 的 agent 路由"这两类,并且要说清现有两个配置入口怎么并进去——`AigcExecutorProperties.llmModel` 是 worker 的单模型默认值,`SaaGraphDispatcher` 的 `saaForceModel` 是一个全局覆盖开关(创始人那次"只用 M3"加的,非空时就把全部 11 个角色统一成那个模型)。models.yaml 落地时,前者降为 fallback、后者作为"全局强制覆盖"这一档保留在配置里(它本来就是运营手段),逐角色那一档从 Java 工厂迁进 yaml。 - -至于"配置注册表"对 prompt 之外的推广(skill/tool/mcp 也进注册表),是本档的净增量。但有一条很硬的纪律:**别在裂的地基上盖更大的注册表。** 这里要诚实交代一件现状:今天的 Prompt Registry 并不是一块"现成可热加载"的地基。它的加载器类注释白纸黑字写着,prompt 是构建期被 maven 插件复制进 classpath 的**快照**——改 prompt 等于改 contracts 原文件、升版本号、过四道闸,然后**下次构建部署**才会携带新版。它是 Git 版本化加构建期注入,根本不是运行时热加载。而且它自身还有一致性缺口:注册表里有的条目标着"STUB 占位骨架,出正式草案时整体替换",对应的 prompt 文件通篇是占位提纲而不是正式内容;加载器里还硬编码了一批模板资源路径,未必都登记进了注册表。所以推广 skill/tool/mcp 之前,要先补一道一致性 CI:断言注册表里列的每条 prompt 都有对应文件、每个被硬编码加载的 id 都在注册表里登记、STUB 条目要么补正要么显式标注为不可上线。地基自洽了,推广才有意义。 - -### 第二块:观测 / 审计仓——"发生了什么"的唯一事实源 - -第二块要回答两个独立的问题,对应两条留痕线。 - -第一条是**运行轨迹**:每一次生成到底发生了什么——每一步推理、每一次工具调用、每一次 LLM 的输入输出、每一道门的裁决、每一次成本。这里要先把一条铁律的真实口径说准:消灭 split-brain(轨迹分散在各条派发路上)指的是"每条派发路诚实地镜像它真有的字段、没有的绝不编造",而**不是**"强求两条线字段对齐"。tier2 的 ReAct 那种"想-做-看"三段,和 SAA 那 16 个节点的阶段裁决,本来就不同构,强求对齐是错的。所以统一轨迹的正确目标是:同一张表,加一个公共核心子集,加各自的扩展段。公共核心子集是两条线都必有的最小集(traceId、step、cost、verdict、timestamp),各轨把自己独有的东西放进一个 JSON 扩展列(SAA 放阶段、修复轮次、门裁,tier2 放推理、动作、观察)。这要落成一份真契约,建议放在 `contracts/trace/` 下,对齐现有契约组里已命名的轨迹契约位,additive 地演进,内容包括字段定义、schema 版本、敏感字段脱敏规则、两条线各自的 adapter 怎么映射,以及一条必须明确选边的策略——轨迹写不进去时,是阻塞生成还是 best-effort 丢弃并告警(默认 best-effort 不阻塞主流程,但计入告警)。 - -第二条是**配置审计日志**:谁、在什么时候、改了哪条配置、为什么。这条线现在完全没有,是本档新建的。它的最小数据模型至少要包括:谁改的、从哪改的(UI 还是直接改 Git/DB)、改了什么(前后 diff)、配置版本号、谁批的、何时生效、回滚到哪个版本、这次配置影响了哪些生成任务。这里还有一个必须选边、不能既要又要的架构决策:UI 改配置,是直接写运行时配置(DB 直写),还是创建一个 Git PR(GitOps)?GitOps 这条路审计天然(一次 commit 就是谁、何时、diff、为什么),可回滚、可评审,但生效有 PR 加构建的延迟;DB 直写即时,但审计要自己补全、回滚要自己实现。本档的建议是分类处理:prompt、models 这类版本化资产走 GitOps(它们本来就在 contracts 里,而且线A的 CI 卡字节本就依赖 Git 为源),运营开关类(降级、配额数值)走 DB 直写、复用现有的 infra_config 通路(它们本来就该即时生效、且已经有现成通路)。 - -把这两条线钉在一起的价值是:任何一次生成的轨迹都能反查"它当时用的是哪几条配置的哪个版本",这样才能回答"那一批游戏质量掉了,是不是上周改的那条 prompt 干的"。存储上复用已经部署的 MySQL 加对象存储,不新起重型可观测中间件(链路追踪那套是 future-state,等真有第一个消费者再上)。 - -### 第三块:运行治理门(D12)——入口前的保护门,已有件复用 - -第三块是 D12 控制平面,它是已经存在的件,本档只复用、不改。它已经把配额、并发限制、背压保护、降级开关、记账骨架,焊在了生成任务的入口前面——代码里 SAA 的提交和重试两条路都过它,默认关闭、零行为变更进主干,开闸前由创始人显式打开。这是控制面"运行治理"那一格。这里要诚实标注两点边界:其一,它现在只覆盖 SAA 那条路,tier2 接进来的入口、预算扣减、并发释放、失败补偿都还要补;其二,它的记账是骨架,不是真计费(只是门结构加配置键,不是成本核算)——别把"记账骨架"写成"已具成本控制"。 - -这一点也接上了前面 O2 那部分埋的伏笔:那道"花到上限就拒绝执行"的硬预算闸,目前并不是现成能力。现有计费只是 best-effort 地去取价、取不到也不阻断,那个金额阈值是观测台账的口径、不是网关层的强制拒绝。tier2 自治多轮 ReAct 的成本风险是真实的(一次失控循环能烧掉数美元),所以需要落一套三层强制:worker 本地的 token/成本预测先闸、网关的配额二闸、任务 deadline 三闸,并定义取价不可达时的策略(是直接失败,还是降级到纯 token 上限)。在这套强制预算建成之前,tier2 不进规模化跑、只在严格时间盒的实验里跑。 - -### 第四块:管理面 UI——注册表与观测仓的视图与编辑器 - -第四块是管理面 UI,它是注册表和观测仓的视图与编辑器,不是真相本身。这是创始人最早最在意的那半边——他要的是"Dify 式可视化 agentic 平台管理":改 prompt/模型/skill/tool/mcp 不发版、可视化、可追踪、可审计、不要死代码。 - -关键的设计选择先讲清:是从零造一个 Dify 式的可视化建图器,还是让配置成为真相、UI 只是配置加轨迹的视图与编辑器?本面选后者,理由有三:前期平台调研已经拍板"维持现有的 SAA/AgentScope、不迁移到可视化平台";裸图的节点是 Java 代码、ReAct 的工具也是代码,真相在代码和配置里,靠 UI 拖拽生成代码是另一套不可靠的范式;以及那条"别过度工程"的纪律。但"配置是真相、UI 是视图"不等于"第一期什么都不做、把可视化全推到远期"。所以管理面按三档落,而且诚实命名,不冒认它还没做到的事: - -**phase-1,叫"配置管理加运行可观测控制面",而不叫"可视化编排"**(因为这一期还没有真正的图编辑,叫"可视化编排"名不副实)。它先包含一个不依赖任何前置、纯只读的"看得见"切片:读现有的轨迹和模型配置,呈现三件事——看各角色当前用的是什么模型、回放任意一次生成的全轨迹、按 new-api 的 quota 口径对账成本。这件事现在就能做,不改任何配置、不画任何图、不依赖线A的任何一步,是立刻能给创始人看见的最小兑现。在这个只读切片之上,phase-1 再加"配置编辑"——在 UI 里改 prompt 文本、换模型、调参数阈值,改的是注册表条目,改完落 Git 加审计日志,而不是直接热生效。 - -**phase-2,叫"配置编辑 UI 的完整化加限定范围的可视化图编辑"**。这一档把图编辑明确排进来(不再推到远期):在 UI 上做节点的启停、边的开关、节点的模型/工具绑定、配置版本 diff、按某次轨迹回放。注意"限定范围"四个字——它编辑的是节点参数和启停这一层,渲染出来的拓扑结构来自运行时自报,而不是让用户拖拽新增节点去改结构。这是"看得见的图加可调的参数",不是"画出一张新图"。 - -**phase-3,叫"完整的可视化建图",是远期的事**。真正的拖拽改拓扑结构、可视化编 agent flow、跨编排复用,要等真有了多编排、多 agent 团队的需求,而且"拓扑结构配置化"那个深坑(运行时重建图)被填了,才上。现在不投。 - -这里要补一条贯穿管理面、也支撑"一份管理面管两条异构线"的设计约束:管理面对拓扑的呈现,只渲染框架运行时自报的结构(数据源就是运行时轨迹实际走到了哪个节点),**绝不在管理面这一侧另外持有一份拓扑模型**。原因是 SAA 是静态的 StateGraph、tier2 的 ReAct 根本没有静态图,这两套异构范式要用同一个管理面呈现,就只能靠"渲染运行时自报"这个共同口径;而且将来换框架时,管理面里如果硬编码了一份拓扑模型,那份模型反而会成为换框架的阻力。这也对应了配置注册表那部分的一个推迟决定:phase-1 只把节点的参数外置(用哪个 prompt、哪个模型、什么阈值),拓扑结构本身的配置化(哪些节点、什么顺序、加哪条边)推迟——因为把结构变成运行时配置就等于运行时重建图,那是真正的平台工程深坑。 - -### 接口对称,不是内容对称 - -最后讲清控制面和两条生成线的接法,这里有一个容易误导落地的口径要纠正:两条线是**接口层对称、内容层不对称**,这才是"一份管理面管两条异构线"能成立的真实条件。读配置上,两条线的节点和 agent 都按"id 加版本"从注册表加载,接口一样,但 SAA 读的是 16 个节点的参数、tier2 读的是 ReAct 的工具集和轮数预算,内容不同。写轨迹上,两条线都按那份统一契约写,公共核心子集是对称的,扩展段各写各的。过治理门上,两条线都先过 D12,但前面说过,D12 现在只覆盖 SAA、tier2 要补。配置安全门上尤其要标清:tier2 的 eval/灰度门是 tier2 实验的产物、现在根本不存在,所以"配置改动要过 eval 门"这句话对 tier2 现在是空头支票——诚实的说法是,在 tier2 自己的 eval 门建成之前,tier2 的配置改动只有"下次任务生效加轨迹留痕"两层保护,没有 eval 门拦截。这不是设计缺陷,是 tier2 成熟度的现实,但必须写明,否则会让人误以为 tier2 配置改动有它实际没有的安全网。 - -## 六、关键决策:我们为什么这么定 - -前面把架构讲透了,这一节把支撑它的关键决策集中梳理一遍,每条说清"定了什么"和"依据是什么"。这些决策来自三条具体的探查:两轮引擎走查(扫了整个无头引擎场,导出了引擎选型的全部结论)、四镜头架构探索(四个独立的 opus 子代理各从一个镜头——最快证通的路、复利护城河、成本反发散、自治天花板——出一套端到端架构,跑完之后收敛出共识、也暴露出那处"自由度给到哪一档"的分歧,正是这处分歧催生了 O1/O2/O3 三选项),以及 `wanglanmei-ref` 这个实物发现(它部分证伪了"富游戏造不出来"的悲观,又坐实了"真引擎工程"这条路)。 - -下面是那一天定下的几条决策。 - -**tier2 定位成一条与廉价线解耦并存的 agent-native 富游戏轨**,而不是去改造现有产线——因为审查判定 Tier0 的声明式范式是范式级地够不到复杂品类,不是补个分支能解的。 - -**引擎是动态加载的能力包,不是硬底座**——因为不同富游戏品类对引擎能力的需求差别很大,钉死一个底座等于提前赌死品类边界;而且"引擎即能力包"天然契合 agent"靠工具集决定怎么生成"的工作方式。 - -**"全 AI 可做"是一道不可妥协的硬筛**——它筛掉了中文生态最厚的 Cocos 和 Laya(强制编辑器依赖),也筛掉了已死的 Cocos2d-x 和 Egret(纯代码但社区停滞),因为自治生成链上没有人坐在编辑器前面。 - -**首批引擎包是 Phaser 加 PixiJS,这一档不用 LittleJS**——因为要从 AI 作者的镜头看引擎,生态丰富约等于训练数据密集、直接决定 LLM 会不会写;LittleJS 富游戏零先例又冷门,留给超休闲档。 - -**验收是确定性地板加人工终审,机器门里禁止 LLM 自评**——因为"好玩"机器判不了,而把 LLM 拉进验收当裁判会触发 Goodhart;所以确定性的归机器、主观的归人。 - -**运行时用 AgentScope 独立成轨,绝不动 SAA**——SAA 是现在廉价线在生产上跑着的编排运行时,富游戏的自治生成需要的是真 ReAct 那种循环,与 SAA 当前承载的形态不同,强行合流会同时拖累两边。这里要补一处对现状的纠正,免得后续工程量被低估:并不是"现在的生产 worker 就是 AgentScope、放开迭代上限即可"。仓内实际是两条线——L1 生产主线是裸 openai 客户端、明确不引 AgentScope(框架的 token 膨胀会吃掉便宜档的单价);AgentScope 是 L2 的叠加依赖,体现在 `agent_loop/studio.py` 那条多角色 studio 编排里(它确实用单轮薄壳、头注也写明可替换)。所以 tier2 演进的对象是 L2 的那条 studio 编排,不是 L1 主线,工程距离比"放开迭代上限"要大一些,但躯干七成已在,是演进、不是重写。 - -**tier2 产物是真引擎工程,不复用 Tier0/1 的 ECS-lite 装载路**(这是创始人当天明确拍板 YES 的一条)——因为 `wanglanmei-ref` 这个真·多文件引擎工程的存在,直接证伪了"声明式数据壳能装下肥鹅级富游戏";而且真·多文件工程本身就是一个可维护的源项目,与项目早已定下的"游戏即长生命周期结构化源项目、改源不改包、重新构建"的产品基座完全对齐。需要补一句:这条真引擎工程的路,不复用 Tier0/1 的 ECS-lite 装载契约,所以要为它新增一套引擎工程的源项目契约(源项目类型标记、文件树 manifest、构建 profile、依赖锁、入口文件、内容哈希规范、落库与寻址 API),这是 tier2 立项必补的第一批工程定义。 - -**架构选 O2「约束自治」**——三层切分把系统层最难、便宜模型最容易崩的那部分锁住,把自治火力集中到不得不写的表现层;O1(纯填充)够不到天花板,O3(纯自治)会烧钱发散,O2 取中间——自治在门内、裁决在门外。 - -**0号「肥鹅骨架」spike 是整条轨的 go/no-go**——tier2 最深的不确定性只有一个:便宜或中等模型到底能不能在约束自治的框子里自治造出多系统富游戏过门,这件事光靠架构论证证不了,只能实测。 - -这里要把一条不可破坏的边界再强调一遍:**绝不动 SAA 与 Tier0/1 廉价线。** tier2 的 AgentScope 运行时、真引擎工程装载路、O2 约束自治,全都是在现有产线旁边另起一轨,与正在生产上跑着的 SAA、ECS-lite 装载路彻底解耦并存,不得触碰、不得回归现有产线的任何契约。 - -## 七、建设排序:从现在到「肥鹅人审过」 - -把前面的架构落成一条可执行的路线。骨架是创始人给的五步,这里把那道 go/no-go 门和几个被隐掉的硬工作补进去、和五步对齐。一条贯穿的原则先讲明:**最深的赌注要在最便宜的时候验,别等平台和引擎都搭漂亮了,才发现便宜模型生成不出富游戏。** - -**第一步,搭起 AgentScope、完成集成。** 这是 agentic 底座(agent 和循环的运行时),从仓内已有的那条 L2 studio 编排(单轮薄壳)演进,而不是从 L1 裸 openai 主线起。它是地基,值得建,而且这层和下一步的配置外置还能回头服务现有的 Tier0/1 线。 - -**第二步,把配置外置做实——这是关键。** 让 prompt、编排、模型这些 LLM 的全部输入都可配置、不发版可改(声明式为主、带脚本逃生口),并把一切挂上可回溯可跟踪的轨迹。这正面解的是"改一下配置就要发版"那个痛点,也是整个平台"可配置、可观测"的地基。这一步的实现归线A的阶段2-3,本档引用、不重排。 - -**第三步之前,先插一道便宜的 0号 spike 门——这是五步里最该补的一件。** 原来的顺序是"搭引擎(大投入)再出肥鹅人审过(才验它能用)";但便宜模型真正要现写的,是那约 56% 的表现层(实测见第二节),这是整轨最深、也最没证过的风险。所以在把全引擎生态铺开之前,要先用一个最小、可丢弃的 spike 把这个赌注便宜地证一遍:一个砍到三四个系统的肥鹅骨架、便宜模型自治填,量它的过门率、单款成本、收敛步数。关键是这道门不必等第一、二步全做完,最小的 AgentScope 加硬编码配置就能先验。它的可跑工程规格——靶子游戏的确切规格、模型矩阵、数字阈值、两段实施步骤、采集字段——不在本档,放在配套的执行详细设计档(《tier2 · 0号 spike 详细设计》)里,它是这道门的 runbook。spike 不过,就按退路树走,绝不滑成无限调参。 - -**第三步,spike 证成后,以 Phaser 为范例搭起游戏生成引擎,边搭边反哺第一、二步。** 这一步表面是"搭引擎",底下藏着几块必须显式排进去、不补会埋雷的硬工作:验收地板(把九门泛化到 Phaser、为经营品类补确定性 driver、加跨表语义门——没有它"人审通过"是空的);Goodhart 安全(agent 自产的取证 driver 必须过平台白名单加独立评审,写者不能写判自己游戏的那张卷子);成本强制(四道熔断加三层预算,现在只是 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 真机门,卡在创始人的三件套那道日历闸门上,不是技术阻断。 - -一句话收束这条路线:先用最便宜的 spike 验最深的赌注,证成了再以 Phaser 为范例把引擎和生态铺开、把那几块隐藏的硬工作(地板、防作弊、成本强制、可观测、人审)显式补齐,最后才扩到 Cocos 和渠道。 - -## 八、现在证到哪了,以及最大的未验证赌注 - -最后盘点这条轨现在的证据状态,把"已证"和"待证"分清楚,免得把假设当成已定。 - -**已证的部分。** 富游戏的产物形态做得出来——这有实物证据:`game-runtime/games/wanglanmei-ref/` 是一款真存在过的、十二文件约 180KB 的多系统经营游戏,过了真输入 harness、赢和输双路径都可达,它证伪了"声明式数据壳之外的真引擎工程装不下肥鹅级富游戏"这个悲观假设。Phaser 这条路本身能跑通确定性门也有独立证据——2026-06-11 那次走廊小卖部样本在 Phaser 上过了五门。这两份证据各钉死一个点:前者钉死产物形态(与引擎无关),后者钉死 Phaser 这条路能跑真 harness。 - -**但这两次成功的共同前提,正是 tier2 真正要证的那一半还没证。** 它们都是最贵的模型(Fable)加重人工编排做到的,不是便宜模型自治。它们证伪了"形状做不出",却把"把模型降下来、把人工编排换成自治"这条路留给了那个 0号 spike。 - -**最大的未验证赌注,就是那个 44/56 校准逼出来的核心问题:** 便宜或中等模型的自治 agent,在经营骨架、玩法模板(也就是按品类引导 AI 生成的结构化 prompt 框架,不是 pre-built 代码)、资产池、RAG(把引擎最新 API 文档检索喂给模型,治版本漂移)、九门兜底这一整套约束下,能不能稳定地把那 56% 的表现层写出来、并过确定性门。整条 tier2 轨的 go/no-go 就悬在这上面,架构论证替代不了实测。这个赌注押在 0号 spike 上,它的工程规格在配套的执行详细设计档里。 - -需要诚实标注、不可纸面宣称已验的,还有这条轨上一串待定的数:过门率、单款成本、收敛步数这三个决定 tier2 经济性的数,要等 spike 跑出来;四道熔断的具体阈值,要等看到模型真实的发散行为之后才能标定;人工终审那套软门的操作细节(终审判据、吞吐模型、player panel 怎么组织),这一天定的是"软门归人"的原则、没定操作细节;AgentScope 从单轮薄壳演进到真 ReAct 的工程量与坑,方向定了、真接成自治循环会遇到什么还没实测过。 - -## 验证状态与下一步 - -这份文档是 tier2 生成架构加控制/管理面治理层的设计评审版,还没落到代码。它把此前 4 份 WIP 设计稿(tier2 架构、决策记录、控制面/管理面设计)合并重讲成一份连贯叙事,与执行级的 0号 spike runbook(《tier2 · 0号 spike 详细设计》)配套。文中所有仓内引用对着现有的 gen-worker、九门 harness、build-from-source、source-project 契约、`wanglanmei-ref` 与 channel-spike 实证;所有外部事实(Cocos 无头核实、微信 weapp-adapter 政策等)带一手出处;两项实证(80/10 实测落在 44/56、Cocos 全无头核实为不可行)与对现有代码的逐条锚点核实(Prompt Registry 是构建期快照、模型有两个配置入口、D12 只覆盖 SAA 等)已并入正文。 - -最大的未验证假设就是第八节那一条核心赌注,不可纸面宣称已验。下一步有三件:本文走一轮轻评审定稿;同步更新 `tech-decisions.md` 与 `引擎与运行时.md` 两处 canonical(引擎 supersession 加纠正"headless MCP"事实错);然后备齐前置物、在 mini-desktop 上跑 0号 spike,据它的 verdict 与退路树决定 tier2 的正式投入与建设顺序。 diff --git a/docs/agent-specs/2026-06-21-tier2-spike-0-详细设计.md b/docs/agent-specs/2026-06-21-tier2-spike-0-详细设计.md deleted file mode 100644 index 4be919c8..00000000 --- a/docs/agent-specs/2026-06-21-tier2-spike-0-详细设计.md +++ /dev/null @@ -1,117 +0,0 @@ ---- -date: 2026-06-21 -topic: tier2 · 0号 spike 详细设计(可跑 runbook) -status: 设计(review 版)· 配套 2026-06-21-agentic生成架构-tier2与控制面.md(§七 建设排序 · §八 核心赌注) -关联: 2026-06-21-agentic生成架构-tier2与控制面.md(主架构档:§七 把本 spike 立为 go/no-go 门 / §八 给出本 spike 要证的核心赌注 / §二 给出判据哲学与四道熔断 / §三 给出引擎与 driver 隔离)· game-runtime/games/wanglanmei-ref(fixture 结构参照) ---- - -# tier2 · 0号 spike 详细设计 - -## 这份文档补什么 - -主架构档(《agentic 生成架构:tier2 富游戏自治轨 + 控制/管理面治理层》)的 §七、§八 把 0号 spike 立成了整条 tier2 轨的生死门,但它写的是**判据哲学**(§二 测什么、为什么分两段、§七 退路怎么走),不是**可跑的工程规格**。内容完整性检查点明:一个工程师拿主架构档跑不起来这个 spike——靶子游戏没有确切规格、模型没点名、过门没有数字阈值、两段没有步骤、采集指标没有字段。这份配套文档就补这五块,把 spike 变成一份能照着执行的 runbook。一句话原则不变:**这个 spike 是为了在最便宜的时候,把"便宜模型能不能自治写出那 56% 的表现层"这个最深的赌注证伪或证成。** - -## 一、靶子游戏规格(spike fixture) - -spike 的实验对照组("人工预建骨架 + 人工预建 driver")必须有一个确切的靶子游戏才能预建。这里把它钉死——一个砍到能证、又保住三个本质难点(多系统耦合、重 UI 表现层、数值经济闭环)的最小经营游戏,代号 **mini-肥鹅**,结构参照仓内 `wanglanmei-ref` 但更小。 - -**三个联动系统(砍掉任务弹窗、背包深度、上百物品):** - -第一个是**资源系统**,维护两种货币——金币和食材库存。它是其余两个系统的读写交汇点:合成消耗食材、订单产出金币、解锁花金币。它的状态就是一张极小的表:`{ coins: number, ingredients: { [id]: number } }`。 - -第二个是**合成系统**,一块 N×N(spike 取 3×3)的棋盘,玩家点两个相同物品合成上一级。合成链是一张数据表——`mergeChains: [{ from: "bread-dough", to: "bread", cost: {flour: 1} }, ...]`,spike 给 6 条链、覆盖 12 个物品。合成产出进资源系统的库存。这块是"重 UI 表现层"的主要承载(棋盘格渲染、拖拽/点击命中、合成动画)。 - -第三个是**订单系统**,一个面板列出 3~5 个顾客订单,每个订单要一组物品、给一笔金币。订单数据表——`orders: [{ id, requires: {bread: 2}, reward: {coins: 30}, patience: 20 }]`。完成订单从库存扣物品、给资源系统加金币;耐心耗尽订单流失。 - -**系统间的确切耦合点**(这是"多系统真联动"的考点,不是三个孤岛):订单的 `requires` 必须能被合成系统产出的物品满足(跨表可达性);完成订单调用资源系统的 `addCoins`;合成消耗调用资源系统的 `consumeIngredient`;金币门控解锁(攒够金币解锁第 4、5 个摊位/更高合成链)。 - -**胜负条件**:赢 = 金币达到 100(从开局的 20 攒上去,经"合成→交单→收金币"的正循环);输 = 连续 3 个订单流失(只合成不交单、或经济崩盘)。两条路径都要能被 harness 真输入驱动跑到终态并 latch。 - -**内容量**:12 个物品、6 条合成链、5 个订单模板、2 种货币——足够证"数据驱动"而不至于让 spike 本身变重。 - -> 这份 fixture 规格 = spike 第一段里"人工预建骨架"和"人工预建 driver"的施工图。骨架按这三个系统 + 耦合点预建(平台代码);driver 按"点合成格→凑齐订单物品→交单→看金币涨"的确定性序列预建。 - -## 二、模型矩阵与样本量 - -"便宜/中等模型"是个集合不是一个值,过门率/成本/收敛步数三个产出数必须有归属对象,否则"60% 是哪个模型的 60%"无法回答。spike 跑这个矩阵: - -| 角色档 | 模型 | 说明 | -|---|---|---| -| 主力便宜档 | deepseek-v4-flash | 现行 Tier0/1 打底模型,tier2 自治的主力候选 | -| 强便宜档 | deepseek-v4-pro | 现行救场档,测"贵一档便宜模型"是否显著抬过门率 | -| 中等 agentic 档 | MiniMax-M3 | 按记忆 m3-agentic 用对它=Anthropic /v1/messages 原生 + agentic 工具循环;tier2 ReAct 的天然候选 | -| 强模型基线 | Opus / Fable | 只跑 1~2 款作"路通不通"的上限基线(对照 wanglanmei-ref 的 Fable 基线),不进成本评估 | - -**样本量**:每个便宜/中等档 **n ≥ 30** 真跑(承袭记忆里"先 mini-desktop 跑 n≥30 真基线、别拿单次当基线"的硬教训),强模型基线 n = 2~3。题面用 5 个一句话变体(美食/水果/咖啡/面包/糖水店),每变体每档跑 6 次凑够 n≥30。**跑哪**:mini-desktop(权威构建 + e2e 门,x86 同构;禁本机 6c6g 跑 chrome)。 - -## 三、过门判据与精确阈值 - -没有数字阈值,go/no-go 必然滑成"再调一轮",退路树也悬空。这里给出 spike 的硬数(标 ★ 的是建议值、需创始人/实测校准;其余是承袭现行线的硬约束): - -| 维度 | 阈值 | 来源 | -|---|---|---| -| 过门率(九门 + 三联动门 + 经济门全绿 + latch) | ★ ≥ 50% 起评、≥ 70% 算强信号 | 对照现行 factory 路 60%、cutover 门 80%;tier2 富游戏更难,spike 阶段先看"是否显著>0、能否随档升" | -| 单款成本 | ★ ≤ ¥3 / 成功款 | 现行 L1 ≤¥0.15、L2 ≤¥5;tier2 premium 取 L2 偏下,留自治多轮空间(此数同时是 §四 P1-3 的产品预算输入,需创始人拍) | -| 收敛步数 | ≤ max_iters(★ 单系统 ≤ 8 轮、整局 ≤ 40 轮) | 防"靠运气擦边";超 max_iters 即判不收敛 | -| 长程一致性 | 12+ 文件工程过程中无 checkpoint 丢失、半轮副作用幂等无脏 | §六 指标 | -| 人锚 | 创始人试玩判一句"是不是个有肥鹅味的可玩雏形" | 软门,不可替代 | - -**退路树的数字触发线**(让主架构档 §七 的退路树真能被触发): - -- 若**最强便宜档(v4-pro)过门率仍 < 40%、且失败集中在表现层(render/事件接线)** → 判"56% 自治承重太重",退向更模板化(更多预制表现模板、少 LLM 写); -- 若**失败集中在某个系统装不出(如合成棋盘命中几何反复错)、但其余系统能过** → 判骨架/driver 缺口,补骨架再试,不是范式问题; -- 若**便宜档全线 < 20%、而强模型基线(Opus/Fable)能过** → 判便宜模型天花板,要么换更贵模型重估经济性(撞 ¥3/款 上限就缓行)、要么整轨缓行。 - -## 四、两段实施步骤(runbook) - -变量隔离的逻辑(主架构档 §二 的约束自治范式 + §七 的 0号 spike 步)落成可执行的两段,每段有输入、跑法、采集、gate。 - -**第一段 · 纯模型变量(固定人工骨架 + 人工 driver)** - -1. **预建(人投入,Opus 或人写)**:按 §一 fixture 规格,预建 mini-肥鹅 经营骨架工程(三系统 + 耦合点的平台代码,先天过 boot)+ 经营品类的确定性 harness driver(点合成/凑单/交单序列)+ 12 物品/6 链/5 订单的数据表 schema(留空给 LLM 填值)+ 共用资产池占位图。 -2. **跑(便宜模型自治填那 56%)**:对每个模型档 × 每个题面变体,跑 `worker/agent_loop/studio.py` 演进版(max_iters 放开):便宜模型在骨架上填数据表 + 写表现层(场景渲染、事件→表现接线、特色规则),自治循环写源→build→headless 快检→九门→读 verdict→改。 -3. **采集 + gate**:按 §六 采集每款的 pass/repairs/¥/wall/出错系统/长程指标;第一段 gate = 过门率/成本/收敛是否达 §三 阈值。**第一段只测"填差异"的纯模型变量,driver 是人预建的、不让 agent 碰。** - -**第二段 · 开放自产 driver(测自治上限 + Goodhart 安全)** - -4. **放开**:在第一段证通的基础上,让 agent 自产/扩 harness driver——但走主架构档 §二「验证哲学」与 §七「Goodhart 安全」定的三层隔离(agent 提议 driver → 平台 schema/白名单编译 → 独立 adversarial 评审查它是否覆盖真实玩家路径、是否读作弊字段)。 -5. **跑 + 采集**:同上,额外采集"自产 driver 被独立评审打回的比例"、"driver 修改次数"(防它用改 driver 逃避卡死探测)。 -6. **判**:第二段 gate = 自产 driver 不降过门可信度(独立评审通过率高)、自治不烧穿成本闸。 - -**两段之间的 gate**:第一段不过(纯模型变量就崩)→ 直接进退路树,不开第二段(开放自治只会更糟)。第一段过、第二段挂在 driver 安全 → 判 Goodhart 防线设计问题,不是模型问题。 - -> step 模板复用仓内 `game-e2e-cdp-harness.md` 的四件套证据编排(render→截图时序→驱动→verdict),每款产出四件套证据可审计。 - -## 五、前置物清单(spike 开跑前必须就位) - -1. mini-肥鹅 经营骨架工程(§一 规格,Opus/人预建)。 -2. 经营品类 harness driver(点合成/凑单/交单,确定性)+ 九门对 Phaser 的两钩子参数化(canvas 选择器、帧计数源)。 -3. 三联动门 + 经济门 + latch 的 assertAfterPlay 规格(订单引物品可达、合成 DAG 无环、经济可盈利可破产)。 -4. studio.py 演进版:max_iters 放开 + 工具(写源/build/headless 快检/跑九门/读 verdict/查资产)注册进 toolkit。 -5. 数据表 schema(12 物品/6 链/5 订单,留空给 LLM 填)+ 共用资产池占位图。 -6. 成本计量接 new-api quota(per-model 折¥)+ 轨迹仓最小版(§六 字段)。 - -## 六、采集指标字段表 - -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 的可跑详细设计(review 版),未落代码。它把主架构档 §七、§八 从"判据哲学"补成"工程师可照跑的 runbook";阈值标 ★ 的需创始人/实测校准(尤其 ¥3/款 premium 预算、50%/70% 过门率门)。下一步:本档随主架构档一并轻评审定稿 → 备齐 §五 前置物 → 在 mini-desktop 上跑两段 → 据 §六 采集与 §三 退路树触发线裁 go/no-go。 diff --git a/docs/architecture/架构/README.md b/docs/architecture/架构/README.md index b1b39aa7..f96f4324 100644 --- a/docs/architecture/架构/README.md +++ b/docs/architecture/架构/README.md @@ -113,7 +113,7 @@ flowchart LR ### 2.3 游戏运行时引擎 = LittleJS 增强发行版(Tier1)+ Cocos(Tier2/3) -> **⚠️ 引擎口径 supersession(2026-06-21 · tier2 全自治生成轨触发)** —— 详见 [`agentic 生成架构(tier2 + 控制面)`](../../agent-specs/2026-06-21-agentic生成架构-tier2与控制面.md) §三(引擎选型:为什么 Phaser/Pixi、为什么排除 Cocos)。 +> **⚠️ 引擎口径 supersession(2026-06-21 · tier2 全自治生成轨触发)** —— 详见 [`自治富游戏引擎`](生成引擎/自治富游戏引擎.md)(引擎选型:为什么 Phaser/Pixi、为什么排除 Cocos)。 > 本节原按"产物复杂度分层"选引擎(Tier1 = LittleJS / Tier2-3 = Cocos),正被一个**正交两轴**框架取代。起因是 tier2 要做"AI agent 全自治生成富游戏",而全自治要求引擎**全无头、纯代码 / CLI 可构建、loop 里不挂 GUI 编辑器**。据此核实(取证级):**Cocos Creator 必须开编辑器才能构建,其"MCP(158 工具)"是连到运行中编辑器的扩展插件、驱动的是 GUI 编辑器而非 headless——所以下表与本节"MCP 可被 / 让 AI 驱动"那几句的 headless 含义是事实错,Cocos 进不了全自治 loop。** 正确两轴是:**① 自治生成引擎(全无头:富 2D = Phaser / Pixi,超休闲 = LittleJS);② 3D / 渠道导出引擎(Cocos,编辑器 + 人在环,服务复杂 3D / 原生 / 一键渠道导出)。** Phaser 当初"放弃"属 Tier1 超休闲流的冷启动之败(渠道 / 交付维度),与 tier2 的 headless 自治维度正交、不是一把尺;tier2 富 2D 自治据 headless 筛子选 Phaser / Pixi。 运行时按产物复杂度分层,不同层用不同引擎。LittleJS 是一个极小的开源 2D 游戏引擎;"增强发行版"指我们在它基础上叠了能力插件库与装载契约。 diff --git a/docs/architecture/架构/生成引擎/README.md b/docs/architecture/架构/生成引擎/README.md index a66475df..127bd49d 100644 --- a/docs/architecture/架构/生成引擎/README.md +++ b/docs/architecture/架构/生成引擎/README.md @@ -343,6 +343,8 @@ flowchart LR | [生命周期项目管理 review](../../../agent-specs/2026-06-17-生成主线-游戏生命周期项目管理-review.md) | "游戏 = 长生命周期源项目、LLM as 工作室"范式的完整裁定与契约 delta(本文 §3 的权威源) | | [游戏生成系统总体架构 review](../../../agent-specs/2026-06-12-游戏生成系统总体架构-review.md) | 三级生成、第 9 契约组、控制平面、灰度矩阵、29 条意图覆盖矩阵(本文 §8 的权威源) | +> **tier2 富游戏自治轨**(与上面现行线解耦并存的新轨,2026-06-21 设计)的三份设计也在本子树:[自治富游戏引擎](自治富游戏引擎.md)(引擎内核:O2 约束自治、Phaser/Pixi 选型、确定性地板加人工终审)、[agentic 集成架构](agentic集成架构.md)(控制 / 管理面治理层,两条生成线共用)、[tier2 实现详设](tier2实现详设.md)(源项目契约、统一 trace 实现接点、建设五步、0号 spike runbook、退路树)。 + > **纪律**:本档是生成引擎的策展层 SoT——读它 = 当前真相。带日期的源档是留痕层,记录设计如何演进至此;两者职责不同,不互相重复。当现行真相与某份带日期的源档冲突时,以本档与它引用的最新裁定为准。 --- diff --git a/docs/architecture/架构/生成引擎/tier2实现详设.md b/docs/architecture/架构/生成引擎/tier2实现详设.md new file mode 100644 index 00000000..11809bab --- /dev/null +++ b/docs/architecture/架构/生成引擎/tier2实现详设.md @@ -0,0 +1,217 @@ +# tier2 实现详设 + +> 🚧 设计中 · tier2 是待 0号 spike 验证的假设,尚未落代码;过了 spike 才进建设。 + +> **这是什么**:tier2 自治富游戏轨的实现详设 —— 怎么对接、怎么建、怎么部署、怎么跑、怎么测、怎么验。 +> **给谁看**:要动手搭 tier2 的工程师,以及拿这份去跑 0号 spike、据结果裁 go/no-go 的人。 + +## 第一批工程定义:源项目契约 + +tier2 的产物是一个真引擎工程 —— 多个源文件、一份构建脚本、一套依赖,build 出来才是能玩的游戏。它不复用 Tier0/1 那条 ECS-lite 装载路:现有廉价线把一份声明式数据壳塞进固定运行时就能玩,tier2 没有这层壳,它要把一整个 Phaser 工程编译、落库、寻址、再装进 feed。这两条装载路不通用,所以 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 完成集成
(从 L2 studio 编排演进,非 L1 裸 openai 主线)"] + S2["第二步 · 配置外置做实
(prompt/编排/模型可配不发版 · 归线A阶段2-3 · 本档引用不重排)"] + SPIKE{"0号 spike 生死门
便宜模型能否自治写出那 56% 表现层?
最小 AgentScope + 硬编码配置即可先验"} + RETREAT["按退路树走
(绝不滑成无限调参)"] + S3["第三步 · 以 Phaser 为范例搭生成引擎
边搭边反哺第一二步"] + S4["第四步 · Phaser 自治生成一款过人审
(对标肥鹅美食街)"] + 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 棋盘 · 点两个相同物品合成上一级
mergeChains 6 条链 / 覆盖 12 物品"] + end + subgraph 资源系统["资源系统(读写交汇点)"] + R["金币 + 食材库存
{ coins, ingredients }"] + end + subgraph 订单系统["订单系统"] + O["3~5 个顾客订单 · 要物品给金币
orders 5 个模板 / 有 patience"] + end + + M -- "合成产出进库存
consumeIngredient 扣食材" --> R + O -- "完成订单扣物品
addCoins 加金币" --> R + R -- "金币门控解锁第 4/5 摊位、更高合成链" --> M + M -- "产出物品须满足订单 requires
(跨表可达性)" --> 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 工具循环;tier2 ReAct 的天然候选 | +| 强模型基线 | Opus / Fable | 只跑 1~2 款作"路通不通"的上限基线,不进成本评估 | + +样本量上每个便宜/中等档跑 n ≥ 30 真跑(承袭"先跑 n≥30 真基线、别拿单次当基线"的硬教训),强模型基线 n = 2~3。题面用 5 个一句话变体(美食、水果、咖啡、面包、糖水店),每变体每档跑 6 次凑够 n≥30。跑在 mini-desktop —— 权威构建加 e2e 门、x86 同构;禁本机 6c6g 跑 chrome。 + +### 过门判据与精确阈值 + +没有数字阈值,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)
+ 确定性 harness driver(点合成/凑单/交单序列)
+ 数据表 schema(留空给 LLM 填)+ 资产池占位图"] + P2["跑:便宜模型在骨架上填数据表 + 写表现层
(场景渲染/事件接线/特色规则)
自治循环 写源→build→headless 快检→九门→读 verdict→改"] + P3["采集 + gate:过门率/成本/收敛是否达阈值"] + P1 --> P2 --> P3 + end + G1{"第一段 gate"} + P3 --> G1 + G1 -- "纯模型变量就崩 → 不开第二段(开放自治只会更糟)" --> R["进退路树"] + + subgraph stage2["第二段 · 开放自产 driver(测自治上限 + Goodhart 安全)"] + Q1["放开:让 agent 自产/扩 driver
走三层隔离 ①agent 提议 driver →②平台 schema/白名单编译 →③独立 adversarial 评审
(查它是否覆盖真实玩家路径、是否读作弊字段)"] + Q2["跑 + 采集:额外采 自产 driver 被打回比例 / driver 修改次数
(防它用改 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 过门率
是否仍 < 40%?"} + Q2{"失败是否集中在表现层
(render / 事件接线)?"} + Q3{"是否失败集中在某个系统装不出
(如合成棋盘命中几何反复错)、
其余系统能过?"} + Q4{"是否便宜档全线 < 20%、
而强模型基线 Opus/Fable 能过?"} + + GO["go:过门率达阈值 → 转第三步以 Phaser 铺引擎"] + R1["退向更模板化:更多预制表现模板、少 LLM 写
(判 56% 自治承重太重)"] + R2["补骨架再试:补该系统的骨架/driver 缺口
(判骨架缺口,不是范式问题)"] + R3["便宜模型天花板:换更贵模型重估经济性
(撞 ¥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% 过门率门)。轨迹契约与控制面的完整治理口径在集成架构档,本档交叉引用、不重排。