webwright

目前多數網頁代理都把瀏覽器工作階段本身視為工作區：在每一步中，模型會收到目前頁面狀態，並預測下一個單一步驟操作——例如點擊、輸入、DOM selector，或簡短的工具呼叫。不論格式為何，代理都被限制在預先定義的互動迴圈中，一次只預測一個網頁操作。當 LLM 還比較弱時，這樣的框架很有用；但隨著模型越來越擅長撰寫與除錯程式碼，這種框架反而變成瓶頸。

Webwright 採取不同立場：將代理與瀏覽器分離，把瀏覽器視為代理在開發程式時可以啟動、檢查並丟棄的環境。持久保存的產物不是瀏覽器工作階段，而是 本機工作區中的程式碼與日誌。

• 🧱 對網頁環境提供穩健、可重用的互動方式 — 不再依賴脆弱的像素層級操作，具備終端機的程式設計代理可以查詢元素、等待條件成立，並處理 lazy loading 或重新渲染等動態行為。產生出的腳本可以重新執行、調整與分享給其他任務使用，而不是每次都從零重新探索。
• ⚡ 高效率組合複雜工作流程 — 像選日期或填表單這類多步驟互動，可以濃縮成簡潔的程式。透過迴圈、函式與抽象化，代理能在相似任務間泛化（例如不同日期），不必反覆預測相同的底層操作序列。互動輪次更少、執行更快、長流程中的錯誤累積也更少。
• 🧪 以工作區為狀態，而非以瀏覽器為狀態 — 代理可以撰寫探索性腳本、啟動全新的瀏覽器工作階段，並自行決定何時擷取截圖與檢查失敗原因，就像人類工程師反覆調整 RPA 腳本一樣。
• 🪄 雖然極簡，效果卻出乎意料地好 — 這種精簡配置其實很能處理複雜、尤其是長時程的網頁任務（見 效能）。

多數網頁代理框架都把實際的代理迴圈埋在多層抽象之下。Webwright 則採取相反做法：

• 🪶 設計上追求輕量 — 核心代理迴圈只有單一個約 450 行的檔案，Playwright 環境約 570 行，CLI 約 150 行。
• 🧩 可插拔的模型後端 — OpenAI、Anthropic 與 OpenRouter 各自約 150–200 行。
• 🔍 零隱藏框架 — 只使用 httpx、pydantic、playwright 與 typer。
• 🔁 扁平化的 prompt → observe → execute script 迴圈 — 端到端可讀、易於除錯，也容易 fork。
• 🧪 以執行產物為優先 — 每次執行都會將 trajectory 與截圖寫入磁碟，方便檢查。

如果你想要的是一個極簡、容易除錯、可作為瀏覽器代理起點的專案，而不是另一個龐大平台，那就是它。

以下是架構層級上的差異：