MCP 的死亡不在技術，在成本曲線

Perplexity 放棄 MCP 不是因為協議設計差，而是當模型足夠聰明且成本夠低時，直接調用比標準化協議更划算。

23 3月 2026 • 3 min read

協議的宿命

Perplexity 決定放棄 MCP（Model Context Protocol），轉向直接調用 CLI，這件事本身不稀奇。稀奇的是它代表什麼：當一個主要玩家開始簡化工具鏈時，通常不是因為技術不行，而是因為成本結構改變了。

MCP 在 2024 年底推出時，解決的是一個真實問題：如何讓 AI 模型以標準化的方式訪問外部工具和資料源。它承諾了互操作性、安全邊界、版本管理——聽起來都很合理。但在生產環境裡，這些特性帶來的維護成本，開始超過它們的價值。

每多一層抽象，就多一層故障面。MCP 需要：

這在模型成本持續下降、推理速度持續提升的時代，變成了一筆不划算的帳。直接用 CLI 呼叫，省去中間層的轉換損耗和維護負擔，反而更快、更便宜。

這不是 MCP 設計不好。這是一個經典的技術棧簡化：當下游變得足夠聰明和便宜時，上游的協議層就會被繞過。

這個轉向說明了什麼：

協議的生命週期取決於成本邊界。 MCP 假設模型調用成本高且不穩定，所以值得用協議層來優化。但如果成本下降到某個臨界點，直接調用變成最優解。

工具集成的未來可能不在標準化協議，而在 LLM 能直接理解的東西。 如果模型足夠聰明，能從文件或 CLI help 推斷出怎麼用工具，那為什麼還要協議？

這對正在投資 MCP 的人意味著什麼？ 不是說別用，而是要清楚自己在解決什麼問題。如果問題是「我的模型太差，需要協議來幫它」，那這個投資的保質期可能比想像中短。

我要老實說：我沒看到 Perplexity 的具體技術決策文件。T客邦的標題有點聳動，「棄坑」這個詞可能言過其實。但趨勢是真的——當工具鏈簡化能直接降低成本和延遲時，複雜的協議層確實會被重新評估。

關鍵問題是：你現在投入的 MCP 相關工作，是在解決一個會隨著模型進化而消失的問題，還是一個長期存在的問題？

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。