夜雨聆风最近我一直在研究一个问题：
Codex 怎么用于游戏测试？下文内容很长，建议结合奶茶+咖啡配合食用
这里说的不是：
“帮我写一段 Airtest 脚本。”
也不是：
“帮我生成几个测试用例。”
这些其实已经是 AI Coding 最基础的能力了。
我真正感兴趣的是：
能不能让 Codex 像一个测试工程师一样，自己操作 Android 真机、打开游戏、完成操作、截图、抓日志、判断结果，发现异常以后继续查日志、定位问题，最后留下可以回归的自动化资产？
如果这条链能够跑通，游戏自动化的形态就会发生比较大的变化。
传统游戏自动化一般是：
测试人员 ↓设计测试用例 ↓写 Airtest / Poco ↓执行 ↓失败 ↓看截图 ↓查 Logcat ↓找开发而 Coding Agent 时代可能逐渐变成：
Codex / Test Agent ↓ 理解测试目标 ↓ 控制 Android 真机 ↓ Airtest / Poco / ADB / AI Vision ↓ 执行游戏操作 ↓ Screenshot + Logcat + SLS ↓ AI Failure Agent ↓ UI异常 / 日志异常 / 数据异常 ↓ 生成稳定自动化回归脚本我花时间把目前 GitHub 上几条比较有价值的路线翻了一遍。
里面既有老牌的 Airtest、Poco，也有 2026 年非常值得关注的新东西，比如 agent-device、Midscene Skills、Mobile-Agent。
如果你本身做游戏测试，这几个项目值得放在一起看，而不是单独学某一个工具。
一、先搞清楚：Codex 在这里到底是什么角色
Codex 不是 Appium，也不是 Airtest。
它本质上是一个 Coding Agent。
它可以理解项目、查看文件、执行 Shell 命令、修改代码、运行测试，再根据结果继续迭代。OpenAI 现在还支持通过 AGENTS.md 给 Codex 写项目长期规则，通过 Skills 把重复工作封装成稳定工作流，通过 MCP 接外部工具。
所以真正合理的架构不是：
Codex ↓替代 Airtest而应该是：
Codex ↓ 理解测试任务 ↓ 决定调用什么能力 ┌───────────┼───────────┐ ↓ ↓ ↓ Airtest Poco ADB ↓ ↓ ↓ 图像 游戏对象 真机 └───────────┼───────────┘ ↓ 游戏客户端Airtest、Poco、ADB这些工具负责“手脚”。
Codex负责“脑子”。
这才是 Coding Agent 用在游戏测试里比较正确的打开方式。
二、Airtest：目前游戏 UI 自动化依然绕不开的底座
GitHub：
AirtestProject/Airtest
截至 2026 年 8 月，Airtest GitHub 大约 9.5K Star。官方定义本身就是“UI Automation Framework for Games and Apps”，支持 Android、iOS、Windows，并通过图像识别定位 UI，而不是完全依赖原生控件树。2025 年底还有新版本发布，2026 年仓库仍有新的 Issue 和代码活动。
为什么游戏测试特别需要这种东西？
因为很多游戏是 Unity、UE 或其他引擎开发的。
Android 原生 App：
ButtonTextViewRecyclerView自动化框架很容易找到。
但是游戏画面可能只有：
UnityPlayer里面真正的按钮、角色、地图、奖励图标，并不一定是 Android 原生控件。
这时候传统的：
find_element(id="xxx")很可能根本找不到。
Airtest采用另外一条路线：
人眼看到什么，就根据图像识别什么。
例如：
touch(Template("login.png"))wait(Template("home.png"))assert_exists( Template("success.png"),"页面进入成功")这也是为什么它到现在在游戏测试领域依然很有价值。
三、Airtest + Codex 应该怎么结合
很多人想到的第一步可能是：
让 Codex 写 Airtest。
当然可以。
但价值不算特别大。
更好的方式是先让 Codex理解已有项目。
例如项目结构：
game-automation/├── common/│├── pages/│ ├── login.py│ ├── lobby.py│ └── battle.py│├── cases/│ ├── test_login.py│ └── test_game.py│├── images/│└── reports/然后让 Codex：
阅读当前 Airtest 自动化项目。找到已有登录、主页和游戏场景的公共能力。新增一条完整游戏流程回归：启动应用→ 登录→ 进入指定功能→ 完成操作→ 判断结果页面→ 保存截图→ 保存日志优先复用已有方法。执行脚本。如果失败，不要立即修改测试代码。首先分析：1. 图片定位失败2. 页面加载超时3. 游戏功能异常4. 设备异常5. 网络异常6. 自动化脚本异常给出证据以后再决定是否修改测试。这时候 Codex做的已经不是“生成代码”。
而是：
维护一套游戏自动化工程。
四、Poco：比截图识别更进一步，直接访问游戏 UI 对象
GitHub：
AirtestProject/Poco
目前约 1.9K Star。
Poco 是一个跨引擎 UI 自动化框架，可以用于 Unity3D、Cocos2d-x、Android Native、iOS Native 等环境。AirtestProject 另外还有专门的 Poco-SDK 仓库，用于给不同游戏引擎集成 Poco。
Poco和Airtest最大的区别可以简单理解成：
Airtest：
我看到这个按钮长这样。Poco：
我知道这个按钮叫什么。例如：
poco("LoginButton").click()poco("GameStart").click()assert poco("ResultPanel").exists()相对于：
touch(Template("login_button.png"))Poco通常更加稳定。
因为UI换个颜色：
Airtest图片识别可能受影响。
但是如果：
LoginButton这个游戏对象没变，Poco仍然可以定位。
五、但 Poco 有个问题：需要游戏项目配合
这是很多测试团队容易忽略的地方。
Poco不像纯图像识别一样完全黑盒。
通常需要在Unity或者其他引擎里面接入对应 SDK。AirtestProject 的 Poco-SDK 仓库就是为这些引擎提供接入实现。 所以实际选择一般是：
研发愿意配合接SDK ↓ Poco研发不愿意修改游戏 ↓ Airtest如果是企业内部长期项目，我个人更倾向：
Poco +Airtest同时使用。
核心流程：
Poco。
复杂画面：
Airtest。
六、AltTester：Unity 游戏自动化非常值得看的另一个项目
GitHub：
AltTester-Unity-SDK
当前约 121 Star。
Star没有Airtest高，但是它的定位非常明确：
Unity UI Driven Test Automation。
它允许通过：
C#PythonJavaRobot Framework查找Unity游戏里的对象并与对象交互。
例如游戏里真正存在：
Canvas ├─ Lobby ├─ StartButton ├─ RewardPanel └─ SettingsAltTester可以直接对这些对象进行访问。
所以从自动化稳定性来说：
图像识别 ↓Airtest游戏对象树 ↓Poco / AltTester它们其实解决的是两种不同层面的问题。
七、AltTester + Codex 特别适合做什么
如果一个Unity项目研发愿意配合测试，Codex可以读取：
Unity代码+AltTester测试代码+测试失败结果然后分析：
UI对象发生改变？业务逻辑发生改变？自动化对象路径失效？还是游戏本身真的Bug？例如：
以前：
Canvas/Lobby/StartButton版本调整成：
Canvas/Home/StartButton传统自动化：
ElementNotFound测试人员自己排查。
Codex可以读取：
Git Diff+Unity代码+AltTester脚本发现：
StartButton仍然存在，但是父节点从Lobby迁到了Home。
然后修改测试。
这就是一个很典型的：
自动化脚本自维护。
八、agent-device：我觉得2026年测试人员非常值得关注
GitHub：
callstack/agent-device
截至目前大约已经 4K Star，而且项目非常活跃，2026 年 8 月仍在快速发布版本。
这个项目和传统移动自动化最大的区别是：
它不是首先为“测试工程师写脚本”设计的。
而是：
给 AI Agent 操作真实设备。
官方定位直接就是：
Mobile app verification for AI agents。
它可以让Agent：
查看设备打开App获取界面状态点击输入滑动截图保存测试证据Android底层还是会使用ADB等能力。项目甚至提供了Android ADB Provider，包括 logcat、应用管理、键盘等能力。
这就非常适合Codex。
九、agent-device甚至已经自带测试Skill
这一点非常有意思。
项目里面直接有：
skills/其中有一个：
dogfood/SKILL.md官方描述就是：
系统性探索和测试 iOS/Android App，寻找 Bug、UX问题以及其他问题。
也就是说，它已经开始把：
移动端探索测试本身封装成 Agent Skill 了。
另外还有：
agent-device/SKILL.md专门教 Coding Agent 怎么使用设备。
这意味着以后可能不需要：
写一个完整Appium Framework而是：
Codex ↓加载 Mobile Testing Skill ↓agent-device ↓真实Android设备十、如果把 agent-device 用在游戏测试里
例如给Codex一个目标：
测试游戏启动和主流程。要求：1. 启动APK2. 等待首页出现3. 进入目标功能4. 完成核心操作5. 每个关键步骤截图6. 操作失败后保存当前UI状态7. 同时拉取最近30秒Logcat8. 判断是否存在Crash / Exception / Timeout9. 输出测试报告Codex可以负责：
Plan ↓调用 agent-device ↓真实设备 ↓收集证据 ↓分析但是这里一定要强调一个限制：
agent-device能够控制Android，不代表它天然就懂Unity游戏内部UI。
如果游戏是大量自绘画面：
Accessibility Tree可能提供不了足够的信息。
所以：
agent-device更适合作为：
设备控制层。
而：
Airtest / Midscene更适合作为：
视觉识别层。
十一、Midscene：我认为特别值得游戏测试关注的AI视觉路线
GitHub：
web-infra-dev/midscene
当前大约 14.6K Star，2026年8月仍在持续快速开发。
Midscene的核心思路特别适合解释给测试人员：
传统自动化：
找到元素ID→ 点击Midscene：
看截图→ 理解页面→ 找到目标→ 操作它的官方说明明确提到：
仅通过截图进行视觉驱动，可以处理缺少语义标记的元素、Canvas、自定义控件、原生应用等界面。
看到 Canvas 这两个字，游戏测试就应该注意了。
因为Unity、WebGL、游戏自绘界面，恰恰是DOM/Accessibility路线最难搞的地方。
十二、Midscene更有意思的是已经直接开始做Skills
GitHub：
web-infra-dev/midscene-skills
目前约 288 Star。
里面已经提供：
Android Automation SkilliOS Automation SkillHarmony Automation SkillVitest + Midscene E2E SkillAndroid直接通过ADB控制。
这意味着：
Codex以后可以：
加载 Midscene Android Skill ↓理解自然语言测试目标 ↓视觉理解游戏画面 ↓ADB控制设备 ↓完成操作这个方向我认为比：
“Codex写Airtest代码”
更值得研究。
因为已经开始接近真正：
AI GUI Testing Agent。
十三、Midscene到底适不适合游戏？
答案不是简单的“适合”或者“不适合”。
如果是：
传统Android控件完全没必要上视觉大模型。
uiautomator/Appium更稳定。
如果是：
UnityCanvas复杂图形UI自绘控件缺乏Accessibility视觉Agent反而开始有优势。
所以可以设计成：
Codex ↓ 判断当前界面 ┌────────┴─────────┐普通控件 游戏自绘UI ↓ ↓Poco/uiautomator Midscene ↓ Vision这其实是未来非常值得研究的一种混合方案。
十四、Mobile-Agent：真正的“AI自己操作手机”
GitHub：
X-PLUG/MobileAgent
目前约 9.1K Star。
这是阿里通义实验室相关的移动GUI Agent项目，当前已经发展到 Mobile-Agent-v3.x / GUI-Owl 等体系，2026年仍在频繁更新和研究。
Mobile-Agent-v2的基本流程本身就是：
手机截图 ↓视觉模型理解 ↓规划下一步操作 ↓ADB操作手机 ↓再次截图 ↓继续判断官方提供的版本明确使用ADB连接Android设备，Mobile-Agent-v2采用多Agent协作改善长任务导航。
这基本已经是：
AI自己玩手机。
十五、那Mobile-Agent是不是可以直接拿来测游戏？
可以研究。
但我不会建议现在直接拿它替代游戏自动化框架。
原因很现实。
AI GUI Agent有一个核心问题：
不够确定。
传统脚本：
点击A点击B点击C100次都应该一样。
视觉Agent：
看图思考点击可能出现：
第1次点这里第2次偏一点第3次理解错页面Mobile-Agent社区过去也讨论过速度、坐标精度、模型依赖等问题。
所以我认为它现在更适合：
探索测试而不是：
核心P0稳定回归十六、游戏测试里最合理的结构其实是“两套自动化”
第一套：
确定性自动化
使用：
AirtestPocoAltTesteruiautomator2负责：
每日回归冒烟测试核心流程版本验证第二套：
AI探索自动化
使用：
CodexMidsceneMobile-Agentagent-device负责：
探索页面异常操作随机路径寻找未知问题生成测试建议发现问题以后：
AI探索 ↓稳定复现 ↓转成 Airtest/Poco ↓进入 Regression Suite这个闭环非常重要。
十七、uiautomator2：设备控制层非常成熟，但游戏里不能乱用
GitHub：
openatx/uiautomator2
目前约 8.3K Star，2026年6月仍发布了3.7.0版本，项目保持活跃。
它本质是：
Python ↓HTTP ↓Android UiAutomator ↓Android设备优点是：
稳定、简单、Python友好。
特别适合：
安装App启动App点击系统控件权限弹窗输入账号系统设置截图设备操作但是到了Unity真正的游戏画面：
uiautomator可能只看到：
UnityPlayer里面的游戏对象不可见。
所以我会把它定位成：
外围自动化。
例如：
uiautomator2负责：安装权限启动系统弹窗外围Native页面 ↓进入游戏 ↓Airtest/Poco十八、ADB：不要小看它，它可能才是整个系统真正的底层
很多AI测试平台做到最后，实际上都会回到ADB。
因为ADB能做：
adb devicesadb installadb shell am startadb shell input tapadb shell input swipeadb exec-out screencapadb logcat也就是说：
连接设备安装APK启动游戏点击滑动截图抓日志全都可以做到。
所以Codex其实天然适合ADB。
它只需要执行Shell。
例如：
检查当前连接的Android设备。如果只有一台：安装build/app.apk。启动目标应用。保存启动后截图。运行期间持续收集logcat。如果出现：FATAL EXCEPTIONANRCrashOutOfMemoryTimeout保存前后30秒日志。这其实已经是一个：
Android Game Testing Skill。
十九、游戏自动化做到这里还不够：必须把日志拉进来
UI测试最大的误区是：
页面看起来对了 = 功能对了。
实际上可能：
UI PASS接口 PASS业务日志 FAIL埋点 FAIL所以游戏质量平台应该同时采集：
ScreenshotLogcat业务日志服务端日志数据结果二十、aliyun-log-android-sdk：如果公司本来就在用SLS，非常值得接
GitHub：
aliyun/aliyun-log-android-sdk
目前约 191 Star。
它支持Android日志异步上传、批量聚合与压缩、本地缓存、多客户端以及失败后的持久化机制。官方仓库的最新Release相对较早，主要集中在2023年，因此它更像成熟基础SDK，而不是当前高频演进的新项目。
这类东西放到测试平台里特别有价值。
例如：
游戏客户端 ↓业务事件 ↓Aliyun Log SDK ↓SLS ↓测试平台查询 ↓规则校验 ↓Codex分析最终一个自动化用例不只是：
按钮点成功而是：
UI执行成功业务日志产生字段完整数值正确没有异常日志二十一、OpenTelemetry Android：如果想把日志平台继续往“可观测性”升级
GitHub：
open-telemetry/opentelemetry-android
项目现在提供 Android Agent，用于初始化 OpenTelemetry Java SDK，并提供 Android App 的自动埋点/RUM能力；2026年仍有持续Release和大量新的Issue、增强需求。
它的价值在于：
以后不只是：
日志而是：
LogsMetricsTraces例如用户进行一个操作：
游戏客户端 ↓Gateway ↓Game Service ↓Database以后测试可以分析的就不只是：
报错了吗？
还可以看：
哪一层慢？
哪个Trace断了？
哪个版本开始异常？
这个已经从：
自动化测试
进入：
质量可观测性平台。
二十二、把上面这些东西放在一起，会是什么样？
我会把整个游戏AI测试系统分成六层。
================================================ ① Codex / Agent Layer================================================ Test Planner Exploration Agent Failure Agent Log Analysis Agent Regression Agent================================================ ② Skills Layer================================================ game-test android-device log-analysis regression bug-reproduce================================================ ③ Automation Layer================================================Airtest Poco AltTesteruiautomator2 Midscene agent-device================================================ ④ Device Layer================================================ ADB Android真机 / 模拟器================================================ ⑤ Data Layer================================================ScreenshotLogcatSLSOpenTelemetryAPIDB================================================ ⑥ Quality Layer================================================UI校验日志校验数值校验Crash分析异常归因测试报告================================================这才是我理解的：
Codex + 游戏测试平台。
二十三、Codex怎么真正调用这些项目？
这里最关键。
目前最适合的有三种方式。
第一种是：
Codex ↓Shell ↓Python/CLI例如：
codex ↓python run_airtest.py ↓adb logcat这是最简单的MVP。
第二种是：
Codex ↓Skill ↓CLIOpenAI官方现在已经把Skill定义成可复用工作流，可以包含 SKILL.md、脚本、参考资料等内容。
例如：
.game-testing/SKILL.mdscripts/ device.py run_airtest.py collect_log.py query_sls.pyreferences/ game_rules.md log_schema.mdCodex读取：
SKILL.md就知道：
游戏测试应该怎么跑。
第三种是：
Codex ↓MCP ↓Game Testing PlatformCodex CLI 本身也可以作为MCP Server接入Agent系统。 如果公司已经有自己的测试平台，这种方式最终会更加合适。
二十四、一个真正能落地的 Game Testing Skill 应该怎么写
例如：
---name: android-game-testdescription: Android游戏自动测试、日志采集和失败分析---执行游戏测试时：第一步：检查adb devices。第二步：确认只有目标设备。第三步：安装指定APK。第四步：启动游戏。第五步：根据场景选择执行器。标准Native UI：使用uiautomator2。Unity可访问对象：优先Poco。不可访问的游戏UI：使用Airtest或视觉Agent。第六步：每个关键步骤保存截图。第七步：测试期间启动adb logcat采集。第八步：失败后禁止立即重跑。必须先保存：ScreenshotLogcat当前页面设备信息版本信息第九步：分析失败类型：Product BugAutomation BugEnvironmentNetworkDataCrashUnknown第十步：如果确定属于自动化脚本问题，才允许修改脚本并重新执行。这就是Codex特别适合做的事情。
二十五、AGENTS.md又有什么用？
Skill解决：
某一种工作怎么做AGENTS.md解决：
这个测试项目永远遵守什么规则OpenAI官方说明Codex在开始工作前会读取 AGENTS.md，用于获得项目级长期指导。
例如游戏自动化仓库可以写：
# Game QA Rules本项目是移动游戏自动化测试。禁止为了让测试通过修改业务代码。自动化失败必须先判断失败类型。核心测试不得使用sleep作为主要等待方式。所有失败必须保存截图。Android失败必须保存logcat。新增测试优先复用已有Page/Component。UI图片统一存放assets。核心P0流程必须保持确定性。Vision Agent发现的问题不能直接进入CI。必须首先转换成稳定Regression Case。以后Codex每次进仓库都按照这些规则执行。
二十六、那这些项目到底值不值得学？
按照我这轮调研，截至2026年8月，可以先这样看：
这里我不会把Star当成唯一依据。
真正需要看的是：
它在整条质量链路里负责什么。
二十七、如果让我现在从0开始，我不会一上来做“大平台”
我会先跑通一个非常小的闭环：
Android真机 ↓Codex ↓ADB ↓Airtest ↓自动执行游戏操作 ↓Screenshot+Logcat ↓Codex分析 ↓PASS / FAIL先证明：
Agent真的可以把一条游戏测试跑完。
第二步再加入：
SLS变成：
UI+客户端日志+服务端日志第三步：
加入：
Poco解决稳定定位。
第四步：
加入：
Midscene做AI探索测试。
第五步：
再做：
Game Testing Skill最后才做：
Web管理平台二十八、最后真正想做的，其实不是“游戏自动化平台”
我现在越来越觉得，下一代测试平台和以前会很不一样。
以前我们的思路是：
平台 ↓测试人员配置 ↓脚本执行以后可能会变成：
测试人员告诉Agent目标↓Agent理解业务↓自己选择：Airtest？Poco？ADB？Vision？↓执行↓采集UI + Log + Data↓判断失败↓尝试复现↓生成稳定测试资产真正发生变化的不是：
“AI帮测试写代码。”
而是：
AI开始参与测试过程本身。
对于游戏测试来说，这件事尤其值得关注。
因为游戏天然就是：
复杂UI、非标准控件、视觉内容多、状态变化多、日志复杂、业务数值复杂。
传统DOM驱动的Web Agent可能并不占优势。
反而：
Vision+ADB+Airtest+Poco+日志+Coding Agent这套组合，很可能更适合游戏。
如果让我从上面这些项目里只挑三个现在就开始实验，我会选：
Airtest + agent-device + Midscene。
Airtest负责成熟的游戏自动化能力。
agent-device负责把真实Android设备变成Agent可以直接操作的工具。
Midscene负责视觉理解和探索。
然后让Codex站在最上面负责：
规划执行分析修复回归等这条链真正跑通以后，再把Poco、SLS、OpenTelemetry和数值校验逐步接进来，就很完美啦。