MCP 没死，死掉的只是那种把它当万能胶的幻觉
过去几个月，MCP 从“万物皆可协议化”的明星，迅速变成不少人口中的历史包袱。但真正过时的不是 MCP，而是把个人效率工具和团队级 agent 基础设施混为一谈的判断方式。
来源参考： chrlschn.dev
MCP 最近挨骂，其实一点都不奇怪。
前几个月它被吹得太狠了，仿佛只要给 agent 套上一层协议，工具调用、知识同步、组织协作、工程治理，所有问题都会一起解决。现在风向一转，很多人又开始说 CLI 才是真答案，MCP 已经死了。这个摆动看上去像技术共识更新，实际更像一轮标准的 AI 舆论钟摆。
问题不在于谁吹得更响，而在于很多人从一开始就把两个完全不同的问题混成了一个问题：一个人怎么把 agent 用得更顺手，和一个团队怎么把 agent 变成可治理、可维护、可复用的生产系统，本来就不是同一道题。
如果你讨论的是个人工作流，CLI 的优势确实非常明显。git、curl、jq 这种已经深深进入模型训练语料的工具，对大模型来说几乎是“母语”。它不需要你再解释一遍 schema，不需要额外教它怎么调用，很多时候一把就能打中。单从即时效率看，这一派的结论没有错：很多场景里，直接用 CLI 就比 MCP 轻，也比 MCP 省 token。
但问题是，这个结论一旦被不加区分地扩大，就会迅速失真。
模型熟悉的是那些公共 CLI，不是你团队内部临时搓出来的私有命令。只要工具开始变成定制接口，agent 还是得知道命令名、参数结构、调用边界、错误语义和使用时机。你以为自己绕开了 MCP，最后往往只是把一套原本结构化的工具描述，重新塞回 README、AGENTS.md、帮助文档和示例命令里。省掉的不是复杂度，只是把复杂度藏起来了。
说得再直白一点：**很多“CLI 胜利论”成立的前提，其实是你用的恰好都是模型天生会的那一批工具。**一旦离开这个舒适区，CLI 也会长出自己的上下文负担，而且常常是更零散、更难治理的那种。
这也是为什么 MCP 真正值得讨论的部分，根本不是本地 stdio 形态下那个“像不像多套了一层壳”的版本。那个版本被嫌重，很多时候也确实不冤。明明写个简单包装脚本就能完成的事，非要塞进一层协议，当然容易让人觉得在过度设计。
但远程 MCP 完全不是同一个物种。
一旦 MCP 通过 HTTP 变成中心化服务，它的价值就不再是“让某一次调用更优雅”，而是“让一整个团队的 agent 接入方式开始收敛”。权限可以集中管，开发者不必人手抱着一堆 API key；工具调用可以统一做 telemetry，你终于知道哪些能力有人用、哪些能力形同摆设、哪里最容易失败；提示词、资源、文档索引也可以动态下发，而不是复制进几十个仓库，然后在半年后一起过期。
这才是这轮讨论里最容易被忽视的一点：**CLI 优化的是个人当下的操作成本，MCP 优化的是组织长期的接口秩序。**两者都重要，但压根不是替代关系。
很多人现在说“MCP 没必要”，其实真实意思往往是：“我在我自己的电脑上，不需要为团队治理付出这么多额外结构。”这句话对于个人开发者完全成立。但如果把它直接推广成团队结论，问题就来了。团队不是一个放大版的个人。团队要面对的是权限回收、审计、兼容性、统一更新、跨前端接入、失败排查和经验沉淀。你今天觉得 MCP 多余，明天可能就会在“为什么每个人本地工具版本都不一样”“为什么这个 agent 在 A 环境能跑，在 B 环境就坏了”“为什么没人知道哪些工具真的有效”这些问题上把时间加倍还回去。
所以“MCP 已死”这种标题党说法，最误导人的地方，不是它批评得太狠，而是它默认所有人都在解决同一种问题。事实正好相反。个人开发者追求的是快，组织追求的是稳；个人希望少一点约束，组织必须有更多边界；个人可以容忍一点混乱，团队迟早要为混乱付维护成本。
这也是我更认同的判断：真正死掉的，不是 MCP，而是那种“一个接口范式打天下”的想象。API wrapper 不是 MCP 的全部，stdio 也不是 MCP 的终局。对个人来说，CLI 会继续赢下很多场景；对团队来说，远程 MCP 这类可观测、可认证、可统一分发的接口层，反而会越来越重要。
当然，MCP 也没有自动赢。它如果只是多一层协议名词、多一层包装、多一次 tools/list 展示，而没有把认证、资源、提示词、内容同步、监控这些团队真正关心的能力做扎实，那它当然会继续被嫌弃，而且活该被嫌弃。
但如果把视角从“我这一次调用能不能省几百 token”拉到“一个组织怎么把 agent 变成基础设施”，MCP 不但没死，反而才刚刚开始进入它真正有意义的阶段。
这事说到底没那么玄。CLI 更像手里的刀，趁手就行；MCP 更像团队里的电路和管线，平时不显眼，但一旦要规模化协作，就不能没有。