為什麼越來越多的大廠拋棄 MCP，轉向 CLI？
=========================
前言--
最近在 AI 圈，有一個話題引發了巨大的爭論——「MCP 已死，CLI 稱王」。
從 Perplexity CTO 公開宣布放棄 MCP，到 Y Combinator CEO 直言「MCP sucks」，再到飛書、釘釘、企業微信等大廠紛紛選擇開源自家的 CLI 而非 MCP，一場關於 AI Agent 如何與外部世界互動的範式轉移正在發生。
MCP 是 Anthropic 在 2024 年底推出的協議，旨在解決 AI 模型與外部工具之間的溝通問題，一度被稱為 AI 界的「Type-C 介面」，月下載量一度超過 9700 萬次。
然而僅僅一年多後，這個曾經被譽為「產業希望」的協議，卻正在被越來越多的人拋棄。
今天這篇文章專門跟大家一起聊聊這個話題，希望對你會有所幫助。
更多專案實戰在 Java 突擊隊網：susan.net.cn
一、MCP 的底層原理
在理解 MCP 的問題之前，我們先看看它的工作原理。
MCP（Model Context Protocol）是一個用戶端-伺服器架構的協議，專門用來把外部工具（如檔案系統、資料庫、GitHub API）「包裝」成 AI 模型可以呼叫的函式。
MCP Server 啟動時，會透過 JSON-RPC 向 Client 發送一個 tools/list 訊息，裡面包含了該 Server 提供的所有工具的名稱、描述、參數 Schema。
Client 收到後，會在 AI 模型的系統提示詞中動態插入這些工具定義。
然後，當 AI 決定呼叫某個工具時，Client 會構造一個 tools/call 訊息，Server 執行後返回結果。
這個過程聽起來很標準，但問題恰恰出在「把所有工具定義塞進上下文」這一步。
二、MCP 的四大致命缺陷
2.1 上下文臃腫
還沒幹活，Token 已燒完。
MCP 的「全量載入」機制是它最根本的效能殺手。
下圖展示了 MCP 載入工具時的上下文構成：
連接 3 個 MCP Server，僅工具定義就佔用約 143K token。在 200K token 的模型上，72% 的上下文被工具定義吃掉。
對於 AI 來說，上下文視窗是它擁有的最寶貴的「房地產」，而 MCP 的設計下，Agent 還沒開始幹活，就已經「滿」了。
更嚴重的是，上下文中的無關內容越多，模型對真正重要內容的關注就越弱。
研究人員記錄了一個現象——「上下文腐爛」：隨著工具數量的增加，工具選擇的準確率從 43% 下降到 14% 以下。
矛盾的是，工具越多，工具的使用效果反而越差。
2.2 架構複雜
初始化不穩定，認證繁瑣。
MCP 的架構涉及多個獨立程序和網路邊界，每一步都可能出錯：
在實務中，MCP Server 經常無法正常啟動，有時需要反覆重試，有時甚至需要清空狀態推倒重來。
失敗跨越多個邊界——模型推理、協議轉換、網路呼叫、下游服務——任何一個環節出問題都可能導致整條鏈路失敗，排查極其困難。
有人調侃說：「配置 MCP 的時間，比寫程式的時間還長。」
認證方面同樣糟糕：使用多個 MCP 工具，就需要在每個工具上都重新走一遍認證。
各個服務的認證流程五花八門（OAuth2、API Key、個人存取權杖），Agent 無法統一管理，給開發者帶來極大的維運負擔。
2.3 安全風險：架構級的隱患
MCP 的威脅遠超大多數人的想像。
2026 年 1 月，CoSAI 發布了《MCP 安全白皮書》，指出 MCP 引入的架構級安全風險無法透過修補或配置修改來解決。
隨後 Netskope 的研究進一步證實，MCP 存在三類固有漏洞：
- 間接提示注入：攻擊者可以透過在共享文件或 API 回應中植入惡意指令，讓 MCP Server 在不知不覺中執行危險操作。
- 工具投毒：惡意 MCP Server 可以註冊名稱相似的工具，誘導 AI 呼叫錯誤工具。
- Rug Pull 攻擊：攻擊者先發布合法 MCP Server，累積信任後突然更新惡意程式碼。
安全研究人員已發現近 7,000 個暴露在公網的 MCP 伺服器，其中約半數沒有任何授權控制。
更令人擔憂的是，Cloudflare 的「Block AI Bots」設定（新網域預設開啟）會直接阻止 Anthropic 後端伺服器存取你的 MCP 端點，而且這個設定是全有或全無——無法只允許 Anthropic 而阻止其他 AI 爬蟲。
2.4 被動工具設計：Agent 無法自己探索
MCP 工具是「被動暴露」的：Server 提供什麼，AI 就用什麼。
Agent 無法主動發現新工具、無法探索更高效的用法。
而 Agent 真正需要的是能夠像人類開發者一樣主動探索和學習的能力。
例如，一個人類開發者想了解 gh 命令，會執行 gh --help；而 MCP 下的 Agent 只能等待開發者預先配置好所有工具。
三、CLI 的底層原理
為什麼「老古董」突然煥發第二春？
CLI（命令列介面）是電腦歷史上最古老的互動方式之一。
但恰恰是這種「古老」，讓它成為了 AI Agent 的理想操作介面。
Andrej Karpathy 在 X 上評價道：「CLI is super exciting precisely because they are legacy.」
3.1 漸進式發現，告別上下文污染
MCP 的問題是「開局全塞」，CLI 的做法是「按需載入」。
下圖展示了 CLI 的發現機制：
Agent 執行 gh --help 看有哪些命令，需要時再 gh pr --help 看子命令參數，最後才執行帶參數的命令。
資訊按需載入，不是開局全塞。有實測表明，CLI 方案比 MCP 方案便宜 17 倍，可靠性接近 100%。
更多專案實戰在 Java 突擊隊網：susan.net.cn/project
3.2 管道操作，組合能力強
MCP 工具回傳結果如果需要後處理，得寫額外程式碼。
CLI 直接透過管道（Pipe）就能搞定，這是 Unix 哲學的精髓：
Agent 輸出幾個命令用 | 串起來，後處理就搞定了。
更簡單、更靈活、維護成本更低。
3.3 LLM 天生就會用 CLI
LLM 的訓練資料裡包含了數十年的 Unix 文件、Stack Overflow 的回答、GitHub 上無數的 shell 腳本。
模型天生就認識 git、curl、grep、docker、kubectl。
你不需要給 Agent 寫複雜的工具 Schema，它自己就知道怎麼用。
3.4 可除錯性極強
當 AI 執行出錯時，工程師可以直接在終端機裡跑一遍同樣的指令，確認 AI 到底看到了什麼。
而在 MCP 的黑盒架構下，你只能去翻冷冰冰的 JSON 日誌。
3.5 生態成熟，穩定性高
CLI 有成熟的身分驗證體系（如 OAuth2、API Key），有標準化的錯誤碼和輸出格式（如 /dev/stdout、/dev/stderr、退出狀態碼），數十年的工程實踐已經讓它極其穩定可靠。
四、MCP vs CLI vs Skills 是什麼關係？
很多人覺得這三者是同一類東西，其實不是。它們分別解決不同層面的問題。
| 維度 | Skill | MCP | CLI |
|---|---|---|---|
| 核心作用 | 告訴 AI「懂什麼」 | 告訴 AI「怎麼接」 | 告訴 AI「怎麼做」 |
| 實作方式 | Markdown 指令檔 | JSON-RPC 協議 + Server | 標準化命令介面 |
| Token 消耗 | 極低（30-50 token 待命） | 極高（每個工具幾千 token） | 按需載入 |
| 穩定性 | 高 | 中（Server 易崩潰） | 極高 |
| 安全性 | 可控 | 架構級風險 | 成熟 |
| 除錯難度 | 低 | 高 | 極低 |
五、如何讓 AI 透過 CLI 幹活？
5.1 讓 Claude Code 操作 GitHub
安裝 GitHub CLI：
# macOS
brew install gh
# Linux (Ubuntu/Debian)
curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo dd of=/usr/share/keyrings/githubcli-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null
sudo apt update && sudo apt install gh
# Windows (winget)
winget install --id GitHub.cli登入：
gh auth login在 Claude Code 中使用：
在 Claude Code 中，直接告訴它用 GitHub CLI 操作：
用 GitHub CLI 查看我所有的 open 狀態 PR，列出編號和標題Claude Code 會自動執行：
gh pr list --state open --json number,title --jq '.[] | "\(.number): \(.title)"'5.2 進階：組合管道操作
找到所有包含「bug」的 PR，提取編號和建立者Claude Code 會執行：
gh pr list --state open --json number,title,author --jq '.[] | select(.title | test("bug")) | "\(.number) by \(.author.login)"'5.3 橋接工具：mcpkit
把 MCP Server「降級」成 CLI。
雖然 CLI 有很多優勢，但 MCP 生態中已經有大量現成的 Server，直接丟掉太可惜。
mcpkit 就是專門解決這個問題的——它是一個 MCP 用戶端，能把任何 MCP Server 變成 CLI 命令和輕量級 Agent Skills，零上下文膨脹。
安裝：
npm install -g @balakumar.dev/mcpkit安裝 GitHub MCP Server 作為 CLI 工具：
mcpkit install "npx -y @modelcontextprotocol/server-github" --name github呼叫工具：
mcpkit call github search_repositories '{"query":"mcpkit"}'5.4 橋接工具：unmcp
直接從終端機呼叫 MCP 工具。
unmcp 是一個更輕量的選擇，讓你直接從終端機呼叫 MCP Server 工具，沒有協議開銷。
安裝：
uvx unmcp呼叫工具：
uvx unmcp filesystem read_file --path "/tmp/example.txt"輸出為 JSON：
uvx unmcp filesystem --json read_file --path "/tmp/example.txt"六、大廠為何紛紛擁抱 CLI？
飛書開源了官方 CLI——200 多條指令，涵蓋 11 個業務領域，內建 19 種 Agent Skills。
Google 推出了用於 Google Workspace 的 gws CLI。
Zilliz 發布了 Zilliz CLI，讓你直接從終端機管理 Milvus 向量資料庫。
這些大廠的選擇揭示了一個趨勢：CLI + Skills 模式正在迅速成為企業級 Agent 工具的預設模式。
原因很現實：AI 要真正進入業務流程，就必須具備執行能力。
而 GUI 是為人類設計的，AI 在圖形介面上的操作效率很低。
CLI 的優勢在於命令清晰、無歧義、易自動化，對 AI 來說執行成本更低。
總結
MCP 並非「已死」，但它的適用範圍正在縮小。
CLI 也並非要「取代」MCP，兩者各有適用場景。
選擇 MCP：需要標準化協議、需要跨平台工具共享、有多 Agent 協作的場景。
選擇 CLI：追求極致效能、需要低成本、追求穩定可靠、AI 需要自主探索。
一個值得關注的趨勢是混合架構：用 CLI 處理高頻、簡單的執行任務，用 MCP 處理複雜的、需要標準化整合的場景。
而 mcpkit、unmcp 這類橋接工具，恰好讓這種混合架構成為可能。
對於大多數開發者來說，在 2026 年，CLI + Skills 的組合可能是最務實、最高效的選擇。
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
