开源游戏测试 Agent 的实测与架构

让 AI 读代码找 Bug，和让 AI 真正玩一遍游戏，差别有多大？作者在 Godot 演示游戏里埋了 4 个问题，Aura Autopilot 用真实按键操作，约 4 分钟找全，还发现了一个额外问题。随后，作者让 Gemini 只读源码，发现较强的模型同样能找全预埋 Bug，而且更快、更便宜。

这次测试最有价值的地方，是把两种方法的收益分开了：源码审查负责低成本筛查，实际试玩负责提供运行证据。至于宣传中的「准确率高约 43%、速度快约 2 倍」，需要单独看它的测试条件。

它为什么不直接让模型按方向键

Aura Autopilot 是采用 Apache-2.0 许可的开源 Agent，但开源不等于运行时无需付费服务。它由四部分协作。

引擎插件负责读取游戏状态、按下真实键鼠，原文列出的支持范围是 Unreal Engine 5（5.4–5.8）、Unity 6 和 Godot 4.7+。本地 Python 服务通过 WebSocket 连接插件，在沙箱中执行模型生成的代码，并保存项目记忆。

编码 Agent 默认使用 OpenCode，也可以接 Claude Code 或 Codex。它先读源码，再生成 harness，也就是一组适合当前游戏的操作封装，比如「开始游戏」「向左闪避」「打开背包」。

最后，TypeSafe 的 Jev 模型约每 0.25 秒选择一个动作；需要快速响应的闪避逻辑直接由代码执行，不必每次等待模型。

这里最值得借鉴的设计，是先把游戏操作变成有意义的动作，再让模型做选择。

按照 Aura 团队的经验，直接提供「按 W」「点击」这样的原始操作，试玩效果较差。不过，原文没有给出这部分的独立对照数据。

每个项目还会保存源码副本、笔记、可用的 harness 和历史报告，后续运行可以复用。任务分为 Explore、Test、Verify、Goal 四类，分别对应探索、排查、验证具体行为和完成目标，例如击中树木后是否摇晃，或击败 Boss 时保持血量高于 20%。

四分钟找到四个 Bug，证据具体到什么程度

作者使用 Linux 和真实 X 显示环境，运行 Godot 4.7.2 的「Dodge the Creeps」。Autopilot 官方提供 Windows、macOS 版本；作者的 Linux 测试通过源码安装完成，依赖 Python 3.12，Godot 插件则是纯 GDScript。

作者删除了 Git 历史，避免工具直接读取修改差异。预埋问题有四个：死亡后继续计分、Game Over 后 Start 按钮不再出现、玩家能走出右边界 240px、斜向移动约为直行的 1.4 倍。

安装时，作者使用以下两条命令，原文记录安装耗时不到一分钟：

uv venv
uv pip install -e ".[dev]"

第二行包含 .[dev]，对应作者从源码安装开发依赖的路径。随后运行的测试套件使用模拟游戏，不涉及真实按键和网络，结果是 492 passed、5 skipped，耗时 4m50s；这项检查不能替代后面的实际试玩。

作者复制 addons/autopilot 并启用插件，用 autopilot serve --aura 启动服务，再以 --playtest=explore --playtest-minutes=5 启动游戏，没有提示 Bug 位置。

编码 Agent 读取 10 个项目文件，生成操作封装，并先探测动作是否有效。接着 Jev 完成一段 150 秒的试玩：开始游戏、躲避敌人、持续向右移动，大约 29 秒后死亡，再反复尝试重新开始。

从启动到退出约 4 分钟，记录的 Agent 时间为 222 秒。四个预埋问题都有运行数据：

• 在宽度为 480px 的画面中，玩家到达 x=720，持续向右时共观察到 5 次越界。
• 死亡时分数为 16，两分钟后增长到 146，此时没有游戏正在进行。
• Start 按钮持续隐藏 120 秒，尝试按 Enter 重启 10 次均无效，形成无法继续的软锁。
• 斜向速度约 580 px/s，直行约 400 px/s，前者快约 41%。

它还实际发现，标题画面尚未开始游戏时，按键会让隐藏的玩家移动。另一个疑似 D-pad 映射颠倒的问题只来自代码阅读，报告明确标注尚未通过试玩验证。这个区分很重要：怀疑和复现没有混在一起。

此次运行还保存了视频、逐帧翻页记录和项目记忆，模型用量约 $1.11。作者原本配置 OpenCode 搭配 Gemini，但报告显示 Aura 模式实际使用 Claude Opus 5.5 处理代码阅读。自行提供密钥时，则需要支付所选模型提供商及 TypeSafe 的 Jev 费用。

宣传数字和源码审查，应该怎样比较

Aura 的官方基准与作者的 Godot 测试是两件事。

官方在 Unreal Engine 5.8 的 Easy Survival RPG V5 上安排了 7 个任务，包括 5 个 Verify、2 个 Goal。每个工具只进行一次空记忆冷启动，使用同一台 Windows 机器，原文称均使用 medium effort 的 Claude Opus 5.5。

结果是 Autopilot 完成 7/7，Claude Code 完成 5/7，未具名竞品完成 4/7；平均耗时依次为 262s、437s、508s。传送、生成物品、无敌模式均算失败，Claude Code 的两个 Goal 运行都因作弊失败。

「43%」来自 Autopilot 的 100% 与竞品约 57% 的差距。严格说，这是约 43 个百分点，不能直接当成相对准确率提升 43%。「约 2 倍」对应 508s 与 262s；相对 Claude Code，速度则约快 1.7 倍。

这些是厂商在单个游戏、7 个任务、各一次尝试中得到的结果，没有重复实验，也没有更广泛的游戏覆盖。

作者自己的源码审查对照则更贴近日常 AI 编程：

方法	预埋问题命中	耗时	本次费用
Autopilot	4/4，另有一个实际问题	约 4 分钟	约 $1.11
gemini-3-flash-preview	4/4，另列 5 项，部分是猜测或设计选择	31.6s	免费额度内 $0
gemini-3.1-flash-lite	1/4	25.6s	免费额度内 $0

Flash 输入约 6.7K tokens，能指出正确文件和行号；Flash-Lite 只找到死亡后计分，还列出了作者认为实际不会发生的时序问题。

这组对照说明，源码可见的 Bug 未必值得先花钱试玩。Autopilot 的优势在于把判断变成了可检查的证据：它确实走到 x=720，也确实重启失败了 10 次。

我的判断

我认可「先读代码筛查，再实际运行验证」的分工。尤其在游戏项目里，能把问题对应到轨迹和视频，通常比只有一段自信的文字更方便复现、讨论和修复。

但这次实验还不足以证明 Autopilot 更擅长处理物理碰撞、关卡布局或复杂时序。作者自己也承认，这些问题才是实际试玩的重要用途，而这次预埋的四个 Bug 都能从源码中看出来。

零误报、项目记忆带来的改进，也需要分别看待。前者是这次小样本运行的观察，后者目前主要是架构上的预期，原文没有给出第二轮运行提速多少的实测。

接入条件同样会影响取舍。没有 Aura 账户或 TypeSafe key，运行约 20 秒就会停止，Jev 不能替换。作者也没有测试 autopilot connect claude 或 connect codex 路径，不能把这些接入方式视作已经验证。

另外，运行分享默认开启。作者通过 AUTOPILOT_SHARE=0 和 --playtest-share=0 关闭分享。Linux 下若端口 8765 被占用，需要用 --port 指定服务端口，再通过 --playtest-url 告诉游戏；作者因此遇到了两次各 2 分钟的超时。

能拿来做什么

• 给 Godot、Unity 或 Unreal 项目做检查时，可以先让较强模型阅读源码，把疑似问题列出来，再用 Autopilot 验证需要实际操作才能确认的部分。
• 把「新游戏后还能否打开背包」「死亡后是否停止计分」写成明确的 Verify 任务。原文称 Verify 和 Goal 支持通过成功或失败退出码接入 CI，但作者没有展示完整流水线配置。
• 在自己的游戏里保留一组固定任务，分别记录冷启动和复用记忆后的命中情况、耗时与费用，用项目实测判断 harness 和记忆是否值得投入。
• 私有项目试用前，先关闭运行分享，并检查 Jev 的账户条件与本地端口，让首次评估真正花在试玩质量上。