前言

讓 AI Agent 操作瀏覽器，最麻煩的往往不是「怎麼 click」，而是它到底在操作哪一個瀏覽器。另開 headless browser，登入狀態帶不過去；接管使用者正在看的 Chrome，又會搶分頁、滑鼠和焦點。當兩個 Agent 同時工作，tab collision、cookie、captcha 與人工確認會更難管理。

citrolabs/ego-lite 的答案是：不要只做一套 browser automation library，而是做一個可同時服務人與 Agent 的 Chromium-based browser。人保留自己的 tabs，Agent 在獨立 Task Space 裡工作，但可以沿用匯入後的登入狀態；外部的 Claude Code、Codex、Cursor 或其他 Agent，則透過 ego-browser Skill 與本機 CLI 控制它。

這個方向很實用，也帶來一個不能忽略的問題：Agent 一旦拿到登入狀態、Node.js 與 raw CDP，權限不只是「可以讀網頁」，而是接近已登入使用者加上本機 shell 的組合。研究 ego lite，必須同時看它怎麼提升效率，以及真正的信任邊界在哪裡。

結論先講：開源的是連接層，不是完整 Browser App

本次研究固定在 2026-08-06 可取得的 main 快照 f260b21761354ca0d2781ce750418305f16f8988。從這個快照可以直接檢查：

  • ego-browser Agent Skill 與操作規則。
  • Node.js／TypeScript helper runtime。
  • CLI 執行、CDP facade、snapshot、locator、input、download 與 Task Space helper。
  • 安裝腳本、unit tests、CI 與 release workflow。
  • Claude Code 與 Codex 的 plugin metadata。

但真正的 ego lite.app、Chromium fork、profile storage、native globalThis.ego bridge、更新器與 browser telemetry 實作不在公開 tree 裡。package README 也明確把責任分開：browser runtime 擁有 tabs、Task Spaces、CDP transport、snapshot 與 events；開源 package 只負責 Agent-facing ergonomics。

因此，「ego-lite repository 採 MIT」不能自動推論下載的 Browser App 與 Chromium fork 也能完整重現或稽核。README 最後特別寫明：repository 內容採 MIT，而 browser 是另一個免費下載項目。

ego lite 在解決什麼問題？

一般 browser automation 常見三種路線：

路線 優點 常見摩擦
Headless／獨立 Chromium 隔離清楚、適合 CI 登入狀態、extension 與人工接手不容易搬移
接管現有 Chrome tab 可以直接使用目前登入 容易搶使用者的 tabs、焦點與工作狀態
內建 Agent 的 AI Browser Browser 與 Agent 整合緊密 通常只能使用該產品自己的 Agent

Ego lite 想建立第四種組合：同一個 browser 裡，人與外部 Agent 各自有 workspace。Agent 的每個任務進入 Task Space，tabs 不和人的日常視窗混在一起；需要登入或確認時可以交還控制權，完成後再關閉該 Space。

這個設計處理的是 操作空間衝突，不是權限隔離。固定快照的 SKILL.md 明說：Task Space 有獨立 tabs，但預設繼承使用者的登入狀態。換句話說，Space 不搶畫面，卻仍可能以你的身份讀取或修改 SaaS 資料。

一次 Browser Task 的真實資料流

Agent 並不是逐次呼叫一個 click CLI。Skill 要求它把多個操作寫成 JavaScript heredoc，一次交給 ego-browser nodejs：

ego-browser nodejs <<'EOF'
const task = await useOrCreateTaskSpace('inspect account')
await openOrReuseTab('https://example.com/account', {
  wait: true,
  timeout: 20,
})
cliLog(await snapshotText())
EOF

底層流程可以整理成：

Coding Agent 產生 JavaScript
    ↓
ego-browser nodejs 讀取 stdin
    ↓
AsyncFunction 執行 JavaScript
    ↓
page / browser / taskSpaces / fetch / cdp helpers
    ↓
nav / observe / locator / keyboard / waits / files / downloads
    ↓
browser-runtime.ts 呼叫 globalThis.ego.sendCDPMessage()
    ↓
公開原始碼稽核邊界
    ↓
Native bridge → ego lite Chromium App

run.ts 會讀完整 stdin，使用 AsyncFunction 執行 Agent 產生的 JavaScript，最後 flush output 或處理 hard stop。browser-runtime.ts 則把 CDP request 與 callback 配對、管理短期 session、重連 active tab，並將命令送到 app 注入的 native bridge。

這種 code-based 模式的優點，是 Agent 可以在一段 script 裡完成「開頁面、擷取、篩選、填表、驗證」，減少工具呼叫回合。代價是權限與除錯面也比受限 DSL 大很多。

三種操作工作流

Ego Browser Skill 沒有假設每個網站都能靠 CSS selector 解決，而是把操作分成三條路徑。

1. Semantic：Snapshot、ref 與 locator

一般表單、按鈕、連結、列表先用 snapshotText() 取得整頁語意樹，再以 @N、CSS、XPath、ARIA 或穩定 locator 操作。這條路徑對文字模型最省 context，也比盲點座標穩定。

2. Visual：Screenshot 與真實輸入

Google Docs、試算表、Figma、地圖或 canvas 類介面，DOM 裡看到的 input 不一定是真正編輯面。Skill 要求先截圖、小量寫入探測，再以座標、滑鼠與鍵盤操作並重新驗證。

3. Direct DOM／CDP

需要自訂擷取、browser state 或 helper 未涵蓋能力時，可以直接使用 js() 或 cdp()。這提供很高彈性，也代表網站內容、Agent prompt injection 或錯誤程式碼有機會觸及更底層的 browser capability。

三條路徑可以混用。這比「所有網站都 snapshot + click」更符合真實網頁，但每增加一條 fallback，也增加需要驗證的狀態與失敗模式。

Task Space 如何維持多回合狀態？

每段 heredoc 都是短命 Node process，結束後 JavaScript 變數會消失；tabs 與 Task Space 狀態則留在 Browser App。下一回合必須用同一個 name 或 id 重新選取 Space，不能假設前一段 script 的變數還在。

Skill 對 lifecycle 的規定值得肯定：

  1. 同一個使用者目標持續沿用原本 Space，不因追問就另開一個。
  2. 登入、captcha 或人工確認時，用 handOffTaskSpace 把控制權交給使用者。
  3. 只有使用者明確說繼續，Agent 才能 takeOverTaskSpace。
  4. 使用者主動接管時，Agent 必須停止，不可繞路重試。
  5. 工作確定完成後，以獨立 final heredoc 呼叫 completeTaskSpace(..., { keep })，預設關閉。

這是一套不錯的 human-in-the-loop UX contract。不過 helpers.ts 顯示部分 ownership enforcement 位於未公開 native bridge；takeOverTaskSpace 的使用時機仍依賴 Skill 規則。它不能當成付款、刪除或正式發布的強制審批系統。

登入狀態共享：最好用，也是最高風險的能力

初次 onboarding 可以匯入 Chrome 的 logins、cookies、extensions 與 bookmarks，之後 Agent 在自己的 Task Space 使用這份 browser profile。這解決了自動化最痛的登入摩擦，也把 Agent 權限直接提升到「已登入使用者」。

因此 Task Space 應被理解成 workspace isolation，而不是 credential sandbox：

  • Agent tabs 和使用者 tabs 分開。
  • 多個 Agent 任務可以各自有 Space。
  • 但 Space 預設可繼承相同登入能力。
  • 網站本身看到的仍可能是同一個帳號與 session。
  • 帳號可做的刪除、付款、發文或管理操作，Agent 也可能做到。

實際導入時，最好先用低權限測試帳號、測試 tenant 或專用 browser profile，不要一開始就匯入擁有 production、付款與管理員權限的主要 Chrome profile。

「資料留在本機」要拆成兩個問題

README 表示 browsing data 留在裝置上，setup 只記錄是否選擇 Chrome migration。就公開 helper 而言，也沒有看到自建帳號、OAuth server 或 analytics SDK；profile、cookies 與 Task Spaces 由 Browser App 管理。

但這只能回答「browser profile 存在哪裡」，不能回答「整個工作流是否離線」。snapshotText()、擷取結果與 CLI output 會回到 coding agent；如果 Claude Code、Codex 或 OMP 使用雲端模型，登入後頁面內容可能進入模型 context。Browser App 是否另有 telemetry、crash reporting 或 updater backend，也因 app source 不公開而無法從 repo 排除。

此外，open helper 本身還有其他資料面：

  • env.ts 會讀 package root 與 Skill workspace 的 .env。
  • Screenshot 預設寫入 OS temp，也能寫到指定位置。
  • Download 先進 OS temp，再由 saveAs 複製。
  • Upload 接受 absolute local path。
  • serverFetch 從 Node 發 request；browserFetch 則在目前頁面 origin 執行，可能攜帶適用的 browser cookies。

所以「本機 browser profile」不是完整的資料外洩保證。真正要治理的是模型供應商、Agent shell 權限、local files、網站帳號與 Browser App 五個邊界。

Node.js 執行模型不是受限 Browser DSL

ego-browser nodejs 會以 AsyncFunction 直接執行 Agent 產生的 JavaScript。程式可以接觸 Node globals、dynamic import、filesystem、network 與 environment；同時又能操作已登入 browser、上傳檔案與執行 raw CDP。

這是效率來源，也是安全風險來源。當未信任網站內容進入模型 context 時，prompt injection 不只可能讓 Agent 點錯按鈕，還可能誘導它讀本機檔案、呼叫網路或操作其他登入服務。

需要高保證的環境，不應只靠「Agent 應該不會這樣做」：

  1. 限制 Agent 可讀的 workspace 與環境變數。
  2. 使用專用低權限 browser profile。
  3. 對付款、刪除、發文與權限修改加上外部人工 gate。
  4. 限制允許的網域、下載與 upload 路徑。
  5. 保存操作紀錄，並在自己的真實網站做 prompt-injection 測試。

安裝腳本需要先審查

固定快照的 install.sh 會依 CPU 從 cdn.ego.app 下載 DMG、mount、把 app 放進 /Applications，必要時使用 sudo，最後啟動 App。

較敏感的地方有三個：

  • DMG URL 沒有可辨識版本 pin。
  • Script 未見 SHA-256 或 code-signature 驗證。
  • Script 主動移除 com.apple.quarantine，而且失敗會忽略。

這不等於下載檔一定有問題；它表示自動安裝流程繞過了一部分 macOS 原本用來提示與檢查下載 App 的安全邊界。Managed Mac、公司設備或高敏感環境，應先取得可固定版本的 artifact，人工核對 hash、Developer ID、notarization 與 entitlement，再決定是否安裝，不要直接讓 Agent 執行腳本。

固定快照只支援 macOS；Windows 與 Linux 當時仍在 roadmap。從 source build ego-browser helper 也不能取代 App，因為 native globalThis.ego、Task Spaces 與 snapshot runtime 不在 repo。

在 OMP 裡能不能用？

固定快照沒有 .omp manifest、OMP 安裝文件或 OMP CI，因此不能寫成 CitroLabs 官方支援。不過 OMP 可以載入一般 Agent Skill，也能讓 Agent 透過 Bash 執行 ego-browser nodejs；從介面上看，做下游整合是可行的。

必須同時滿足兩件事：

  1. 把完整 skills/ego-browser/ 放到 OMP 可掃描的 Skill 目錄，例如 ~/.omp/agent/skills/ego-browser/。不能只複製 SKILL.md，因為它還會讀 references/、scripts 與 learnings。
  2. 安裝 Ego Lite App、完成 GUI onboarding，並確認 ego-browser CLI 已加入 PATH。

即使能跑，也不代表一定比 OMP 內建 browser 工具適合。匿名讀頁、一般表單與短任務，既有工具通常更簡單；真正需要登入狀態、獨立 Task Spaces、使用者接手與多個 Agent 並行時，Ego Lite 的差異才明顯。

導入前應先在新的 OMP profile、測試帳號與非 production 網站做 PoC，不要把主要 Chrome profile 當第一個測試資料集。

測試與 CI 證明了什麼？

開源 helper 並非只有 demo。npm test 包含 build、TypeScript typecheck 與 Node test runner；tests 涵蓋 browser runtime、CDP eval、keyboard、locator、navigation、waits、video 與 Task Space helpers。CI 在 Ubuntu、Node 22 上執行 tests 與 site-skill validation，quality gates 另有 Prettier、npm audit、typecheck 與 validation。

但證據邊界同樣清楚：

  • 預設 CI 不是 macOS App 的完整 E2E。
  • Native bridge 與 Chromium fork不在公開 source。
  • Repository 雖有 real-browser E2E cases，固定 CI 沒有執行它們。
  • Mock 通過不等於真實 Browser App 的 CDP timing 與並行一定正確。

因此可以說 helper 有相當完整的單元與介面測試，不能說整套 Browser App、profile migration 與多 Space 隔離已由公開 CI 完整驗證。

官方 Benchmark 該怎麼看？

README 宣稱在四個複雜 browser automation tasks 中，Ego Lite 相較 Vercel agent-browser 最快可達 2.5 倍，並使用更少 tokens。這個方向與 code-based 一次執行多步操作的設計吻合，但固定 repository 只有結果圖片，沒有：

  • 原始結果資料。
  • 四個任務的完整定義。
  • 硬體、網路與登入狀態。
  • 模型、版本與 runner pin。
  • 重跑 script、trial 數與統計方法。

所以文章只能把它寫成官方 benchmark claim，不能稱為獨立、可重現的效能證明。真正的採用測試應使用自己的登入網站、同一模型、同一網路與同一成功條件，比較完成率、tool calls、token、人工接手次數與錯誤恢復，不只比最快時間。

版本其實有三條軸

固定快照同時出現三種版本：

元件 可見版本 代表什麼
Git source main@f260b217… 可重現的 repository 狀態
ego-browser-v2 package 0.1.0 Node helper package metadata
Agent Skill 1.2.6 Skill instruction 版本

Browser App 與 CLI 又有自己的 build。這幾條版本線不能混成一個「ego lite 1.2.6」。GitHub Release workflow 打包的是 helper／Skill payload，不是 macOS DMG；安裝腳本的 CDN artifact 也沒有清楚的版本檔名。

採用紀錄至少應保存：repository commit、Skill metadata version、App／CLI version、Chromium version與 DMG hash。否則遇到 Skill、helper 與 App runtime 不相容時，很難重現或回滾。

最值得保留的設計

我認為 Ego Lite 最有價值的不是「可以 click 網頁」，而是這四個介面決策：

  1. Task Space lifecycle：同一目標沿用同一 Space，完成後明確關閉。
  2. Control handoff：人工登入或確認時，控制權有正式交接語意。
  3. 多模態 fallback：semantic、visual 與 CDP 各自處理適合的頁面。
  4. Code-based composition：Agent 可把多個確定步驟組成一次 JavaScript 執行，減少來回。

這些概念即使不安裝 Ego Lite，也值得其他 Agent Browser 工具借鑑。尤其「使用者主動接管就是 hard stop」與「完成後清掉 task workspace」，比讓 Agent 無限重試安全得多。

適合與不適合的情境

適合

  • macOS 開發者已使用 Claude Code、Codex、Cursor 或相容 Agent。
  • 需要操作登入後 web app，又不希望 Agent 搶日常 tabs。
  • QA、dogfooding、後台資料整理與低風險重複操作。
  • 任務需要 snapshot、視覺操作、raw CDP 與自訂 JavaScript混用。
  • 團隊能管理 App binary、專用 profile、Agent shell 與人工審批。

不適合

  • Windows／Linux production 或 server／container browser farm。
  • 要求完整 browser engine、native bridge 可稽核與 reproducible build。
  • 不允許登入後內容進入任何雲端模型 context。
  • 金融交易、production deletion、醫療、法務或人資後台直接全自動化。
  • 需要固定、可驗證、可回滾的 App artifact 與長期支援矩陣。

採用前，我會怎麼驗證？

先做一個限制清楚的 PoC：

  1. 新建低權限測試帳號與專用 browser profile，不匯入主要 Chrome profile。
  2. 固定 repository commit，人工檢查 Skill 與 installer；App 安裝後保存版本、hash 與 codesign 資訊。
  3. 選三個可回復任務：登入後讀資料、填測試表單、跨頁整理，不碰付款或 production mutation。
  4. 各跑單 Space 與多 Space，記錄完成率、token、handoff、CDP 錯誤與 tab leakage。
  5. 加入惡意頁面文字、錯誤 locator、下載與 upload 測試，確認 Agent 權限邊界。

只有在這些結果穩定後，才逐步增加網站與帳號權限。付款、刪除、發文、權限修改仍應由外部系統強制人工核准，不能只靠 Skill 中的一句「先詢問使用者」。

研究後的個人結論

Ego Lite 抓到 Agent Browser 的核心矛盾：獨立 browser 很安全但沒有登入狀態，接管現有 browser 很方便卻會打擾使用者。Task Spaces、登入狀態共享與 control handoff，確實是一個比「再包一層 click CLI」更完整的產品方向。

我會把它視為值得在低風險環境測試的早期 Agent Browser，而不是已完成企業安全邊界的瀏覽器平台。開源 helper 的介面設計與測試相當具體；真正最關鍵的 native bridge、profile isolation 與 Browser App 則不在 repo，安裝供應鏈和 benchmark 也還缺可重現證據。

如果需求是「讓 Agent 讀匿名網站」，Ego Lite 太重；如果需求是「讓多個外部 Agent 操作登入後網站，又不搶我的分頁」，它的 Task Space 模型很有吸引力。採用決策的關鍵不是 Star 數或最快 2.5 倍，而是你是否願意把已登入帳號與本機 Node 權限交給這條 Agent 執行鏈，並補上真正強制的審批與隔離。

參考資料