“MCP已死”是AI圈最大的技术谎言？

西域狂鸭

【“MCP已死”是AI圈最大的技术谎言？】


快速导读：最近，技术圈风向突变，鼓吹“MCP已死，CLI万岁”。但这场争论的本质，并非协议优劣或Token效率，而是一个更深层的问题：你是满足于自娱自乐的“感觉编程”，还是在构建严肃的“智能体工程”？本文揭示，对于任何想超越个人玩具规模的团队来说，这场争论的答案从一开始就是确定的。

---

技术圈的风向变得比天气还快。几个月前，模型上下文协议（MCP）还是人人都想上的船，转眼间，风评急转直下，鼓吹“MCP已死，CLI万岁”成了新的政治正确。

很多人被表象迷惑了。他们说，MCP臃肿、消耗大量上下文，远不如简单直接的命令行（CLI）来得高效。经验丰富的老炮们甚至不屑一顾：“这玩意儿看起来就像垃圾，那它就是垃圾。”

这种论调听起来很酷，但可能完全搞错了重点。

是的，如果AI智能体要用的工具是`git`或`curl`这种早已刻在模型“肌肉记忆”里的命令，那用CLI当然省事。但如果你用的是一个自定义工具呢？智能体照样需要一份说明书（`--help`或者`SKILL.md`）来学习，所谓的Token优势瞬间荡然无存。整个OpenAPI schema塞进上下文的场景，并不少见。

这场争论的真正分野，不在于技术，而在于开发的组织形态。它区分了两种开发者：单打独斗的“感觉编程”（vibe-coding）信徒，和面向组织的“智能体工程”（agentic engineering）实践者。

对于前者，MCP确实显得多余。但对于一个10人以上的团队，问题就变了：如何保证不同技术栈的工程师用不同智能体得到一致的结果？如何管理密钥、做权限控制？如何追踪哪个工具有效、哪个在拖后腿？

这才是MCP真正发力的地方——不是本地`stdio`模式的小打小闹，而是作为中心化服务器通过HTTP提供的服务。它把认证（Auth）、安全（Security）、遥测（Telemetry）这些麻烦事一揽子解决了。工程师离职？吊销他的OAuth令牌即可，他从未接触过核心密钥。这对于任何依赖GitHub Actions这类临时运行环境的团队来说，更是刚需。

更有趣的是，连Anthropic和Cloudflare都发现，让LLM直接调用MCP，不如让LLM“写代码去调用MCP”来得更稳、更省。Anthropic的“程序化工具调用”甚至能节省高达98.7%的Token。这说明，MCP的价值在于提供了一个稳定的、可被机器理解的“契约”，而不是一个手感舒适的“玩具”。

所以，当人们在激烈争论MCP和CLI的优劣时，他们实际上在无意中暴露了自己的立场：他们究竟是在构建一个随时可丢弃的个人项目，还是在为一个需要长期维护、多人协作的系统打地基？这根本是两条路线的斗争。

---

简评：

这已经不是技术选型问题，而是工程成熟度问题。当你的智能体应用开始考虑“人”的因素——团队协作、权限、审计、迭代——你会发现，你需要的不是一个更“聪明”的工具，而是一个更“笨”、更稳固、有明确边界的协议。那些嘲笑MCP的人，可能还没遇到需要为AI代码擦屁股的烦心事。

---

ref: chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/

##