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