AI 開發實戰

MCP vs CLI：為什麼這位開發者說 MCP「整個概念很蠢」？

MCP vs CLI 怎麼選？PSPDFKit 創辦人 Peter Steinberger 認為 CLI 更適合 AI Agent，解析他在 Clawdbot 的技術選型邏輯。

2026 年 1 月 29 日 · 來源： The Pragmatic Engineer Podcast

本文整理自 The Pragmatic Engineer Podcast 2026 年 1 月 28 日播出的單集，訪談 PSPDFKit 創辦人 Peter Steinberger。

當所有人都在談 MCP，他說「這整個概念很蠢」

MCP（Model Context Protocol）是這一年 AI 開發圈的熱門話題。Anthropic 推動的這個標準，讓 AI agent 可以透過統一的協定呼叫各種工具。很多人認為這是 AI 工具生態的未來。

但 Peter Steinberger 不這麼想。

在訪談中，主持人問他：「你為什麼用 CLI 而不是 MCP？」Peter 的回答很直接：「我覺得 MCP 最大的貢獻，是讓公司重新思考要開放更多 API。但這個協定本身？整個概念很蠢。」

這是一個很逆主流的觀點。讓我們聽聽他的理由。

Peter 解釋，MCP 的運作方式是這樣的：當你的 session 載入時，所有工具的所有函數、所有參數說明，全部都要先匯出來塞進 context。然後 AI 必須送出一個精確的 JSON blob 去呼叫工具，再收到 JSON 回來。

問題在哪？在於「模型其實很擅長用 Bash」。

他舉了一個例子。假設你有一個天氣服務的 MCP。AI 想知道：倫敦今天會不會下雨？但 MCP 的流程是這樣的：

整個過程，你的 context 被塞滿了一堆你根本不需要的資訊。500 個城市的列表？不需要。50 個天氣指標？只要降雨機率。但 MCP 沒辦法讓你過濾，因為那不是協定的一部分。

相比之下，如果是 CLI，AI 可以直接下這樣的指令：

weather london --fields rain_probability | jq '.rain_probability'

一行搞定，只拿需要的資訊，context 乾乾淨淨。

Peter 認為 CLI 對 AI 更友善的核心原因是：CLI 可以串接、可以過濾、可以寫成 script。

這是 Unix 哲學的精髓——每個工具做一件事，然後透過 pipe 串起來。AI 模型對這套模式非常熟悉，因為訓練資料裡充滿了這樣的 shell 命令。

但 MCP 做不到這件事。每次呼叫都是獨立的，你不能在 MCP 裡面說「先呼叫 A，把結果 pipe 給 B，再 filter 一下 C」。這種組合操作，你得讓 AI 自己在 context 裡做，消耗大量 tokens。

Peter 在 Clawdbot 裡走得更極端——他把幾乎所有功能都包成 CLI。Google 日曆？有 CLI。智慧家居燈泡？有 CLI。床的控制（對，他連床都能程式控制）？有 CLI。

這樣的好處是，他的 AI agent 可以自由組合這些工具，用它熟悉的方式（shell scripting）來完成複雜任務，而不是被 MCP 的框架限制住。

Peter 不是說 MCP 完全沒用。他承認 MCP 推動了一件好事：讓更多公司願意開放 API。以前很多服務是封閉的，現在因為 MCP 的熱潮，大家開始思考「怎麼讓 AI 能用我們的服務」。這是正面的影響。

另外，他也做了一個橋接方案。他寫了一個叫 MacPorter 的工具，可以把任何 MCP 轉成 CLI。所以如果有人做了一個很好用的 MCP，Peter 可以把它轉成 CLI 格式，然後用他習慣的方式呼叫。

這個做法很務實——他不是說 MCP 生態裡的東西都不能用，他只是不想被 MCP 的協定框架限制住。

聽完 Peter 的論點，我有一些想法。

首先，他的觀點在技術上是成立的。MCP 確實會產生額外的 context 負擔，而 CLI 的 pipe 模式確實更適合組合式的操作。對於他這種「一個人跑 10 個 agent 同時做不同事情」的工作模式，最小化每個 agent 的 context 消耗確實很重要。

但另一方面，MCP 解決的問題是「標準化」。在沒有 MCP 之前，每個服務的 API 格式都不一樣，AI 要學怎麼用每個工具，成本很高。MCP 提供了一個統一的界面，讓 AI 可以用一致的方式操作不同工具。這對於「讓 AI 能用更多工具」這件事，是有價值的。

Peter 能繞過這個問題，是因為他自己控制所有的 CLI。他可以確保每個 CLI 的設計風格一致、輸出格式標準化。但如果你要用第三方服務，你就得接受它們的 API 設計。這時候 MCP 的統一界面就變得有意義。

所以這不是「CLI 對、MCP 錯」的問題。這是一個架構選擇——取決於你的使用情境、你對 context 效率的要求、你能控制多少工具的設計。

Peter 選擇 CLI，是因為他有能力（也有意願）把所有工具都包成 CLI。對大多數人來說，用現成的 MCP 可能還是比較省事。

Peter 的案例給我的最大啟示是：不要因為某個技術很熱門，就假設它適合你。

MCP 很熱門，但 Peter 分析過利弊之後，決定走另一條路。他不是為了標新立異，他是因為 CLI 更適合他的工作流程。

這種「先搞懂原理，再決定要不要用」的態度，其實是資深工程師最寶貴的能力之一。新技術一直出來，但並不是每個都適合你。能夠看穿 hype，做出適合自己的選擇，比盲目追新更重要。

你可能沒辦法像 Peter 一樣把所有東西都包成 CLI。但至少，在選擇工具的時候，你可以問自己：這個工具解決的問題，真的是我的問題嗎？還是我只是因為大家都在用，所以跟著用？