H5类游戏在Web和App中智能UI方案

基于你的需求，我将设计一个面向H5游戏的AI Agent自动化测试平台。平台核心是利用大模型的语义理解、推理与多模态能力，实现从需求到用例生成、执行、自愈、断言的完整闭环。底层工具agent-browser和agent-device我们抽象为可接收自然语言指令并返回结构化状态的智能执行器。

一、整体平台架构

采用微服务分层架构，将业务流程拆解为多个独立模块，通过消息队列和API进行协作。

复制代码

┌──────────────────────────────────────────────────────────────────────┐
│                         用户交互层 (Web Console)                      │
│  需求输入 → 手工用例审核 → 用例管理 → 执行监控 → 报告查看              │
└────────────────────────────────┬─────────────────────────────────────┘
                                 │
┌────────────────────────────────┼─────────────────────────────────────┐
│                      API网关 + 认证鉴权 (Kong/APISIX)                │
└────────────────────────────────┼─────────────────────────────────────┘
                                 │
┌────────────────────────────────┼─────────────────────────────────────┐
│                        核心服务层 (微服务)                            │
│                                                                      │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────────┐   │
│  │ 用例生成服务  │  │ 执行调度服务  │  │ 自愈&诊断服务            │   │
│  │ -需求解析    │  │ -任务队列    │  │ -失败分析               │   │
│  │ -手工用例生成│  │ -环境分配    │  │ -大模型重规划           │   │
│  │ -自动化脚本  │  │ -结果收集    │  │ -元素自愈定位           │   │
│  │  生成        │  │ -重试管理    │  │                          │   │
│  └──────┬───────┘  └──────┬───────┘  └──────────┬───────────────┘   │
│         │                 │                      │                    │
│  ┌──────┴─────────────────┴──────────────────────┴───────────────┐   │
│  │                        AI 编排引擎 (LangChain + 工作流)        │   │
│  └───────────────────────────────────────────────────────────────┘   │
│         │                 │                      │                    │
│  ┌──────┴─────┐  ┌────────┴────────┐  ┌─────────┴──────────┐        │
│  │ 元素知识库 │  │ 用例/模板库     │  │ 执行记录 & 截图库 │        │
│  │ (向量DB)  │  │ (结构化存储)    │  │ (对象存储)        │        │
│  └────────────┘  └─────────────────┘  └────────────────────┘        │
└──────────────────────────────────────────────────────────────────────┘
                                 │
┌────────────────────────────────┼─────────────────────────────────────┐
│                         执行引擎层                                    │
│  ┌─────────────────────┐      ┌──────────────────────────────┐      │
│  │   agent-browser     │      │      agent-device            │      │
│  │  (Web自动化执行器)   │      │   (App自动化执行器)          │      │
│  │  - 基于Playwright   │      │  - 基于Appium + 设备农场     │      │
│  │  - 自然语言指令映射 │      │  - 自然语言指令映射          │      │
│  │  - 多Tab/iframe支持 │      │  - 多点触控/手势支持         │      │
│  └─────────────────────┘      └──────────────────────────────┘      │
└──────────────────────────────────────────────────────────────────────┘

二、核心模块详解

1. 用例生成服务

输入：用户上传的需求文档（PRD、功能说明、截图、UI稿等）。

流程：

需求解析：大模型提取关键业务流、页面元素、交互规则、预期结果。
手工用例生成：以结构化JSON输出测试用例，包含步骤、期望、前置条件等，必须含元素的自然语言描述（如"主界面右上角的金色'开始游戏'按钮"）。
交互确认：通过Web界面展示用例，支持用户修改、补充、标注关键区域截图。确认后的用例存入用例库（版本化管理）。
自动脚本生成：将确认的手工用例转化为执行引擎可接受的指令序列。指令不是具体坐标，而是自然语言定位 + 操作类型 + 参数，例如：

{
"action": "click",
"target": "开始游戏按钮",
"context": "主界面中央，金色，带描边",
"expected": "加载界面出现，随后进入选关页面"
}

技术选型：

大模型：GPT-4o / Claude 3.5 Sonnet / 开源Qwen-VL（多模态解析文档和截图）
提示工程：Chain-of-Thought + Few-Shot，模板包含游戏H5常见模式（如登录、商城、战斗）
输出校验：通过JSON Schema约束，确保指令格式合规。

2. 执行调度服务

负责将自动化指令派发给 agent-browser 或 agent-device。

关键能力：

双端适配路由：根据用例标记（Web/App）或用户指定的平台，调用对应agent。
环境管理：管理浏览器实例池和手机设备池（通过STF或自建设备农场），支持并发执行。
状态传递：上一个步骤的截图和DOM/控件树状态，可作为下一步操作的上下文。
结果回收：收集每步操作的截图、执行时间、错误信息，存储到对象存储（MinIO/S3）。

agent-browser 构建方案：

基础：Playwright 或 Puppeteer
指令解析：将自然语言target通过大模型视觉定位转换为具体坐标或选择器。工作流程：

a.截取当前视口全图。

b.将截图和"找到'开始游戏按钮'"的提示发送给多模态模型（如 GPT-4V 或本地部署的 Qwen-VL）。

c.模型返回归一化坐标（0-1），agent计算绝对坐标点击。

d.对于Canvas/WebGL中的元素，直接基于坐标操作；对DOM元素，可尝试生成辅助的CSS/XPath选择器用于增强稳定性。

agent-device 构建方案：

基础：Appium (WebDriverAgent for iOS, UiAutomator2 for Android) + 屏幕流媒体（scrcpy/minicap）
指令解析：类似的视觉定位方案，但需考虑移动端特有的多点触控、滑动等。同样通过截图+多模态模型返回坐标。

技术选型：

任务队列：Celery (Redis/RabbitMQ) 或 Apache Kafka
设备管理：STF (Smartphone Test Farm) 或自研基于 adb/ios-deploy 的管理服务
截图存储：MinIO（兼容S3）

3. 自愈 & 诊断服务

自愈发生在两个层面：元素定位自愈和流程自愈。

元素定位自愈

当 agent 执行失败（如找不到元素）时，触发自愈流程：
将失败步骤的截图、上一步截图、目标自然语言描述、历史成功时的截图（知识库中检索）一起提交给大模型。
大模型分析原因（如UI改版、动画未结束、分辨率不同）并给出新定位：可能是新的坐标，或是重新描述的元素特征。
若修复成功，将新的定位特征反馈到元素知识库（向量化存储），后续类似场景优先使用新特征。
修复失败则标记为需要人工介入。

流程自愈

如果断言失败或预想不到的弹窗中断了流程，大模型重新规划后续步骤：

输入当前截图、已执行步骤、原用例的预期目标。
模型判断当前状态（如弹出了"签到"弹窗），生成临时操作（如点击关闭），然后继续原流程；或判断流程彻底中断，标记失败。

实现：

元素知识库：向量数据库（Milvus/Qdrant）存储元素的描述文本、截图特征向量、历史成功定位方式（坐标/选择器）。
自愈模型：复用多模态模型，结合执行历史进行推理。

4. 断言服务（大模型断言）

传统UI断言（如断言某文字存在）在游戏H5中经常失效。采用视觉语义断言。

执行到断言步骤时：

1.截取当前界面。

2.将截图与断言描述（自然语言）发送给大模型，例如："判断界面中是否出现'胜利'字样，并且背景有烟花特效"。

3.模型返回 true/false 及原因解释。

4.支持多参考图断言：提供预期效果图，大模型比对差异。

5.对于动态数值（如金币数量），可在断言描述中使用通配，由模型识别数字并比较。

优化：

非每次都调用大模型，可先用轻量级CV（OCR、颜色直方图）做预判断，置信度低时再转大模型。
缓存重复断言结果。

三、平台工作流（以一次完整测试为例）

1.用户上传需求：一份描述"玩家登录后领取每日奖励"的文档及参考截图。

2.用例生成服务：大模型生成手工用例，并展示在Web界面：

步骤1：打开游戏首页，等待加载完成。
步骤2：点击"登录"按钮，输入账号密码，点击提交。
步骤3：等待主界面出现，检查是否存在"每日奖励"图标，点击它。
步骤4：断言弹窗显示"领取成功"，金币数增加。

3.用户确认：补充"登录按钮在右上角，形状为圆形"等细节，确认后保存。

4.脚本转化：将手工用例转为 agent 指令序列，标记执行平台为 agent-browser。

5.执行调度：分配一个空闲浏览器实例，agent-browser 开始执行：

使用视觉定位找到并点击登录按钮，输入文本，提交。
每一步截图存档。

6.执行中发生小偏移：第3步找不到"每日奖励"图标。自愈服务启动，对比历史成功截图，大模型重新定位到"奖励"图标（可能换了位置）。更新知识库，继续执行。

7.断言：调用大模型进行视觉断言，判断"领取成功"是否存在，且金币数字变化符合预期。

8.生成报告：展示每步截图、操作轨迹、断言结果和自愈记录，支持人工复核。

四、技术选型总结

|---------|-----------------------------------------------------------------------------------|---------------------------------------|
| 模块 | 推荐技术/工具 | 说明 |
| 大模型（核心） | GPT-4o / GPT-4V（用于视觉定位和断言） Claude 3.5 Sonnet（长上下文）本地部署 Qwen-VL / CogVLM2（数据敏感场景） | 多模态能力必备。可做fallback：本地小模型做初筛，大模型做复杂判定。 |
| AI 编排框架 | LangChain / LangGraph / Dify | 链式调用、工具调用管理，便于构建工作流。 |
| 向量数据库 | Milvus / Qdrant | 存储元素截图特征、描述文本 embedding，用于自愈时相似元素召回。 |
| 自动化底层 | agent-browser : Playwright + 自研视觉定位插件 agent-device : Appium + STF + 截图流 | 视觉定位插件需封装多模态模型调用，返回坐标或选择器。 |
| 对象存储 | MinIO / 阿里云OSS | 存截图、视频、执行日志。 |
| 消息队列 | RabbitMQ / Redis (Celery) | 任务分发与结果回调。 |
| 设备农场 | STF (Android) + tidevice/Appium (iOS) | 管理移动设备。 |
| 前端 | React / Vue + AntV/G6 (流程可视化) | 用例编辑、执行看板、报告。 |
| 后端 | Python (FastAPI) + Go（设备管理高性能部分） | 微服务拆分。 |
| 监控与日志 | Prometheus + Grafana + ELK | 全链路监控，便于排查问题。 |

五、关键难点与应对

1.视觉定位的稳定性

策略：采用多级定位。先尝试基于文本OCR定位，若失败再使用视觉大模型定位；记录坐标并检测元素是否移动（通过目标跟踪）。对于频繁活动的特效，截取静态帧或等待动画结束。

2.跨平台一致性

抽象统一的指令原语（如 tap, swipe, input, assert），agent-browser 和 agent-device 各自实现解析。用例生成时无需关心平台细节。

3.自愈后的回放验证

自愈调整后的步骤需要快速重跑验证，通过后自动提交修改到用例库形成新版本，并标记变更原因。

4.成本控制

多模态大模型调用昂贵，需做缓存（相同场景截图hash缓存结果）、降级（置信度高时用CV方法），并优先使用微调的小模型处理高频重复操作。

5.安全与隐私

内部H5游戏画面可能敏感，可本地化部署视觉模型，或通过边缘渲染截屏后发送给私有化大模型。

六、演进方向

强化学习自愈：从大量自愈案例中训练一个策略模型，直接在agent层面预测修复动作。
智能探索测试：给定一个页面，让大模型自动生成探索性操作，发现潜在漏洞。
性能与渲染异常检测：结合图像分析，检测掉帧、撕裂、资源加载异常等问题。

该架构将业务人员从繁琐的脚本编写中解放出来，真正实现"需求即用例，自动执行与愈合"，尤其适合变化频繁的H5游戏测试场景。