AI Agent 想上網，瀏覽器卻是最大瓶頸：Kernel 如何用 20 毫秒冷啟動改寫遊戲規則

本文整理自《Open Source Startup Podcast》2026 年 2 月播出的單集。

---

Coding Agent 成熟了，但上網的 Agent 還不行

如果你最近用過 Claude Code 或 Cursor，應該會有一個明顯感受：AI 寫程式這件事，已經從「堪用」進化到「真的能幹活」。幾個月前還需要手動修一堆東西，現在很多任務丟出去就能拿到接近完成的結果。Kernel 共同創辦人 Rafael Garcia 甚至開玩笑說自己正在從 prompt engineer 變成「markdown engineer」，因為他的工作幾乎只剩下寫規格文件和審查產出。

但如果你試過讓 AI 去操作瀏覽器，體驗完全是另一個世界。慢、貴、不穩定、經常失敗。同樣是 AI Agent，一個已經能獨立完成複雜的程式碼任務，另一個連穩定地在網頁上點個按鈕都做不到。這個落差不只是模型能力的問題，更是基礎設施的問題。Kernel 的共同創辦人兼 CEO Catherine Jue 在 Podcast 中直接點出了這個痛點：computer-use agent 今天的狀態，大概相當於自駕車十年前的階段，技術本身是非確定性的，但每個月都在進步。

這就是 Kernel 要解決的事。他們不做模型，不做 Agent 框架，專注做一件事：讓 AI Agent 能夠快速、穩定、安全地使用瀏覽器上網。

瀏覽器為什麼對 Agent 來說這麼難

你可能會想：開個瀏覽器有什麼難的？如果你試過把 Chrome 塞進 Docker 容器跑，就會知道這件事有多痛苦。Chrome 是一個極度吃資源的軟體，光是把它打包成容器映像就非常沉重。Google 搜尋「browser crashing Docker container」，你會找到無數開發者在各種奇怪的邊際情況中掙扎的討論串。

更關鍵的問題是冷啟動時間。傳統的做法是把 Chromium 放進 Docker 容器，但即使映像已經建好，從啟動到可用通常需要 15 到 30 秒以上。對人類使用者來說，等 30 秒或許還能接受。但對於需要即時回應的 AI Agent 來說，這 30 秒就是致命的。想像一個語音客服 Agent 正在跟客戶通話，客戶問了一個需要上網查詢的問題，Agent 說「請稍等 30 秒」，客戶早就掛電話了。

Catherine Jue 在 Cash App 工作時親眼目睹了這個問題。他們的 QA 團隊需要自動檢查數千個合作商家的網站上，Afterpay 的「分期付款」小工具是否正確顯示。這些網站經常改版，用傳統的 Selenium 或 Puppeteer 寫死腳本根本維護不了。當 Claude Computer Use 測試版出來時，團隊興奮地發現 LLM 終於能像人一樣「看懂」網頁介面了。但底層基礎設施跟不上，這個能力就無法真正落地。

Kernel 的解法：把 Chromium 放上 Unikernel

Kernel 的技術突破來自一個看起來有點瘋狂的想法：把 Chromium 瀏覽器載入到 Unikernel 上跑。

Unikernel 是一種極度精簡的作業系統映像，只包含運行單一應用程式所需的最少程式碼。Kernel 的共同創辦人 Rafael Garcia 之前就一直在研究 Unikernel 和 Firecracker VM，某天他跟 Catherine 說：「我覺得把 Chrome 放上 Unikernel 應該很酷，我們試試看。」這在當時沒有任何公開的先例，沒人做過。他們最後跟 Unikraft（一個 Unikernel 研究專案背後的公司）合作，成功把 Chromium 載入了他們的 Unikernel 平台。

結果令人驚艷。冷啟動時間從 Docker 的 15-30 秒，直接壓縮到 20 毫秒以下。這不是小幅改善，是三個數量級的飛躍。此外，基於 Firecracker VM 的架構還帶來了一個額外好處：快照與恢復。你可以把一個跑到一半的瀏覽器「凍結」起來，不消耗 CPU 和記憶體，只佔硬碟空間，等需要的時候再瞬間「解凍」恢復到完全相同的狀態，包括登入 cookie、頁面狀態，全部保留。

這個成果被他們放上 Hacker News 的 Show HN，反應非常熱烈。Catherine 回憶說，他們在最後一刻才在官網掛上等候名單，結果收到大量正面訊號。這也成了 Kernel 正式起步的起點。

隨著客戶需求成長，Kernel 又進一步開發了 HypeMAN，一個基於 Cloud Hypervisor 的控制平面。Cloud Hypervisor 是 Firecracker 的下一代，提供更大的彈性，例如能在瀏覽器運行時動態調整資源。當某個老舊的電商網站塞滿動畫和圖形處理時，HypeMAN 可以即時幫瀏覽器「加油」，應對突發的高負載。這個控制平面也被開源了，Kernel 希望其他開發者能用它來建構自己的安全隔離沙箱。

速度為什麼重要：不只是「快一點」的問題

Catherine Jue 坦承，一開始他們自己也不確定「快」這件事到底有多重要。直到產品上線，客戶開始用真實場景告訴他們答案。

第一個場景是語音 Agent。想像一個 AI 語音客服正在跟真人通話，對方期待的是人類般的反應速度。如果 Agent 需要上網查資料，底層瀏覽器得在幾百毫秒內就緒，而不是讓客戶等上半分鐘。人類的耐心極限大概就是幾秒鐘，超過這個時間窗口，使用者就會放棄。Kernel 的目標是讓瀏覽器自動化的速度接近一般 API 請求的體感。

第二個場景是人機協作的工作流。今天很多 Agent 工作流都需要「人在迴圈中」，也就是人類隨時介入修正 Agent 的錯誤。如果 Agent 的工具本身很慢，人類會失去耐心，整個協作節奏就會崩掉。快速的基礎設施讓人機之間的互動能保持流暢。

第三個場景是 Agent-to-Commerce。這是 Catherine 認為最前沿但也最令人興奮的方向：有一天，你的 AI 助理不只是幫你「推薦 T-shirt」，而是直接幫你完成下單、付款的動作。當這個「最後一哩」被打通，Agent 對人類生產力的貢獻和整體 GDP 的正面影響將持續擴大。

開源作為信任引擎

Kernel 選擇開源不是因為慈善，而是因為它在商業上真的有用。Catherine 分享了一個讓她印象深刻的例子：一家企業客戶在做安全審計時問，「你們怎麼保證沒有記錄任何個人資料？」她的回答很簡單：「我們的瀏覽器映像是開源的，你自己去看 ingress 和 egress 就知道了。」對方去看了，確認沒問題，審計就過了。

這種透明度在傳統的閉源模式下根本做不到。對企業客戶來說，開源不只是一個行銷話術，而是一個可以實際驗證的信任機制。Kernel 目前有兩個主要的開源專案：瀏覽器映像本身（Apache 2.0 授權），以及 HypeMAN 控制平面。

在商業模式上，Kernel 走的是典型的「開源核心 + 託管服務」路線。雖然映像是開源的，但自己維護 Kubernetes 來跑大規模瀏覽器叢集是一件很痛苦的事。Catherine 說，到目前為止幾乎沒有客戶真的想自己搞，大多數人非常樂意付費使用 Kernel 的託管 API，按用量付費、無伺服器架構，接上去就能用。

值得一提的是 Kernel 的天使投資人陣容：Docker 創辦人 Solomon Hykes、Sentry 創辦人 David Cramer、YC 創辦人 Paul Graham。Catherine 提到，開源創辦人社群其實非常小且慷慨，如果你在做的東西技術上有趣且推動產業前進，要拿到這些人的回饋和支持，比想像中容易。

我的觀察

Coding Agent 和 Computer-Use Agent 的差距正在急速收窄。 Catherine 在節目中描述的「每月嘗試一次，看 Agent 能不能一次完成任務」的實驗方法，其實我自己也在做類似的事。三個月前讓 Claude 操作瀏覽器，成功率大概三成；現在已經接近六成。模型端的進步加上基礎設施的改善，兩者正在同步加速。我的判斷是，computer-use agent 要達到 coding agent 今天的可靠度，大概還需要 12 到 18 個月。但一旦跨過那個門檻，整個自動化的版圖會重新洗牌。

瀏覽器基礎設施已經是一個正式賽道。 過去一年，這個領域從「沒人在做」變成了激烈競爭。Browserbase、Kernel、Hyperbrowser、Browser Use，各有不同的技術路線和定位。Kernel 靠 Unikernel 的極致速度和開源策略拉出差異化，2025 年 10 月完成 Accel 領投的 2,200 萬美元 A 輪。這不是一個小眾的 side project，而是一個被頂級創投認真下注的基礎設施賽道。當基礎設施層的競爭成熟，Agent 的能力天花板會被大幅拉高。

「New Wave RPA」的機會窗口同樣適用於臺灣。 Catherine 提到醫療、保險、政府系統這些「沒有 API、只有網頁介面」的領域，是 Agent 自動化的最佳切入點。臺灣的情況幾乎完全對號入座：健保系統、各種政府申報平台、老舊的金融交易介面，這些都是每天有人手動登入十幾個入口網站、下載 CSV、填表格的場景。當瀏覽器基礎設施的可靠度和速度達到商用等級，這些重複性高但流程複雜的工作，將是第一波被 Agent 接手的目標。對臺灣的 SaaS 新創來說，這裡面有很大的機會空間。