Page-Agent 怎麼讓 AI 操作網頁：嵌入式 GUI Agent、表單自動化與權限邊界

Page-Agent 的思路不同於讓 Agent 控制整台瀏覽器：它將 JavaScript 放進網頁，讓頁面本身擁有 GUI Agent。官方說明它以文字化 DOM 操作為主，不依賴截圖、多模態模型、Python 或 headless browser；多頁任務可選 Chrome 擴充功能，另有 Beta MCP Server。專案 README

它適合為 ERP、CRM、後台表單或內部工具加入「用一句話完成一串操作」的輔助能力，但不代表能繞過產品權限。Agent 的動作仍必須受既有鑑權、伺服器驗證與人工確認約束。

Page-Agent 和瀏覽器自動化怎麼選

目標	較合適的方案
為自家 Web 產品內嵌自然語言助手	Page-Agent
回歸測試、跨站擷取、確定性腳本	Playwright 或 Puppeteer
讓 coding agent 檢查網路、主控台與效能	Chrome DevTools MCP
控制使用者真實 Chrome 並保留人工工作階段	browser-harness 一類工具

站內已有 browser-harness、Playwright、Puppeteer 比較。Page-Agent 不取代測試框架，而是把操作能力做成產品功能交給使用者或外部 Agent。

從 NPM 設定最小實例

先安裝套件：

1

npm install page-agent

再於前端入口建立實例。模型位址、金鑰與允許操作範圍應由伺服器或安全設定管理，不要把正式環境金鑰直接寫進瀏覽器程式碼。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


import { PageAgent } from 'page-agent'

const agent = new PageAgent({
  model: 'qwen3.5-plus',
  baseURL: 'https://your-compatible-api.example/v1',
  apiKey: 'USE_A_SCOPED_KEY',
  language: 'zh-CN',
})

await agent.execute('在当前页面找到“新建客户”按钮，但不要提交表单')

上例只驗證 DOM 識別與按鈕定位。實際業務中，apiKey 應改為短期、限額、可撤銷的方式；不可將萬用金鑰、使用者 token 或管理端憑證交給頁面腳本。

建議接入順序：先唯讀，再草稿，最後提交

先選權限低、欄位少的頁面，例如客戶清單篩選或工單草稿。第一階段僅開放定位元素、讀取可見文字與產生操作建議，並以測試資料驗證 Agent 能區分同名紀錄與不同狀態。此時不要開放儲存、上傳附件或跳轉外部網域。

第二階段才允許填寫表單。把輸入限制成客戶 ID、折扣比例、有效期等結構化業務參數，而非只說「給張三打折」。前端應預覽 Agent 準備寫入的欄位；伺服器再依目前角色驗證欄位是否可寫、值是否在範圍內。確認後頁面才呼叫既有業務 API，不能讓 Agent 擁有繞過介面的後門。

第三階段才考慮提交。提交必須走與人工按鈕相同的 API、稽核日誌與二次確認；成功後讀取物件 ID、版本與錯誤訊息並顯示。即使模型誤解自然語言，也會在預覽、權限或伺服器驗證其中一層被攔下。

將任務拆成可稽核階段

表單自動化最常出錯的不是點擊，而是對象與副作用。建議拆成：

查找：只讀取目前頁面的可見欄位與候選紀錄。
填入草稿：只寫入本地表單，不提交、不上傳附件。
顯示差異：將即將寫入的欄位和值交給使用者確認。
提交：只在使用者確認且伺服器權限驗證通過後執行。

例如「替客戶 A 建立 20% 折扣」不應直接交給 Agent。較安全的做法是產生表單草稿、顯示客戶 ID、價格規則與有效期，再由有權限的人提交。

將頁面能力收斂為動作白名單

不要把所有 DOM 元素都當成可呼叫工具。可定義 searchCustomer、fillDiscountDraft、previewDiscount、submitDiscount 等業務動作，分別標示唯讀、可撤銷或有副作用。Agent 選擇動作，前端再執行對應互動；刪除、退款、邀請成員、匯出資料等高風險動作應不註冊，或永遠要求手動確認。

每次執行都記錄使用者、頁面、動作、輸入摘要、結果與失敗原因。日誌須脫敏，不能保存完整金鑰、cookie 或客戶敏感欄位。出錯時，它能說明 Agent 看見什麼、提議什麼、最後由誰確認。

登入、多頁與 MCP 的邊界

Page-Agent 可以使用頁面既有登入狀態，但這不該成為擴大權限的理由。應避免：

讓 Agent 從自然語言擷取或展示 cookie、密碼、驗證碼；
讓它把登入後資料送往未審核的模型端點；
用「自動化」略過二次確認、付款確認或角色審批；
預設對所有使用者開放跨頁能力。

官方 Chrome 擴充功能與 MCP Server 用於多頁或外部 Agent 控制時，尤其要建立網域白名單、動作白名單與稽核日誌。Beta 能力應先在測試環境驗證。

上線前以真實任務驗收

選三到五條客服或營運的低風險任務，例如篩選本週待跟進客戶、補齊指定工單草稿欄位、從訂單頁跳到客戶頁。每條都要準備成功、歧義、無權限樣本：成功樣本應走到預覽；歧義樣本必須追問或停止；無權限樣本必須由後端拒絕且不洩漏額外資料。

不要只看 Agent 是否點到按鈕，也要檢查首次回應時間、失敗是否可理解、重新整理後草稿是否正確，以及斷網或模型逾時是否保留未提交資料。通過後再擴大頁面範圍。

排錯清單

問題	處理方式
找不到按鈕或欄位	檢查 DOM 是否動態渲染、元素是否在 iframe／遮罩層內，以及頁面文案是否穩定。
Agent 選錯紀錄	加入唯一 ID、唯讀預覽與結果回顯，避免只靠名稱比對。
模型呼叫失敗	檢查相容 API、限額、CORS 與金鑰注入位置；不要在前端日誌輸出金鑰。
表單已填但提交結果不對	將填表與提交拆開，提交後讀取並顯示伺服器回傳值。

小結

Page-Agent 的重點不是讓頁面聽懂一句話，而是將自然語言動作限制在可觀察、可撤銷、可審批的產品流程。先用唯讀查詢和草稿填寫驗證，再逐步開放有副作用的操作。