基于函數計算FC構建 Browser Tool Sandbox 詳解與實操

瀏覽器自動化的前世今生

從 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-55fi https://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 活動、直播，用戶最佳實踐。

posted @ 2025-09-03 15:03 Serverless社區閱讀(64) 評論(0) 收藏舉報

刷新頁面返回頂部

Serverless社區