MCP 已死？為什麼 AI Agent 最後可能還是要回到 CLI

一句話結論：最近社群開始喊 「MCP is dead, embrace CLI」，這句話不是完全錯，但也不夠完整。更準確的說法是：在 coding agent 與 terminal-first 場景，CLI 確實常常比 MCP 更強；但在跨產品整合、非 shell 環境、權限治理與平台化場景，MCP 仍然有位置。 真正值得看的不是 MCP 有沒有死，而是 AI agent 的工具層正在分裂成兩條路。

Premise（前提）

1. 你最近已經開始看到 MCP is dead、embrace CLI、MCP vs CLI 這些說法，想知道它們到底在吵什麼。
2. 你關注的不只是某個工具好不好用，而是 AI agent 的工具層到底會往哪個方向收斂。
3. 你是開發者、產品人，或對 AI 產業方向有判斷需求的人，不想把社群情緒直接當結論。
4. 你接受：這篇不是 tutorial，也不是單純 benchmark，而是幫你拆清楚 CLI 為什麼突然重新變成主角。
5. 你想知道接下來一年，agent 工作流的主戰場比較可能長在 shell、協議、還是兩者共存。

Exclusions（排除）

1. 你現在只想知道怎麼設定 MCP server 或怎麼包 CLI 工具：你需要的是實作教學，不是這篇。
2. 你只想看 token benchmark 表：這篇不是做數據彙編，而是做取捨判讀。
3. 你完全不在意 coding agent、tool calling、權限邊界與工作流：那這個題目對你現在的價值有限。
4. 你要的是某一方全面勝利的爽文：這篇的主張剛好相反，我認為這場爭論本質上是場景分層。
5. 你只想聽單一標準通吃：這篇會直接說，agent 世界短期內更像雙軌，而不是一統江湖。

為什麼最近大家開始說「MCP 已死」？

這句話會紅，不是因為大家突然討厭標準，而是因為越來越多人發現：

對 coding agent 來說，CLI 常常真的更直接。

你把常見情境攤開來看，就不難理解：

• 要看 GitHub PR：gh pr view
• 要查 k8s：kubectl get
• 要跑 Terraform：terraform plan
• 要篩資料：jq、awk、sed
• 要串工作流：pipe、redirect、exit code

這些東西對 terminal-native agent 來說有幾個明顯優勢：

• 模型本來就很熟 CLI 語境：man page、Stack Overflow、README、shell script 早就餵過一大堆。
• 不需要額外 schema 注入：很多 CLI 工具直接下指令就能用，不像 MCP 常要先把工具描述帶進 context。
• debug 比較直觀：stdout、stderr、exit code、pipe 結果都清清楚楚。
• composability 更強：Unix 世界本來就很擅長把小工具串成大流程。

所以當開發者開始真的拿大量 agent 任務去跑，他們自然會問：

我為什麼要繞一層 MCP，不直接讓 agent 用 CLI？

這就是「MCP 已死」這句話真正的情緒來源。

先講我的主張：這不是 MCP vs CLI 的輸贏，而是場景分層

我不認為 MCP 會直接消失，也不認為 CLI 會全吃。
我更相信，接下來會越來越清楚地分成兩條路：

• terminal-first / coding agent / 本機開發工作流：CLI 更常是主角
• 產品化 agent / 多租戶整合 / 非 shell 環境 / 權限治理：MCP 這類協議仍然有必要

換句話說，現在最值得看的不是「哪個協議終結誰」，而是：

哪一類 agent，最後會把哪一種工具接法變成預設。

這也是為什麼這個題目其實比表面上更有產業意義。因為它不是在吵工具好不好，而是在吵：

• 控制面要放在哪裡？
• agent 能力要透過什麼形式暴露？
• 誰來掌握整合成本、權限邊界、與產品體驗？

為什麼 CLI 在 coding agent 場景真的很難輸？

1. 模型對 CLI 有先天優勢

這一點其實不用神化也不用貶低，現實就是：

• 大量公開技術文件都是 CLI 語境
• 命令、參數、輸出格式已經被重複學了很多遍
• shell 命令通常比抽象 schema 更接近真實操作

所以對 coding agent 來說，CLI 不是 retro，而是 最接近模型既有語言能力的介面。

2. CLI 的回饋回圈更短

如果你真的在 terminal 裡做事，CLI 有非常強的即時回饋：

• 指令成功或失敗
• exit code
• stderr
• stdout
• 可重試的命令歷史

這種 feedback loop 對 agent 很重要，因為它可以快速：

• 修正參數
• 重跑
• 改變 pipe
• 根據錯誤訊息自我修復

而這剛好就是 coding agent 最常做的事情。

3. CLI 原生就支援組合

很多 MCP 支持者講的是「標準化」，但很多 CLI 使用者真正愛的是「組合性」。

像這種東西：

terraform show -json | jq '.values.root_module'

或：

gh pr view 123 --json files | jq '.files[].path'

本來就是 Unix 世界的強項。
當 agent 需要動態拼接工作流時，CLI 往往比很多結構化協議更靈活。

那 MCP 到底哪裡輸了？

如果你問的是：為什麼最近很多開發者對 MCP 失去耐心？
我會認為主因通常不是理念，而是成本。

1. 成本感太明顯

對很多本機 agent 任務來說，MCP 的問題不是不能做，而是：

• 要先有 server
• 要有 transport
• 要處理 tool schema
• 要處理 server process
• 出事時還要排查是 client、schema、transport，還是 server 本身壞掉

對只想把事情做完的開發者來說，這層抽象很容易被感知成多餘。

2. 對 terminal-native agent 而言，它不一定更自然

如果 agent 本來就跑在 terminal，且本來就有權限：

• 呼叫 shell
• 讀 stdout/stderr
• 管理 process
• 使用已登入的 CLI 工具

那你很難說 MCP 比 CLI 更自然。
很多時候，反而是 MCP 在模擬一件 CLI 已經很擅長的事。

3. MCP 被過度吹成「萬用答案」

這也是 backlash 的來源之一。

MCP 最早紅起來時，很多人把它講得像所有 agent 的標準答案。但現實很快證明：

• 它不是 agent-to-agent 全解
• 它不是 UI 層全解
• 它也不是所有工具接法的最佳解

一旦社群先過度神化，後面就很容易出現反向情緒，開始喊「它已經死了」。

但我不會因此說 MCP 已死

這裡是我和很多「擁抱 CLI 派」最大差異的地方。

因為 CLI 很強，並不代表 MCP 沒價值。它們解的問題本來就不完全一樣。

1. 不是每個 agent 都活在 shell 裡

官方 MCP 文件現在已經直接列出 Claude、ChatGPT、VS Code、Cursor 等客戶端支援。這件事很重要，因為它提醒你：

• 有些 agent 在聊天產品裡
• 有些在 IDE 裡
• 有些在桌面 app
• 有些在瀏覽器或企業環境裡

這些地方不一定適合，也不一定能直接放一個全權 shell 給模型。

2. MCP 比較適合做「可治理的能力暴露」

對很多產品團隊來說，問題不是「能不能叫到工具」，而是：

• 能不能限制只暴露這幾個能力？
• 能不能讓不同 client 用同一種方式接？
• 能不能不要把整個 bash 權限直接交出去？
• 能不能做更清楚的工具描述、驗證、與治理？

這種需求下，MCP 這類結構化協議就不是多餘，而是產品化必要成本。

3. 跨產品互通這件事，CLI 不一定能替代

OpenAI 的開發文件已經直接教人怎麼建 remote MCP server 給 ChatGPT apps 與 API integrations 用。
這代表至少在某些產品化情境裡，主流公司不是在放棄 MCP，而是在把它吸進自己的平台。

所以我會這樣總結：

MCP 沒死，它只是失去了「所有場景都該先用我」的神話。

真正的分水嶺：你是在做 developer tool，還是在做 platform product？

這場爭論真正有價值的地方，是它幫你把兩種完全不同的 agent 類型分開來看。

如果你在做 developer tool / coding agent

你大概率更該先想 CLI：

• terminal 本來就是你的主場
• 工具本來就以 CLI 存在
• agent 需要高頻試錯與短回饋回圈
• 你想要最少抽象、最快落地

這種情況下，CLI 很可能就是你真正的 control plane。

如果你在做 platform product / 多租戶整合

你大概率不能只想 CLI：

• 你需要可控的能力邊界
• 你需要可重複整合不同 client
• 你需要更結構化的暴露方式
• 你可能根本不在 shell 環境

這種情況下，MCP 這種協議仍然合理。

如果你在看產業戰

那你應該得到的不是「CLI 贏了」這種過度簡化結論，而是：

AI agent 世界正在從單一路線，分裂成 terminal-native 路線與 protocol-native 路線。

這才是真正值得追的變化。

那 A2A、AG-UI 還重要嗎？

重要，而且剛好證明「MCP 不是全部」。

如果你把 agent stack 分層來看，大致會變成：

• agent-to-tool：MCP
• agent-to-agent：A2A
• agent-to-user interaction：AG-UI

這也剛好說明，為什麼把 MCP 神化成整個 agent 世界的標準，本來就是過度延伸。

反過來說，因為未來 stack 會分層，CLI 的崛起也不代表協議層不存在。
它比較像是在說：

在 developer-heavy 場景，最底層那一層不一定要再抽象一次。

我現在真正的判斷：CLI 會贏下 coding agent，MCP 會留在平台層

如果你逼我押一個方向，我會這樣押：

• coding agent / developer workflow：CLI 的優勢會越來越明顯
• 產品化整合 / 企業連接層：MCP 不會消失，反而會留在更平台化的位置

這其實和很多技術標準的命運很像：

• 最底層高頻操作，常常回到最直接的 interface
• 跨系統互通與治理，則需要更結構化的協議

所以接下來真正會輸掉的，不是 MCP 本身，而是下面這種說法：

所有 agent 都應該先用 MCP

我認為這句話會越來越站不住。

我願意承認的反方

我也不會說 CLI 就完全沒風險。

因為把 shell 權限直接交給 agent，本來就有代價：

• 權限外擴風險
• shell injection / command misuse
• 對非技術產品不友善
• 難以直接變成跨 client 的可治理標準

所以如果有人把風向直接下成：

CLI 是終局，MCP 完全沒價值

我也不會跟。

我比較願意接受的版本是：

CLI 在開發者工具場景更強，MCP 在平台與整合場景仍然合理

最後的低後悔建議

如果你只想抓最實用的結論，我會這樣建議：

1. 如果你在做 coding agent，先把 CLI 想清楚：不要一開始就假設 MCP 是預設答案。
2. 如果你在做產品化整合，別太快丟掉 MCP：你之後很可能還是會需要某種可治理的協議層。
3. 不要把社群口號當結論：MCP is dead 很有傳播力，但真正重要的是「在哪個場景裡它輸了」。
4. 重新理解 AI agent 戰爭：這不是單純模型戰，也不是單純標準戰，而是不同場景在爭奪自己的預設控制面。

如果你問我這篇真正想給你的結論是什麼，我會用一句話收掉：

MCP 沒死，但在 developer-heavy 的 agent 世界裡，CLI 正在奪回它原本就很擅長的控制面。

資料來源說明

本文主要根據以下公開資料整理：

• OpenAI：New tools for building agents
• OpenAI Developers：Building MCP servers for ChatGPT Apps and API integrations
• Model Context Protocol 官方文件：What is MCP? 與 clients 清單
• Google / A2A 官方 README 與 a2a-protocol.org
• AG-UI 官方文件
• 近期關於 MCP vs CLI 的社群討論與公開文章

這類討論變化很快，而且不同陣營講的常常其實不是同一種場景。這篇更適合拿來建立判讀框架，而不是拿來替某一邊做最終宣判。