MCP 不只是新工具：AI 從對話層走向本地執行層的架構權衡
MCP 的真正意義，不是讓 AI 多接一個工具，而是把它從對話層推進到可操作本地系統的執行層。當 Agent 開始真正動手，架構競爭就會落在本地權限、可控性與雲端擴展之間的成熟權衡。
近年 AI 發展的焦點，正從純粹的對話能力，悄然轉向對本地系統的實際操作。Model-driven Co-pilot (MCP) 這類框架的出現，不僅是多了一個工具協議，它真正改變的，是將 AI 從對話層（conversation layer）推進到能夠執行任務的執行層（execution layer）。這意味著下一階段的競爭，不再只比模型本身多聰明，而是比誰能在本地權限、可控性與雲端擴展之間，做出更成熟、更安全的架構權衡。
過去一年多，我們已經習慣與大型語言模型（LLM）透過聊天介面互動，無論是 OpenAI 的 ChatGPT 或是 Anthropic 的 Claude。然而，這些互動大多停留在資訊的生成與總結。最近我看到一篇有趣的工程實踐紀錄，開發者嘗試利用 Claude CLI 搭配 MCP 伺服器，讓 AI 直接操作本地的業務應用程式。這個 PoC（概念驗證）雖然規模不大，卻精準地指向了 AI 應用的下一個演化方向：從「能說」到「能做」。當 AI 需要讀取本地檔案、啟動特定軟體，甚至在我們熟悉的 GUI 環境下執行任務時，整個系統的設計複雜度就提升了一個量級。
MCP 框架究竟是什麼？它為何重要？
MCP，全稱「模型驅動的協同駕駛艙」（Model-driven Co-pilot），並非指單一技術，而是一種創新的架構思想。它的核心在於建立一套標準化的介面，讓大型語言模型（LLM）能夠理解並進一步操作外部工具或應用程式。這與 Google Toolformer 研究中「讓模型學會使用工具」的概念不謀而合，也與 OpenAI 的 Function Calling 功能有異曲同工之妙。這些技術的共同目標，都是將 LLM 從一個單純的語言產生器，轉變為一個能與真實世界系統互動的「代理人」（Agent）。
MCP 的重要性在於，它將 AI 的能力從抽象的語言層，下沉到了具體的執行層。這意味著：
- 任務自動化： AI 不再只是提供操作步驟的文字建議，而是能直接執行這些步驟，例如整理下載資料夾中的檔案、在特定軟體中開啟報表並擷取數據。
- 情境感知： 透過存取本地系統，AI 能夠獲得更豐富的情境資訊（context），例如使用者正在使用的應用程式、最近開啟的文件等，從而提供更貼切的協助。
- 工作流程整合： AI 可以被整合進既有的工作流程中，成為一個無縫的數位助理，而不是一個需要來回切換視窗的獨立工具。
這個轉變的潛力巨大，但也帶來了全新的技術挑戰。其中最核心的，就是決定由誰來扮演呼叫 MCP 伺服器、真正執行命令的「主機」（Host）。
為什麼本地執行是下一階段的關鍵戰場？
當我們考慮讓 AI 操作電腦時，一個關鍵的架構決策是：執行命令的主機應該部署在雲端，還是使用者的本機電腦？傳統的 SaaS 服務大多採用雲端執行，但在 AI Agent 的場景下，本地執行（Local Execution）的價值變得不可忽視。
前述的 PoC 中，開發者就明確提到需要處理「ローカルファイルやローカルアプリ」（本地檔案與本地應用程式）。這點出了本地執行的最大優勢：權限。許多高價值的工作流程，都與儲存在本機的敏感資料、或是需要特定硬體環境才能運行的專業軟體（如 CAD、IDE 或影音剪輯工具）緊密相關。若將執行主機放在本地，AI Agent 就能：
- 無縫存取本地資源： 直接讀寫本機硬碟的檔案，無需經過上傳下載的繁瑣過程。
- 操作圖形介面應用： 透過螢幕辨識與模擬鍵鼠點擊，操作任何既有的 GUI 應用程式，打破 API 的限制。
- 保障資料隱私： 敏感資料可以在不出本機防火牆的情況下被處理，大幅降低外洩風險。
真正的挑戰不在於讓 AI 學會點擊按鈕，而在於設計一個既能賦予 AI 足夠權限，又不會打開安全潘朵拉盒子的穩健架構。
然而，本地執行也意味著我們必須面對權限控管、安全性、以及環境碎片化的三重挑戰。這正是下一階段 AI 系統設計者需要權衡的核心議題。
如何在本地權限與雲端擴展之間做出權衡？
選擇本地主機或雲端主機，並非一個非黑即白的決定，而是一個基於應用場景、安全需求與未來擴展性的光譜。我們可以從幾個維度來評估這個架構權衡：
| 考量維度 | 本地主機 (Local Host) | 雲端主機 (Cloud Host) |
|---|---|---|
| 資源存取 | 高（可存取所有本地檔案與應用） | 低（僅限透過 API 或網路存取） |
| 資料隱私 | 高（資料不離開本機） | 較低（需將資料傳輸至雲端） |
| 執行延遲 | 低（對於本地操作，反應時間可低於 100 毫秒） | 高（受網路與 API 延遲影響，通常在 1-5 秒） |
| 環境一致性 | 低（受使用者系統配置影響） | 高（標準化的執行環境） |
| 擴展與維護 | 困難（需在每台客戶端部署與更新） | 容易（集中管理與擴展） |
對於需要處理高度敏感資料、或與特定本地軟體深度整合的專業應用，本地主機可能是唯一的選擇。但對於需要大規模部署、跨裝置協作的通用型助理，雲端主機則更具優勢。更成熟的架構，或許會是兩者的混合體——一個輕量的本地代理程式負責處理敏感操作與本地互動，而主要的邏輯與模型推論則在雲端完成。這種類似 Microsoft AutoGen 框架中多 Agent 協作的概念，讓我們能夠在安全與彈性之間找到平衡。
從 MCP 這類框架的興起，我看到 AI 發展的重心正從模型本身，轉向承載模型的系統架構。未來 12 到 24 個月，能夠在本地權限的深度與雲端服務的廣度之間，提供創新且可靠架構的團隊，將會定義出下一代 AI 應用的樣貌。這不再只是演算法的競賽，更是系統工程與產品設計的深水區。
延伸閱讀
- Toolformer: Language Models Can Teach Themselves to Use Tools (arXiv)
- OpenAI Function Calling Official Documentation
- Microsoft Semantic Kernel Documentation
- AI Agents (Latent Space)
我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。