【MCP走向落幕？看懂协议与实现的错位才明白】

快速阅读：关于 MCP 是否“已死”的争论，本质上是“协议标准”与“工程实现”的错位。虽然 MCP 在消耗上下文窗口、可靠性和与现有 CLI 重叠方面存在明显缺陷，但它在企业级权限管理、非技术人员接入以及填补无 CLI 服务空白方面，提供了不可替代的架构价值。

最近关于 MCP 是否已死的讨论挺有意思。有人觉得它像移动互联网早期的 WAP，是个笨重的过渡方案；有人觉得它太吃上下文，简直是在“浪费 token”。

其实这事儿得拆开看。

如果单纯从开发者的视角看，MCP 确实有很多槽点。它就像在原本精简的指令流里强行塞进了一叠厚厚的菜单，还没点菜，桌子（上下文窗口）就被占满了。有数据测算，接入几个常用的 MCP Server，光工具定义就能吃掉 10% 以上的上下文。而且，比起直接调用现成的 CLI 或 API，MCP 确实多了一层进程开销，响应慢是必然的。

但如果我们把视角从“个人开发者的终端”切换到“企业的 IT 架构”，逻辑就变了。

对于大型组织来说，让成百上千个员工去配置环境变量、管理 CLI 权限，简直是运维噩梦。MCP 在这里扮演的角色更像是一个“身份感知的代理”。它能很好地集成 OAuth，让 AI 代理在受控的权限范围内工作，而不是像直接运行 Bash 那样，一旦失控就可能把数据库给删了。对于那些根本没有 CLI 的 SaaS 服务，MCP 几乎是它们走向 Agentic 时代的唯一门票。

有网友提到，与其搞 MCP，不如直接写好 `llms.txt` 或者完善 OpenAPI 文档。这没错，但那是“给模型看说明书”，而 MCP 是“给模型直接递工具”。

现在的局面有点像是在赶时髦。很多公司为了在官网上挂个“支持 MCP”的标签，匆忙上线了一些并不成熟的服务。这种“弱外部化”确实存在很多缝隙，比如初始化失败、权限不透明。

不过，随着 Tool Search 和延迟加载技术的成熟，上下文爆炸的问题正在被缓解。

MCP 到底会不会死？我觉得它不会死，它只是在从一种“新鲜的玩具”变成一种“无感的底层协议”。它可能不再是那个被反复讨论的话题，而是像 TCP 一样，安静地躺在网络层，处理着那些你甚至感觉不到它存在的调用。

至于它到底好不好用，可能得看你是在自己的笔记本上写代码，还是在一家规章制度森严的跨国公司里管理代理。

ejholmes.github.io/2026/02/28/mcp-is-dead-long-live-the-cli.html