webqa-agent
MigoXLab/webqa-agent加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
凌晨两点，某团队正在发布新功能。测试人员刚刚手工跑完 40 分钟的回归测试，一切正常。就在上线前十分钟，生产环境报警——搜索结果页崩溃了。
这不是孤例。在现代 Web 开发节奏下，"改一行代码，跑半天测试"已经成为无数工程师的噩梦。传统的 Selenium/Playwright 脚本需要预先知道页面结构（CSS 选择器、XPath），一旦前端改版，测试脚本也跟着失效，维护成本极高。
WebQA Agent 正是为解决这个问题而生——它让 AI 像真人一样"看"网页，用自然语言描述测试目标，浏览器自动完成点击、输入、验证的全流程，完全不需要手写任何测试脚本。
图1：WebQA Agent 演示——用一句话让 AI 自动完成百度搜索功能测试
WebQA Agent 的核心是一个多引擎协作的浏览器 Agent 系统。项目采用前后端分离架构，后端由 FastAPI（Python）+ PostgreSQL + Redis 构成，前端使用 React + Vite 构建可视化管理平台，核心 Agent 引擎以 Python 包形式独立运行。
Flash 是项目的默认引擎，也是其核心卖点。它基于 chrome-devtools-mcp（Chrome DevTools 协议 MCP Server），绕过笨重的浏览器自动化框架，直接通过协议与 Chrome 通信。LLM 将自然语言目标实时解析为具体操作指令，Agent 通过 MCP 实时接收浏览器 DOM 状态并作出决策，整个过程无需离线规划，秒级完成反馈。
这种架构的优势在于极致轻量——不需要安装 Playwright、下载浏览器驱动，Flash 模式下仅需一个本地 Chrome 实例即可驱动整个测试流程。对于日常快速冒烟测试和 IDE 内联调试场景，Flash 模式的效率远超传统方案。
当需要更全面的测试覆盖时，Standard 引擎接管。它基于 LangGraph（有向无环图工作流引擎）构建多轮 Agent：先由 LLM 进行深度页面探索，识别关键交互节点，再动态生成结构化测试用例，最后通过 Playwright 执行器精确复现每一步操作。
这个模式引入了"反思"机制——当测试用例失败时，LLM 会分析失败原因并重新规划下一步操作，类似于 AI Agent 的自我纠错循环。适合新功能探索、全面回归测试等需要 AI 自主决策的场景。
对于需要可重复执行的测试场景，Run 模式接受 YAML 格式的测试用例定义。用户编写结构化的自然语言步骤，Agent 按序执行并验证断言，输出标准化测试报告。这种模式适合测试流程相对固定的场景，比如 CI/CD 流水线集成。
项目主力依赖 LangGraph 0.5.1 和 LangChain 0.3.26，构建有状态的多轮对话 Agent 流程。LangGraph 的 Checkpoint 功能支持 Agent 执行中断恢复，配合 Redis 进度缓存，实现长时间任务的断点续跑。LangChain 生态还提供了统一的 Tool Calling 接口，标准化了各类工具（浏览器操作、HTTP 请求、文件读写）的接入方式。
LLM 支持 Anthropic Claude 和 OpenAI GPT 双后端，通过环境变量切换，无需改动代码。对于国内用户，项目也支持配置 OpenAI 兼容接口（如硅基流动等）访问 Claude 系列模型。
标准引擎使用 Playwright 1.58.0 作为浏览器自动化底层，提供 Chromium/Firefox/WebKit 多浏览器支持。Flash 引擎则使用 chrome-devtools-mcp 通过 Chrome DevTools Protocol 直接驱动本地 Chrome。
有意思的是，项目在 webqa_agent/Dockerfile 中还内置了 Nuclei（项目级漏洞扫描器），作为安全测试的内置 Skill 模块。这意味着 WebQA Agent 不仅能做功能/性能测试，还能进行安全漏洞扫描，实现"一站式 Web 质量评估"。
后端采用 FastAPI 0.115.6 构建异步 RESTful API，使用 asyncpg 连接 PostgreSQL，APScheduler 实现定时任务调度，支持创建周期性的自动化测试任务。Kubernetes 客户端集成使得集群环境下可以动态调度 Agent 执行容器，完成大规模并行测试。
项目提供了基于 FastMCP 2.0.0 的标准 MCP Server，将浏览器测试能力封装为符合 MCP 协议的工具集。这意味着 WebQA Agent 可以无缝接入任何支持 MCP 的 AI 应用——最典型的就是 Cursor IDE 和 Claude Code。开发者可以在写代码的同时，用自然语言让 AI 助手调用 WebQA 执行测试，无需切换工具窗口。
对于个人用户，Flash 模式下的 CLI 使用体验极佳：仅需三步，uv init 创建项目、uv add webqa-agent 安装依赖、uv run webqa-agent gen 启动测试，全程不需要理解任何容器或服务概念。但需要注意的是，Flash 模式依赖本地 Chrome 实例，Windows/macOS 用户需要额外安装 Chrome 浏览器。
对于团队协作场景，项目提供了完整的 docker-compose 一键部署方案：PostgreSQL（数据持久化）+ Redis（任务队列）+ Backend API 服务 + Frontend 可视化平台，四个容器一次启动，通过 Nginx 反向代理统一入口。配置仅需填入 LLM API Key，访问 http://localhost 即可使用 Web 管理界面。
对于企业级 K8s 部署，项目也提供了 Helm-like 的 Kubernetes Manifest 文件，支持配置 ConfigMap、Secret、Deployment、Service 等标准资源，可接入内部 SSO 认证和对象存储（项目集成了阿里云 OSS）。部署复杂度相对 docker-compose 更高，需要有 Kubernetes 运维经验。
图2：项目 GitHub Star 互动页面，支持一键 Star 操作
前端工程师：在 Vibe Coding（AI 辅助编程）工作流中，每次 AI 生成代码后，用 WebQA Flash 模式一句话验证功能是否正常，不必手写测试脚本。
QA 工程师：从"写 Selenium 脚本"转型为"描述测试目标"，AI 自动探索页面、生成用例、执行验证，大大降低维护成本。
AI 应用开发者：通过 MCP Server 将 WebQA 集成到 AI Agent 工作流中，实现"让 AI 学会使用浏览器"的能力，这对于构建网页信息提取、自动化录入等场景非常有用。
DevOps / 平台工程师：利用 K8s 部署方案和定时任务功能，构建企业级自动化测试平台，对多个站点进行周期性健康检查。
尽管 Flash 模式极具创新性，但其对 Chrome DevTools Protocol 的依赖也带来了一些局限。在容器化环境中（如无头服务器），需要额外配置 Chrome 浏览器和 DevTools 端口映射，增加了部署复杂度。项目在 Dockerfile 中内置了 Playwright 的 Chromium，但 Flash 模式的 Chrome 实例仍需外部提供，两者共存增加了镜像体积。
此外，WebQA 的测试质量高度依赖 LLM 的推理能力。在复杂交互场景（如分页加载、无限滚动、第三方 SDK 介入）下，Flash 模式的"秒级决策"可能无法覆盖所有边界情况，此时仍需要 Standard 引擎的深度规划能力。对于追求测试稳定性的团队，建议将两种模式结合使用：日常快速验证用 Flash，正式发布前用 Standard 做全面回归。
WebQA Agent 所在的赛道——Browser Agent（浏览器智能体）——正在成为 AI 应用落地的重要方向。从 2023 年的 OpenAI Browse API，到 2024 年的 Anthropic Computer Use，再到 2025 年各类开源浏览器 Agent 框架的爆发，用 AI 操控浏览器完成复杂任务已成为现实。
WebQA Agent 的差异化在于：它没有追求"通用 AI 操控电脑"的宏大叙事，而是专注于 Web 测试这个具体场景，通过 Flash 模式和 MCP 协议，在测试效率和专业性之间找到了平衡点。对于 AI 爱好者，这是一个理解 Browser Agent 架构的绝佳学习样本；对于开发者，它是一个可以直接提升日常工作效率的生产力工具。
数据来源：GitHub 仓库分析（2026-07-12），Stars: 222, Forks: 19, License: Apache-2.0