回望2024年的那个秋天AI圈子里几乎没人Neng绕过MCP这个话题。那时候，Anthropic刚刚抛出这个概念，仿佛给正处于迷茫期的AI Agent开发者们指明了一条康庄大道。它的愿景宏大得让人心潮澎湃——要成为大模型与外部工具通信的“通用标准”，就像当年HTTP协议统一了Web世界一样。一时间，各大技术社区沸腾了GitHub上MCP server的项目如雨后春笋般涌现，各种集成教程、开源实现层出不穷，仿佛谁不跟上这趟车，谁就要被AI时代抛弃。

然而技术的浪潮来得快，去得往往也快。仅仅过了一年多，风向却悄然变了。

上周，Perplexity的联合创始人兼CTO Denis Yarats在内部的一番表态，像是一颗石子投入了平静的湖面激起了层层涟漪。他们正在放弃MCP，转而回归传统的API和CLI。geng有意思的是这个消息扩散出来后业界的反应竟然不是惊讶，而是一种“早该如此”的默契。甚至连Y Combinator的总裁兼CEO Garry Tandou毫不客气地直言：“MCP sucks。”

这不禁让人深思：一个曾经被捧上神坛的协议，为何如此迅速地跌落神坛？是因为它不够稳定？还是因为认证流程太繁琐？这些确实是大家吐槽的点，但它们只是冰山一角。MCP真正的困境，深埋在它的结构性设计之中。今天我们就来扒开这层表象，聊聊这背后的技术逻辑与博弈。

hen多人对MCP的质疑，Zui初往往停留在一些非常具体的体感抱怨上。比如“这玩意儿怎么老是启动失败？”或者“每次接入新服务dou要重新认证一遍，太麻烦了。”这些问题确实存在而且非常折磨人。在日常开发中，MCP server启动失败几乎成了家常便饭，有时候运气好重试一下就过了有时候则不得不推倒重来排查半天也找不到原因。权限管理geng是粗糙得令人发指，只有“允许”和“不允许”两档，你想把某个工具限制为只读？没门。你想约束它Neng传什么参数？也没门。

但Ru果我们把目光放长远一点，会发现这些只是皮外伤。真正致命的，是MCP试图构建一个geng“现代”的抽象层，却忽略了现有工具链Yi经进化得足够成熟这一事实。在不需要额外抽象的地方强行加一层，带来的往往不是便利，而是额外的成本和复杂度。工程师Eric Holmes曾写过一篇言辞犀利但切中肯綮的文章，他的观点hen直接：MCP没有带来任何实际价值，LLM完全有Neng力自己搞懂怎么用CLI。

要理解为什么MCP的设计会让开发者感到头疼， 得明白AgentZui宝贵的资源是什么。不是算力，也不是模型智商，而是上下文窗口。

上下文窗口决定了AgentNengkan见多少对话历史，Neng保留多少工作记忆，Neng有多大的推理空间。这就像是人类的短期记忆，容量极其有限。而MCP的工作方式，恰恰是在挥霍这个资源。它的机制要求把工具的名称、描述、参数结构以及使用示例，全部一股脑地注入到Agent的上下文窗口里。Agent得先读完这些冗长的“说明书”，才Neng决定下一步该调用哪个工具。

想象一下当你接入的服务稍微多一点，比如你有10个服务，每个服务下面挂着5个工具。光是这些工具定义本身，就Yi经烧掉了几千个token。这还没完，Agent还没开始干活，上下文就Yi经被塞满了一半。这种“列菜单”式的代价，在处理复杂任务时是不可接受的。这就好比你雇佣了一个超级大脑的专家，但他每次工作前，dou必须先读完一本厚厚的 可调试性：黑盒与透明的博弈

除了资源浪费，调试的困难也是让开发者抓狂的一大痛点。在传统的CLI环境下当Claude对Jira执行了一个出乎意料的操作，或者结果不对劲时你Ke以直接在终端里跑同一条jira issue view命令。输入一致，输出一致，一切dou在阳光下没有谜团。这种透明性是排查问题的基石。

但在MCP的世界里这一切dou变得扑朔迷离。所有的调用只发生在LLM的对话内部，被封装在复杂的JSON传输日志中。一旦出问题，你只Neng去翻那些令人眼花缭乱的日志，试图在层层嵌套的数据结构中寻找蛛丝马迹。这种“黑盒”体验，极大地增加了开发和维护的心智负担。对于追求效率的工程师来说这简直是噩梦。

这就引出了CLI为何Neng屹立不倒的核心原因——可组合性。CLI存在了几十年，其设计哲学一直遵循着“Zuo一件事，并把它Zuo好”的原则。你Ke以用jq过滤数据，用grep串联逻辑，把输出重定向到文件，或者通过管道传递给下一个命令。这不只是方便，hen多时候这是解决复杂问题的唯一可行路径。

反观MCP，它恰恰缺乏这种优雅的组合Neng力。在MCP的架构下你要么把完整的数据塞进上下文，要么在server端自己写死过滤逻辑。这两种方式，本质上dou是在用geng多的精力换取geng差的结果。你失去了像搭积木一样灵活组合工具的自由，被禁锢在了一个臃肿的框架里。

再来说说认证。CLI复用的是系统级别的认证体系，无论是SSH密钥、环境变量还是OAuth令牌，这套东西Yi经经过几十年的打磨，稳定且安全。开发者熟悉，运维人员也熟悉。

而MCP呢？它似乎有一种执念，要求你为每个工具重新搭一遍认证流程。接入多个服务，就要没有人愿意为了一个所谓的“标准”，去维护一套繁琐且不稳定的认证体系。

这里有一个非常有趣的：MCP的设计初衷是为了让AIgeng好地使用工具，但AI其实根本不需要这种特殊的照顾。

大模型在训练时kan过海量的man手册、Stack Overflow上的精彩回答以及GitHub上数以亿计的Shell脚本。它们对CLI的理解，远比对某个冷门的MCP server要深刻得多。你给它一个命令行工具和一份文档，它就Neng上手，根本不需要什么特殊的适配层。这就像一个精通多国语言的翻译官，你非得给他塞一本“小学识字课本”，这不仅是多余的，甚至是一种侮辱。

给AI构建工具链，不需要发明一套新的协议。AI需要的工具，和人类需要的工具，在hen多时候是同一套。Zui好的工具，是对人类友好，同时对机器也友好的工具。而CLI，恰恰就是这种经过时间考验的“双优”接口。

当然我们并不是比如需要强类型Schema、有严格访问控制要求的企业内部系统，或者是一些极度复杂的遗留系统封装，它依然有它的位置。毕竟结构化的数据交换在某些领域是刚需。

但是作为“AI工具集成的通用标准”，这个定位恐怕是hen难站稳了。Perplexity的转向，Garry Tan的批评，以及社区里越来越多的反思，dou指向了一个共同的MCP试图解决的问题，其实Yi经被CLI和API解决得够好了。强行引入一个新的抽象层，带来的只有摩擦和损耗。

面对这个问题，现有的出路似乎只有三条：继续忍受MCP的高昂成本；回归CLI和API的朴素与高效；或者等待下一个geng聪明的协议出现。但就目前来kan，第二条路显然是Zui明智的。这不是“实现质量”的问题，而是协议设计本身的代价。三条路dou不好走，但至少CLI这条路，我们Yi经走了几十年，虽然布满荆棘，但至少脚下是坚实的土地。

在探讨这些宏观架构的同时我也在思考，作为一线开发者，我们该如何在当下的技术环境中Zuo出选择？目前，我正在开发DocFlow，这是一个完整的AI全栈协同文档平台。这个项目融合了多个技术栈，包括基于Tiptap的富文本编辑器、NestJs后端服务、AI集成功Neng和实时协作。

在开发DocFlow的过程中，我深刻体会到了工具选择的重要性。比如在处理富文本编辑器时我们选择了Tiptap。这不仅仅是因为它基于ProseMirror，拥有无与伦比的 性，geng因为它提供了一套清晰的、基于Schema的API。这与MCP试图Zuo的事情有些类似，但Tiptap成功的地方在于，它没有试图去取代浏览器的DOM操作，而是优雅地封装了它，同时保留了开发者直接操作底层的自由。

我们在ZuoTiptap深度定制、性Neng优化和协作功Neng实现时也遇到了类似MCP的困境：是引入一个复杂的中间层来统一管理状态，还是直接利用现有的成熟机制？经过多次尝试，我们发现，过度封装往往会导致调试困难，性Neng下降。Zui终，我们选择了geng贴近原生、geng透明的方案，这大大提升了开发效率和系统的稳定性。

这其实与CLI vs MCP的争论如出一辙。在DocFlow的AI集成部分，我们同样面临着如何让AI理解文档结构、如何执行操作的问题。我们没有选择构建一个复杂的MCP server来描述每一个编辑操作，而是利用Tiptap现有的命令体系，让AI通过生成特定的命令序列来操作文档。结果证明，这种方式不仅Token消耗geng少，而且出错率geng低，因为AI对“命令”的理解，远比对“JSON Schema”的理解要深刻。

技术的演进往往是一个螺旋上升的过程。我们总是试图通过增加抽象层来简化问题，但有时候，过度的抽象反而成了新的负担。MCP的爆红，代表了人们对AI Agent标准化的渴望；而它的失宠，则提醒我们，不要为了创新而创新，不要为了标准而标准。

Zui好的技术，往往是那些隐形的技术。它们像水和电一样，润物细无声地支撑着应用的运行，而不是横亘在开发者面前的一道高墙。CLI之所以Neng回归，正是因为它足够简单，足够透明，足够强大。它把控制权交还给了用户，交还给了开发者，也交还给了AI。

Ru果你对AI全栈开发、Tiptap富文本编辑器定制，或者DocFlow项目的完整技术方案感兴趣，欢迎加我微信yunmz777进行私聊咨询。我们Ke以一起探讨如何寻找确定性的技术方向。