Cerebras 谈 MCP 与 CLI 之争：推理基础设施和代码执行环境同样关键

2026年4月6日

MCP经历了成长的一年。随后又经历了动荡的一周。

Perplexity CTO Denis Yarats在Ask 2026登台宣布，Perplexity将弃用MCP……回归API和CLI。

Twitter立刻分裂成两个阵营。

这并不令人意外，因为MCP从2024年11月由Anthropic推出的开放标准，在短短十三个月内就发展为行业广泛采用、月下载量超过9700万次（1），覆盖众多公司和平台。

然而，作为一家知名AI公司，Perplexity却选择弃用它。

MCP的开销并非随意设定。该协议的工作方式是（2）引导模型交互沿着特定、可审计的路径进行：每次工具调用都携带完整的schema定义，每次认证握手都端到端执行，每一步都要等前一步完成后才开始下一步。这种可预测性正是企业部署所需要的。

但这是有代价的：在多步骤工作流中，每个结构化步骤都会增加延迟，而这些成本会在长长的工具调用链中不断累积。

为这一转变叫好的人认为，MCP的token开销是一种有害的约束，会拖慢运行时，而且随着接入的工具越多，情况越糟。具体来说，来自DevCommunity的Samir Amzani指出，（3）仅连接GitHub、Slack和Sentry三个服务，就能在agent读取任何一条用户消息之前，向MCP上下文窗口塞入超过55,000个token的工具定义，token用量比CLI高出3-42倍（4）。

然而，支持者在承认MCP延迟问题的同时，也指出了开发者转向CLI会失去什么。CLI轻量且快速，但它们是静态的，只能调用被明确编程使用的工具，要求开发者为每个服务单独管理认证，并且没有用于可观测性或调试的共享协议层。

Perplexity随后并未给出官方解释，但这一分歧反映了真实的开发需求：对延迟要求更快的团队可能会觉得CLI更实用，而优先考虑可观测性和生产安全的团队则可能认为MCP的结构值得这些开销。

转向CLI和API确实解决了一些问题：token开销下降，每步延迟改善。然而，它并不能解决所有问题。一些根本性约束，例如规模化时延迟叠加和不安全的代码执行，并不能通过更换接口得到完全解决。

而这些更深层的约束指向两个值得审视的领域：推理基础设施和代码执行环境。

一个考量点在推理基础设施，更快的推理直接针对延迟问题。为低延迟AI工作流设计的新芯片架构，例如Cerebras的晶圆级引擎（5），将模型权重保存在跨晶圆的片上内存中，而非依赖片外内存，从而消除了传统GPU推理的内存瓶颈。其结果是最高可达每秒3,000个token（6），或比传统基于GPU的方案快约15倍（7），具体取决于模型。

这种速度改变了对MCP的权衡。将更快的推理与真实的MCP服务器搭配使用——GitHub提供代码上下文、Slack提供团队数据、Atlassian提供项目状态——每次工具调用的延迟成本都会显著缩小。当底层推理足够快时，曾让MCP显得不实用的开销就变得更容易管理。

对于优先看重MCP可审计结构的企业来说，这一点很重要：更快的推理并不需要牺牲安全层。它只是让整个技术栈——包括工具调用在内——在生产环境中更加可行。

另一个考量点在安全代码执行。运行agent生成的代码需要在安全与速度之间权衡。

Monty（8）是Pydantic发布的用Rust编写的最小Python解释器，它采取不同做法，将范围保持得很小。Monty不启动容器，也不暴露完整运行时，只运行agent所需的内容：除非明确授权，否则没有文件系统访问、没有网络调用、没有环境变量，并且仅在外部调用需要授权时暂停。由于解释器极小，提示注入的攻击面也相应很小。

启动时间低于0.06ms，相比之下Docker为195ms，沙箱服务则超过1,000ms（9）。不过，Monty仍处于实验阶段，仅支持部分Python子集，且不支持第三方库，因此尚未达到生产就绪。但蓝图已经在那里，可供进一步迭代和开发。

推动MCP与CLI之争的挫败感是真实的。token开销、迟缓的工作流、运行agent生成代码的风险——这些都没有争议。但如何加速体验的很大一部分也取决于推理基础设施和执行环境，而不仅仅是协议本身。而且这些改进并非MCP独有，CLI工作流同样可以变得更快。

Perplexity针对真实约束做出了务实的选择，许多默默转向CLI的团队也是如此：因为MCP感觉太慢。许多其他团队同样坚持使用MCP。鉴于各自具体的开发需求，两者都是合理的决定。

随着MCP与CLI之争继续，抛开协议不谈，推理基础设施和执行环境同样值得关注。

致谢：感谢Sarah Chieng（@MilksandMatcha）、Sherif Cherfa（@0xSero）、James Wang（@draecomino）、Ryan Loney和Sebastian Duerr的审阅和富有洞见的反馈。感谢Chris Kim提供图形支持，感谢Sneha Khanvilkar和Tin Hoang提供编辑支持。

性能比较基于第三方基准测试或内部测试。与基于GPU的系统相比，观察到的推理速度提升可能因工作负载、配置、日期和所测试的模型而异。

1237 E. Arques Ave Sunnyvale, CA 94085