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的爭論繼續，除了協議之外，推理基礎設施和執行環境同樣值得關注。