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

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

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

這就是 Puppeteer Accessibility Tree MCP Server 干的事。它不是又一個瀏覽器自動化工具，而是一個專門為LLM設(shè)計的網(wǎng)頁結(jié)構(gòu)翻譯器。

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

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

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

你可以把它理解為瀏覽器內(nèi)部為屏幕閱讀器等輔助技術(shù)構(gòu)建的“網(wǎng)頁骨架”。它只保留有語義的節(jié)點（如按鈕、輸入框、標題、鏈接），并以清晰的父子層級關(guān)系組織起來。

技術(shù)棧一目了然：

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

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

// 過濾和簡化：只保留關(guān)鍵信息
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 // 保留層級關(guān)系
}));

輸出給LLM的，可能是這樣的結(jié)構(gòu)：

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

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

這套方案帶來的優(yōu)勢是實實在在的：

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

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

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

實戰(zhàn)案例：自動化信息抽取

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

傳統(tǒng)截圖+OCR方案：

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

使用本MCP Server的方案：

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

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

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

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

在90%的場景下，你不需要它。 結(jié)構(gòu)化數(shù)據(jù)已經(jīng)足夠。

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

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

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

作為開發(fā)范例的啟示

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

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

下一步行動

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

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