半年前，MCP（Model Context Protocol）还是AI圈的当红炸子鸡，各路厂商疯狂跟进，仿佛不搞个MCP集成就落伍了。
半年后，风向突变——CLI成了新宠，MCP被踩成了"过度设计的垃圾"。
说实话，这种180度大转弯，我看得有点晕。
网红经济学：每隔6个月，你得换个东西吹
事情得从这波"CLI真香、MCP垃圾"的舆论说起。
作者在Motion工作，半年前被各路厂商疯狂推销MCP产品。他的标准回复是：
这就是个API包装器，我直接调API不就完了，为什么要多此一层？
当时他选择冷眼旁观，没跟风。
结果6个月后，那些曾经吹MCP的人，现在又开始踩MCP、捧CLI了。
有意思的是，这波"反转"里，不乏Garry Tan、Andrew Ng这样的大佬。
作者的原话相当犀利——这些人跟推销伊维菌素治百病的网红没什么本质区别，就是单纯的无知。
话糙理不糙：AI圈需要持续制造FOMO（错失恐惧症）来维持热度，网红们需要不断找新话题来保持存在感。6个月一个周期，周而复始。
CLI省token？是，但也没那么神
CLI派的核心论点很明确：省token、效率高。
这事儿得拆开看。
第一，训练数据里的CLI工具，确实省。
jq、curl、git、grep、psql……这些工具在LLM的训练数据里出现过无数次。模型根本不需要额外说明，直接就能用。
这种情况下，CLI完胜MCP——因为MCP需要在tools/list响应里预先声明所有工具的schema， upfront成本摆在那儿。
第二，自定义CLI工具？省不了。
问题来了：如果你的CLI是定制的、模型从没见过的呢？
模型怎么知道这个CLI怎么用？你得写文档、写说明，要么塞进AGENTS.md，要么放在README.md里。
然后你会发现，模型开始反复试探、犯错、你不断修补文档……最后，你写的那些参数说明，长得跟MCP的schema几乎一模一样——只是没有任何结构化约束。
# 你以为的CLI省token
command: searchFlights Search for available flights
input: JSON object with origin, destination, date
example:
{
origin: "(string; required) departure city",
destination: "(string; required) arrival city",
date: "(date:yyyy-MM-dd; required) travel date"
}
这不就是MCP schema的"野生版"吗？
第三，渐进式加载？多轮对话反而更费。
CLI有个理论优势：可以渐进加载--help内容，而不是一次性把所有schema塞进上下文。
但现实是：对于复杂流程，模型最终还是要遍历大部分命令树。省下的token，被多轮对话的开销吃掉了。
更重要的是——不把完整schema给模型，它选错工具的概率会上升。Vercel的实验早就证明了：把完整文档索引放进AGENTS.md，模型表现更好。
MCP的真面目：stdio是鸡肋，HTTP才是王道
这可能是整个争论里最大的误解。
大多数人喷MCP，喷的是stdio模式——本地跑个MCP服务器，确实多此一举，写个CLI不就完了？
但MCP还有另一种模式：基于HTTP的远程服务器。
这玩意儿对企业级场景来说，是真正的游戏规则改变者。
集中化的威力
远程MCP服务器意味着什么？
更强大的后端能力。 你的工具可以直接访问Postgres、图数据库、索引化的上下文……这些在本地环境里要么很难实现，要么状态共享是噩梦。
适配临时性运行环境。 比如GitHub Actions里的Copilot Agent，需要访问复杂的后端服务？MCP让这一切变得极其简单——指向一个HTTP端点，搞定。
认证和安全。 CLI用curl访问受保护的API？每个开发者手里都得握着一堆密钥，运维团队噩梦。集中到MCP服务器后面，开发者用OAuth登录，敏感密钥永远不离开服务器。员工离职？撤销OAuth token，完事。
可观测性。 哪些工具被频繁使用？哪些工具在吃灰？哪里在出错？集中式MCP服务器配合OpenTelemetry，答案一目了然。
这些，CLI都做得到吗？技术上可以。但每个CLI工具都要自己实现一套，运维成本爆炸。
被忽视的MCP三件套：Prompts、Resources、Tools
大多数人聊MCP，只聊Tools。
但MCP规范里还有两个重量级选手：Prompts和Resources。
简单翻译一下：
- MCP Prompts = 服务器下发的SKILL.md
- MCP Resources = 服务器下发的/docs
这玩意儿香在哪？
动态内容。 静态markdown文件要手动更新、同步、维护。服务器动态生成的prompts和resources？永远是最新的。想注入实时价格、系统状态？轻而易举。
组织级知识同步。 安全最佳实践、微服务文档、跨团队技能……全都从中央服务器下发，不需要在每个repo里复制粘贴。服务团队每次发布，相关文档自动更新。
配置一次，自动同步，永不过时。
从"牛仔式写代码"到"工程化智能体"
作者用了一个很妙的词：Cowboy vibe-coding（牛仔式氛围编码）。
翻译成人话：单兵作战、凭感觉写、没有规范、难以维护。
AI辅助编程的早期，这样玩没问题。但Amazon AWS最近的翻车案例已经敲响了警钟——AI生成的代码，最终还是要人来运维和负责的。
企业需要的，是从"牛仔式写代码"进化到"组织级智能体工程"。
而MCP的设计初衷，正是为此而来：标准化、可观测、安全可控、知识同步。
别被噪音带节奏
6个月前，MCP是救世主。
今天，MCP是过气网红。
6个月后呢？谁知道，可能又冒出个新概念。
但如果你是工程团队的负责人，需要为组织选择工具架构，建议你问自己一个问题：
我是要追热点，还是要解决问题？
CLI适合个人开发者、简单场景、训练数据里已有的工具。
MCP适合团队、企业、需要集中管理和可观测性的场景。
两者不矛盾，选对场景最重要。
至于那些每隔几个月就换立场的大V？看看就好，别当真。
毕竟，他们的KPI是流量，你的KPI是交付。
【glm-5锐评】：网红的KPI是换话题，你的KPI是选对工具——别把别人家的内容日更，当成你家的技术路线图。
参考链接：
https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/