LLM讀不懂網頁？試試把DOM樹“翻譯”成它能懂的語言

想讓AI Agent自動填表、抓數據，結果它對著截圖一臉懵，或者被幾千行HTML代碼直接搞暈？

問題不在LLM，在于你喂給它的“食物”不對。截圖信息密度太低，原始HTML噪音又太多。我們需要一個“翻譯官”，把網頁翻譯成LLM能高效理解的結構化語言。

這就是 Puppeteer Accessibility Tree MCP Server 干的事。它不是又一個瀏覽器自動化工具，而是一個專門為LLM設計的網頁結構翻譯器。

核心原理：從“看見”到“理解”

傳統方案要么給LLM一張截圖（視覺模式），要么給它原始HTML。前者依賴多模態能力，成本高、精度有限；后者Token消耗巨大，且充斥著<div>、<span>等對理解任務毫無幫助的標簽噪音。

這個MCP Server走了第三條路：提取網頁的可訪問性樹（Accessibility Tree）。

你可以把它理解為瀏覽器內部為屏幕閱讀器等輔助技術構建的“網頁骨架”。它只保留有語義的節點（如按鈕、輸入框、標題、鏈接），并以清晰的父子層級關系組織起來。

技術棧一目了然：

1. Puppeteer 控制無頭瀏覽器，打開目標網頁。
2. 通過Chrome DevTools Protocol (CDP) 調用 Accessibility.getFullAXTree 命令。
3. 將獲取到的、原生的可訪問性樹數據，進行過濾、簡化和格式化。
4. 輸出一份精煉的、JSON格式的“網頁語義地圖”，直接作為上下文喂給LLM。

// 核心邏輯示意（非完整代碼）
const client = await page.target().createCDPSession();
const { nodes } = await client.send('Accessibility.getFullAXTree');

// 過濾和簡化：只保留關鍵信息
const simplifiedTree = nodes.map(node => ({
  role: node.role.value, // 如 'button', 'textbox', 'heading'
  name: node.name.value, // 如 '登錄', '搜索', '標題文本'
  value: node.value?.value,
  description: node.description?.value,
  states: node.states, // 如 ['focused', 'disabled']
  children: node.childIds // 保留層級關系
}));

輸出給LLM的，可能是這樣的結構：

{
  "role": "WebArea",
  "name": "登錄頁面",
  "children": [
    {
      "role": "textbox",
      "name": "郵箱地址",
      "states": ["required"]
    },
    {
      "role": "textbox",
      "name": "密碼",
      "states": ["required"]
    },
    {
      "role": "button",
      "name": "登錄"
    }
  ]
}

技術價值：為Agent自動化“降本增效”

這套方案帶來的優勢是實實在在的：

1. Token成本斷崖式下降
一份復雜的電商商品頁，原始HTML可能有數萬Token。而經過提煉的可訪問性樹，可能只需要幾百Token就能精準描述“有一個價格篩選滑塊、一個‘加入購物車’按鈕、一個商品評論列表”。這直接降低了API調用成本，讓Agent能處理更長的任務流。

2. 任務理解精度飆升
LLM拿到的是清晰的“角色-名稱”語義對。當你說“點擊登錄按鈕”時，它不再需要從一堆<div class="btn btn-primary">中猜測，而是直接定位到 role: "button", name: "登錄" 的節點。這極大減少了因選擇器錯誤導致的自動化失敗。

3. 行動指令明確
結合Puppeteer的 page.click() 或 page.type()，Agent可以基于可訪問性樹中的節點信息，直接生成精確的定位和操作指令。整個流程是：理解結構 -> 決策 -> 生成代碼 -> 執行，形成閉環。

實戰案例：自動化信息抽取

假設你要做一個“比價Agent”，自動從三個電商網站抓取同一款手機的價格。

傳統截圖+OCR方案：

1. Agent訪問頁面，截圖。
2. 調用多模態模型識別“價格”區域（可能識別錯誤）。
3. 用OCR提取數字（可能識別錯誤）。
4. 流程長，錯誤率高，成本高。

使用本MCP Server的方案：

1. Agent調用MCP Server的工具，獲取三個頁面的可訪問性樹。
2. LLM分析樹結構，在每個頁面中精準定位 role: "text", name: "價格" 或類似語義的節點。
3. 直接提取節點的 value 或 name 中的價格數字。
4. 一次調用，結構化輸出，準確率接近100%。

另一個例子是自動化表單填寫。Agent拿到表單的可訪問性樹后，能清晰地知道需要填寫“姓名”、“郵箱”、“地址”等字段，并對應到具體的輸入框。它甚至能識別出哪些字段是“必填”（通過states屬性），從而生成更可靠的填寫策略。

“視覺模式”：是備胎，也是王牌

這個Server提供了一個可選的“視覺模式”——即在提取可訪問性樹的同時，也生成頁面截圖。

在90%的場景下，你不需要它。 結構化數據已經足夠。

但在10%的復雜場景下，它是救命稻草。 比如：

• 驗證碼識別：需要“看”圖片內容。
• 復雜圖表理解：需要“看”柱狀圖的趨勢、餅圖的比例。
• 非標準UI組件：某些高度定制化的交互組件，其可訪問性信息可能不完整，需要視覺輔助判斷。

這種“結構化為主，視覺為輔”的混合模式，是一個非常聰明的商業定位。它把核心功能（結構化翻譯）做到極致輕量和高效，同時為高階需求保留了擴展性。

作為開發范例的啟示

如果你想開發自己的MCP Server，這個項目是一個絕佳的參考：

1. 明確核心價值：它不追求大而全，而是解決“為LLM提供網頁上下文”這一個具體痛點。
2. 選擇合適的技術：Puppeteer + CDP是獲取瀏覽器內部數據的最直接路徑。
3. 做好數據預處理：原始數據往往不能直接用，過濾和格式化是提升體驗的關鍵。
4. 設計清晰的工具接口：對外暴露的工具（如 getAccessibilityTree, takeScreenshot）功能單一、語義明確。

下一步行動

1. 親自試試：在GitHub上找到這個項目（搜索 puppeteer-accessibility-mcp 或類似關鍵詞），按照README在本地跑起來。用它去“讀”幾個你常去的網站，看看輸出的結構是什么樣。
2. 改造你的Agent：如果你正在開發一個需要網頁交互的Agent，嘗試用它替換掉原來的截圖或HTML解析模塊，對比一下Token消耗和任務成功率。
3. 動手開發：以此為模板，思考你常用的其他數據源（比如某個API、某個數據庫），能否也封裝成一個為LLM優化的MCP Server。為LLM設計數據接口，是下一代工具開發的核心范式。

別再讓LLM“猜”網頁了。給它一份清晰的“地圖”，它的能力會超乎你想象。