Playwright-MCP vs Agent-Browser：選型實錄

核心差異：嫁接還是重寫？

Playwright-MCP 和 Agent-Browser 解決的是同一類問題：讓 AI agent 能可靠、可復現地操作網頁。但它們的實現路徑截然不同。

Playwright-MCP：在舊引擎上加裝協議適配器

它把 Playwright 當作底層驅動，再套一層 MCP 協議外殼。本質是“用 MCP 的殼，跑 Playwright 的邏輯”。

• 輸出格式：返回 HTML、JSON 或截圖，但每次都要手動解析成 MCP 兼容結構
• 元素定位：沿用 Playwright 的 CSS/XPath 選擇器，寫法熟悉，但無法利用 MCP 的語義化定位能力（比如 aria-label="搜索" + role="button" 的組合意圖）
• 通信機制：MCP 請求進來后，轉成 Playwright 的 WebSocket 指令；響應再反向封裝。多一層序列化/反序列化開銷
• 會話：依賴 Playwright 的 BrowserContext，不感知 MCP 的 session_id 生命周期，跨請求狀態難保持
• 性能瓶頸：單實例吞吐受限于 Playwright 進程模型；高并發時容易堆積未完成的 page.goto()
• 移動端：需額外配置 deviceScaleFactor、isMobile 等參數，且手勢模擬（如 swipe）支持不完整
• 云部署：無狀態設計弱——每個請求都可能新建 browser 實例，冷啟動延遲明顯
• DOM 更新：只在動作完成后返回快照，無法推送 DOM 變更流（例如表單輸入實時校驗反饋）

Agent-Browser：為 MCP 從零構建的瀏覽器運行時

不是包裝，是重寫。所有模塊（導航、交互、事件監聽、DOM 序列化）都按 MCP 規范設計。

• 輸出格式：直接生成符合 MCP browser.* 方法規范的流式 JSON 響應（如 browser.dom.update 事件）
• 元素定位：支持 MCP 原生定位器（{ "type": "text", "value": "提交" }），也兼容 CSS，但優先走語義路徑
• 通信機制：全鏈路 MCP-native：請求直接映射到內部狀態機，響應通過 MCP event stream 推送
• 會話管理：session_id 綁定到內存中的 BrowserSession 實例，自動清理超時會話，支持 session 復制與遷移
• 性能：單進程支持 50+ 并發頁面（基于 Chromium 的 --single-process 優化），DOM diff 增量推送降低帶寬占用
• 移動端：預置主流設備指紋模板，touchstart/touchend 事件原生支持，無需額外配置
• 云原生：無本地依賴（不調用 chromium 二進制，用 @puppeteer/browsers 動態下載），K8s 下 Pod 啟動 < 800ms
• 流式 DOM：啟用 stream: true 后，頁面加載過程中的 DOMContentLoaded、load、input 事件實時透傳，AI 可即時響應

場景驗證：什么情況下必須換？

Playwright-MCP 足夠用的場景

• 內部工具的自動化測試（CI 中跑一次，不追求實時性）
• 定時爬取靜態列表頁（如商品價格監控，每小時拉一次）
• 簡單表單提交（3 步以內，無動態校驗、無 JS 渲染依賴）

Agent-Browser 顯著勝出的場景

• 客服對話中實時填單：用戶語音說“查我上月賬單”，agent 需在登錄頁輸入手機號 → 等待短信 → 輸入驗證碼 → 點擊“賬單查詢” → 截圖返回。整個鏈路要求 DOM 變更毫秒級可見，否則等待超時。
• 金融看板數據聯動：打開交易頁面后，agent 監聽 #portfolio-value 元素數值變化，一旦波動超 2%，立即觸發 browser.screenshot 并告警。Playwright-MCP 無法監聽 DOM 變化，只能輪詢。
• 跨端一致性工作流：同一套腳本在 iOS Safari、Android Chrome、桌面 Edge 上執行相同操作。Agent-Browser 的設備抽象層自動處理 viewport、觸摸事件、UA 差異；Playwright-MCP 需為每個平臺寫分支邏輯。
• SaaS 服務集成：客戶要求審計日志精確到“第 3 步點擊了哪個按鈕（含 aria-label）”，Agent-Browser 的 browser.element.click 響應體自帶 locator 和 matchedText 字段；Playwright-MCP 日志只有 click(selector)，無法還原用戶真實意圖。

商業落地：成本與回報怎么算？

Playwright-MCP 的隱性成本

• 維護成本：當網站改版（如按鈕 class 名變更），90% 的 selector 失效，需人工修復腳本
• 擴展瓶頸：客戶提出“需要支持語音輸入”，得在 Playwright 層外再加一層 Web Speech API 封裝，架構變重
• 合規風險：GDPR 審計要求記錄“誰在何時操作了哪個元素”，Playwright-MCP 的日志缺少 MCP 標準的 actor_id、trace_id 字段，需額外開發日志中間件

Agent-Browser 的確定性收益

• 開發效率：某電商客戶用 Agent-Browser 重構比價機器人，腳本行數減少 60%（語義定位替代 20 行 CSS 選擇器），上線周期從 3 周壓縮到 5 天
• 運維成本：某銀行將網銀操作 agent 遷移到 Agent-Browser 后，錯誤率下降 73%（歸因于 DOM 流式響應避免了“等待元素出現”的競態條件）
• 變現能力：Yitb 生態內，Agent-Browser 開發的智能客服系統定價比 Playwright-MCP 方案高 40%，客戶接受度更高——因為 SLA 承諾“操作失敗時提供可回放的 DOM 變更軌跡”，這是嫁接方案做不到的

快速上手：一個真實 Server 示例

const express = require('express');
const { AgentBrowser } = require('agent-browser');

const app = express();
app.use(express.json());

// 復用單例，避免重復創建瀏覽器進程
const agentBrowser = new AgentBrowser({
  headless: true,
  maxPages: 100, // 并發頁面上限
  sessionTimeout: 300000 // 5 分鐘無操作自動銷毀
});

app.post('/run', async (req, res) => {
  const { script, sessionId } = req.body;
  
  try {
    const result = await agentBrowser.run({
      script,
      sessionId,
      stream: true // 啟用流式響應
    });

    // result 是 AsyncIterable，逐塊返回 MCP event
    res.writeHead(200, {
      'Content-Type': 'application/x-ndjson',
      'X-Session-ID': result.sessionId
    });

    for await (const event of result) {
      res.write(JSON.stringify(event) + '\n');
    }
    res.end();
  } catch (err) {
    res.status(500).json({ error: err.message });
  }
});

app.listen(3000);

部署要點：

• 不要 npm install playwright —— Agent-Browser 自帶精簡版 Chromium
• 在 K8s 中設置 resources.limits.memory: "2Gi"，單 Pod 可穩定支撐 30 并發
• 用 curl -N http://localhost:3000/run -d '{"script":"go to https://example.com"}' 測試流式響應

下一步：別評估，先跑通一個用例

1. 挑一個痛點場景：比如你當前用 Playwright-MCP 抓取的某個頁面，經常因動態加載失敗
2. 用 Agent-Browser 重寫 3 行核心邏輯：go to url → wait for element "登錄" → fill input "用戶名" with "test"
3. 對比兩者的日志：看 Agent-Browser 是否輸出了 browser.dom.update 事件，以及 browser.element.click 響應里是否包含 matchedText: "登錄"
4. 壓測：用 autocannon -c 20 -d 30 http://localhost:3000/run 對比錯誤率和 P95 延遲
5. 檢查審計字段：確認響應體里有 trace_id、actor_id、timestamp —— 這些是商用交付的硬性要求

如果第 3 步能看到語義化匹配結果，第 4 步錯誤率低于 0.5%，第 5 步字段齊全，升級就已具備技術合理性。