會把 web agent 化的是 computer-use 模型,不是 API

TL;DR

• 他要駁的是三段論的第三步:(1) agent 會取代人成為 web 上的主要行動者 ✓;(2) web 會被「agent 化」✓;(3) 靠 MCP / web MCP / 支付協定等十幾種標準的 API ✗。
• 長尾網站不會有 API:餐廳菜單的現實是純文字(easy)、PDF(medium)、到一疊沒 OCR 的像素化掃描圖(hard)。光是歐洲某一國就有約 20 萬名自建網站的小店主——「我們在等的援軍不會來」。
• 「叫 coding agent 讀 HTML」也不成立:電商庫存狀態根本不在 HTML 裡,而在載入時取回的 JSON,再由另一段程式決定選項要不要變灰。瀏覽器本質上是 renderer,像素才是 source of truth。
• Navigator:Yutori 的 pixels-to-actions 模型,輸入螢幕截圖、輸出人類式動作;但不受限於人類方式——它有 execute JavaScript 動作,可一次填完整張表單。
• computer use 沒有停滯:Ohio State 學術團隊維護的 benchmark 已被推到約 97%、基本飽和,需要出新的;專用小模型在成本與速度上也已勝過前沿模型。

重點整理

論證的靶子:三段論的第三步(約 00:29–00:30)

網路上流行的說法分三步:

1. AI agent 而非人類,將成為 web 上主要的行動驅動者——幫我們訂會議、訂位、買東西、取得資訊。
2. 問「怎麼做到」,答案是:web 會被 agent 化,會被改造成 agent 友善的樣子。
3. 再問「怎麼改造」,答案是:透過 API——我的 agent、你的 agent、企業的 agent 都經由十幾種標準來呼叫,MCP、web MCP、支付協定等等。

他的主張很明確:前兩步是對的,第三步是錯的。真正會把 web(尤其是長尾)agent 化的,是像人一樣看螢幕、按按鈕操作瀏覽器的 computer-use agent。

為什麼訂機票的 demo 很荒謬(約 00:30–00:31)

這個領域最常見的 demo:使用者在 iPhone 上說「幫我找這班機」,背後一個 browser-use agent 打開 flights.google.com,像人一樣點按鈕。他說這荒謬得好笑——那明明就是個資料庫,有現成的聚合器 API 服務,送結構化查詢、拿結構化結果就好,何必去點按鈕?

換個問題才看得出差別:「我要辦一場晚間聚會,這家餐廳的菜單上有無麩質的選項嗎?」人們想像的是未來有 myrestaurant.com/menu 這種端點,可以直接 curl、用自然語言查詢或篩選出 gluten-free 品項。

長尾的真實樣貌(約 00:32–00:33)

他實際展示三種難度的餐廳網站:

• Easy:菜單是可讀的文字。
• Medium:菜單是 PDF。
• Hard:菜單是一疊各自獨立掃描的頁面圖片,拼在一起、像素化、連 OCR 都沒做。

而網站背後是真實的人——光是歐洲某一個國家,就有約 20 萬名自己維護網站的小店主。「你想像的是,明天或未來五年內他們會全部革新,為你的 agent 開好閘道。」他的判斷是:不會發生。web 極度長尾,單一小網站價值有限,但整條尾巴累積起來價值巨大;而基礎設施改變得很慢。

為什麼「讓 agent 讀 HTML」也不行:osmium cube 的例子(約 00:33–00:35)

常見的反駁是:「那我們有 coding agent,直接讀 HTML 就好。」他用一個電商頁面反駁:問「這個 24mm 鋨立方體是否有貨?」

• 人眼看下拉選單,可以看到四個選項中有三個是 sold out、一個可買。
• 但 agent 去讀 HTML,選單只有品項描述,完全沒有數量資訊。
• 真相是:頁面載入時另有一個查詢回傳 JSON 字典,裡面才是當下的庫存與數量;點開下拉時,另一段程式碼決定該選項要顯示成灰色還是彩色。

結論用遊戲工程的類比講得最清楚:瀏覽器本質上是一個 rendering engine——底下有 assets、有 code,最終產出的是像素。web 是為人眼建造的,像素才是 source of truth,所以機器必須用視覺來操作。 Yutori 為此寫了一篇 blog:《The Bitter Lesson for Web Agents》——如果你不看像素,你就會卡在無止盡的 feature engineering 上,永遠搆不到長尾。

現場插曲:一個彈窗蓋掉了他半張投影片,他一邊等工作人員處理一邊說:「API 不會來,但我的 computer-use agent 會來,而且它會做得比這更好。」

Navigator:pixels-to-actions(約 00:37–00:38)

Yutori 訓練的模型叫 Navigator:輸入是瀏覽器截圖,輸出是人類式動作(click、type、scroll)。

• 應用範例:「我有一組促銷碼,它到底能不能用?」——這種事永遠不會有 API,商店後台不可能開這個介面。Navigator 會開瀏覽器、走一遍模擬結帳流程、套用促銷碼、比對價格是否下降,然後回傳結構化物件:是的,可用,價格降了 22%。這才是 web 的 API。
• 要用視覺,但不必被人類的方式綁住:模型有一個 execute JavaScript 動作,可以直接讀寫 JavaScript。在表單填寫任務上,它會自己寫程式一次填完多個欄位,而不是一格一格點。

反駁「computer use 卡住了」與「太慢太貴」(約 00:38–00:40)

網路上有一種說法:coding agent 一直在進步,computer use 卻停滯了。他說事實不是這樣——benchmark 一個接一個倒下。他舉了一個由 Ohio State 學術團隊維護的 benchmark:過去兩年基本已被推到飽和,大約一個月前準確率已達 97%,得再造新的了。

至於慢與貴:如果你用前沿通用模型,確實如此。他對比 Opus 4.7 與 GPT-5.5——GPT-5.5 每個動作大約要 10 秒,某個資料集上跑完整個任務要花到 230 美元。而 Yutori 訓練的專用模型小得多,準確度相當、速度更快、也便宜得多。

結語:我們有 30 年的 web 是為人類消費而建造的,這正在改變,但「怎麼改」很重要。那個「任意網站都能拉、任意任務都能用自然語言描述」的 web API,將會由背景中一大群操作瀏覽器的 agent構成。

金句

"The cavalry that we're waiting for is not coming."(約 00:33)

指望長尾網站都長出 agent 友善的 API,是在等一支不會抵達的援軍。

"A browser really is a renderer. … The web was built for human eyeballs. That is the source of truth. And so machines will need to operate with vision."(約 00:35)

整場演講的核心一句。

"APIs are not arriving, but my computer-use agent is arriving. It'll do a better job than this."(約 00:36)

投影片被彈窗蓋住時的即興回應,也剛好是他論點的現場演示。