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的争论继续，除了协议之外，推理基础设施和执行环境同样值得关注。