AI-Chain

把 AI Agent 放進網頁:Page Agent 如何用 DOM 讓自然語言直接操作 UI

Page Agent 是一個以 JavaScript 執行在網頁內的開源 GUI Agent。本文從 DOM 驅動、LLM 連接、最小整合範例與安全邊界切入,拆解它如何把「請幫我完成這個網頁操作」轉成可執行的 UI 行動。

分享:
把 AI Agent 放進網頁:Page Agent 如何用 DOM 讓自然語言直接操作 UI

把 AI Agent 放進網頁:Page Agent 如何用 DOM 讓自然語言直接操作 UI

當我們說「讓 AI 操作瀏覽器」,直覺通常會想到瀏覽器擴充功能、Playwright、Selenium,或需要截圖理解畫面的多模態模型。但另一條路是:把 Agent 直接放進目前正在執行的網頁,讓它讀取 DOM、理解互動元素,再用自然語言完成操作。

Page Agent 就是沿著這條路設計的開源 JavaScript GUI Agent。它的官方定位是「living in your webpage」:透過一段腳本,讓任何網頁擁有自己的 AI Agent。本文不只介紹功能,也會從實作角度拆解它的整合方式、適用場景與不能忽略的安全限制。

一、它解決的不是「看懂畫面」,而是「控制網頁介面」

傳統瀏覽器自動化常把問題拆成兩層:先取得頁面狀態,再透過選擇器或座標觸發操作。這在固定流程中很可靠,但當使用者用自然語言描述任務,例如「把這張訂單改成待出貨,然後填入備註」,系統還需要一層把意圖對應到介面元素。

Page Agent 的做法是把這一層直接放在頁面裡:

  1. Agent 取得目前網頁可互動的結構。
  2. LLM 根據任務與頁面資訊決定下一個動作。
  3. 頁面控制器對 DOM 元素執行點擊、輸入或其他 UI 操作。
  4. Agent 觀察結果後,繼續或結束任務。

官方 README 特別強調它採用文字型 DOM 操作,不需要截圖、多模態 LLM 或特殊權限。這讓它更像一個「嵌入式 UI 控制層」,而不是遠端操控整個瀏覽器的黑盒子。

二、從套件結構看 Page Agent 的分工

目前 repository 使用 workspace 管理多個套件,核心可分成幾個部分:

  • page-agent:對外提供 PageAgent 類別與整合入口。
  • @page-agent/core:處理 Agent 核心流程。
  • @page-agent/page-controller:負責頁面與 DOM 控制。
  • @page-agent/llms:負責 LLM 呼叫、工具呼叫與重試。
  • @page-agent/ui:提供頁面上的互動面板。
  • @page-agent/mcp 與 @page-agent/extension:分別支援 MCP Server 與跨頁面的 Chrome Extension 能力。

從公開原始碼可以看到,PageAgent 建構時會建立 PageController,再把它交給核心 Agent;同時初始化頁面上的 Panel。這種組合方式很適合「把 Agent 當成前端元件」使用:控制器負責做事,核心負責推理,面板則負責讓人與 Agent 協作。

LLM 層則要求至少提供 baseURL 與 model。官方實作預設使用 OpenAI-compatible client,並提供可重試的呼叫流程;這表示它不把模型供應商硬編碼成單一服務,而是把相容 API 的設定交給整合者。

三、最小整合:一段腳本讓頁面出現 Agent

最快的試用方式,是直接載入官方提供的 IIFE bundle:

<script
  src="https://cdn.jsdelivr.net/npm/[email protected]/dist/iife/page-agent.demo.js"
  crossorigin="anonymous"
></script>

官方 README 將這個 Demo CDN 定位為技術評估用途。若要在自己的產品中正式整合,則可改用 npm:

npm install page-agent
import { PageAgent } from 'page-agent'

const agent = new PageAgent({
  model: 'your-model',
  baseURL: 'https://your-openai-compatible-endpoint/v1',
  apiKey: 'your-client-side-credential',
  language: 'zh-TW',
})

await agent.execute('開啟訂單頁面,找到最近一筆訂單並展開詳細資料')

這段程式的重點不是特定模型名稱,而是 Page Agent 的整合邊界:頁面負責提供 UI,PageAgent 負責建立控制器與推理流程,LLM endpoint 則由應用程式配置。

四、為什麼 DOM 驅動值得注意?

1. 不必把每一步都寫死

固定選擇器適合穩定流程,但產品 UI 一改版就可能需要同步修改腳本。自然語言任務則把「想做什麼」與「元素目前在哪裡」分開,讓 Agent 根據當下頁面狀態做決策。

2. 不一定需要多模態模型

Page Agent 官方主打文字型 DOM 操作。對表單、按鈕、選單、後台管理介面等結構化 UI,這種做法可以避免每一步都傳送截圖,也降低對視覺模型與瀏覽器權限的依賴。

3. 更容易嵌入產品體驗

它不是只供內部測試的外部自動化腳本,也可以變成 SaaS 產品中的 AI Copilot。例如在 ERP、CRM 或管理後台中,讓使用者用一句話完成原本需要多次點擊的流程。

不過,DOM 驅動並不代表所有網頁都能可靠自動化。畫布型介面、需要視覺判斷的元件、封閉式 iframe、複雜權限流程與高度動態的頁面,都可能需要額外設計或不同工具配合。

五、三個適合落地的使用場景

SaaS 產品內建 Copilot

產品團隊可以把 Page Agent 放在自己的管理介面裡,讓使用者直接下達「建立一個本月有效的折扣方案」或「找出逾期帳款並匯出」等指令。Agent 操作的仍是既有 UI,因此不一定需要先重寫後端 API。

智慧表單填寫

對 ERP、CRM、客服系統或申請流程來說,使用者常知道目標,卻不想逐欄尋找欄位。Agent 可以把自然語言轉成表單操作,尤其適合欄位多、流程長但規則相對清楚的內部系統。

無障礙與自然語言操作

官方 README 也列出 accessibility 作為使用案例。對部分使用者而言,以語音或自然語言描述「下一步要做什麼」,可能比逐一定位網頁元件更直觀。但正式產品仍應搭配清楚的操作預覽、確認機制與可復原設計。

六、模型與權限:最容易被忽略的工程問題

「把 Agent 放進網頁」很方便,但也意味著模型呼叫與頁面操作的邊界更靠近使用者端。整合時至少要處理以下問題:

  • 不要把高權限長期憑證直接硬編碼在前端。 README 的範例使用的是示意值;正式環境應評估短效憑證、後端代理或受限權限。
  • 將可操作範圍限制在必要頁面。 不要讓一般任務可以任意讀取帳務、管理員設定或其他租戶資料。
  • 對不可逆動作加入確認。 刪除、付款、送出申請或修改權限前,應顯示即將執行的動作並要求使用者確認。
  • 保留操作紀錄。 需要知道 Agent 看到了什麼、執行了什麼、在哪一步失敗,才能除錯與稽核。
  • 把頁面內容視為不可信輸入。 網頁中的文字、第三方內容與使用者可編輯欄位都可能影響模型判斷,不能只依賴提示詞要求 Agent 永遠做對事。

這些並不是 Page Agent 特有的缺陷,而是所有會替使用者操作 UI 的 Agent 都必須面對的產品責任。

七、Page Agent 與瀏覽器自動化框架如何分工?

Page Agent 的官方定位是 client-side web enhancement,而不是 server-side automation。這句話很重要:它適合把智慧操作能力嵌入現有網頁,不等於要取代 Playwright、Selenium 或完整的瀏覽器測試基礎設施。

可以用下列方式分工:

  • 產品內的自然語言操作: 優先評估 Page Agent。
  • 可重現的端對端測試: 使用明確斷言與固定流程的測試框架。
  • 跨頁面與瀏覽器外部控制: 評估 Page Agent 的 Chrome Extension 或 MCP Server Beta,並重新檢查權限。
  • 大量背景任務與排程: 使用後端工作佇列及 API;不要把前端 Agent 當成無限可靠的批次執行器。

換句話說,Page Agent 的價值不在於「所有自動化都改用 LLM」,而在於補上自然語言與現有 UI 之間的最後一哩。

八、導入前的實作檢查清單

在正式接入前,可以先做一個最小垂直切片:

  1. 選一個低風險、可復原的流程,例如查詢資料或填寫草稿。
  2. 使用測試帳號與最小權限模型 endpoint。
  3. 記錄 Agent 可見的 DOM 範圍與實際操作結果。
  4. 測試頁面改版、空資料、錯誤訊息與權限不足等情境。
  5. 為高風險動作加入人工確認。
  6. 比較自然語言操作與既有按鈕流程的完成率、延遲及除錯成本。

如果一個任務無法清楚定義「成功」,或失敗後無法安全回復,就不應直接交給 Agent 全自動執行。

九、結語:把 Agent 放進 UI,不代表把控制權交出去

Page Agent 的想法很直接:把一個可配置 LLM、DOM 控制器與頁面互動面板組合起來,讓網頁從被動介面變成可以理解自然語言的操作環境。它的技術亮點是輕量的 in-page JavaScript 整合、文字型 DOM 操作,以及對多種 LLM endpoint 的彈性。

但真正能否落地,關鍵不只是 Agent 能不能點到按鈕,而是產品是否建立了權限隔離、操作確認、可觀測性與失敗復原。把 Page Agent 當成一個前端能力層,而不是無限制的自動化黑盒,才是比較務實的導入方式。

官方查證來源

查證時間:2026-09-17。本文的功能描述、安裝方式與使用案例以官方 README、公開原始碼及 GitHub repository metadata 為準;實際模型支援與 API 行為仍應以當前官方文件及版本為準。