MCP vs CLI爭論：速度之爭背後的推理基礎設施與安全執行

2026年4月6日，在Perplexity的Ask 2026大會上，CTO Denis Yarats宣佈Perplexity正在從MCP（模型上下文協議）轉向API和CLI（命令列介面）。這一訊息立即在Twitter上引發了兩極分化的討論。

MCP自2024年11月由Anthropic作為開放標準推出以來，在13個月內月下載量超過9700萬次，被眾多公司和平臺採用。然而，Perplexity作為一家知名AI公司，卻選擇了放棄它。

MCP的開銷並非任意為之。該協議透過引導模型互動沿著特定、可審計的路徑工作：每個工具呼叫都攜帶完整的模式定義，每次身份驗證握手端到端執行，每一步都等待上一步完成。這種可預測性正是企業部署所需要的。但代價是，在多步驟工作流中，每個結構化步驟都會增加延遲，這些成本在長鏈工具呼叫中累積。

反對MCP的人認為，令牌開銷是一個有害的限制，會減慢執行時速度，並且隨著連線更多工具而惡化。例如，DevCommunity的Samir Amzani指出，連線GitHub、Slack和Sentry三個服務，就會在MCP上下文視窗中放入超過55,000個令牌的工具定義，然後代理才能讀取使用者訊息，令牌使用量比CLI高出3到42倍。

然而，支持者指出，轉向CLI意味著放棄許多好處。CLI輕量且快速，但它們是靜態的，只能呼叫顯式程式設計的工具，要求開發者為每個服務單獨管理身份驗證，並且沒有用於可觀察性或除錯的共享協議層。

Perplexity沒有給出官方解釋，但分歧反映了實際開發需求：需要更低延遲的團隊可能發現CLI更實用，而優先考慮可觀察性和生產安全性的團隊可能認為MCP的結構值得開銷。

轉向CLI和API確實解決了一些問題：令牌開銷下降，每步延遲改善。但它不能解決所有問題。一些根本性限制——如大規模下的複合延遲和不安全的程式碼執行——並不能透過交換介面完全解決。

這些深層限制指向兩個值得關注的領域：推理基礎設施和程式碼執行環境。

更快的推理

更快的推理直接針對延遲問題。新晶片架構（如Cerebras的晶圓級引擎）將模型權重保留在晶圓上的片上記憶體中，而不是依賴片外記憶體，從而消除了傳統GPU推理的記憶體瓶頸。結果是高達每秒3000個令牌，比傳統GPU解決方案快15倍。

這種速度改變了MCP的計算方式。將更快的推理與真正的MCP伺服器（如GitHub用於程式碼上下文，Slack用於團隊資料，Atlassian用於專案狀態）配對，每個工具呼叫的延遲成本顯著降低。當底層推理足夠快時，MCP的開銷變得可管理。

對於優先考慮MCP可審計結構的企業來說，這意味著更快的推理不需要放棄安全層，只是使整個堆疊（包括工具呼叫）在生產中更可行。

安全程式碼執行

執行代理生成的程式碼需要在安全性和速度之間權衡。Monty是一個基於Rust的微型Python直譯器，由Pydantic釋出，它透過保持較小範圍來採取不同方法。Monty只執行代理需要的內容——沒有檔案系統訪問，沒有網路呼叫，沒有環境變數（除非明確允許），僅在外部呼叫需要授權時暫停。由於直譯器極小，提示注入的攻擊面也相應較小。啟動時間低於0.06毫秒，而Docker為195毫秒，沙箱服務超過1000毫秒。不過，Monty仍是實驗性的，只支援部分Python子集，沒有第三方庫支援，尚未準備好投入生產。但藍圖為進一步迭代和開發奠定了基礎。

這些改進對MCP和CLI都有利。驅動MCP與CLI爭論的挫折是真實的——令牌開銷、緩慢的工作流、執行代理生成程式碼的風險——但如何加速體驗的很大一部分也在於推理基礎設施和執行環境，而不僅僅是協議本身。

Perplexity的決策是務實的，許多團隊悄悄轉向CLI也是如此：因為MCP感覺太慢。同樣，許多其他團隊堅持使用MCP。考慮到各自的開發需求，兩者都是合理的決定。

隨著MCP與CLI的爭論繼續，除了協議之外，推理基礎設施和執行環境同樣值得關注。