文章核心观点 - MCP协议在推出一年多后正走向消亡，行业领先公司如Perplexity和Duetchat已放弃或删除对其的集成，其根本原因在于协议设计存在天生缺陷，尤其是在线性上下文成本、使用效率及可调试性方面表现不佳，而传统的CLI和API方案被证明是更优选择[3][4][8][9][11][14][17] MCP协议的现状与行业态度 - MCP协议由Anthropic于2024年11月推出，旨在成为大模型通信和交互的标准协议，但推出一年多后已声量微弱，甚至其“一周年纪念日”也在一片寂静中度过[3] - 行业对MCP的质疑始终存在，包括“builder多于user”和“旧瓶装新酒”的批评[3] - Perplexity的联合创始人兼CTO Denis Yarats在公司内部表示，正在放弃MCP，转而使用API和CLI[4] - 曾全面支持MCP集成并实现了OAuth和动态客户端注册的AI聊天工具Duetchat，在其v2版本中彻底删除了MCP功能[8] - Y Combinator总裁兼CEO Garry Tan公开批评“MCP sucks”，随着Skills逐渐占据智能体应用主场，MCP似乎早该消失[9] MCP协议的技术缺陷与问题 - **线性上下文成本高昂**：MCP协议要求将每个工具的名称、描述、参数Schema和示例都注入Agent的上下文窗口，若连接10个服务且每个服务有5个工具，在任务开始前就可能消耗掉数千个Token，极大地挤占了宝贵的上下文窗口资源[11] - **使用模式难以为继**：为应对高成本，用户只能在不理想的方案中做选择，包括：1) 预先加载所有内容，导致实际任务性能下降；2) 限制集成数量；3) 构建动态工具加载，但会带来延迟和复杂性[11][12] - **日常使用体验差**：存在初始化极不稳定、无休止的重新认证以及权限管理非黑即白（仅能通过名称白名单，无法限制为只读或限制参数）等问题[18] CLI与API方案的优势 - **大语言模型天然擅长使用CLI**：大语言模型在数以百万计的man手册、Stack Overflow回答及Shell脚本仓库中受过训练，给予它们CLI和文档，它们就能有效工作[14] - **CLI具备一致性与可调试性**：当AI操作出错时，人类可以运行相同的CLI命令来复现和调试，输入输出一致，没有谜团，而MCP下的工具操作仅存在于对话内部，出错后需翻查复杂的JSON传输日志[14] - **CLI具有强大的可组合性**：可以通过`jq`、`grep`等工具进行数据过滤、逻辑串联或重定向，这通常是唯一可行的方法，而使用MCP要么需将整个计划塞入昂贵且有限的上下文窗口，要么需在服务端构建自定义过滤功能，结果更差且耗费更多精力[15] - **CLI是经过时间检验的成熟工具**：CLI经历了数十年的设计迭代，可组合、可调试，并且能利用现有的认证体系，对人类和机器都友好，是一个已经足够好的抽象层[16][17]