我正在开发 DocFlow，它是一个完整的 AI 全栈协同文档平台。该项目融合了多个技术栈，包括基于
Tiptap的富文本编辑器、NestJs后端服务、AI集成功能和实时协作。在开发过程中，我积累了丰富的实战经验，涵盖了Tiptap的深度定制、性能优化和协作功能的实现等核心难点。
如果你对 AI 全栈开发、Tiptap 富文本编辑器定制或 DocFlow 项目的完整技术方案感兴趣，欢迎加我微信 yunmz777 进行私聊咨询，获取详细的技术分享和最佳实践。
如果你对 AI全栈 感兴趣，也欢迎添加我微信，我拉你进交流群
MCP 出生时，被捧得很高。
2024 年 11 月，Anthropic 发布"模型上下文协议"，几乎所有 AI 开发者社区都在讨论这件事。它的定位很诱人，要成为大模型和外部工具之间通信的"通用标准"，有点像当年 HTTP 对 Web 的意义。一时间，MCP server 满天飞，各种集成教程、开源实现层出不穷。
但时间只过了一年多。
上周，Perplexity 的联合创始人兼 CTO Denis Yarats 在内部表示，他们正在放弃 MCP，转而改用 API 和 CLI。这个消息扩散出来后，引发了一波讨论，但讨论的内容不是"为什么"，而是"早该如此"。
Y Combinator 的总裁兼 CEO Garry Tan 甚至直接说了一句话："MCP sucks。"
MCP 的问题从来都不是技术实现不够好
很多人对 MCP 的质疑，停留在"不稳定"、"认证烦"这些体感上的抱怨。这些问题确实存在，但它们只是表象。MCP 真正的困境，是一个结构性问题。
MCP 的工作方式是，把工具的名称、描述、参数结构（Schema）以及使用示例，全部注入到 Agent 的上下文窗口里。Agent 读完这些信息，再决定要调用哪个工具。
这个设计在工具数量少时还可以接受。但你一旦接入 10 个服务，每个服务有 5 个工具，光是工具定义本身就已经烧掉了几千个 token。Agent 还没开始干活，上下文就已经塞满了一半。
上下文窗口是 Agent 最宝贵的资源，它决定了 Agent 能看见多少对话历史，能保留多少工作记忆，能有多大的推理空间。MCP 的代价，是把这个资源拿来"列菜单"。
面对这个问题，现有的出路只有三条：
- 一次性加载所有工具，接受推理性能下降
- 限制接入工具数量，接受 Agent 能力边界收窄
- 构建动态工具加载机制，接受额外的延迟和复杂度
三条路都不好走。这不是"实现质量"的问题，而是协议设计本身的代价。
除此之外，日常使用中的痛点也不少。MCP server 启动失败是家常便饭，有时重试能解决，有时必须推倒重来。接入多个服务就要在每个服务上重新认证一遍。权限管理也只有"允许"和"不允许"两档，没有办法把某个工具限制为只读，也没有办法约束它可以传什么参数。
CLI 是更好的答案，不是因为它新，而是因为它够旧
工程师 Eric Holmes 写过一篇文章，观点直接：MCP 没有带来任何实际价值，LLM 完全可以自己搞懂怎么用 CLI。
这话有点刺，但它说的是实情。
大模型在训练时看过海量的 man 手册、Stack Overflow 回答和 GitHub 上的 Shell 脚本。它们对 CLI 的理解，远比对某个 MCP server 的理解深得多。给它一个命令行工具和一份文档，它就能上手，不需要特殊适配。
CLI 在几个关键点上，比 MCP 天然占优。
第一是可调试性。当 Claude 对 Jira 执行了一个出乎意料的操作，你可以直接跑同一条 jira issue view 命令，看看它看到了什么。输入一致，输出一致，没有谜团。但 MCP 的调用只发生在 LLM 的对话内部，出问题了只能去翻复杂的 JSON 传输日志。
第二是可组合性。这是 CLI 的核心竞争力。你可以用 jq 过滤数据，用 grep 串联逻辑，把输出重定向到文件。这不只是方便，很多时候这是唯一可行的路。MCP 没有这个能力，你要么把完整数据塞进上下文，要么在 server 端自己写过滤逻辑，两种方式都在用更多的精力换取更差的结果。
第三是认证。CLI 复用的是系统级别的认证体系，这套东西已经经过几十年的打磨。MCP 需要你重新为每个工具搭一遍认证流程。
这件事说明了什么
Perplexity 放弃 MCP，以及其他工具陆续移除 MCP 支持，这件事背后有一个更值得思考的信号。
给 AI 构建工具链，不需要发明一套新的协议。AI 需要的工具，和人类需要的工具，在很多时候是同一套。最好的工具是对人类和机器都好用的工具。
CLI 存在了几十年，设计上一直遵循一个哲学，每个工具做好一件事，然后把工具组合起来解决复杂问题。这套哲学放到 Agent 身上，依然成立。
MCP 想构建一个更"现代"的抽象层，但它解决的问题，现有工具已经解决得够好了。在不需要额外抽象的地方强行加一层，带来的只有额外的成本和复杂度。
当然，MCP 不会完全消失。在某些特定场景，比如需要强类型 Schema、有严格访问控制要求的企业内部系统，它依然有它的位置。但作为"AI 工具集成的通用标准"，这个定位恐怕很难站稳了。
参考：