摘要： Reflex 在 2026 年 5 月公布的實測中，讓同一個 Claude 模型分別以瀏覽器視覺操作與結構化 API 完成同一個管理作業。視覺路線平均用 550,976 個輸入 tokens、約 17 分鐘，API 路線只用 12,151 個 tokens、19.7 秒。文章認為內部工具應優先提供結構化介面，第三方或舊系統才需要 computer use。
2026 年 5 月,Python 全端框架 Reflex 公布的這份實測,等於替火熱的 Computer Use 話題澆了一盆冷水:同一個 Claude 模型、同一份資料、同一個後台管理作業,一條路線讓視覺代理在瀏覽器裡點擊,另一條路線讓模型直接呼叫結構化 API。兩種接法的輸入 tokens 相差約 45 倍——視覺路線平均燒掉 550,976 個輸入 tokens、跑了約 17 分鐘;API 路線只花 12,151 個 tokens、19.7 秒就結束。這份 benchmark 連原始碼一起開源,並在 5 月 5 日攻上 Hacker News 首頁。
控制變因:只換介面
實驗刻意把變數收斂到只剩一個。題目取材自 react-admin 的 Posters Galore 示範專案:資料集凍結在 900 位客戶、600 筆訂單、324 則評論,代理要從中找出訂單量最大的 Smith 客戶,把這位客戶的所有待審評論都核准,再將最新一筆訂單標成已出貨。兩條路線唯一分歧處在介面層:視覺路線由 Claude Sonnet 透過 browser-use 0.12 的 vision 模式,靠截圖與點擊操作畫面;API 路線同樣跑 Sonnet,但 Reflex 0.9 的外掛會從 event handlers 自動生成 HTTP endpoints,模型因此能用 tool use 呼叫 list_customers、update_order 這類結構化工具。模型一樣、資料一樣、任務一樣——介面是唯一在動的變數。
45 倍是怎麼累積出來的
兩邊並排,數字很難看。視覺路線平均要跑 53 步(正負 13),每一步都得把整頁截圖重新餵進模型,輸入 tokens 就這樣堆上 55 萬;API 路線固定打 8 次呼叫,輸入壓在 1.2 萬 tokens,離散程度幾乎歸零(正負 27)。耗時的差距同樣懸殊:1,003 秒對 19.7 秒。換模型能改變的也有限——同樣走 API 路線,Haiku 用不到 1 萬 tokens、7.7 秒就把任務做完。問題的核心在於:升級模型只會壓低單一步驟的單價,步數卻由介面決定,而每一張截圖天生就是幾千 tokens 的固定開銷。
帳單外的兩筆成本
除去檯面上的 token 數字,實測還點出兩項不會列在帳單上的代價。其一,只給原始 prompt 的話,視覺代理其實是失敗的:4 則待審評論裡它只核准到 1 則,其餘幾則躲在表格分頁後面,模型從頭到尾沒捲動過頁面。直到作者補上一份 14 步驟的書面操作指南,它才連續 3 次全數通過——這份靠人力逐步寫出的 UI 說明文件,恰恰是視覺路線最容易被低估的工程投入。其二,視覺路線非常不穩定:三次運行散布在 40.7 萬到 75.1 萬 tokens、749 到 1,257 秒之間,單跑一次的結果完全沒有代表性。作者對自身限制也說得很白:樣本只有 3 到 5 次、任務只測一個;endpoints 雖是自動生成,餵給模型的工具描述依然出自人工。
Computer Use 何時仍派得上用場
這份實測沒有判視覺代理出局,真正的分界是「這個 App 是不是你自己寫的」。內部工具出自己手,結構化 API 就是壓倒性的選擇,特別是像 Reflex 這類會自動生成 endpoints 的框架,等於把過去手寫 API 或架 MCP 層的傳統成本整段消掉。反之,遇上你無法更動的第三方 SaaS 或遺留系統,截圖加點擊仍是唯一的入口。網路資料擷取也逃不開同一道取捨——結構化抓取 API 通常比讓代理開瀏覽器划算,可以參考 Firecrawl 抓取指南。
寫給開發者的三件事
第一,替代理設計專屬介面,別要求代理去遷就給人用的介面:截圖是固定成本、步數取決於介面,45 倍差距的根源就在這裡。第二,衡量 Computer Use 成本時要看 token 總量與變異,不是只盯單步價格;benchmark 的程式碼與結果都攤在 GitHub 上,方向性結論經得起檢驗。第三,乾淨的 API 介面搭配 Haiku 級模型,整體表現勝過視覺介面搭配旗艦模型——把預算投在介面工程,比拿去追更強的模型報酬更高。