浏览器自动化的前世今生

从 Web 1.0 到 Web2.0，再到单页应用 (SPA) 和 React/Vue 等前端框架时代，再到当下的 AI Agent 时代。每个阶段都有当时的浏览器自动化的王者。

Selenium 昔日王者

Selenium 的时代诞生于 Web 1.0 和 2.0 初期，当时网页主要是静态或多页面应用。Selenium 的架构基于命令驱动、需要显式等待，这完美契合了那个时代可预测的、步骤化的测试流程。

作为最早的行业标准，Selenium 的核心是 WebDriver 协议。该协议充当了测试脚本和浏览器驱动程序之间的中间层，通过 HTTP 进行通信。这种架构虽然实现了广泛的跨浏览器和跨语言兼容性，但也引入了额外的网络开销，导致性能相对较低，且架构较为复杂。

虽然 Selenium 支持的语言（Java, Python, C#, Ruby, JavaScript 等）和兼容性（包括一些旧版浏览器，比如老IE）相对广泛，但是性能问题，复杂度问题使得使用 Selenium 构建的自动化脚本非常脆弱和不稳定，也无法满足当前各种具备"动态"属性的前端特性和需求。

Puppeteer 现代挑战者

随着单页应用 (SPA) 和 React/Vue 等前端框架的普及，Web 变得高度动态、异步和状态化。网页不再是简单的文档，而是复杂的应用程序。为了应对这种新的现实，Google Chrome 团队开发了Puppeteer。 Puppeteer 绕过了 WebDriver 协议，通过 WebSocket 直接与 Chrome DevTools Protocol (CDP) 通信。这种直接通信的方式极大地提升了执行速度和控制的可靠性。

显而易见，Puppeteer 的最大优势是与 Chrome/Chromium 浏览器的深度集成，这也是 Puppeteer 性能很好的核心原因，这让 Puppeteer 非常适合执行 Chrome 特定的自动化任务，如网页截图、PDF 生成、Web录制和性能分析等。

但是 Puppeteer 也有明显的劣势，核心还是在支持的语言和兼容性方面。目前只支持 JavaScript、Node.js 和 Chromium 生态，虽然也支持 Firefox，但其跨浏览器能力远不如 Selenium 或 Playwright 。

Playwright 当代领跑者

Playwright 由微软推出，其核心开发团队正是来自最初创建 Puppeteer 的团队。Playwright 沿用了与 CDP 类似的 WebSocket 直接通信架构，但将其扩展为了一个统一的协议，能够同时支持 Chromium、Firefox 和 WebKit (Safari) 三大主流浏览器引擎，且提供完全一致的 API。

在当前 AI Agent 的时代下，AI Agent 代表了更高维度的交互模式。AI Agent 不是在执行预设的脚本，而是在根据实时感知的页面状态进行动态决策。这种模式要求其底层的执行器必须具备极高的鲁棒性、稳定性和对异步环境的适应能力，以应对来自 Web 和 AI 推理过程的双重不确定性。而 Playwright 正是在这个大背景下诞生的，所以天然具备自动等待、工具链、面向现在 Web 框架的鲁棒性等特性，从而使其成为构建 AI Agent 的理想选择。

• 自动等待 (Auto-waiting)：这是 Playwright 的核心价值点之一。它会在执行点击、输入等操作前，自动等待目标元素变为可操作状态。这极大地简化了代码，并从根本上解决了由异步加载导致的脚本不稳定性问题，对于需要应对不可预测的 Web 环境的 AI Agent 来说至关重要。
• 强大的工具链：内置了 Codegen（录制生成代码）、Playwright Inspector（交互式调试）和 Trace Viewer（全链路追踪）等强大的开发工具，显著提升了开发和调试效率。
• 面向现代 Web 的鲁棒性：对 Shadow DOM、iframes 等现代 Web 应用的复杂结构提供了无缝支持，使得与这些元素的交互变得简单直接。

AI Agent 场景下为什么需要 Browser Tool Sandbox

应用场景

当下，AI Agent 的能力类比人类，所以任何一个人类用户能在浏览器中完成的事情，理论上都可以通过 Browser Tool 赋予 AI Agent 来完成。但是有很多网站、企业内部系统和在线服务都是为人类用户设计的图形界面，它们并没有提供专门为机器准备的 API 接口。所以，Browser Tool 可以使得 AI Agent 能够直接操作这些为人类设计的界面，从而极大地扩展了其能力范围。比如：

• 信息获取与研究：
  • 网页抓取与数据提取：从复杂的动态网站中提取数据，例如收集产品评论、监控电商价格、从目录中提取联系方式等。
  • 市场与竞品分析：自动访问竞争对手的网站，收集产品信息、定价策略和客户评价，并进行汇总分析。
  • 综合研究：跨多个信息源进行全面的网络研究，并综合信息生成报告或摘要。
  • 等等
• 工作流程自动化：
  • 表单填写与提交：自动登录网站、填写复杂的在线表单并提交。
  • 潜在客户挖掘：自动从 LinkedIn 等平台筛选和收集潜在客户信息，并整合到 CRM 或表格中。
  • 电子商务自动化管理：自动化处理订单、更新商品信息、监控库存等。
  • 等等
• 个人与工作协同：
  • 差旅规划与预订： 根据要求自动搜索并预订机票、酒店。
  • 日程与事务管理： 访问在线日历，根据邮件或新闻内容安排会议。
  • 数据整理： 访问在线表格，并根据指令进行数据更新和格式调整。
  • 等等
• 社交媒体与内容互动：
  • 内容发布与互动： 自动登录社交媒体账户（如 Weibo、LinkedIn、Twitter），发布帖子或与其他帖子进行互动。
  • 等等

安全隐患

然而，AI Agent 的强大自主性同时也带来了很多安全问题：

参考：https://dev.to/polozhevets/are-browser-ai-agents-a-security-time-bomb-unpacking-the-risks-and-how-to-stay-safe-55fihttps://www.imperva.com/blog/the-rise-of-agentic-ai-uncovering-security-risks-in-ai-web-agents

• 提示词注入与任务劫持 (Prompt Injection & Task Hijacking) ：攻击者可以将恶意指令嵌入到看似无害的网页内容中，例如产品评论、论坛帖子，甚至是隐藏的 HTML
  标签里。当 AI Agent 为了理解页面内容而解析这些文本时，会无意中执行攻击者的指令。有研究论文指出：仅仅通过让 Agent 读取一个包含恶意内容的 GitHub issue 页面，就成功诱使其泄露了用户的凭证 。
• 凭证与数据窃取 (Credential & Data Exfiltration)：由于 AI Agent 在使用 Browser Tool 时可能会需要登录，所以它天然地能够访问到浏览器状态中的所有敏感信息。一个被劫持的 AI Agent 可以被指令去定位并窃取会话 cookies、本地存储（Local Storage）中的数据，乃至浏览器自动填充的密码。开源框架 Browser Use 最近被披露的一个 CVE 漏洞，就恰恰是这种凭证窃取风险的真实写照。
• OAuth 授权和钓鱼诱骗：AI Agent 同样可能被钓鱼网站或恶意的 OAuth 授权流程所欺骗。安全公司 SquareX 的研究显示，一个 AI Agent 在被要求注册文件共享工具时，盲目地批准了一个恶意应用的 OAuth 请求，授予了攻击者完全访问用户电子邮件的权限。整个过程中，AI Agent 忽略了多个对于人类而言极为明显的危险信号。

综上所述，在沙箱环境（Sandbox）中运行 Browser Tool 或者 Browser Use Agent 就变的至关重要，只有在沙箱（Sandbox）提供的受控环境中，我们才有可能安全地释放 AI Agent 的潜力。

Sandbox 环境有效避免安全隐患

众所周知，沙箱环境（Sandbox）最基本的作用是充当一个与你的主机系统、主程序完全隔离的、受控的环境 。你可以把它想象成将 Browser Agent 放置在一个行为受到严格限制的安全房间里。所以，即使 AI Agent 被欺骗而"失控"，沙箱环境（Sandbox）也能将"爆炸半径"控制在内部，确保损害仅限于这个临时的、可随时销毁的环境。

• 防止系统级损害： 即使攻击者成功注入恶意提示并劫持了 AI Agent，沙箱环境（Sandbox）也能充当一道坚实的屏障。被入侵的 AI Agent 被困在这个隔离环境中，无法对你的真实计算机执行破坏性操作，例如删除个人文件、安装恶意软件或更改关键系统配置。
• 限制资源访问： 沙箱环境（Sandbox）的特点就是隔离，网络隔离，资源隔离，所以可以阻止 AI Agent 访问其指定范围之外的资源。例如，当发现AI Agent被劫持后，一个合格的沙箱环境（Sandbox）可以快速禁止被劫持 AI Agent 访问外部服务。或者快速关闭沙箱环境（Sandbox），直接泯灭掉被劫持的 AI Agent 以及所有数据。本质就是阻止数据外泄。

手把手带你构建 Browser Tool Sandbox

在带大家实操构建 Browser Tool Sandbox 前，我对整体的架构和涉及到的组件，以及基于函数计算 FC 构建的 Browser Tool Sandbox 的优势先作以解释，让大家有初步的概念。

FC Browser Tool Sandbox 架构

核心组件解释：

• Xvfb (X Virtual Framebuffer)：作用是在 Linux 中创建一个虚拟的显示器，可以让图形程序可以在没有物理显示器的服务器上运行，所有图形输出都在内存中完成，不需要真实屏幕。
• VNC (Virtual Network Computing)：远程桌面控制技术，允许你通过网络查看和控制另一台计算机的桌面。
• RFB (Remote Framebuffer Protocol)：远程帧缓冲协议，是 VNC 的底层通信协议。定义了如何传输屏幕图像和键盘鼠标事件，本质上就是 VNC 的"语言规范"。
• x11vnc：一个 VNC 服务器程序，专门用于共享 X11显示。可以把真实的或虚拟的 X11桌面通过 VNC 协议分享出去。
• x11 (x Window System)：Linux/Unix 系统的图形显示系统，负责管理窗口、处理鼠标键盘输入、绘制图形界面。
• Fluxbox：轻量级的窗口管理器，为 X11提供基本的窗口管理功能。
• 显示编号（Display Number） ：X 服务器的显示编号
  • :0 = 第一个 X 服务器（通常是你的物理显示器）
  • :1 = 第二个 X 服务器（可能是另一个物理显示器或虚拟显示器）
  • :2 = 第三个 X 服务器，以此类推

FC Browser Tool Sandbox 优势

别看上面涉及到那么多的组件和概念，其实我们都已经封装好了，你只需要一键，就可以把 Browser Tool Sandbox 构建出来并使用。除了快捷的构建以外，基于函数计算 FC 构建的 Browser Tool Sandbox 还有其他的一些优势和特性：

• 安全性：这个是首当其冲的优势，因为函数计算 FC 可以提供完全隔离的运行环境，所以可以杜绝 AI Agent 操作浏览器时的安全隐患，上文中已经做过解释。
• 会话管理：实现浏览器页签级别的会话管理，包括自动保存会话状态，支持断线后的会话恢复，自动清理过期会话等能力。
• 内置录制/回放：支持每个 VNC 会话自动录制。
• 可观测：支持连统计（活跃 VNC 连接数）、资源使用（CPU、内存、磁盘）、性能（API 响应时间、错误率等）三个维度的可观测。
• 启动速度：函数计算 FC 实例的百毫秒级拉起速度配合预下载的浏览器驱动，大幅减少启动时间。
• 资源管理：基于函数计算 FC，可以针对不同的浏览器访问内容，构建不同规格的实例运行，做到精细化管控Browser Tool Sandbox 资源。
• 并发管理：支持多个浏览器会话同时运行，可智能管理 VNC 连接池。

FC Browser Tool Sandbox 构建实操

部署

登录阿里云账号，打开 FunctionAI 中的 Browser Tool Sandbox 模板，点击立即部署。

• 项目名称：根据需求自行输入。
• 地域：选择对应的地域。
• 服务角色 ARN：选择 AliyunFcDeafultRole。
• 实例名称，根据需求自行输入。

点击部署项目按钮，等待部署。

几分钟后，整个项目即可部署完成。

整个项目包含3个函数：

• browserTool：包含了上述架构中的虚拟显示层、VNC 服务层、协议代理层内容。
• mcp：包含了上述架构中的浏览器自动化层内容。
• vncclient：包含了 NoVNC 客户端。

使用 NoVNC 客户端

选择 nvcclient 函数，进入触发器页签，可以看到访问 NoVNC 客户端的公网地址和内网地址。

但是为了安全考虑，我们提供的默认域名不能直接在浏览器中访问，所以需要配合云原生 API 网关或者绑定自定义域名来使用。

进入配置 页签，找到最下方的自定义域名 ，点击编辑进行配置。

具体的配置方法可参见文档：配置自定义域名

当配置完自定义域名后可以看到该函数有变更，点击右上角部署按钮进行部署。

部署成功后，使用浏览器访问你绑定的自定义域名，便可以打开 NoVNC 客户端。

点击左侧配置按钮，在 WebSocket 中配置协议代理层的地址。

• 主机：进入 browserTool 函数，点击触发器页签，负责公网访问地址。这里因为是 WS 协议，所以不需要 http://
• 端口：80
• 路径：ws/livestream

配置完后点击连接，便可以使 NoVNC 通过 RBF 协议连接到 x11VNC 服务了。

这里因为没有对浏览器做任何请求，所以看到的是黑屏，后续我们通过 Playwright 对浏览器做操作时，通过 NoVNC 就可以看到内容了。

使用 Playwright MCP

文本中我使用 DeepChat 这个客户端来演示如何使用 Playwright MCP 操作浏览器。大家也可以使用其他的 MCP Client，配置 MCP 服务的方式都是一致的。

进入 DeepChat 的 MCP 服务设置界面，点击新增按钮。

• 服务器名称：根据需求自行输入。
• 服务器类型：选择服务器发送事件（SSE）。
• 基础 URL：进入 mcp 函数，点击服务测试 页签，可以看到访问地址。
• 自动授权：选择全部。
• 自定义请求头：因为默认有 Token，所以需要配置 Authorization Header。同样在服务测试 页签可以找到 Token。
  • Content-Type=application/json
  • Authorization=Bearer [Token]

点击提交并开启该 MCP 服务后，可以看到我们提供的21个工具。

回到对话界面，开启 Playwright MCP 服务。

我们可以输入"使用浏览器，在 Bing 中搜索函数计算，列出前3条内容"。

此时，开始调用 Playwright MCP，对浏览器进行操作。

此时打开 NoVNC 客户端，可以看到界面中显示了浏览器，并访问了 Bing。

然后开始使用 browser_type 工具，也就是开始进行搜索。

此时在 NoVNC 客户端可以看到在搜索框输入了函数计算，并进行了搜索。

最后显示出了结果。

大家可以使用提供的其他工具玩出更多花样。

使用 Browser Use 操作

使用 Browser Use 框架稍微需要点编程能力。在熟悉的 Code IDE 中使用如下实例代码：

from browser_use import Agent, BrowserSession
from browser_use.llm import ChatDeepSeek
from browser_use.browser import BrowserProfile
from playwright.async_api import async_playwright
from dotenv import load_dotenv
import os
import asyncio

load_dotenv()

async def main():
    browser_session_wss_url = "ws://[browserTool函数的连接地址]/ws/automation"
    browser_session = BrowserSession(cdp_url=browser_session_wss_url, browser_profile=BrowserProfile(
        headless=False,
        user_agent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36",
        timeout= 3000000,
        keep_alive=True,

    ))
    # 需要修改DeepSeek的sk，如果您使用其他模型，请自行修改
    llm = ChatDeepSeek(api_key="sk-your-deepseek-sk")

    agent = Agent(
        task="请访问 https://www.aliyun.com/product/list 并分析一下阿里云目前都提供了哪些产品",
        llm=llm,
        browser_session=browser_session,
        use_vision=True
    )
    result = await agent.run()
    print(result)


if __name__ == "__main__":
    asyncio.run(main())

• browser_session_wss_url 这个属性的值从 browserTool 函数的触发器页签中获取，协议需要改为 ws://。

使用 Puppeteer 操作

示例代码：

const puppeteer = require('puppeteer-core');

const browser = await puppeteer.connect({
  browserWSEndpoint: 'ws://[browserTool函数的连接地址]/ws/automation/'
});

const page = await browser.newPage();
await page.goto('https://example.com');
await page.screenshot({ path: 'screenshot.png' });
await browser.close();

使用 REST API 操作

• 打开特定页面：

curl -X POST http://[browserTool函数的连接地址]/navigate \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com", "wait_for":{"timeout": 3000}}'
● 截图：

• 截图：

curl-XPOSThttp://[browserTool函数的连接地址]/screenshot\
-H"Content-Type: application/json"\
-d'{"url": "https://example.com"}'\
--outputscreenshot.png

• 生成 PDF：

curl-XPOSThttp://[browserTool函数的连接地址]/pdf\
-H"Content-Type: application/json"\
-d'{"url": "https://example.com", "options": {"format": "A4"}}'\
--outputdocument.pdf

• 提取内容：

curl-XPOSThttp://[browserTool函数的连接地址]/content\
-H"Content-Type: application/json"\
-d'{"url": "https://example.com", "selector": "h1"}'

• 录制：

# 获取录制文件列表
curlhttp://localhost:3000/api/vnc/recordings
# 下载录制文件
curlhttp://localhost:3000/api/vnc/recordings/filename.fbs
# 删除录制文件
curl-XDELETEhttp://localhost:3000/api/vnc/recordings/filename.fbs

会话管理

Context API：

# 创建 Context
curl-XPOSThttp://[browserTool函数的连接地址]/contexts\
-H"Content-Type: application/json"\
-d'{
"name":"test-session",
"browser":"chromium"
}'
# 使用 Context 进行操作
curl-XPOSThttp://[browserTool函数的连接地址]/contexts/navigate\
-H"Content-Type: application/json"\
-d'{
"context_id":"context-id",
"url":"https://example.com"
}'

更多内容关注 Serverless 微信公众号（ID：serverlessdevs），汇集 Serverless 技术最全内容，定期举办 Serverless 活动、直播，用户最佳实践。