Tap 把瀏覽器操作變成程式

瀏覽器自動化最煩的點。就是每次都要付 AI 費。Tap 想換個玩法。先讓模型把流程看懂一次。再把動作寫成程式，之後直接重播。

這件事很實際。很多團隊一天會跑 50 次、100 次。每次都叫 LLM 想一遍，錢跟延遲都很難看。Tap 的思路是把 AI 放在前面，把執行放到後面。講白了，就是把「聊天」改成「編譯」。

Tap 不是單純的瀏覽器外掛。它是一套 protocol 加工具鏈。它會看 DOM、網路請求、accessibility tree，然後產生 .tap.js。第一次靠模型，之後靠 JavaScript。這種設計很像把瀏覽器操作做成可重用的資產。

Tap 到底在做什麼

Tap 的核心概念很直白。先讓 AI 找出步驟，再把步驟固定下來。這樣一來，模型不必每次都從零推理。它只負責「發明流程」，不是「每次執行」。

這種做法對開發者很友善。因為你拿到的是程式，不是一次性的對話紀錄。程式可以看、可以版控、可以測試。出問題時，也比較好查。

Tap 的流程通常分三段。Forge 階段讓模型觀察頁面並寫出程式。Verify 階段會拿不同輸入去測。Run 階段就直接重播，不再呼叫模型。

• Forge：模型讀頁面，產生 Tap 程式。
• Verify：用不同輸入測腳本穩不穩。
• Run：直接執行，不再付 AI 成本。
• 重點：第一次花錢，之後省錢。

作者給的經濟例子也很直接。第一次可能要花約 0.50 美元。之後每次重跑是 0 美元。這不是理想圖。這是很現實的成本結構。

我覺得這裡最有意思的地方，不是省多少而已。是它把「模型推理」和「工作執行」拆開了。這樣你才知道哪裡慢，哪裡壞，哪裡要修。

為什麼這種模型有意思

多數 browser agent 都像聊天機器人。你丟任務給它，它一邊看頁面一邊想。這沒錯，但每次都要重新思考。對重複工作來說，這種模式很浪費。

Tap 的想法比較像編譯器。模型先把自然語言和頁面狀態，翻成可執行腳本。之後就是一般程式執行。這很適合每日抓榜單、填表單、查庫存、巡檢後台。

Tap 作者提到，它有 8 個核心操作，外加 17 個內建操作。數字不算誇張，但夠用了。重點是 runtime 只要實作 8 個方法，就能吃到後面那堆能力。這種抽象很工程。

“Programs should be used to express the details that humans have already figured out.” — Peter Norvig, Teach Yourself Programming in Ten Years

這句話很適合 Tap。人已經把流程摸熟了。那就別每次都叫模型重新想。把細節交給程式，才是比較穩的做法。

這也解釋了為什麼 Tap 比純 agent 更適合 production。當腳本壞掉時，你看的是程式和頁面狀態。不是再丟一次 prompt，然後祈禱模型換個走法。

跟 Playwright 比，差在哪

最直接的對照組是 Playwright。它本來就是很多團隊的標準工具。穩、完整、文件多。Tap 沒想取代它。Tap 比較像把 AI 的那一段搬到前面。

Tap 可以跑在 Chrome Extension、Playwright，也能走 macOS 的原生 accessibility API。這點很重要。因為同一份生成腳本，可以落在不同 runtime。

另外還有 tap-skills。作者說裡面有 119 個 community skills，涵蓋 55 個網站。這種技能庫很像現成模板。對實務很有幫助。

• Playwright：人寫腳本，控制力高。
• Tap：AI 先寫腳本，之後重播。
• tap-skills：119 個技能，55 個網站。
• Tap 優勢：重跑時不用再叫模型。

如果你的工作流一天跑 100 次，差異就很明顯。Playwright 省的是人力。Tap 省的是人力和推理費。當任務穩定時，這筆帳會越來越漂亮。

但也別想太美。網站版型一改，生成腳本還是會壞。這不是魔法。它只是把不必要的 AI 呼叫拿掉，沒有把網頁變成永遠不變。

實際上誰會用到

Tap 最適合重複性高的工作。像內部儀表板、客服後台、排行榜、商品頁巡檢，還有每天固定抓資料的流程。這些場景很吃穩定和成本。

它也適合團隊裡已經有 Playwright 經驗的人。因為 Tap 產生的東西最後還是可執行程式。你不用接受一個黑盒 agent。你拿到的是能進 Git 的東西。

安裝流程也蠻輕。先跑 shell script，再下像 tap github trending 或 tap hackernews hot 這類指令。這種命令風格很像小型 compiler toolchain。乾脆，不囉嗦。

如果你在做資料蒐集，這種模式很有吸引力。第一次讓模型理解頁面。之後就直接批次跑。對比一直呼叫 LLM，成本和延遲都更好控。

我覺得它最像的不是 agent。比較像把 AI 當成一次性的程式生成器。這個定位很務實，也很符合很多團隊的日常需求。

產業脈絡跟下一步

過去兩年，browser automation 一直在往兩條路走。一條是純腳本。像 Playwright、Selenium。另一條是 agent 化。靠 LLM 看頁面，再自己決定怎麼點。

問題是，agent 很方便，但也很貴。每次都要推理，速度慢，debug 也麻煩。Tap 這種工具，剛好站在中間。它保留 AI 的理解能力，也保留程式的可控性。

這種中間路線，對台灣團隊其實很實用。很多公司不是要做炫技 demo。是要穩穩抓資料、跑流程、接內部系統。這時候，能省 inference cost 的工具，就會很有感。

如果 Tap 之後把技能庫繼續擴大，runtime 也更穩，我猜它會更像一個「瀏覽器任務編譯器」。不是每個任務都要 agent 即時思考。很多任務，只要第一次想對，後面就該交給程式。

結語：先想一次，再跑一百次

Tap 最有價值的地方，是把 AI 放在第一次。後面就交給可重播的程式。這樣做，成本低，速度快，也比較好維護。

如果你現在就在做瀏覽器自動化，我會建議你直接問一個問題：這個任務，是不是每次都在重複同一套動作？如果答案是肯定的，Tap 這種模式就很值得試。

我的預測很簡單。接下來會有更多團隊，把 LLM 當成程式生成器，而不是天天在線的操作員。因為講白了，重複工作不需要每次都重新思考。