"MCP已死 (MCP is dead)。" 最近在AI社区流传的这句煽动性语句并非单纯的流行语。在2026年的当下，这是一种技术警示，预示着模型上下文协议（Model Context Protocol，以下简称 MCP）所面临的局限性已达到临界点。

先说结论：虽然名为 MCP 的“连接方式”正在走向消亡，但 AI 与外部世界进行交互的“必要性”比以往任何时候都更加强烈。我们正处于一个巨大的过渡期，正在从简单的工具调用（Tool Calling）时代，迈向由智能技能（Skills）和智能体间协作（A2A）主导的新架构时代。

为什么人们在谈论 MCP 的终结？

为什么人们在谈论 MCP 的终结？

为什么最近 Reddit 和各类技术博客上对 MCP 的批评层出不穷？这并非仅仅因为技术不够好，而是因为在实际应用场景中，它产生了意想不到的“成本”和“负载”。

最大的问题在于模型的认知负荷 (Cognitive Load)。观察 MCP 的结构可以发现，每当模型连接到外部服务器时，它都必须每次重新读取并理解该服务器提供的无数工具（tool）的规范和用法。如果工具是10个，就需要进行10次“学习”过程；如果是100个，就需要100次。这种过程发生在实时响应过程中，必然会导致响应延迟（Latency），并且随着工具数量的增加，模型选择错误工具的可能性也会随之提高。

此外，实际落地实施的壁垒也很高。2026年初，许多企业试图在企业级环境中引入 MCP，但由于与现有遗留系统的兼容性问题、复杂的身份验证（Auth）流程，以及数据外泄带来的安全漏洞，导致许多企业纷纷退缩。特别是运行在本地环境的 MCP 服务器，正面临着无法在直观性和速度上赶上 CLI（命令行界面）的批评。

最终，随着“与其用 MCP，不如直接用熟悉的快速 CLI，或者干脆用更聪明的方式”的声音越来越大，甚至出现了“MCP is dead”这种极端的论调。

从“工具”迈向“技能 (Skills)”时代

'工具'迈向'技能 (Skills)'时代

那么，谁将填补 MCP 留下的空白呢？专家们提出的答案不是简单的“工具调用”，而是以“技能 (Skills)”为中心的设计。

为了方便理解，我们可以做一个比喻：

  • MCP 方式就像是每次都给厨师（AI）递交一份说明书，告诉他“这把刀怎么拿”、“这个锅怎么控火”。厨师因为要阅读说明书，导致做菜的速度变慢。
  • 技能 (Skills) 方式则是让厨师本身就内化了“煎牛排”这项熟练的技术。厨师无需思考刀具或锅具的细节规格，只要收到“煎牛排”的指令，就能立即执行。

换句话说，技能不仅仅是调用 API 的接口，而是将执行特定任务所需的知识、上下文和执行逻辑抽象成了一个模块。如果有一个“数据分析”技能，它内部已经包含了 Pandas 库的使用方法或 SQL 查询优化逻辑。模型不再需要将能量浪费在学习单个工具的细微差别上，而是可以专注于用户的最终意图。

这种方式可以极大地减少 Token 的消耗。实际上，像 Cloudflare 这样的公司已经通过将工具调用机制替换为代码生成方式，将 Token 使用量降低了惊人的 244倍。这可以看作是利用“以执行为中心的智能”克服了 MCP 所具有的“以解释为中心的开销”的一个典型案例。

企业级 AI 的核心：构建控制平面 (Control Plane)

企业级 AI 的核心：构建控制平面 (Control Plane)

然而，仅仅转向“技能”并不能解决所有问题。从企业的角度来看，对 MCP 的批评核心在于治理问题：“谁来管理和控制这些连接？”

目前的 AI 架构正在向三个层级分离并演进：

  1. 记录系统 (Systems of Record)：如 ERP、CRM 等，是底层坚实的数据层，数据的准确性是其生命线。
  2. AI 创新层 (AI Innovation Layer)：如 GPT-5 或最新的智能体框架，是顶层快速变化的智能层。
  3. 控制平面 (Control Plane)：连接这两层的核心层。

许多企业犯错的地方就在这里。他们仅仅将 MCP 视为“连接管道”，而忽略了中间发生的安全性、审计（Audit）、权限管理以及业务逻辑封装等问题。

真正意义上的企业级 AI 并不是抛弃 MCP，而是应该将 MCP 作为“控制平面”的一部分来使用。如果将业务逻辑（例如：退款处理、报价生成）封装成技能并部署在控制平面上，那么即使顶层的 AI 模型发生变化，企业的核心资产——“业务执行能力”——也能得以保留。这就是为什么必须将 MCP 的“工具”功能与“提示词/资源”功能相结合，并将其提升至企业级水平的原因。

MCP 与 A2A：AI 智能体的协作语法

MCP 与 A2A：AI 智能体的协作语法

现在，我们正在经历从 AI 单打独斗到多个 AI 组成团队的时代。在这里，我们将遇到另一个重要的概念：A2A (Agent-to-Agent)。

明确区分 MCP 与 A2A 的差异，是未来 AI 智能体设计的核心。

  • MCP (Model Context Protocol)：是 AI 与外部世界（数据库、API、文件系统）对话的“语言”。它定义了“我能做什么？”
  • A2A (Agent-to-Agent)：是 AI 智能体之间交换信息并协作的“语法”。它定义了“我们如何共同工作？”

例如，当用户发出“帮我规划明天的济州岛旅行”的指令时，“旅行规划智能体”会通过 MCP 从航空公司和酒店 API 获取信息（MCP 的角色），同时与“天气智能体”或“预算管理智能体”交换信息并进行协商（A2A 的角色）。

最终，未来的 AI 生态系统将通过 MCP 获取工具，通过 A2A 联结同伴，从而趋于完整。正如 Kakao Ventures 的分析所言，AI 正在从单纯的工具使用者演变为一个“协作的成员”。

结论：我们应该走哪条路？

结论：我们应该走哪条路？

正如我们所看到的，“MCP 已死”这句话一半是对的，一半是错的。

仅仅将 API 传递给模型的“被动型 MCP 接口”肯定会被淘汰。因为它会增加模型的认知负荷，存在安全隐患，且成本效率低下。但是，MCP 提供标准化连接和发现（Discovery）的本质价值依然有效，甚至在企业级环境中，它会以更精密的形式生存下来。

未来的 AI 开发方向是明确的：

  1. 不要停留在简单的工具调用（Tool Calling）层面，而要思考包含业务逻辑的以技能 (Skills) 为中心的设计。
  2. 构建能够确保安全性和可见性的控制平面 (Control Plane)，以管控 AI 的行为。
  3. 为了克服单一智能体的局限，要准备好通过 A2A 协议实现多智能体协作的体系。

与其被技术的炒作（Hype）裹挟而急于更换工具，不如先问问自己：我们想要构建的系统应该位于哪一层（Layer）？基础设施应遵循标准（Protocol），而智能则应实现抽象（Skill）。

您的 AI 项目目前是停留在简单的“工具连接”阶段，还是正在向真正的“基于技能的智能体”演进？欢迎在评论区分享您的看法！

参考资料