Agent Benchmarks

視覺代理比結構化 API 貴 45 倍:Reflex 的完整實測

Reflex 讓 Claude 用兩種方式完成同一個後台任務:視覺 Computer Use 燒掉約 55 萬輸入 tokens、花 17 分鐘;結構化 API 只用 1.2 萬 tokens、20 秒完成。45 倍差距來自介面設計,不是模型好壞。

視覺代理比結構化 API 貴 45 倍:Reflex 的完整實測 — 文章封面
本頁內容6 個段落
  1. 同一個任務,兩種介面
  2. 45 倍差距從哪裡來
  3. 視覺路線的隱藏成本
  4. 什麼時候仍該用 Computer Use
  5. 給開發者的三個結論
  6. 參考來源

2026 年 5 月,Python 全端框架 Reflex 發布了一份讓 Computer Use 陣營降溫的實測:讓同一個 Claude 模型、同一份資料、同一個後台管理任務,分別用「視覺代理操作瀏覽器」與「呼叫結構化 API」兩種方式完成。結果是約 45 倍的輸入 token 差距——視覺路線平均燒掉 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 秒。換模型的效果也有限——Haiku 在 API 路線上 7.7 秒、不到 1 萬 tokens 就完成任務;換更強的模型只能降低「每一步」的成本,但步數由介面決定,每一張截圖就是幾千 tokens 的固定開銷。

視覺路線的隱藏成本

數字之外,實測還揭露兩個帳面外的成本。第一,視覺代理在原始 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,方向性結論夠扎實。第三,Haiku 級模型配上乾淨的 API 介面,整體表現優於旗艦模型配視覺介面——把預算花在介面工程上,報酬率高於追逐更強的模型。

參考來源

本文由 AI 協助自上述來源整理,經人工審核後發布。

分享X電郵