AutoGenesis 与 agent-browser 对比及组合测试方案

结论摘要

AutoGenesis 和 agent-browser 不是同一类工具的替代关系。AutoGenesis 更适合控制桌面端、移动端、系统窗口、原生控件、Appium 设备和 BDD 测试生成；agent-browser 更适合网页、浏览器会话、DOM、网络请求、Cookie、本地/远程 CDP、截图 diff、HAR 和可重复的 Web 自动化。

如果目标是测试“纯 Web 应用”，优先使用 agent-browser。如果目标是测试“Windows/macOS/Android/iOS 原生应用”，优先使用 AutoGenesis。如果目标是测试复杂业务链路，例如“桌面客户端登录 -> 跳转网页管理台 -> 手机 App 接收通知 -> 浏览器后台确认状态”，两者应该组合使用：AutoGenesis 负责 App/桌面/设备层动作，agent-browser 负责 Web/浏览器层动作，再由一个上层测试编排器统一步骤、状态、证据和失败恢复。

在可信本机或可信内网环境中，可以更积极地使用 agent-browser 的 CDP、--auto-connect、持久 profile、state 文件、网络捕获和调试能力；但这些能力应限定在可信主机和受控端口内，不应扩散到不可信机器或公共网络。

本地项目依据

本分析基于当前机器上的两个项目：

• AutoGenesis：E:\codexworkspace\AutoGenesis-main
• agent-browser：E:\codexworkspace\agentbrower

AutoGenesis 关键入口：

• pywinauto-mcp-server/：Windows 桌面自动化 MCP Server，基于 pywinauto/UIA。
• appium-mcp-server/：Android、iOS、macOS 自动化 MCP Server，基于 Appium/Selenium WebDriver。
• behave-demo/：Behave BDD 示例和 MCP 客户端编排。
• bdd_ai_toolkit/：VS Code 扩展，面向 BDD、自然语言任务和测试生成。
• pywinauto-mcp-server/tools/wechat_tool.py：当前项目里对个人微信桌面端的专项增强，包含窗口激活、剪贴板输入、OCR 搜索和分阶段发送确认。

agent-browser 关键能力：

• agent-browser CLI：基于 Rust 的浏览器自动化命令行工具。
• Chrome/CDP：open、snapshot、click、fill、eval、network、screenshot、pdf、diff、trace 等命令。
• 会话能力：--profile、--session-name、--state、--auto-connect、--cdp。
• Web 测试能力：DOM/可访问性树、语义定位、网络捕获、Cookie/localStorage、HAR、控制台错误、截图 diff、远程浏览器 provider。

工具定位对比

维度	AutoGenesis	agent-browser
核心定位	MCP 化的多平台 App 自动化与 BDD 生成框架	面向 AI Agent 的浏览器自动化 CLI
最适合对象	Windows 桌面应用、macOS 应用、Android/iOS App、系统弹窗、文件选择器、桌面客户端	Web 应用、浏览器页面、Web 管理后台、OAuth 登录页、网页抓取、网络层验证
底层协议	pywinauto/UIA、Appium、Selenium WebDriver、MCP	Chrome DevTools Protocol、WebDriver/iOS provider、浏览器 daemon
交互模型	MCP tool 调用，返回页面源、UI 快照、截图或执行结果	CLI 命令，返回 snapshot、JSON、文本、截图、HAR、trace
AI 友好性	通过 MCP 暴露工具，适合被 Cursor/VS Code/Codex 等客户端调用	snapshot refs、JSON 输出、语义定位、批处理命令适合 Agent 编排
测试风格	更偏 BDD、步骤记录、自动生成 step code	更偏脚本化、命令式、可组合 Web 自动化
可观测性	Appium page source、pywinauto snapshot、截图、视觉校验	DOM snapshot、网络请求、console/errors、截图、trace、HAR、diff
会话复用	依赖 App/设备状态、Appium session、已登录桌面窗口	profile、state、session-name、CDP attach、Cookie/localStorage
非标准 UI	可通过窗口、坐标、OCR、剪贴板、截图补偿	对 canvas/非 DOM UI 可用截图和坐标，但弱于原生 App 工具
网络验证	原生 App 流量需要额外代理/抓包工具	浏览器网络请求是强项，可直接 route、inspect、HAR
运行环境	Python/uv/MCP/Appium/设备或桌面环境	单 CLI + 浏览器，Web 场景启动快、依赖少

AutoGenesis 优势

1. 多平台 App 自动化覆盖面更广。

   AutoGenesis 同时包含 Windows pywinauto MCP Server 和 Appium MCP Server，能覆盖 Windows 桌面、macOS、Android、iOS。对于真实客户端、桌面软件、移动 App、多端联动测试，它的覆盖面明显比纯浏览器工具更合适。

2. 能处理浏览器外部的系统级交互。

   文件选择器、系统弹窗、桌面应用窗口、微信这类自绘 UI、App 内置 WebView、移动端手势、键盘隐藏、坐标 tap、pinch zoom 等，都属于 AutoGenesis 更自然的领域。

3. 和 BDD 测试生成链路结合紧密。

   项目里有 behave-demo、step 记录、before_gen_code、preview_code_changes、confirm_code_changes 等生成能力，更适合把自然语言场景沉淀成 Behave 测试脚本。

4. MCP 化后适合由 AI 编排。

   MCP tool 可以被上层客户端调用，统一承载“启动应用、查找元素、点击、输入、截图、校验、生成代码”等动作。对于 AI 驱动的探索和逐步修复，MCP 抽象比直接写底层 pywinauto/Appium 调用更顺手。

5. 对已登录桌面应用更友好。

   对个人微信桌面端这种必须复用当前登录态的应用，AutoGenesis 可以连接已有窗口、使用剪贴板输入、OCR 确认目标，而不是强行启动一个新的浏览器或新会话。

6. 可处理 App 内 WebView 与原生控件混合场景。

   Appium 能处理移动 App 内的原生控件和 WebView 上下文切换。对于“移动 App 中打开 H5 页面”的场景，AutoGenesis 是更合适的入口。

AutoGenesis 局限

1. Web 细粒度能力不如 agent-browser。

   AutoGenesis 可以操作浏览器窗口或 App WebView，但不天然拥有浏览器网络层、DOM eval、HAR、console errors、CDP trace、storage 快照等能力。对于 Web 应用调试和稳定抓取，它不是最佳工具。

2. 自绘桌面 UI 仍可能依赖截图、OCR 或坐标。

   微信这类自绘窗口不一定暴露可靠 UIA 控件，AutoGenesis 需要采用窗口坐标、局部截图、OCR、剪贴板等组合策略。相比 DOM refs，稳定性更依赖窗口大小、缩放、语言、主题和 OCR 质量。

3. 环境复杂度较高。

   Windows pywinauto、Appium、移动设备、BrowserStack、MCP transport、Python/uv、权限、驱动版本都可能成为环境变量。它适合 App 自动化，但搭建和排障成本比单 Web CLI 高。

4. 运行速度通常不如浏览器协议级工具。

   原生 App、设备云、截图/OCR、窗口激活、真实键鼠输入都比 CDP 操作慢。大规模 Web 抓取或纯浏览器回归时，AutoGenesis 的成本偏高。

5. 失败定位需要额外设计。

   App 侧失败可能来自窗口焦点、设备状态、权限弹窗、系统缩放、App 冷启动、Appium session 失效、OCR 误识别等。需要保存截图、page source、窗口矩形、日志和动作轨迹才能快速定位。

agent-browser 优势

1. Web 自动化能力直接且稳定。

   snapshot、click @ref、fill、find role/text/label、eval、wait --load networkidle 等命令直接面向浏览器页面。对于有可访问性树或稳定 DOM 的页面，比桌面 UI 自动化更稳。

2. 网络层和调试能力强。

   agent-browser 支持 network requests、HAR、route/mock、console、errors、trace、profiler。测试 Web 应用时，可以同时验证 UI 结果、接口请求、响应状态、前端异常和性能线索。

3. 会话复用方式丰富。

   可使用 --profile、--session-name、--state 保存登录态，也可以在可信环境中用 --auto-connect 或 --cdp 连接已有 Chrome/Edge 调试会话。对于需要复用登录态的 Web 管理后台很方便。

4. 适合 Agent 的确定性元素引用。

   snapshot ref 例如 @e1、@e2 可以把“看页面 -> 选择元素 -> 执行动作”的 Agent 工作流固化为可重复步骤，避免每次都重新猜 CSS selector。

5. 输出结构适合自动化流水线。

   CLI 支持 JSON 输出、batch、session 隔离、截图目录、下载目录、配置文件、环境变量，容易嵌进 CI、脚本或上层测试编排器。

6. 纯 Web 场景效率高。

   浏览器协议级操作通常比真实桌面键鼠/OCR 快，也更适合批量网页备份、数据抽取、回归测试和跨 URL 对比。

agent-browser 局限

1. 不能自动控制任意已经打开的普通浏览器窗口。

   只有浏览器启动时开启 CDP 远程调试端口，或工具自己启动/管理浏览器，agent-browser 才能稳定接管。普通 Edge/Chrome 窗口如果没有远程调试端口，--auto-connect 不一定能附着。

2. 浏览器外部能力弱。

   系统文件对话框、桌面客户端、原生 App、微信、托盘菜单、多窗口桌面软件、移动 App 原生页面，都不是 agent-browser 的主战场。

3. 对非 DOM UI 有天然限制。

   Canvas、WebGL、远程桌面画面、视频流或复杂自绘组件，DOM snapshot 可能看不到真实状态，需要 screenshot、视觉分析或坐标动作补充。

4. CDP 和登录态能力有安全边界。

   在可信访问下可以使用 --cdp、--auto-connect、profile、state 文件；但 CDP 端口等同于本机浏览器完全控制权，state 文件可能包含登录令牌。必须保证只在可信主机、本地回环或受控内网使用，并把状态文件排除出 Git。

5. 对 App 内 WebView 不一定可直接接管。

   移动 App 内 WebView 更适合通过 Appium context 处理。agent-browser 主要控制浏览器，不是移动 App 内嵌 WebView 的通用控制器。

选择建议

场景	推荐工具	原因
备份网页文章、抓取网页内容	agent-browser 或专用抓取脚本	DOM/API/网络层更稳定，不需要桌面坐标
Web 管理后台回归测试	agent-browser	refs、DOM、网络请求、console/error、HAR 都可验证
个人微信桌面端发消息	AutoGenesis	需要复用已登录桌面窗口，且微信 UI 不适合 CDP
Windows 客户端自动化	AutoGenesis	pywinauto/UIA、窗口、键鼠和截图是主能力
Android/iOS App 自动化	AutoGenesis	Appium 是主路径
App 内打开 H5 页面	AutoGenesis 优先，必要时结合 agent-browser	Appium 负责 App/WebView 上下文；外部浏览器跳转可交给 agent-browser
OAuth/网页登录态准备	agent-browser	profile/state/auto-connect 更直接
文件上传流程	Web 内上传用 agent-browser；系统文件选择器异常时用 AutoGenesis	Web input 可直接 upload；原生对话框需要桌面工具
端到端跨端业务链路	两者组合	用各自最强边界，统一编排和证据

组合测试架构

推荐分层

测试编排层
  - 读取场景定义
  - 分配步骤给 AutoGenesis 或 agent-browser
  - 管理测试数据、账号、会话、检查点
  - 聚合截图、日志、HAR、page source、manifest

能力适配层
  - app_driver: 调 AutoGenesis MCP tools
  - web_driver: 调 agent-browser CLI
  - evidence_store: 保存截图、HAR、trace、manifest
  - assertion: 统一断言与错误格式

执行层
  - AutoGenesis pywinauto/Appium MCP Server
  - agent-browser browser daemon/CDP session
  - 被测桌面 App、移动设备、浏览器、后端服务

编排原则

1. 按边界分配工具。

   App/桌面/设备动作交给 AutoGenesis；Web/浏览器/网络动作交给 agent-browser。不要用桌面坐标去点网页按钮，也不要强迫 agent-browser 处理原生 App 弹窗。

2. 每个步骤都产出可复核证据。

   AutoGenesis 步骤至少保存截图或 page source；agent-browser 步骤至少保存 snapshot、URL、console/errors，关键链路保存 HAR 或网络请求摘要。

3. 统一测试状态对象。

   跨工具传递的不是隐式 UI 状态，而是明确的业务状态，例如 order_id、user_id、message_id、download_path、callback_url、auth_profile。

4. 对异步链路使用轮询和超时语义。

   例如 App 提交后 Web 后台等待状态变更，应定义最大等待时间、轮询间隔、失败截图、最后一次 API/Web 状态。

5. 将可信访问显式配置。

   如果使用 CDP 连接已登录浏览器，配置必须写清楚端口、profile 路径、运行机器和清理方式。可信访问不是无限授权，而是“当前本机/受控内网内可用”。

6. 避免共享写冲突。

   多端并发测试时，每个 worker 使用独立账号、独立浏览器 session、独立设备或独立 App 数据目录；产物路径按 run id 隔离。

组合测试示例：桌面 App + Web 管理后台

目标：在 Windows 桌面客户端创建业务单据，然后在 Web 管理后台审核，最后回到客户端验证状态。

建议流程：

1. AutoGenesis 启动或连接桌面客户端。
2. AutoGenesis 完成客户端登录和业务单据创建。
3. AutoGenesis 从 UI 或日志中提取 order_id，保存截图。
4. agent-browser 使用持久 profile 打开 Web 管理后台。
5. agent-browser 搜索 order_id，验证单据已出现。
6. agent-browser 点击审核按钮，捕获网络请求和响应。
7. agent-browser 保存审核后的页面 snapshot、URL、console/errors、必要时保存 HAR。
8. AutoGenesis 回到桌面客户端刷新状态。
9. AutoGenesis 验证状态变为“已审核”，保存最终截图。
10. 编排层生成统一报告，包含两侧证据和业务 id。

关键断言：

• 桌面端创建成功，且业务 id 非空。
• Web 后台能用该业务 id 搜到同一条记录。
• 审核接口返回成功，页面状态变更。
• 桌面端刷新后状态一致。
• 任意失败都保留最后一次桌面截图、浏览器 screenshot、网络摘要和步骤上下文。

组合测试示例：移动 App + Web 支付/后台

目标：移动 App 下单，浏览器打开支付或后台页面，App 收到状态更新。

建议流程：

1. AutoGenesis Appium 启动 Android/iOS App。
2. AutoGenesis 在 App 中登录、选择商品、提交订单。
3. AutoGenesis 获取订单号或支付链接。
4. agent-browser 打开支付链接或 Web 后台。
5. agent-browser 完成 Web 侧支付模拟、后台审批或状态修改。
6. agent-browser 捕获关键网络请求，确认后端状态。
7. AutoGenesis 回到移动 App，刷新订单页。
8. AutoGenesis 验证移动端状态、金额、按钮状态。

关键断言：

• App 端订单创建后状态正确。
• Web 端处理的是同一个订单。
• 浏览器网络请求没有 4xx/5xx 或前端异常。
• App 最终状态与 Web 后台一致。

组合测试示例：Web 触发桌面客户端外部协议

目标：Web 页面点击 myapp:// 或类似外部协议，唤起桌面客户端并完成动作。

建议流程：

1. agent-browser 打开 Web 页面并登录。
2. agent-browser 点击外部协议入口，记录触发前 URL 和 console/errors。
3. AutoGenesis 检测桌面客户端窗口出现或激活。
4. AutoGenesis 处理协议参数带来的客户端页面。
5. AutoGenesis 验证客户端显示正确业务对象。
6. agent-browser 回到 Web 页面验证状态同步。

注意点：

• 浏览器外部协议弹窗可能是系统级 UI，通常应由 AutoGenesis 处理。
• Web 侧点击是否真的触发协议，可通过 URL、console、network 或页面状态辅助判断。
• 桌面端应通过窗口标题、进程、截图和业务字段共同确认，不只依赖窗口存在。

可信访问下的 CDP 使用建议

在可信本机或可信内网环境中，agent-browser 可以使用更强的浏览器接管方式：

agent-browser --cdp 9222 snapshot
agent-browser --auto-connect get url
agent-browser --profile E:\runtime\profiles\admin open https://admin.example.local
agent-browser --session-name admin-web open https://admin.example.local

使用建议：

• CDP 端口只绑定本机或受控网络，不暴露到公共网络。
• 每个测试环境使用独立 profile，不复用个人日常浏览器 profile。
• state 文件、profile 目录、HAR、截图中可能包含敏感信息，应放入 .runtime/、tmp/、artifacts/ 等非源码目录。
• 需要复用已登录浏览器时，优先显式启动带 --remote-debugging-port 的专用测试浏览器，而不是附着个人日常浏览器。
• CI 或无人值守环境优先使用 --profile、--session-name、--state，减少人工登录依赖。

统一产物建议

每次复杂场景测试建议建立 run 目录：

.runtime/test-runs/<run-id>/
  manifest.json
  steps.jsonl
  app/
    screenshots/
    page-source/
    logs/
  web/
    screenshots/
    snapshots/
    har/
    console/
    errors/
  artifacts/
    downloads/
    exported-reports/

manifest.json 建议记录：

• run id、场景名、开始/结束时间、执行人或 agent。
• AutoGenesis MCP server 配置摘要。
• agent-browser session/profile/cdp 配置摘要。
• 测试账号、环境名、版本号，但不要记录密码、token、Cookie 明文。
• 每个步骤的状态、耗时、证据文件路径。
• 失败时的最后已知业务 id、App 页面、Web URL、网络状态。

编排实现建议

方案 A：Behave 作为主编排器

适合已经使用 AutoGenesis 的 BDD 工作流。

• Behave step 中继续调用 AutoGenesis MCP。
• 新增 Web step helper，通过 subprocess 调用 agent-browser。
• 每个 step 把证据写入统一 run 目录。
• 用 tags 区分 @app、@web、@cross-platform。

优点：

• 贴合 AutoGenesis 现有 BDD 结构。
• 易于把自然语言场景转为测试代码。
• 报告层可以沿用 Behave 生态。

缺点：

• Python step 里需要自行封装 agent-browser JSON 输出解析。
• 并发和多浏览器 session 管理需要额外设计。

方案 B：Python 编排器统一调用两类工具

适合复杂流程、长链路、多端状态机。

• Python 用 MCP client 调 AutoGenesis。
• Python 用 subprocess 调 agent-browser，统一 --json 输出。
• 上层代码维护 ScenarioContext，记录业务 id、账号、路径、证据。
• 对每个动作封装 run_step(name, action, evidence_policy)。

优点：

• 最灵活，容易加重试、轮询、断点、证据聚合。
• 适合 CI、无人值守、多端联动。

缺点：

• 需要自己维护 DSL 或步骤规范。
• 初期工程量大于 Behave。

方案 C：Agent 作为临时探索层，脚本作为固化层

适合需求还在变化、页面和 App 还不稳定时。

• 先由 Agent 使用 AutoGenesis 和 agent-browser 探索可行路径。
• 探索稳定后，把动作固化成 Python/Behave 脚本。
• 对高风险动作保留人工确认或 dry-run 阶段。

优点：

• 前期快，适合摸清未知系统。
• 后期能沉淀稳定回归脚本。

缺点：

• 不能长期依赖聊天上下文和手工判断。
• 需要及时把经验提升为脚本、约束和测试。

推荐落地路线

1. 保持 AutoGenesis 作为 App/桌面/移动自动化主工具。
2. 把 agent-browser 引入为 Web 专用能力，不让 AutoGenesis 承担纯 Web DOM/网络测试。
3. 在 AutoGenesis 仓库中新增 web_driver helper，统一封装 agent-browser 命令。
4. 在 behave-demo 或新的 cross-platform-tests 目录中建立组合测试示例。
5. 定义统一 run 目录和 manifest 格式。
6. 对可信访问场景建立专用浏览器 profile 和 CDP 启动脚本。
7. 把失败证据收集作为默认行为，而不是事后补救。

最终建议

两者结合时，不要追求一个工具覆盖所有动作。正确边界是：

• AutoGenesis = App、桌面、移动、系统 UI、真实设备、原生控件。
• agent-browser = Web、DOM、浏览器会话、网络、Cookie、HAR、console、trace。
• 编排器 = 业务状态、步骤顺序、证据、重试、报告、失败恢复。

按这个边界组合，复杂场景测试会比单独使用任一工具都更稳定，也更容易把探索过程沉淀成可重复的自动化资产。