2026-05-31 主Agent游戏生成方案

任务背景

用户明确当前目标是完成 P0，短期目标是完成 MVP，长期目标是完成完整产品目标。MVP 的游戏生成入口不是用户手动配置游戏数据，而是用户和一个主 Agent 对话；主 Agent 根据意图分派内部子代理，降低用户心智负担。

本次只做文档和方案收口，不宣称 harness、runtime、转换器或应用代码已经实现。

已确认产品主线

长期规划：绘境AI要做 AI 管理的游戏产品生命周期平台，不是单一 H5 小游戏站，也不是一次性代码生成器。

短期架构：MVP 走对话式 AI 游戏设计入口，产出受控设计草稿、结构化确认、Web 可玩、反馈数据和小游戏转换证据。

当前实现主线：P0 先完成 Web 运行底座和受控转换门禁，但入口合同必须从对话生成开始，避免后续返工成手工配置工具。

核心链路

flowchart LR
  User[用户自然语言对话] --> Main[MainCreationAgent]
  Main --> Router[Intent Router]
  Router --> SubAgents[内部子代理]
  SubAgents --> Draft[AIGameDesignDraft]
  Draft --> Sections[DesignSection / DesignSectionPatch]
  Sections --> IR[GameIR]
  IR --> Config[GameConfig]
  Config --> Logic[GameLogicModule]
  Logic --> Package[GamePackage]
  Package --> Web[Web Runtime]
  Package --> Mini[MiniGameCodeConversion]
  Mini --> Evidence[ConversionReport / DevToolImportEvidence]

用户只面对 MainCreationAgent。需求确认、草稿生成、配置修改、素材建议、预览问题解释、发布辅助等能力由内部子代理完成。UI 不要求用户选择或理解子代理。

关键合同

MainCreationAgentSession：用户对话入口，绑定 creator/project/version/context。
AgentTask：主 Agent 派发内部子代理任务，必须有 task type、subagent、输入输出引用、状态、超时和审计。
RequirementBrief：需求确认子代理输出，记录玩法、用户、核心循环、约束、缺失字段和风险。
PromptRecord：原始 prompt、归一化 prompt、模板提示、素材引用、moderation、幂等和 generationTaskId。
AIGameDesignDraft：AI 生成的游戏设计草稿，包含 sections、风险、模板版本和 checksum。
DesignSection：AI 草稿拆分后的结构化确认单元，供用户确认/微调和 IR 编译器消费。
DesignSectionPatch：用户微调或配置修改子代理输出，必须做 checksum 冲突检测。
GameIR -> GameConfig -> GameLogicModule -> GamePackage：受控制品链，不允许 AI 直接写三端平台业务代码。

源码调研结论

Web 游戏运行：

参考 LittleJS 的最小 loop、固定 tick 和 canvas/WebGL fallback 思路，但不能原样使用其 document/window 依赖。
参考 PixiJS 的 Application/Ticker/Adapter 分层，但 Pixi 只能作为 runtime 内部实现候选，不能把 DOM adapter 暴露给业务逻辑。
参考 GDevelop/ct-js 的资源导出、manifest、截图/预览/QA 流程，但它们是 Web 导出 runtime，不符合小游戏转换和受控 GameLogicModule 边界。
S4 推荐自研薄 Web runtime：WebRuntimeHost + WebPlatformAdapter + RuntimeSdkContract。

小游戏转换：

参考 Cocos 的微信/抖音模板结构和“先 adapter 后 runtime”的启动方式。
参考 Laya 的平台能力槽位、小游戏 downloader/cache、生命周期适配方式。
参考 GDevelop/ct-js 的导出 pipeline 和资源收集/压缩/报告。
Phaser/GDevelop/ct-js Web runtime 都不能直接作为小游戏 runtime，DOM/BOM/Web-only SDK 证据明显。
本地参考仓未找到可直接复用的快手小游戏模板或 ks.* 实现；快手覆盖必须写为 unknown，不能从微信/抖音外推。

执行约束

不接受用户手动从空表单配置完整游戏数据作为 MVP 入口。
不接受 AI 分别维护 Web/微信/抖音/快手四份业务代码。
不把 Web 包改名冒充小游戏包。
不把 DevToolImportBlocker 或 ChannelReadinessNote 冒充 DevToolImportEvidence.result=passed。
不把开发者工具导入证据冒充三端真机 smoke 或渠道上架。
每个新增模型必须有 Entry、Consumer、Gate、Evidence，禁止孤儿设计。

已更新文档

docs/agent-specs/2026-05-30-MVP产品技术路线-执行版.md
docs/superpowers/specs/2026-05-31-mvp-S0-harness-design.md
docs/superpowers/plans/2026-05-31-mvp-S0-harness.md
docs/superpowers/specs/2026-05-31-mvp-S1-app-foundation-design.md
docs/superpowers/specs/2026-05-31-mvp-S8-deploy-readiness-design.md

本次已落地

S3/S4 文档已强化薄 runtime、RuntimeSdkContract、WebPlatformAdapter、S4/S5 mock consumer 和 smoke evidence。
S5 文档已强化 PlatformApiAdapter、项目模板、static gate、快手 unknown 风险和 devtool import evidence。
S8 验收已改为从 MainCreationAgent 对话生成草稿开始，并以 DevToolImportEvidence.result=passed 作为 P0 Go/No-Go 必需证据。

后续实现约束

实现阶段要先落 S0 harness 和 schema/fixture/validator，再进入 S1-S8。
实现阶段不能把文档中的源码参考理解成引入完整引擎依赖；默认主线仍是自研薄 runtime、adapter 和静态项目 builder。

5.2 KiB Raw Blame History Unescape Escape