用AI Agent工厂批量生产H5游戏：Synapse游戏工厂实践

TL;DR

问题背景

上周三夜里两点，值班群弹出一条消息：游戏工厂第47号游戏在红米Note12上帧率崩到8fps，美术资源是正常包的3倍大。上周我们刚用Synapse游戏工厂跑出了第89款H5游戏——从需求文本到线上部署，平均周期从人工开发的3周压缩到了4小时。这听起来是效率的胜利，但代价是另一个维度的失控：当你用AI流水线批量生产游戏时，问题不再是"怎么做一个好游戏"，而是"怎么让100个游戏同时保持可接受的下限"。我们发现，在第50到70个游戏之间，废品率突然从5%跳到了22%。

Synapse游戏工厂是Synapse-PJ团队内部搭建的一套AI Agent流水线，核心逻辑是用多个专精Agent串联完成H5游戏的端到端生产：一个理解产品需求，一个生成游戏逻辑，一个输出渲染配置，一个做资源优化。听起来分工明确，但当游戏数量从十几款扩展到近百款时，问题性质发生了根本变化：单个游戏的问题可以被人工修复，但当流水线每天产出5-8款游戏时，任何一个环节的疏漏都会被乘数放大。

为什么这个决策难做

我们一开始以为瓶颈在游戏逻辑生成的质量，所以花了大量精力调优Agent的prompt。但实际上，当我们审视第60到70个失败游戏的问题分布时发现，只有23%的问题源于逻辑生成，剩下77%都是"接口契约"问题：游戏逻辑Agent输出的配置格式，和渲染Agent预期的输入格式之间存在隐性依赖，这种依赖在单游戏开发时不会暴露，因为人工会做上下文补全，但在批量自动化场景下，每个游戏的中间产物都带着不同的"缺省假设"，最终在某个节点汇合时直接崩溃。

另一个反直觉的事实是：测试覆盖策略的失效速度比我们预期的快得多。我们一开始以为只要每个游戏上线前跑一遍自动化测试用例就算过关。但问题在于，H5游戏的性能表现强依赖于具体机型——一款游戏在Chrome DevTools模拟器里跑出60fps，在小米8上可能只有28fps。自动化测试只能验证逻辑正确性，无法验证"这个配置在特定硬件组合下是否会导致资源泄露"。所以决策的真正难点在于：我们需要在设计阶段就做出取舍——是追求生成速度还是追求配置的可预测性，是接受一定比例的"事后修复"还是把校验成本前置到流水线里。

根因/核心设计决策

经过三轮迭代，我们把问题收敛到了一个核心决策：把游戏配置和生产规则彻底分离。具体实现是通过一个叫Spec Contract的中间层。

游戏逻辑Agent不再直接输出渲染配置，而是输出一个规范化的游戏规格文档（Spec），渲染Agent只消费这个Spec，不感知上游是怎么生成它的。这样做的好处是：当某款游戏出现渲染异常时，我们可以独立排查渲染Agent的逻辑，而不必回溯整个生成链路。

但仅有分层还不够。我们在实践中发现，Spec Contract在第73号游戏上被遵守了，但在第74号上又被绕过了——因为没有强制约束力的系统，Agent在遇到复杂场景时会"走捷径"。于是我们引入了预校验层（Pre-Validate Layer），在游戏逻辑Agent输出后、渲染Agent接收前，对Spec进行完整性检查。

预校验层的核心逻辑是这样的：

class SpecPreValidator:
    def __init__(self, rules: list[ValidationRule]):
        self.rules = rules

    def validate(self, spec: GameSpec) -> ValidationResult:
        errors = []
        for rule in self.rules:
            result = rule.check(spec)
            if not result.passed:
                # 记录具体违规字段而非仅返回布尔值
                errors.append({
                    "rule": rule.name,
                    "field": result.offending_field,
                    "expected": result.expected,
                    "actual": result.actual
                })
        return ValidationResult(passed=len(errors) == 0, errors=errors)

    def enforce_or_reject(self, spec: GameSpec) -> bool:
        result = self.validate(spec)
        if not result.passed:
            # 强制截断流水线，不允许带病流转
            raise SpecContractViolation(result.errors)
        return True

这个校验器拦截的问题类型很具体：资源尺寸超限、缺少关键动画帧数据、碰撞体坐标越界。实施预校验后的第80到89号游戏，废品率从22%降回了4.7%。数据好听，但代价是校验规则的维护成本——每次游戏类型扩展，我们都需要为SpecPreValidator补充新的ValidationRule。这是一个必须接受的结构性投入。

另一个关键决策是渲染配置的"降级策略"。当校验通过但运行时检测到设备性能不足时，系统会自动切换到简化渲染路径：减少粒子数量、降低分辨率、关闭某些特效。

# 设备适配配置片段
device_profiles:
  low_end:
    max_particles: 50
    texture_quality: 0.5
    shadow_enabled: false
    target_fps: 30
  mid_range:
    max_particles: 150
    texture_quality: 0.75
    shadow_enabled: true
    target_fps: 45
  high_end:
    max_particles: 400
    texture_quality: 1.0
    shadow_enabled: true
    target_fps: 60

# 降级触发阈值
degradation_trigger:
  consecutive_low_fps: 30  # 连续30帧低于目标FPS则降级
  memory_threshold_mb: 80   # 内存占用超过80MB则降级

这个配置看似简单，但真正踩过的坑藏在"连续30帧"这个数字里。我们第一次设置的阈值是"连续5帧"，结果在部分机型的短暂卡顿（系统调度导致）时触发了误降级，导致玩家在游戏中途看到画质突然下降。调整到30帧之后，误触发率降到了可接受范围。这个阈值没有理论最优值，只有经验最优值——它来自真实机型的性能曲线数据，而不是设计文档。

可移植的原则

1. 如果你在多Agent系统中遇到"间歇性崩溃"，优先检查Agent间的接口契约是否被遵守，而不是单个Agent的内部质量——大多数问题出在接口层面。
2. 如果你在追求生成速度和质量之间做取舍，把校验成本前置到流水线里——事后修复的边际成本会随着游戏数量线性增长，前置校验的边际成本接近常数。
3. 如果你在设计设备适配策略，用真实机型的性能数据而非模拟器的数据做阈值校准——模拟器永远比真机宽容，用模拟器数据设计的降级策略在实际设备上会失效。
4. 如果你在扩展游戏类型，先扩展校验规则再扩展生成能力——没有校验护城河的生成能力扩展，等于在积累技术债。

结尾

回到开头的那个凌晨两点的报警：第47号游戏的帧率问题，最后定位的原因是游戏逻辑Agent在生成跑酷类游戏时，给粒子特效设置了超出低配机型承受范围的参数——这个问题在Spec Contract的分层架构下，原本应该被预校验层捕获，但因为跑酷类游戏是那周新扩展的类型，相应的ValidationRule还没来得及补全。修复方案是给SpecPreValidator加了两条规则，同时触发了一次流水线配置的版本更新。第89号游戏之后，我们要求每新增一个游戏类型，SpecPreValidator的规则覆盖必须同步完成，否则不允许进入正式生成队列。这个规则不优雅，但管用。