Kimi WebBridge：Moonshot AI 讓 AI 代理直接控制你的瀏覽器，資料毋須上傳雲端

本地優先（Local‑First）架構

不少 AI 自動化工具會使用 雲端瀏覽器：用戶需要在遠端環境登入帳戶，AI 才能操作。

Kimi WebBridge 採取完全不同的方式。

它的系統由兩部分組成：

• 一個瀏覽器擴充功能
• 一個在你電腦運行的本地 bridge 服務

AI 代理會把指令發送到本機服務，而該服務再透過 Chrome DevTools Protocol 控制瀏覽器，例如讀取網頁、導航、截圖或點擊元素。

因為整個流程都在本地執行：

• 可以直接使用你現有的登入 session
• cookies 和帳戶資料留在本機
• 網頁內容毋須傳送到遠端自動化環境

Moonshot 的文件亦強調，登入狀態與頁面內容都會保留在用戶裝置內，不需要把憑證或 session 匯出到雲端。

對很多需要登入的網站來說，這大大降低了自動化的門檻。

設計成「代理中立」的瀏覽器層

另一個值得留意的地方是：WebBridge 並不是只為某一個 AI 應用而設。

官方將它定位為一個 agent‑agnostic（代理中立）的瀏覽器控制層。

目前列出的支援環境包括：

• Kimi Code
• Claude Code
• Cursor
• Codex
• Hermes
• OpenClaw

換言之，不同 AI 代理都可以透過 WebBridge 控制瀏覽器。

實際上，代理負責思考與決策，而 WebBridge 負責把指令轉化為瀏覽器動作。

Kimi K2.6 模型的角色

在整個系統中，WebBridge 只負責「執行」。真正負責推理與任務規劃的是 Moonshot AI 的 Kimi K2.6 模型。

Kimi K2.6 是一個面向 AI 代理場景設計的多模態模型，採用 Mixture‑of‑Experts 架構，總參數約 1 兆，推理時約 320 億參數會被激活，並支援約 256K tokens 的上下文長度。

這個模型的重點能力包括：

• 多步推理
• 工具調用與協調
• 長流程自動化與程式任務

Moonshot 的平台指出，K2.6 在 長時間程式生成與代理自動執行能力方面有顯著提升，能夠更穩定地完成多步任務流程。

在 WebBridge 的實際運作中，大致分工如下：

• Kimi K2.6：負責推理、規劃和決策
• WebBridge：在真實網站上執行操作

例如，一個代理可以先規劃整個流程——搜尋資料、瀏覽多個網站、收集資訊、整理結果——然後由 WebBridge 在瀏覽器中逐步完成每個動作。

為何這次推出值得關注

AI 行業的競爭正逐漸從「模型能力」轉向另一個層面：代理基礎設施（agent infrastructure）。

AI 代理要完成任務，通常必須與真實網站互動，而不少網站都需要登入。雲端瀏覽器模式往往會帶來幾個問題：

• 需要傳輸帳戶憑證或 session cookies
• 企業合規與安全風險
• 遠端環境的資料管理問題

透過讓 AI 直接在用戶自己的瀏覽器運作，WebBridge 在某程度上減少了這些阻力，同時把敏感資料保留在本機。

如果這類架構被廣泛採用，AI 代理在以下場景可能會更實用：

• 網上研究與資料收集
• 企業內部工具操作
• 表格填寫與行政流程
• 監控需要登入的網站資料

更大的競爭格局：Agent Stack

Moonshot AI 的策略其實反映了一個更大的行業趨勢——AI 公司不再只做模型，而是打造 完整的代理技術堆疊（agent stack）。

在這個架構中：

• 模型負責推理與規劃
• 工具負責執行動作
• 連接層把 AI 接入真實軟件環境

WebBridge 提供瀏覽器執行層，而 Kimi K2.6 提供推理引擎。兩者結合，等於為 AI 代理建立了一條從「思考」到「實際操作網頁」的完整鏈路。

隨著 AI 助手逐步由回答問題走向 直接完成任務，能否控制瀏覽器這個入口，很可能會成為未來 AI 生態中最關鍵的基礎設施之一。