一款游戏如何变成一座游戏工厂
这是 game-factory 系列文章的第 2 篇（共 8 篇）。
一句话进去，一款游戏出来。
游戏工厂（game factory）是一条由多个智能体（agent）组成的流水线，它能把一句话主题变成一款已经部署、可以直接玩的老虎机游戏。我输入一句“ancient Egypt treasure slots”，中途确认几个决策，几分钟后，一个主题游戏就出现在某个 URL 上：金色的圣甲虫转轴、莎草纸背景、关于法老的获胜提示、还能正常工作的排行榜。我不需要画图标，不需要写一行 React，也不碰控制台。
第 1 篇讲的是我为学习网络博彩（iGaming）领域而手工搭建的那台老虎机。这一篇要讲的是，那款游戏如何变成一条能按需生产变体版本的流水线——六个 agent 各做什么、它们怎么交接，以及人在这条线上仍然站在哪里。
为什么用一条 agent 流水线，而不是一个 agent
最直观的做法是一个全能 agent：给它一个主题、一份代码库，让它直接做出一款游戏。但我没这么做，而原因很关键。
一款老虎机变体不是单一任务。它要先定需求规格，然后生成图片，接着改代码，再做浏览器测试，最后部署。每一步用的工具不同，出错的方式也不同，人想在继续之前检查的地方更不一样。让一个 agent 包办所有事情，它脑子里要装的东西太多，一旦失败很难定位出问题在哪，而且各步骤之间没有任何可供你审查的东西。
所以我把整个过程拆成一条流水线，每个阶段是一个小型 agent，只负责一项工作，输出干净明确，直接供下一阶段使用。这里的 agent 没什么特别的：一个在循环里运行的模型，配一组工具，外加一个结束循环的条件。调用模型，让它调用工具，把结果喂回去，重复直到它报告完成。没有用任何框架，只有 Bedrock API 和 Python——我特意这样选，是为了弄懂每一个环节。
有意思的工程点不在循环本身，而在如何界定每个 agent 的任务范围，让循环真的能顺利结束。
六个阶段
流水线按顺序运行。每个阶段读取前面的输出，写出下一阶段需要的东西。
one sentence in
│
▼
┌────────────────┐
│ Designer │ ──▶ the spec (a JSON contract)
└────────────────┘
│
▼
┌────────────────┐
│ Image-Gen │ ──▶ symbol icons
└────────────────┘
│
▼
┌────────────────┐
│ Background-Gen │ ──▶ the page background
└────────────────┘
│
▼
┌────────────────┐
│ Builder │ ──▶ the themed React code
└────────────────┘
│
▼
┌────────────────┐
│ Tester │ ──▶ a pass / fail QA report
└────────────────┘
│
▼
┌────────────────┐
│ Deployer │ ──▶ a live URL
└────────────────┘
│
▼
以下是对原文第 3/4 段的翻译：
一条从设计到上线的完整流水线
- 设计师（Designer）。你描述一个游戏主题，Designer 会追问细节，然后产出一份规格说明——一个 JSON 文件，后续所有阶段都读它。这份文件里包含：符号及其权重、配色方案、中奖模式、界面文案、字体等等。它是整个构建过程的契约。示例：
{
"theme_id" : "ancient-egypt-slots",
"symbols" : [{ "name" : "Scarab", "value" : "scarab", "weight" : 3 }],
"color_palette" : { "primary" : "#C8A24B", "background" : "#1A0F0A" },
"win_names" : { "three_of_a_kind" : "PHARAOH'S FORTUNE" }
}
-
图像生成（Image-Gen）。根据规格中的每个符号，用提示词生成对应图标，再调整尺寸以适配老虎机的转轴区域。转轴上的图案不再是云服务 logo，而是圣甲虫和安卡符号。
-
背景生成（Background-Gen）。同样的思路，只做一次，生成页面背景图。
-
构建器（Builder）。负责把赌场的 React 代码改写成当前主题的代码。这是一个代码修改代理，也是让我最头疼的一个——它难缠到值得单独写一篇博客来复盘。
-
测试器（Tester）。用 Playwright 在真实浏览器里运行构建好的游戏，每步都截图，然后用视觉模型来判断游戏是否真的能玩：转轴会不会转、中奖结果是否正确显示、界面看起来是否正常。这是一种「靠看而不是靠断言」的自动化 QA。
-
部署器（Deployer）。构建应用并部署到 AWS——前端部署到 CloudFront，配合无服务器后端——而且只有当测试报告显示游戏通过时，它才肯执行部署。
人在流程中的位置
这条流水线刻意不是全自动的。各阶段之间设有人工审批关卡：Designer 提出规格后要等确认；Builder 在改动代码前要先提交方案；Deployer 上线前要获得批准。整个模式是：代理提方案，人类做审批。这样既能保证在错误代价高昂的节点有人把关，又不必让人事事亲力亲为。
阶段之间的交接刻意做得朴实无华。规格就是一个磁盘上的文件，图标和背景图就是磁盘上的文件，测试结果也是磁盘上的文件。每个代理读取前一个代理留下的产物，仅此而已。
朴素的交接是可检查的交接——当生成结果看起来不对劲时，我可以打开规格文档和图片，清楚地看到上一阶段究竟交给了下一阶段什么东西。
结论是：如果你在做的事，是把一段提示词变成真实产物，那么真正值得复制的结构，不是「一个包办一切的智能体」，而是一条由多个单一职责智能体组成的流水线——每个智能体只负责一件工作，以普通文件的形式输出给下一阶段读取，并在出错代价高的环节设置人工检查关卡。
这样做能把故障局部化：当游戏成品有问题时，我知道该去找哪个环节，因为我能看到它产出了什么。同时，你还可以在不影响其他环节的情况下，单独替换或加固某个阶段——这正是后来 Builder 能被整个拆掉重建、周围五个智能体却不受干扰的根本原因。
接下来，我会按顺序为每个阶段单独写一篇，每篇都回答同样三个问题：它是什么、它做了什么、哪里出了问题。