Web-Use：让 AI 真正学会「浏览网页」的浏览器智能体

从手动操作到自动驾驶：网页交互的新范式

你是否曾经花半小时反复填写同一个表单、在一堆搜索结果里找信息、或者盯着屏幕等待某个页面加载完成？这些重复性的网页操作正在消耗你大量的时间和精力。

Web-Use 带来了一个截然不同的思路：与其让人类来操作浏览器，不如让 AI 直接接管整个浏览过程。你只需要给出一个目标——比如「帮我从亚马逊印度站找出 RTX 4060 笔记本显卡的所有报价」——AI 就会自动打开浏览器、导航到网站、填写表单、滚动页面、提取数据，全程无需人工干预。

这个项目在 GitHub 上获得了 293 颗星，由 Jeomon George 和 Muhammad Yaseen 两位开发者维护，定位是「CDP 驱动的浏览器智能体」，即通过 Chrome DevTools Protocol 直接与真实浏览器通信，实现高精度网页自动化。

Chrome DevTools Protocol：与浏览器深度对话

Web-Use 的核心技术栈建立在 Chrome DevTools Protocol（CDP） 之上。这是一个 Chrome 浏览器内置的调试接口，Web-Use 通过 CDP 直接与浏览器通信，绕过了传统 Selenium/Playwright 依赖的中间层（如 WebDriver 协议）。这种直接通信方式带来了几个关键优势：

精准的语义树构建：传统自动化工具往往依赖 XPath 或 CSS 选择器，这些选择器在网页结构变化时极其脆弱。Web-Use 则从真实 DOM 树直接构建「语义树」，每棵树节点都包含 tag、id、class、role 和文本内容。例如：

form#checkout-form
├── [#3] input#email.form-input "Email"
├── [#4] input#name.form-input "Name"
└── [#5] div.btn-group [button] "Submit"

每个可交互元素都有一个稳定的索引编号（[#3]、[#4]），AI 可以直接通过编号「点击这个按钮」或「填写这个输入框」，无需猜测选择器。

实时页面状态感知：CDP 允许 Web-Use 获取实时的网络请求、JavaScript 执行状态、DOM 变化，甚至能检测 CAPTCHA 弹窗和 OTP 验证码等需要人工介入的交互。这让 AI 不再是盲目操作，而是「看见」页面上正在发生的一切。

多 LLM 支持：灵活的模型选择

Web-Use 并不绑定某个特定的大语言模型，而是通过模块化 provider 接口同时支持十余种 LLM 后端：

• Anthropic Claude：官方推荐，用于复杂推理和指令遵循
• OpenAI GPT-4 系列：成熟的 GPT 模型支持
• Google Gemini：Google 自研多模态模型
• Ollama 本地部署：支持 qwen、llama 等开源模型，数据完全本地化
• Groq / Cerebras / Mistral / vLLm / DeepSeek：其他主流云端和本地推理引擎
• LiteLLM：统一的 LLM 调用抽象层

这种多 provider 架构让用户可以根据任务复杂度、成本敏感度和数据隐私要求自由切换模型。比如处理敏感数据时用 Ollama 本地模型，追求效果时切到 Claude。

视觉理解：让 AI 「看见」页面

仅靠 DOM 语义树有时不足以理解复杂页面的视觉布局。为此，Web-Use 集成了视觉能力（use_vision=True）：AI 可以对当前页面截图进行多模态理解，识别图片内容、图表数据、色彩状态等纯 DOM 信息无法表达的视觉信号。

结合滚动感知的边界框标注，AI 能准确知道「页面上的哪个区域是可点击的」，即使该区域的 DOM 属性不完整。这对于处理电商网站、地图应用、图表页面等高度依赖视觉信息的场景尤为重要。

OAuth 2.0 + PKCE：自动化登录认证

传统浏览器自动化最难处理的问题之一是登录态——每次运行都要重新登录，或者需要手动维护 Cookie。Web-Use 提供了内置的 OAuth 2.0 + PKCE 支持，工作流程如下：

1. 启动时启动一个本地 HTTP 服务（localhost:PORT/callback）
2. 浏览器导航到第三方登录页面，用户首次手动授权一次
3. 授权码通过 PKCE 流程交换为 Access Token
4. 后续所有浏览器请求自动注入 Authorization: Bearer 头
5. Token 保存到 ~/.web-use/oauth/，下次运行自动加载，过期自动刷新

这意味着首次认证后，AI 可以直接以登录态访问 GitHub、Google Drive、Notion 等 OAuth 保护的资源，全程无需人工介入。

WebMCP：让网站自定义工具成为可能

Web-Use 还支持 Web Model Context Protocol（WebMCP），这是一个正在兴起的标准化协议，允许网站主动向 AI agent 暴露自定义工具。例如访问一个文档网站时，网站可能暴露一个 search_docs(query) 工具，AI 会自动发现并使用它。

这一设计让 Web-Use 不仅仅是一个「操作浏览器的工具」，更是一个可以与网站能力动态集成的智能体平台。随着更多网站支持 WebMCP，AI 能做的事边界会持续扩展。

代码架构：清晰的分层设计

从项目结构来看，Web-Use 的代码被组织为几个核心模块：

• src/agent/：Agent 核心逻辑，包含 loop.py（主循环）、base.py（基础类）、browser/（浏览器管理）、dom/（DOM 解析）、context/（上下文管理）、auth/（认证）、tools/（工具服务）
• src/cdp/：CDP 协议层，包含 service.py（CDP 会话管理）、protocol/（协议文件）、generator/（CDP 协议生成器）
• src/providers/：多 LLM provider 适配层，支持 anthropic、openai、google、ollama、groq、mistral、deepseek、vllm 等十余种
• src/tools/：工具服务层
• src/hooks/：钩子机制
• src/messages/：消息处理

整体采用模块化插件架构，各 provider 之间相互独立，新增一个 LLM 支持只需实现 BaseChatLLM 接口即可。项目依赖管理使用 UV（现代快速 Python 包管理器），Python 版本要求 3.11+，依赖涵盖 httpx（HTTP）、rich（终端输出）、pydantic（数据验证）、pillow（图像处理）、pymupdf（PDF 处理）等。

部署与使用：门槛低但有前提

Web-Use 以 Python CLI 工具形式提供，部署流程非常简洁：

git clone https://github.com/CursorTouch/Web-Use.git
cd Web-Use
uv sync
# 设置 .env 文件（API Key）
uv run main.py

核心前提条件只有一个：系统已安装 Chrome 浏览器。Web-Use 通过 CDP 连接本地 Chrome 实例，无需额外安装 ChromeDriver 等驱动。

不过需要注意，项目目前不支持 Docker 部署。没有提供 Dockerfile 或 docker-compose.yml，也无法在纯命令行环境（无 GUI）中运行——因为它的本质是驱动真实 Chrome 浏览器。不过换个角度想，如果你需要在服务器上做网页自动化，可能本身就需要一个有头浏览器环境。

从资源占用来看，Web-Use 的内存需求仅约 1GB，磁盘占用 200MB 左右，对硬件要求极低，不需要 GPU。

项目亮点与局限

亮点：

• 多模型支持：同时支持十余种 LLM 后端，灵活切换
• CDP 直连架构：相比 Selenium/Playwright，DOM 理解和交互更精准
• OAuth 自动化：解决了长期困扰浏览器自动化工具的登录态管理问题
• WebMCP 前瞻布局：为网站与 AI agent 的双向通信铺路
• 代码质量较高：类型提示完整，pytest 测试覆盖，使用 ruff 代码检查

局限：

• 无 Docker 支持，无法在容器环境快速部署
• 需要本地 Chrome，不支持无头服务器纯命令行部署
• 高度依赖页面 DOM 结构稳定性，极端 SPA 页面可能有挑战
• 对复杂 CAPTCHA（如 hCaptcha）处理能力有限

行业意义：浏览器自动化进入 Agent 时代

Web-Use 代表了一个重要趋势：浏览器自动化正在从脚本驱动转向 AI Agent 驱动。传统的自动化工具需要人类预先编写精确的操作步骤，而 AI Agent 只需要你描述目标，就能自主规划执行路径。

结合 Claude MCP（Model Context Protocol）和 Browser Use 等同类项目，这一方向正在快速发展。Web-Use 的特色在于其 CDP 直连架构和 OAuth 自动化能力，在需要处理真实登录态的商业场景中有独特优势。

如果你需要自动化复杂的网页操作流程、构建数据采集 pipeline、或者让 AI 能够访问需要登录才能获取的网页资源，Web-Use 值得一试。