當 Agent Host 需要可探索、具型別資訊的工具，並要在協定層處理能力宣告與使用者同意時，選 MCP。若工作本來就適合以命令、檔案、管線、結束碼和受控 shell 表達，CLI 往往更簡單。瀏覽器擴充功能通常不是第三個平行選項；它更像是位在下層、提供或連接瀏覽器存取的元件，可由 MCP 或 CLI 暴露給 Agent 使用。
AI Agent 該選 MCP 還是 CLI？
先界定操作邊界，不要急著選贏家。Host 若必須列出工具、驗證 JSON 參數、呈現使用者核准，還要在多個 Server 間切換，MCP 提供了一份共用契約。反過來說，如果程式 Agent 已在受限 shell 中工作，而操作本來就能以具有穩定 stdout 與結束碼的命令表達，CLI 通常更直接。
| 需要 | 偏好MCP | 偏好CLI |
|---|---|---|
| 執行期工具探索 | 具型別資訊的工具目錄 | 命令說明或已載入的 Skill 已足夠 |
| 組合方式 | Host 協調結構化呼叫 | 管線、檔案、腳本與結束碼 |
| 遠端執行邊界 | 協定傳輸與 Server 生命週期 | SSH、容器、工作程序或本機程序控制 |
| 輸出控制 | Schema 與工具結果契約 | 依命令而定的原始輸出或 JSON |
MCP、CLI 與瀏覽器擴充功能可以直接比較嗎？
不在同一個層級。MCP 與 CLI 都是呼叫介面：它們定義 Agent Host 要如何發出工作請求。瀏覽器擴充功能則是瀏覽器中的執行或存取元件，可能連接使用者分頁、要求主機權限、注入內容指令碼，或把瀏覽器狀態橋接到另一個程序。
先分清這點，才不會做出假比較。把「MCP 支援 schema」和「擴充功能能點頁面」放在一起，比的是協定特性與實作能力，並不公平。真正該問的是：在什麼權限與使用者控制邊界下，哪一條呼叫路徑應該公開哪一種瀏覽器實作？
MCP 和 CLI 有何不同？
MCP Client 會初始化連線、協商能力、列出工具，並對 Server 發出結構化呼叫。現行 tools 規格允許 Server 公開名稱、說明、JSON 輸入 schema、選用的輸出 schema 與註記；但該怎麼向使用者呈現同意，仍是 Host 的責任。除非 Server 值得信任，否則工具註記也應一律視為不可信。
CLI 程序從作業系統接收字串與環境狀態。它的契約通常由 `--help`、man page、範例、結束碼，以及選用的 JSON 輸出來說明。shell 能透過重新導向、管線、指令碼、程序隔離與標準日誌做成熟的組合；同時也帶來引號、路徑、環境變數與注入風險，必須由 Host 加以限制。
兩者都可以包裝相同的實作。 在我們的實驗中，Playwright 為兩條路線提供動力。 瀏覽器任務的能力並沒有因為一個指令跨越 JSON-RPC 而另一個指令跨過 shell 而變得更強或更弱；發現、輸出、會話和政策面發生了變化。
工具發現與上下文成本有何差異？
MCP 讓發現變成機器可讀。 這有助於主持人決定可以調用什麼，並給出模型描述和參數形狀。 代價是，如果客戶端急切地載入大型目錄或冗長的工具結果，則它們可能會佔據有意義的上下文。 客戶端可以透過伺服器選擇、搜尋、工具組、結果檔案、有界快照和簡潔輸出來緩解這個問題。
CLI 不會消除上下文。 代理仍然需要命令名稱、標誌、範例和返回的輸出。 精心設計的技能可以只載入相關的命令配方，並向 CLI 請求緊湊的 JSON 或結果檔。 設計不良的 CLI 可能會轉儲兆位元組或強制重複呼叫幫助。 比較實際路由的位元組和模型可見內容，而不是諸如“零令牌 CLI”之類的口號。
哪個介面比較安全？
這兩個介面本質上都不是安全的。 MCP 可以將工具描述為唯讀或破壞性，但規格警告用戶端不要信任來自不受信任伺服器的註解。 主機仍然需要伺服器信任、使用者同意、身份驗證、目標限制、逾時、日誌記錄以及撤銷憑證的方法。
CLI 可以嚴格包含在狹窄的可執行白名單、固定工作目錄、清理環境、非管理員使用者、檔案系統沙箱和參數驗證。 如果代理程式收到包含機密、命令替換、廣泛文件存取或生產憑證的通用 shell，也可能變得危險。 避免將機密直接放置在提示或命令參數中，因為進程和轉錄日誌可能會保留它們。
瀏覽器擴充功能加入自己的邊界。 檢查請求的權限、主機模式、內容腳本範圍、更新來源、本機訊息傳遞橋以及使用者是否可以查看和中斷操作。 「在我的瀏覽器中運行」既不是安全證明，也不是風險證明；權限和資料流程圖決定。
每種方法的可移植性如何？
MCP 可以在伺服器作為本地進程或服務運行時保持穩定的面向客戶端的合同，但身份驗證、傳輸、文件系統路徑和伺服器安裝仍然因主機而異。 CLI 工具可以在目標作業系統、執行時期、二進位檔案和 shell 相容的情況下順利運作。 腳本必須考慮引用、路徑分隔符號、瀏覽器可用性和版本固定。
擴充功能與瀏覽器的擴充 API、權限模型、商店或企業分發以及使用者設定檔相關。 它們之所以有用，正是因為它們靠近真實的瀏覽器，但這使得它們不太容易移植到無頭伺服器或非瀏覽器任務。
同一項任務的實測結果是什麼？
兩條路線都打開一個自有頁面，填寫一個字段，等待延遲的產品，發現重複的控件，在 DOM 替換中倖存下來，觀察到故意的 HTTP 503 和成功的請求，然後關閉瀏覽器。 每條路線使用九個任務呼叫或命令，重複三次。
| 觀察中位數 | Playwright MCP 0.0.80 | Playwright CLI 0.1.19 |
|---|---|---|
| 任務成功 | 3 / 3 | 3 / 3 |
| 呼叫/命令 | 9 | 9 |
| 回傳的 UTF-8 位元組數 | 22,235 | 1,737 |
| 工具目錄 | 24 個工具； 18,569 位元組 | 不會自動回傳 |
| 實際耗時 | 2,165 毫秒 | 14,544 毫秒 |
實際耗時與位元組數呈現相反趨勢，是因為 CLI 測試刻意啟動九個獨立的 `npx` 程序，並重新連回具名 session。改用常駐包裝器或批次命令，結果就可能不同。因此能成立的結論很有限：在這個設定下，MCP 提供較豐富的探索資訊、回傳文字也較多；CLI 的回應較精簡，但把探索步驟移到任務呼叫之外。
何時該使用 MCP、CLI 或兩者都使用？
若能力要提供給 Host 使用，而且必須可探索、具型別資訊、支援同意流程，並能在不同 Client 間替換，優先選 MCP。若是可預期的本機操作、既有工程工具、建置步驟、儲存庫工作，或檔案與結束碼契約已很穩定的命令，CLI 通常更適合。
邊界有需要時，兩者可以並用。受治理的 MCP Server 可公開一項範圍明確的商業操作，而程式 Agent 用 CLI 命令做本機驗證；CLI 也能負責 Server 的安裝與診斷，實際任務則走 MCP 工具。除非授權與稽核行為真的等價，否則別透過多條未受控路徑公開同一項高風險操作。
只有任務必須使用既有分頁、使用者看得到的狀態，或瀏覽器專屬 API 時，才加上瀏覽器擴充功能。不需要個人設定檔時，優先使用乾淨的自動化設定檔或直接協定。
什麼是 ego (lite) 和 ego-browser Skill？
把產品本身與它的控制介面分開來看。ego (lite) 是一套完整的本機 Chromium 瀏覽器，供人與 AI agent 使用；以產品類別來說，它是一款 agent 瀏覽器。它不是 AI agent、瀏覽器擴充功能、MCP server，也不是雲端瀏覽器。相容的 agent 會透過 ego-browser 直接在頁面中操作，不需要安裝、配對或維持連線的擴充功能橋接，也不會有任何東西跟你目前的索引標籤或視窗焦點搶奪注意力。使用者可以觀看、暫停或隨時接手。雖然這個 Skill 是從 shell 進入點啟動並執行 JavaScript，但它並不是一次只下一個指令的 CLI 工作流程。
AI Agent 會撰寫一段 JavaScript 程式，並透過 ego-browser 的 shell 入口執行。這個工作流程可以在一次執行中完成導覽、等待、檢查、點擊與擷取，然後只把選定的結果回傳給模型，因此模型看到的是最終結果，而不是每一個中間步驟。
ego-browser nodejs <<'EOF'
const task = await taskSpace("review dashboard");
const page = task.page("p1");
await page.goto("https://app.example.com/reports");
const title = await page.title();
console.log({ title });
await task.finish({ keep: [] });
EOF這是一條有效的第三路線，因為真正需要比較的是執行模型，而不是可執行檔的名稱。MCP 公開可探索的結構化工具，通常每次工具呼叫後都會回傳；逐條指令式 CLI 公開單一 shell 操作；ego-browser Skill 則在模型上下文之外，針對獨立且可見的 Space 執行多步驟 JavaScript 工作流程。shell 只是啟動 Skill，並不會因此把 Skill 變成 CLI 類別。
如需深入了解批次 JavaScript 為何會改變上下文成本和模型往返次數，請閱讀我們對上下文外執行路線的技術拆解.
在我們 2026 年 9 月 11 日的受控執行中，ego-browser 0.5.0.31 恢復了一個 ego (lite) Space、等待延遲的 fixture 資料、辨識出兩個重複的 Beta 控制項，並開啟了一個另行驗證的收據分頁，而使用者自己的分頁全程未受影響。
當 Agent 需要使用者授權且可見的瀏覽器 Space、多步驟 JavaScript 應在模型迴圈之外執行，而且人工接管很重要時，選擇這條路線。當宿主需要標準化工具探索和受治理呼叫時選擇 MCP；當工作本來就適合穩定指令、檔案、管線和結束碼時選擇 CLI。如果 API、一般 HTTP 請求、一次性測試瀏覽器或確定性的 Playwright 測試套件能以更小的信任面完成任務，則優先使用它們。
要怎麼驗證這個選擇？
- 凍結一項代表性任務、版本、主機、憑證和停止條件。
- 以事先宣告的分母，統計模型看得見的 schema 與結果內容；不要拿字元數去推估 token。
- 記錄呼叫失敗、錯誤的工具選擇、權限提示、秘密暴露路徑和復原工作。
- 以交替順序重複並保留失敗而不是平均它們。
- 測試實際部署邊界：本機、遠端、容器、瀏覽器擴充或現有設定檔。
- 選擇能滿足工具探索、安全性、可攜性、可觀測性與維護需求的最簡單路徑。
哪些官方來源定義了這些層？
使用目前的MCP架構規範和工具規範用於協議聲明。 測試的實作記錄在官方文件中Playwright MCP和Playwright CLI儲存庫。
將瀏覽器存取視為單獨的權限表面； Chrome 將其模型記錄在聲明權限。 ego-browser 範例已根據目前版本進行檢查ego (lite) 快速入門於 2026 年 9 月 11 日。
常見問題
MCP 一定比 CLI 用更多 token 嗎？
Client 一次載入大量工具 schema 或冗長結果時，的確可能如此；但沒有放諸四海皆準的百分比。CLI 的說明與輸出同樣會占用上下文。應以實際的 Client、Server、Skill 與任務，搭配真實遙測資料來量測。
CLI 可以是 MCP 伺服器嗎？
可以。MCP Server 可以先驗證結構化呼叫，再在底層執行既有 CLI。包裝層必須保留錯誤語意、限制參數，且不能重新暴露一個不受控的通用 shell。
瀏覽器擴充功能比 MCP 更安全嗎？
不依類別。 比較準確的擴充權限、主機策略、憑證、更新路徑、使用者可見度和撤銷。 MCP描述呼叫；擴充描述了瀏覽器端存取。
