去年全网热捧的 MCP 协议，你还记得吗？当 Anthropic 发布它的时候，几乎所有人都将其视为 AI 智能体的未来通信标准。
但现实似乎有些骨感。才过去一年多，Perplexity 的 CTO 就在内部宣布放弃 MCP。Y Combinator 的 CEO 更是直言不讳，称 MCP “挫爆了”。就连一些曾经全面支持 MCP 的工具，也在新版本中将它彻底移除。
这是为什么呢？我们来聊聊 MCP 在实践中暴露的几个核心问题。
1. 线性上下文成本：MCP 太占地方了
想象一下，AI 智能体的上下文窗口就像一张大小有限的办公桌。每次接入一个 MCP 工具，就相当于往桌子上放一本厚厚的工具手册。这本手册里包含了工具名称、详细的参数说明、使用示例等等。
当你接入 10 个服务，每个服务有 5 个工具时，还没开始处理实际任务，桌面就已经被这些“手册”堆满了。真正需要分析和处理的用户问题或数据文件，反而没有空间了。这就是所谓的线性上下文成本。工具越多，Agent的“有效工作记忆”就越少，表现自然就越“笨”。
2. 开发与使用体验：一言难尽
在实际使用中，MCP 的体验也常常让人抓狂。初始化过程不稳定，MCP 服务端动不动就启动失败，开发者不得不反复重启，甚至清空所有状态从头再来。每个工具往往需要单独的认证流程，接上五六个之后，繁琐程度直线上升。
权限管理也是一个痛点，通常只有“全开”或“全关”两个选项，无法精细控制，比如“只允许读，禁止写”。这些问题单独看或许都不致命，但叠加在日常开发流程中，就成了一种持续的“折磨”。
很多经验丰富的开发者早就意识到了这一点：CLI（命令行工具）才是更优解。有篇文章说得很透彻：大语言模型（LLM）本身就是在海量的命令行手册和技术文档上训练出来的。你直接给它一个 CLI 工具和相应的文档，它反而能更快地上手，用得更好。
而且，CLI 有一个 MCP 难以比拟的优势：可组合性。你可以用管道 (|) 串联命令，用 grep 过滤结果，将输出重定向到文件。这些操作逻辑清晰，无论是人还是 AI 都能理解。当出现问题时，你可以在终端里原样执行一遍命令来复现和排查。
反观 MCP，工具调用隐藏在对话的 JSON 交互内部。一旦出现 Bug，你需要翻查一堆结构化的日志，很难直观地复现和定位问题根源。
3. 为什么“旧工具”反而更靠谱？
如果你正在搭建 AI 智能体或开发相关应用，现在选择技术栈时需要多一分清醒。不要盲目地将 MCP 塞进你的项目，而是应该优先考虑那些经过时间考验的成熟方案：清晰的 API 和稳定的 CLI。
技术的选择标准，从来不是看它是否“新潮”或“概念先进”，而应该看它是否“人能用、机器也能用、出了问题还能查”。有时，一个工具能存在几十年，恰恰因为它真正解决了实际问题。
回过头看，MCP 的困境或许不是输给了某个具体的竞争对手，而是输给了一个朴素的道理：我们并不总是需要更复杂、更花哨的抽象层。很多时候，一个设计良好、接口清晰、文档齐全的基础工具，才是高效和可靠的基石。
想明白这一点，不仅在做技术选型时有用，在做产品、做内容时，背后的逻辑也是相通的。
关于 AI 智能体和工具演进的更多讨论，欢迎在 云栈社区 的 开发者广场 板块与大家交流。 | 
发表于 4 小时前
|
查看: 5|
回复: 0
