MCP已死
一句话看懂：AI编程助手Claude Code背后的公司Quandri通过实测发现，MCP（模型上下文协议）在工具调用中消耗大量上下文窗口、性能显著低于直接调用CLI/API，且与现有工具链存在功能重叠。团队已转向基于Skills+CLI的轻量方案，将MCP从日常开发流程中基本淘汰。
事件核心：发生了什么
Quandri团队在博客中披露，他们在实际生产环境中测量了多个MCP服务器（Linear、Notion、Slack等）的资源消耗。仅4个MCP服务器连接时，工具定义本身占据10.5%上下文窗口；Linear一个服务就贡献超过12,800 token、42个工具定义，哪怕用户只频繁使用其中2个。性能对比显示，Jira MCP的每次调用比直接调REST API慢3倍，首次调用含初始化则慢9.4倍。查询同一Linear Issue时，MCP消耗的token是直接使用CLI方式的约65倍。即便Claude Code后续推出“延迟加载”功能将工具定义上下文使用量减少85%以上，团队认为MCP在性能、调试和架构层面的根本问题依然存在。
为什么重要
MCP自2024年底推出后被包装为“AI生态的USB-C”，大量SaaS产品将“MCP支持”列为市场宣传卖点。但Quandri的实证数据直接挑战了这一叙事：它并非轻量标准，反而因过度加载工具定义、增加进程层而导致严重的上下文浪费与延迟。对于依赖大模型上下文窗口的Agent类应用而言，10%+的固定开销是大模型推理预算中不可忽视的损耗。这意味着，在开发者最关注的实际效率场景中，MCP可能正在成为与早年“AI驱动”“区块链”类似的营销热词，而非技术最优解。Quandri提出的替代方案——将CLI使用指令嵌入Skills，按需加载对应命令——在token消耗和稳定性上均优于MCP，代表了一种更务实的工程路线。
对用户/开发者/创作者的影响
开发者：如果你正在构建AI编程助手或Agent工作流，建议重新评估MCP的ROI。对已有CLI且本地认证成熟的工具（如GitHub、Linear），直接复用CLI+API通常比配置MCP服务器更高效、更易调试。MCP在需要统一认证、数据库交互或跨语言工具集成时仍有效，但不应作为默认优先方案。创作者/AI应用用户：如果你使用基于MCP的AI工具发现响应慢、频繁崩溃或上下文不够用，原因可能不是模型不够强，而是底层协议消耗过大。选择工具时，优先关注其是否支持按需加载工具指令，而非机械地看是否标榜“支持MCP”。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
1. MCP协议迭代方向：Claude Code已推出延迟加载以缓解上下文膨胀，其它MCP实现是否会跟进相同思路，以及能否从根本上解决进程层性能损耗。
2. Skills方案商业验证：Quandri的Skills+CLI模式是否会被更多AI Agent产品（如Cursor、Continue、GitHub Copilot）采纳为标准工作流。
3. SaaS厂商策略分化：当下一个开发者生态逐步意识到MCP的代价后，“MCP支持”标签是否还会保持当下的营销热度，或者会被更轻量的协议（如直接API+指令嵌入）所取代。
