AI Agent 做游戏的方法论：从系统提示词、场景生成到 Fable 5 长任务闭环

AI Agent 做游戏，最容易被误解成“一句话生成一个游戏”。这句话适合演示，不适合生产。真正能跑起来的系统，通常不是一个超长 prompt，而是一组可以被反复执行的工程流程：设计契约、场景生成、玩法代码、资产管线、引擎集成、自动试玩、回归修复。

游戏比普通网页更能暴露 Agent 的真实能力。一个网页第一屏好看，未必说明模型理解了产品；一个游戏要可玩，就必须同时处理输入、状态、碰撞、资源、反馈、难度、失败、胜利和重开。只要其中一个环节松掉，玩家立刻能感知到。

所以这篇不讨论“哪个模型最会写游戏 demo”，而是整理一套更可复用的方法论：如何让 Agent 从创意走到 playable prototype；如何写系统提示词、场景生成 spec 和游戏设置；如何使用 Unity、Unreal、Web、Roblox 这类工具；以及 Fable 5 这类强模型应该放在流程的哪一层。

先把参考项目拆开看

几个值得长期跟踪的项目，其实分别代表了游戏 Agent 系统里的不同部件。

这些项目共同说明一件事：AI 游戏开发的核心不是生成，而是闭环。

生成代码只是其中一环。更难的是把“我要一个潜入游戏”变成一组可以被验证的契约：玩家能否移动，敌人能否巡逻，视野锥是否生效，失败条件是否稳定，移动端是否能操作，场景是否有导航路径，重开是否清空状态。

一套更可靠的总架构

我会把 AI Agent 游戏开发拆成六层：

1. Design Contract：把创意压成可执行游戏契约。
2. Scene Spec：把世界、对象、空间、导航、触发器结构化。
3. Gameplay Spec：把状态机、规则、输入、胜负条件结构化。
4. Asset Pipeline：检索、生成、压缩、命名、授权和导入资产。
5. Implementation Agent：在 Web / Unity / Unreal / Roblox 中写入项目。
6. Playtest Agent：实际运行、观察、点击、截图、记录并反推修复。

这张图里最重要的是右边的回路。没有自动试玩，Agent 很容易把“能编译”误当成“能玩”。游戏里的很多 bug 不会出现在 TypeScript 或 C# 编译期：角色出生在墙里、敌人永远走不到玩家、按钮被遮住、碰撞框太大、移动端摇杆挡住 UI、胜利条件永远触发不了。这些都必须通过运行时观察发现。

系统提示词：先约束角色，再约束产物

做游戏的系统提示词不能只说“你是一个资深游戏开发者”。这个身份太泛，模型会倾向于写一堆设定和美术描述。更实用的提示词要把它约束成一个交付型 Agent：先定义契约，再写代码，再运行试玩。

你是一个 Game Director + Technical Lead Agent。
你的目标不是写概念稿，而是交付一个可试玩的最小闭环。

工作顺序：
1. 把用户创意拆成 Design Contract、Scene Spec、Gameplay Spec、Test Rubric。
2. 先实现 3 分钟内能验证的核心循环，再扩展视觉、剧情和关卡。
3. 每个规则都必须能映射到状态、输入、反馈或测试。
4. 不允许只输出概念描述；所有产物必须是结构化 spec、代码、资产清单或测试。
5. 写代码前先读取当前项目结构、引擎版本、已有组件、构建命令和资源目录。
6. 不确定引擎 API 时，先查项目封装或官方文档，不凭记忆硬写。
7. 每次改动后必须运行 build/test/playtest，并把失败转成 bug list。

输出格式：
- design_contract
- scene_spec
- gameplay_spec
- changed_files
- run_commands
- playtest_result
- known_issues
- next_patch_plan

停止条件：
- 核心循环可以启动、操作、失败、胜利、重开。
- Rubric 中的核心项全部通过。
- 如果连续两轮无法获得新证据，停止并请求人类决策。

这个提示词的重点是把模型从“创意生成器”拉回“可验证交付者”。尤其是“3 分钟内能验证的核心循环”，能有效防止模型第一轮就扩成开放世界、剧情分支和复杂经济系统。

Design Contract：不要先写故事，先写不变量

多数失败的 AI 游戏 demo，都不是因为代码少，而是因为一开始没有定义游戏不变量。一个可执行的 Design Contract 至少要回答这些问题：

可以要求 Agent 先输出一份 JSON：

{
  "genre": "top_down_stealth",
  "session_length_seconds": 90,
  "player_goal": "collect_5_chips_and_reach_exit",
  "core_loop": ["scout", "avoid_guard", "collect_chip", "unlock_exit"],
  "states": ["menu", "playing", "paused", "won", "lost"],
  "entities": {
    "player": {"hp": 3, "speed": 170, "has_shield": false},
    "guard": {"vision_angle": 70, "patrol_speed": 95, "alert_speed": 140},
    "chip": {"count": 5, "respawn": false},
    "exit": {"locked_until": "chips >= 5"}
  },
  "win_condition": "chips_collected >= 5 && player_overlaps_exit",
  "fail_condition": "player_hp <= 0 || timer <= 0",
  "must_support": ["keyboard", "touch", "restart"],
  "playtest_rubric": [
    "menu starts the game",
    "player movement is visible",
    "at least one chip can be collected",
    "guard collision reduces hp",
    "exit unlocks after 5 chips",
    "win screen appears",
    "loss screen appears",
    "restart clears hp, timer and chips"
  ]
}

这类契约对 Agent 很关键，因为它把“好不好玩”至少一部分转成了“能不能验证”。

Scene Spec：让场景生成服务玩法

场景生成最常见的错误，是把模型引向美术堆砌。很多 AI 生成场景看起来丰富，但玩家没有路径，关键物体没有碰撞，敌人出生点不合理，交互对象没有标签。更可靠的做法是让场景 spec 明确绑定玩法。

{
  "scene_id": "night_lab_01",
  "camera": {
    "mode": "top_down",
    "bounds": {"width": 1920, "height": 1080},
    "follow_player": true
  },
  "zones": [
    {
      "id": "spawn",
      "role": "safe_start",
      "rect": [80, 820, 220, 180],
      "must_contain": ["player", "tutorial_sign"]
    },
    {
      "id": "patrol_core",
      "role": "risk_area",
      "rect": [520, 260, 860, 540],
      "must_contain": ["guard_path_a", "guard_path_b", "2_chips"],
      "must_not_contain": ["exit"]
    },
    {
      "id": "exit_zone",
      "role": "goal",
      "rect": [1600, 120, 220, 220],
      "must_contain": ["exit"]
    }
  ],
  "objects": [
    {
      "id": "wall_blocks",
      "asset_query": "modular sci-fi wall tile",
      "fallback_primitive": "rectangle",
      "collision": "static",
      "placement_rule": "form corridors with at least 96px walkable width"
    },
    {
      "id": "chip",
      "asset_query": "glowing energy chip",
      "fallback_primitive": "small cyan diamond",
      "collision": "trigger",
      "interaction_tags": ["collectible"]
    }
  ],
  "navigation": {
    "walkable_width_min": 96,
    "guard_patrol_points_min": 4,
    "player_to_exit_path_required": true
  },
  "validation": [
    "player spawn is not inside collision",
    "all chips are reachable",
    "exit is reachable after collecting chips",
    "guards have patrol routes that do not start on top of player"
  ]
}

这类 spec 可以给 Web 游戏，也可以映射到 Unity prefab、Unreal PCG graph、Roblox scene 或自定义关卡编辑器。关键不是 JSON 格式本身，而是把每个对象写清楚：它在玩法里是什么角色，碰撞是什么，能否交互，如何验证。

Gameplay Spec：用状态机压住复杂度

Agent 很容易写出散落在各处的 if。第一版小游戏还好，迭代两轮以后就会出现暂停状态下还能受伤、胜利后敌人继续攻击、重开后计时器没清空等问题。最好一开始就让它写有限状态机。

type GameState = 'menu' | 'playing' | 'paused' | 'won' | 'lost'

type Event =
  | { type: 'START' }
  | { type: 'PAUSE' }
  | { type: 'RESUME' }
  | { type: 'PLAYER_DAMAGED'; hp: number }
  | { type: 'CHIP_COLLECTED'; count: number }
  | { type: 'EXIT_REACHED'; count: number }
  | { type: 'TIMER_EXPIRED' }
  | { type: 'RESTART' }

export function transition(state: GameState, event: Event): GameState {
  if (event.type === 'RESTART') return 'menu'

  switch (state) {
    case 'menu':
      return event.type === 'START' ? 'playing' : state
    case 'playing':
      if (event.type === 'PAUSE') return 'paused'
      if (event.type === 'PLAYER_DAMAGED' && event.hp <= 0) return 'lost'
      if (event.type === 'EXIT_REACHED' && event.count >= 5) return 'won'
      if (event.type === 'TIMER_EXPIRED') return 'lost'
      return state
    case 'paused':
      return event.type === 'RESUME' ? 'playing' : state
    case 'won':
    case 'lost':
      return state
  }
}

这个代码片段看起来很朴素，但对 Agent 很有用。后续无论它改敌人 AI、触摸控制、UI 动画还是关卡生成，都必须尊重状态机。Playtest Agent 也可以直接围绕状态机写验收。

工具链：不同引擎要用不同 Agent 形态

不要把所有游戏都交给同一套工具。Web、Unity、Unreal、Roblox 适合的 Agent 工作方式不同。

Web 原型最适合做第一轮，因为 Playwright 可以直接帮你证明它是否可玩。Unity 和 Unreal 更适合当核心玩法确定后，进入真正资产、动画、编辑器和发布管线。旧游戏迁移则完全是另一类问题，重点不是生成玩法，而是理解已有系统。

自动试玩：把“能跑”升级成“能玩”

OpenGame 和 Play2Code 的共同启发，是把试玩也交给 Agent 或脚本。对 Web 游戏来说，最小试玩脚本可以这样写：

import { test, expect } from '@playwright/test'

test('core loop is playable', async ({ page }) => {
  await page.goto('http://127.0.0.1:3000')

  const canvas = page.locator('canvas').first()
  await expect(canvas).toBeVisible()

  await page.keyboard.press('Enter')
  await page.keyboard.down('ArrowRight')
  await page.waitForTimeout(500)
  await page.keyboard.up('ArrowRight')

  const before = await page.screenshot()
  await page.keyboard.down('ArrowDown')
  await page.waitForTimeout(500)
  await page.keyboard.up('ArrowDown')
  const after = await page.screenshot()

  expect(Buffer.compare(before, after)).not.toBe(0)
  await expect(page.getByTestId('hud')).toContainText(/HP|Time|Score|Chips/)
})

这不是完整测试，但能挡住几类低级失败：页面空白、canvas 不存在、输入无效、画面完全不动、HUD 没渲染。再往上可以加视觉模型评估：截图里是否有玩家、敌人、出口、道具；移动端 viewport 是否遮挡按钮；失败/胜利弹窗是否出现。

Unity 和 Unreal 的自动试玩可以不用 Playwright，但原则一样：给 Agent 一个可重复的运行路径。比如 Unity PlayMode tests、Unreal functional tests、MCP Editor command、录制输入回放、截图对比、日志解析。

Fable 5 最适合的位置：长任务负责人，不是万能生成器

Fable 5 相关讨论里，最值得细看的不是一个普通小游戏 demo，而是 C&C Generals / Zero Hour iOS 移植这类案例。公开仓库和报道里能看到，这不是“AI 从零生成一个大型 RTS”，而是在已有开源基础、社区项目和跨平台技术栈之上，让强模型参与大型迁移。

这类任务比生成新游戏更能体现 Fable 5 的价值，因为它需要：

• 读懂旧 C++ 工程和历史包袱；
• 分清哪些系统要保留，哪些系统要替换；
• 把渲染、输入、音频、视频、文件系统、平台打包拆成子系统；
• 根据真机症状追踪问题，比如黑屏、音频异常、触控映射、性能回退；
• 把每次修复沉淀成 porting pattern，而不是只修一处。

如果把这个经验抽象出来，Fable 5 适合承担的是“长任务技术负责人”角色：

你是一个旧游戏移植负责人，负责把现有游戏迁移到新平台。

约束：
- 不重写核心玩法。
- 每次只处理一个子系统：渲染、输入、音频、视频、文件系统、打包、性能。
- 先读当前源码和已有移植文档，再提出 patch plan。
- 每个 patch 必须绑定一个可观察症状和一个验证方式。
- 真机日志、截图、崩溃栈和用户操作步骤优先于猜测。

输出：
- subsystem
- observed_symptom
- root_cause_hypothesis
- files_to_inspect
- minimal_patch
- validation_steps
- regression_risks
- handoff_notes

这和“做一个像 C&C 的 RTS”完全不同。后者会诱导模型生成大量不稳定代码；前者让模型进入一个真实工程闭环：读、改、跑、看、记录、再改。

Fable 5 不该直接负责的部分

强模型也不应该被放到所有位置。几个边界要明确：

比较合理的分工是：普通模型负责吞吐，Fable 5 负责困难判断，脚本负责确定性检查，人类负责品味、方向和风险。

一个可落地的项目目录

如果要认真做 AI Agent 游戏开发，可以在仓库里准备这样的结构：

game-agent/
  docs/
    DESIGN_CONTRACT.md
    SCENE_SPEC.json
    GAMEPLAY_SPEC.json
    TEST_RUBRIC.md
    ASSET_MANIFEST.md
  src/
    game/
      state-machine.ts
      systems/
      scenes/
      entities/
    tools/
      generate-scene.ts
      validate-scene.ts
      run-playtest.ts
  tests/
    core-loop.spec.ts
    mobile-input.spec.ts
    visual-smoke.spec.ts
  agent/
    SYSTEM_PROMPT.md
    LOOP_STATE.md
    DEBUG_PATTERNS.md
    HANDOFF.md

这里最重要的是 DEBUG_PATTERNS.md 和 LOOP_STATE.md。游戏 Agent 会反复遇到类似错误：canvas 空白、资源路径错、物理世界没有 step、敌人导航点为空、移动端 pointer event 被 UI 层吃掉。把这些错误沉淀下来，下一次 Agent 就不需要重新猜。

一个好的 DEBUG_PATTERNS.md 可以长这样：

## Canvas renders blank

Symptoms:
- Page loads with no runtime error.
- Canvas is visible but all pixels are near-black.

Checks:
- Verify asset promises are awaited before scene start.
- Verify camera is centered on player or world bounds.
- Verify sprites are not spawned outside viewport.
- Verify render loop is ticking after state transition.

First patch:
- Add a temporary debug rectangle at player spawn.
- Log camera scroll, player position, asset load status.

这类文件比“请你记住上次问题”可靠得多。

场景生成 Agent 的工具接口

Agent 需要工具，但工具接口不要太自由。比如场景生成可以只暴露几类确定性操作：

type SceneTool =
  | {
      name: 'createStaticCollider'
      args: { id: string; x: number; y: number; width: number; height: number }
    }
  | {
      name: 'spawnCollectible'
      args: { id: string; kind: 'chip' | 'key' | 'health'; x: number; y: number }
    }
  | {
      name: 'createPatrolRoute'
      args: { id: string; points: Array<{ x: number; y: number }> }
    }
  | {
      name: 'validateReachability'
      args: { from: string; to: string; minPathWidth: number }
    }

这样做有两个好处。第一，Agent 不会直接写一堆不可控的场景文件。第二，验证工具可以在写入前拒绝明显错误，比如路径宽度不足、道具不可达、敌人出生点压住玩家。

Unreal 和 Unity 里的 MCP 工具也应该遵循类似原则：允许 Agent 创建、移动、检查对象，但每次修改都要能反查当前 Editor 状态。Cutscene Agent 的一个重要启发就是双向观察：Agent 不只调用工具，还要读取场景里的对象、轨道、关键帧和实际状态。

评测要分三层：Build、Visual、Intent

OpenGame 的评测拆法很实用，可以泛化成三层。

很多 Agent 项目只做第一层，所以会产出大量“能启动但不好玩”的 demo。真正决定质量的是第三层：玩家是否能理解目标，输入是否有效，反馈是否清楚，胜负是否公平。

可以给 Agent 一个硬性发布门：

{
  "release_gate": {
    "build": ["install_ok", "typecheck_ok", "runtime_no_uncaught_error"],
    "visual": ["canvas_non_blank", "player_visible", "hud_visible", "mobile_controls_visible"],
    "intent": [
      "player_can_collect_first_item",
      "damage_rule_triggers",
      "win_condition_reachable",
      "loss_condition_reachable",
      "restart_resets_state"
    ]
  }
}

只要有一项失败，就不能算“完成”。这会迫使 Agent 把漂亮输出变成可试玩产物。

一条实操路线

如果今天要开始一个 AI Agent 游戏项目，我会按这个顺序推进：

1. 先做 Web 版核心循环：Phaser 或 Pixi 足够。目标是 1 到 3 分钟能玩完一局。
2. 建立 Design Contract 和 Gameplay Spec：胜负、状态、输入、反馈全部结构化。
3. 让 Agent 生成第一版场景：只允许用基础图形或开源素材，先不追求美术。
4. 接 Playwright 试玩测试：至少证明画面非空、输入有效、状态变化。
5. 引入资产管线：再接图像生成、Cube 3D、Blender、Kenney、Mixamo 或内部素材库。
6. 迁移到 Unity / Unreal：当核心循环稳定后，再进入编辑器、动画、物理、平台发布。
7. 把错误写进 DEBUG_PATTERNS：让下一轮 Agent 少走弯路。
8. 用 Fable 5 处理长链路问题：迁移、性能、复杂调试、多轮失败复盘，不把它浪费在批量小改动上。

这条路线的关键是“先可玩，再好看，再复杂”。很多 AI demo 失败，是因为顺序反了：先生成华丽场景，再往里面硬塞玩法。结果是场景越复杂，bug 越难修。

最后的判断

AI Agent 做游戏的机会很大，但不是因为模型会写几段游戏代码，而是因为它能把游戏开发里大量低层工作自动化：脚本、配置、场景搭建、试玩回归、bug 归纳、资产清单、移植适配。

真正的门槛也很清楚：游戏必须进入反馈闭环。没有 playtest 的 Agent 只能叫代码生成器；有 playtest、rubric、debug memory 和引擎工具的 Agent，才开始接近一个小型制作管线。

Fable 5 这类模型应该被放在最需要长上下文和结构性判断的位置：复杂项目负责人、旧工程迁移者、疑难 bug 调查者、自动试玩后的修复规划者。它不应该替代所有工具，也不应该绕过构建、试玩和人工品味。

更现实的未来不是“一句话生成 3A 游戏”，而是一个人用 Agent 在几天内做出过去几周才能完成的可玩原型；一个小团队用 Agent 维护更多实验分支；一个旧游戏移植项目用 Agent 更快穿过平台层、渲染层和输入层的泥潭。这已经足够改变游戏原型和独立开发的节奏。

延伸阅读

• OpenGame: Open Agentic Coding for Games
• Play2Code: A Framework for Continual Game Generation
• AutoUE: LLM Agent Framework for Automated Game Creation in Unreal Engine
• Cutscene Agent: LLM Agent Framework for 3D Cutscene Generation
• Unity AI 官方页面
• Roblox Cube 3D 介绍 与 Cube 3D GitHub
• C&C Generals Mac / iOS / iPad 移植仓库
• PC Gamer 对 C&C Generals iOS 移植的报道