OpenBuild 导读：
在 AI 智能体工具调用的赛道上，MCP 与 CLI 的路线之争从未停歇。一方凭借结构化、可审计的优势成为企业级首选，另一方则以轻量低延迟占据效率高地。而随着 Perplexity 公开宣布弃用 MCP、回归 CLI 与 API，这场技术路线的辩论被彻底推向高潮。双方分歧看似围绕协议展开，实则核心都指向同一个关键指标：速度。
原标题：The Debate of MCP vs. CLI Centers on Speed.
MCP 走过成型之年，却在一周内陷入巨大争议。
https://x.com/morganlinton/status/2031795683897077965
在 Ask 2026 大会上，Perplexity CTO Denis Yarats 登台宣布：Perplexity 将弃用 MCP，重新回归 API 与 CLI 方案。
消息一出，社区立刻分成两大阵营。
这并不令人意外。毕竟 MCP 最初只是 Anthropic 在 2024 年 11 月推出的一项开放标准，却在短短 13 个月内实现全行业普及，横跨多家公司与平台，月下载量突破 9700 万。而现在，一家头部 AI 公司却选择退出。
https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-Agentic-ai-foundation
MCP 的额外开销并非毫无意义。该协议的设计思路，是把模型交互约束在明确、可审计的固定路径上：
每次工具调用都会携带完整的 Schema 定义
每次鉴权握手都走完整端到端流程
每一步执行都必须等待上一步完成
这种强规范性与可预测性，正是企业级落地所需要的。
但代价也显而易见：在多步工作流中，每一个结构化步骤都会引入延迟，延迟会在一连串工具调用中不断累积。
支持 Perplexit 这一决定的人认为：MCP 的Token 开销过高，严重拖慢运行时性能，而且接入工具越多，问题越严重。
DevCommunity 的 Samir Amzani 给出了一个直观对比：只接入 GitHub、Slack、Sentry 三个服务，MCP 在上下文窗口中就会塞入超过 55,000 个 Token 的工具定义，甚至早于模型读取用户消息。其 Token 占用是 CLI 的 3～42 倍。
尽管承认 MCP 存在延迟问题，但其支持者指出，切回 CLI 会让开发者失去一系列关键能力。CLI 确实轻量、快速，但也高度静态：
只能调用预先写死在代码里的工具
每个服务都需要开发者单独维护鉴权
没有统一的协议层来做可观测性与调试
Perplexity 并未发布官方解释，但这场分歧本质上反映了真实的工程需求差异：
切换到 CLI 和 API 确实能解决一部分问题：Token 开销下降，单步延迟降低。但这并不能解决所有问题。一些更底层的约束 —— 比如大规模场景下的延迟叠加、不安全的代码执行 —— 并不能靠简单替换接口来彻底解决。
这些更深层的问题，指向两个更值得关注的方向：推理基础设施与代码执行环境。
一个核心思路是优化推理底层，直接解决延迟问题。Cerebras 晶圆级引擎等新一代低延迟 AI 芯片架构，可以将模型权重保持在片内存储，而不依赖传统 GPU 的片外内存，从而消除内存瓶颈。
效果显著：推理速度最高可达 3000 Token / 秒，相较传统 GPU 方案提升约 15 倍（视模型而定）。
这会直接改变 MCP 的性价比。当推理足够快时，搭配 MCP Server、GitHub 代码上下文、Slack 团队数据、Atlassian 项目状态等工具，每次调用的延迟成本会大幅降低。曾经让人难以接受的开销，会变得可以接受。
对于优先选择 MCP 可审计性的企业来说尤为重要：更快的推理不必牺牲安全层，只是让整套工具调用栈在生产环境真正可行。
https://artificialanalysis.ai/models/glm-4-7/providers
另一个方向是安全代码执行。运行智能体生成的代码，本质是在安全与速度之间做权衡。
Pydantic 推出的 Monty—— 一个用 Rust 编写的极简 Python 解释器 —— 选择了另一条路：最小化执行域。它不启动容器，也不暴露完整运行时，只执行智能体真正需要的逻辑：
无文件系统访问
无网络调用
无环境变量，除非显式授权
仅在外部调用需要授权时暂停
因为解释器极度精简，提示注入的攻击面也大幅缩小。
启动时间低至 0.06 毫秒，对比之下：Docker 为 195 毫秒，通用沙箱服务超过 1000 毫秒。
当然，Monty 仍处于实验阶段，仅支持部分 Python 子集，暂无第三方库支持，暂不适合生产。但它已经给出了清晰可行的演进方向。
https://modelcontextprotocol.io/docs/getting-started/intro
https://github.com/pydantic/monty
围绕 MCP vs CLI 的痛点都是真实存在的：Token 开销大、执行链路慢、运行智能体代码有风险…… 这些并无争议。但很大一部分性能提升空间，其实在于推理基础设施与执行环境，而不只是协议本身。而且这类优化并非 MCP 专属，CLI 同样可以受益。
Perplexity 是基于现实约束做出的务实选择，很多转向 CLI 的团队也是如此：因为 MCP 太慢了。与此同时，也有大量团队坚定留在 MCP 生态中。
基于各自的业务需求，两种选择都合理。
在 MCP 与 CLI 的争论持续之际，抛开协议本身，推理基础设施与代码执行环境同样值得行业重点关注。
原文：https://x.com/cerebras/status/2041300697258590590
作者：@cerebras
（OpenBuild 翻译整理，原文有删减）
👇欢迎加入 OpenBuild 开发者交流群，第一时间获取技术干货、最新行业动态！
粤ICP备14082021号
免费POC，
零成本试错
