微軟研究院本週放出了 Webwright——一個 web agent 框架,丟掉瀏覽器 DOM 點擊和截圖座標預測,改讓 agent 在終端機裡寫 Playwright 程式碼。架構賭注:把瀏覽器當作可啟動的工具,不是有狀態的會話。Agent 接收上下文,返回程式碼和推理,透過 Terminal Environment 執行,然後把觀察結果(日誌、截圖、回傳值)再帶回上下文。三個元件,總共約 1000 行:Runner ~150 LOC 協調 loop,Model Endpoint ~550 LOC 處理 LLM 介面,Terminal Environment ~300 LOC 執行所有東西。單 agent loop,無多 agent 編排。對那些看著 browser-agent stack 不斷累積 Operator 式 DOM 包裝層和截圖管線的 builder 來說,這是架構極簡主義的動作。
Benchmark:Odysseys(長時多站瀏覽,任務平均 272.3 字)——GPT-5.4 基線 33.5%,Webwright 配 GPT-5.4 提升到 **60.1%**(相對提升 79.4%)。Odysseys 之前的 SOTA 是 Opus 4.6 的 44.5%,2026 年 4 月設定。Claude Opus 4.7 配 Webwright 完成任務用更少步數(均值 21.9 vs 26.3),但每任務 $6.09 對比 GPT-5.4 的 $2.37——成本/步數權衡是真實且明確的。Online-Mind2Web(300 任務,136 網站):Webwright+GPT-5.4 達到 86.67% 準確率。Qwen3.5-9B 配預建工具腳本:hard split 上 66.2%。微軟誠實記錄的工程注意點:模型在沒完成時過早宣告「done」,透過 self-reflection 加 fresh-folder 驗證加明確成敗判斷來緩解;長軌跡上下文爆炸,透過每 20 步壓縮歷史緩解。
生態解讀:這是微軟自家 Fara1.5 模型家族(4B/9B/27B)發布後兩週內第二個重大 browser-agent 發布。Fara 是模型側;Webwright 是 harness。兩者表達一個連貫姿態——保持模型介面最小,讓 Playwright 程式碼(微軟自己的瀏覽器自動化函式庫,原本為測試設計)承載動作詞彙。這與 OpenAI Operator(DOM 樹感知,點擊座標)和 Google Antigravity 2.0(瀏覽器即執行時)是不同的賭注。對 builder 來說含義很具體:如果你寫過自訂 DOM 抓取 harness,或在跟截圖到座標預測搏鬥,Playwright-code-as-action-language 這條路現在有了一個公開 baseline,在 Odysseys 上超過前 SOTA 15.6 個絕對點。Repo:github.com/microsoft/Webwright。ship 時帶一個 Claude Code skill——除了 Claude 訂閱外不需要單獨的 LLM 金鑰,帶 project-scoped 或 user-scoped 安裝路徑。
週一早上:如果你在 ship 一個 web-agent 產品,clone repo,把 Odysseys split 跑一遍對比你現在的 harness——蘋果對蘋果的對比能告訴你,你的 DOM-walker 是在做真正的工作,還是在同一個基礎模型上用一個 Playwright 程式碼產生器會做得更好。1000 LOC 的預算讓這個測試很便宜就能 setup。如果你從零開始原型 web agent,Webwright 的形狀(Runner / Model Endpoint / Terminal Env)是一個合理的起手分解——小到一晚上能讀完,有結構能擴展。Opus 4.7 上的成本/步數權衡也值得在你的預算裡明確建模:每任務 $2.37 對比 $6.09 用 Opus,值不值得 4.4 步的減少要看你的 agent 實際是為什麼被付錢的。