Browser-Use 跟 MCP 都很熱——但官方課程說：兩個都不是「全或無」的選擇（拆解微軟 L11 / L15）
Browser-Use（CUA）跟 MCP 是 2025-2026 AI agent 圈最熱的兩個題目——但官方課程的論述都同一個方向：兩個都不是「全或無」的選擇。CUA 適合動態 UI、結構固定還是要回 Playwright；MCP 解 tool 接駁、agent 之間還要 A2A、網頁層還要 NLWeb。這篇拆解 Lesson 11 + 15 的選型對照與混合策略。
為什麼這兩課要合在一起讀
第 11 課的 MCP / A2A / NLWeb 三個 protocol 跟第 15 課的 Browser-Use（CUA）表面看是不同層——前者是 agent 跟系統 / agent / 網站的溝通協定、後者是 agent 直接控制瀏覽器。但兩課共享同一個設計判斷：把 agent 能力分層、選對層、混合用、不要 over-commit 到單一方案。
實戰上這代表：MCP 不是「萬用 API 替代品」、CUA 不是「全自動瀏覽器人」。每個工具都有自己最強的場景跟最爛的場景，選型問題比實作問題重要。下面 4 個工具一個一個拆。
MCP — 3 個 primitive 跟「integrate once」幻想
Model Context Protocol 是 client-server 架構：
- Hosts：LLM 應用（VSCode 之類），發起連線
- Clients：host 內的元件、跟 server 維持 1-to-1 連線
- Servers：暴露能力的輕量程式（譬如「天氣 server」「電商 server」）
MCP server 3 件 primitive：Tools（可呼叫的 action，如 get_weather）、Resources（read-only 資料，如檔案、DB 記錄）、Prompts（預定義模板）。這 3 個 primitive 的清楚分層是 MCP 設計的亮點——很多人講 MCP 只講 Tool、漏掉 Resource 跟 Prompt。Resource 是「給 LLM 讀 context」、Tool 是「給 LLM 執行 action」、安全模型完全不同。
微軟強調的 MCP 3 個好處：
- Dynamic Tool Discovery：agent 動態問 server「你有什麼 tool」、不必事先 hard-code。
- Interoperability Across LLMs：MCP 跨 LLM 通用、可以隨意換 model 評估。
- Standardized Security：標準化驗證、不必每個 API 自己一套。
「Integrate once」的幻想：第 1 個好處被宣傳成「寫一次、API 變動不必改 code」。實際上：API 變動依然要改、只是從應用端推到 MCP server 端。MCP server 自己要做 versioning、backward compatibility、breaking change 管理。痛點沒消失、只是下推到不同團隊。對應用端看是「integrate once」、對 server 維護方看是「持續工作」。
這條 trade-off 在組織決策上很重要——如果你公司是 MCP server 提供方、要計算長期維護成本；如果你是 MCP server 消費方、要確認你連的 server 真的有人在維護。沒有人維護的 MCP server 跟過期的 API SDK 一樣危險。
A2A — 4 件 component 跟長連線成本
Agent-to-Agent 跟 MCP 補位——MCP 連 agent 跟 tool、A2A 連 agent 跟 agent（跨組織、跨平台）。4 件 component：
- Agent Card：agent 的「名片」——名稱、能做什麼、有什麼 skill、endpoint URL、版本、capabilities。其他 agent 看 card 決定要不要 call。
- Agent Executor：把 user chat 的 context 傳給 remote agent、讓 remote 用自己的 LLM + tool 執行。
- Artifact：remote agent 完成後產出的成果物 + 描述 + text context。送完就斷連線。
- Event Queue：處理更新跟訊息、production 重要——防止任務還沒完成連線就斷。
A2A 3 個好處：跨 vendor / 平台協作、每個 agent 可選自己的 LLM（不像某些 MCP 場景綁單一 LLM）、內建驗證。
長連線的隱藏成本：Event Queue 設計的目的是「防止任務還沒完成連線斷掉」、暗示 A2A 任務常常會跑很久。Production 維持長連線的成本不便宜——connection pool、heartbeat、reconnect 邏輯、跨 organization 防火牆穿透。實戰上 A2A 適合 high-value / low-frequency 任務（跨公司預訂行程、跨部門審批），不適合 high-frequency / low-value 任務（一秒 100 次的查詢）。
NLWeb — 把網站變成 agent 可消費的層
NLWeb 是 3 個 protocol 中最少被提到、但概念最有想像空間的一個：把網站本身做成 agent 可以用自然語言查詢的接口。內含：
- NLWeb Application：處理自然語言查詢的核心引擎
- NLWeb Protocol：基本互動規則、回 JSON（Schema.org 格式）
- MCP Server Endpoint：每個 NLWeb 同時是 MCP server——這條設計很關鍵、讓網站自動進入 agent 生態系
- Embedding Models：把網站內容向量化
- Vector Database：存 embedding、支援 Qdrant / Snowflake / Milvus / Azure AI Search / Elasticsearch
實際運作：旅遊網站把產品（航班、飯店、行程）用 Schema.org 結構化 → NLWeb ingest 變 embedding → 用戶用 chat「找個能帶小孩、有游泳池的 Honolulu 飯店」→ NLWeb 用 LLM 理解 + 向量搜尋 → 回真實飯店資料（不會幻覺）→ 外部 AI agent 也可以透過 MCP `ask` method 直接 query 這個網站。
NLWeb 的 embedding 陷阱：純向量搜尋的限制——「便宜」「家庭友善」這類抽象偏好可以匹配、但「房間 25 平米以上」這類精確條件容易漏。實務上要混合 vector search（捕語意）+ structured filter（捕精確條件）、不能只靠 embedding。微軟提到支援多種 vector database 不是巧合——選擇 DB 時要看「能不能跟 structured filter 混用」。
Browser-Use（CUA）— Agent + Actor 混合模式
第 15 課的主軸：Computer Use Agent 是用 vision 看畫面、像人一樣操作瀏覽器；Playwright 是傳統 actor、用 CSS selector 精準控制。微軟 lesson 直接給出選型表：
| 場景 | 用 Agent（CUA） | 用 Actor（Playwright） |
|---|---|---|
| 動態 layout | ✅ AI 適應變化 | ❌ brittle selector 容易壞 |
| 已知結構 | ❌ agent 比直接控制慢 | ✅ 快且精準 |
| 找元素 | ✅ 自然語言好用 | ❌ 需要精確 selector |
| 時序控制 | ❌ 較不可預測 | ✅ 完全控制 wait/retry |
| 複雜 workflow | ✅ 處理意外 UI | ❌ 需明確分支 |
5 個維度看下來、沒有「全 agent」或「全 actor」會贏——每個維度的最優選擇不同。所以微軟教的是混合架構：
- Chrome 啟動時開 CDP（Chrome DevTools Protocol）、讓 Playwright 跟 Browser-Use 共享同一個 browser session
- Browser-Use agent 處理開放式導航（開 Airbnb、dismiss pop-up、搜 Stockholm）
- 當前頁面用 Pydantic schema 結構化提取（listing 標題、夜間價格、評分、URL）
- Python 邏輯比對提取的 listing、找出最便宜的
這個架構的核心判斷：「探索期」用 agent vision、「執行期」用 actor 直接控制、共享 browser session 避免 state 重建。微軟給的 7 個 best practice 都圍繞這個 framing——start with agent for exploration、switch to direct page control when predictable、blend agent and actor patterns to get both flexibility and precision。
5 個工具的選型對照
把這 4 個工具（MCP / A2A / NLWeb / Browser-Use）加上「直接呼 API」做選型對照：
| 場景 | 最適工具 | 為什麼 |
|---|---|---|
| 有穩定 API、已知 endpoint | 直接呼 API（function calling） | 最簡單、最快、最便宜 |
| 有多個內部 service、想統一接駁 + 動態發現 | MCP | 3 primitive 分清楚、跨 LLM 可移植 |
| 跨公司 / 跨部門協作、不同 agent 不同 LLM | A2A | 跨組織協作 + 各自選 model |
| 網站要被 AI agent 查詢、想 expose 內容 | NLWeb（含 MCP endpoint） | Schema.org + vector search + 自動進 agent 生態 |
| 目標網站沒 API、UI 動態 | Browser-Use（agent + actor 混合） | vision 適應變化 + actor 精準控制 |
判斷流程：先問「有 API 嗎」→ 沒有再問「能不能裝 NLWeb / MCP server」→ 都不行才用 Browser-Use。順序顛倒等於用大砲打蚊子（不少團隊看到「Browser-Use 很酷」就直接上、忽略後端其實有 API）。
我的觀察 — 為什麼混合永遠贏「全或無」
4 個工具的設計都指向同一個原則：「全自動」是迷思、「精準分層」才是 production-grade 的答案。原因：
- 每個工具都有 cost-quality 取捨。Agent 靈活但慢、actor 快但脆；MCP 統一但 server 要維護；A2A 跨組織但長連線貴；NLWeb 自動 expose 但 embedding 有侷限；Browser-Use vision 適應變化但 token 燒得快。沒有單一工具能在所有維度都贏。
- 失敗模式互補。Actor 在動態 UI 壞、agent 在動態 UI 撐；agent 在結構固定的任務慢、actor 在結構固定的任務飛快。混合用、兩者的失敗模式互相吸收、整體 reliability 比單一方案高。
- 組織決策層級不同。MCP 是工具層接駁、A2A 是 agent 編排、NLWeb 是網站層曝光、Browser-Use 是執行層。組織內不同團隊負責不同層、技術決策不該綁定。混合代表每層可以獨立選最適工具、不被單一框架鎖住。
這個原則跟我在多 AI 工具協作上的觀察一致：讓不同工具做它最強的事、人在中間做策略決策、不假設「無縫」是好事。微軟在 Browser-Use 課程明確說「blend agent and actor patterns」的時候、本質是同一條原則——分層 + 混合 + 顯性策略決策。
常見問題
MCP 跟傳統 API 有什麼不一樣？我為什麼需要 MCP？
傳統 API 是「我寫死 endpoint + 認證 + schema、API 變了我改 code」；MCP 是「我連 MCP server、它告訴我有什麼 tool 跟 schema、變了它告訴我」。差別在誰負責 schema 變動的同步——傳統 API 是 client、MCP 是 server。對單一穩定 API、MCP 是 over-engineering；對多個會變動的 internal service、MCP 顯著節省維護成本。判斷準則：你連的後端 API 一年改幾次？改超過 2 次以上、MCP 開始划算。
Browser-Use 跟 Selenium / Playwright 是什麼關係？
Browser-Use 不取代 Playwright、是蓋在 Playwright 上面的 vision agent 層。底層 Chrome 控制還是 Playwright + CDP；上層的「看畫面、決定下一步」是 Browser-Use 加的（用 Azure OpenAI vision 或其他多模態 LLM）。微軟的混合架構是兩者並用、共享同一個 Chrome session——不是二選一。
NLWeb 跟一般的 RAG 網站有什麼差別？
一般 RAG 是「網站文章被 embed、用戶查詢拿到 chunk 拼回答」——核心是內容檢索。NLWeb 進一步把網站本身（含結構化的 product catalog、tour list 等）做成可被自然語言查詢的接口、且自動是 MCP server。差別：RAG 服務的是有 chat UI 的用戶；NLWeb 服務的是用戶 + 外部 AI agent。網站老闆角度：RAG 是 site search 升級、NLWeb 是「讓我網站進入 agent 生態」。
原文出處：Microsoft AI Agents for Beginners — Lesson 11 Agentic Protocols（MCP / A2A / NLWeb）、Lesson 15 Browser-Use (CUA)