MCP 不只是工具调用：重新理解 AI 系统的协议层

很多人第一次听到 MCP，会先记住一句传播性很强的话: 它像 AI 世界的 USB-C。这个比喻并不算错，因为 MCP 确实在尝试把模型连接外部世界这件事标准化。但如果只停留在这句类比，MCP 很容易被误解成又一个插件协议，或者某个 AI IDE 的专属扩展机制。

真正值得讨论的，不是它有没有一个好记的比喻，而是它为什么会在 2025 到 2026 这段时间突然变得重要。过去我们让模型调用一个天气接口、一个数据库函数，通常写点胶水代码就够了。现在情况变了，AI 工具开始进入 IDE、知识系统、设计协作和企业内部流程，模型面对的不再是单个 API，而是一整套需要长期接入、持续维护、可以迁移的外部能力体系。MCP 的真正价值，也正是在这里: 它不是让模型多一个“调用工具”的能力，而是试图把 AI 接入外部系统这件事，从零散胶水代码提升为可组合、可迁移、可治理的协议层。

为什么现在值得重新理解 MCP？

如果时间回到只有聊天问答和少量函数调用的阶段，MCP 看起来并没有那么迫切。那时外部能力的接入方式通常很简单: 模型要么直接请求一个后端接口，要么由开发者手工封装几个固定函数。只要场景足够局部，这种方式完全能跑起来。

但当 AI 开始进入更复杂的工作流之后，问题就不再是“会不会调用某个函数”，而是“怎么在一个宿主环境里长期组织越来越多的工具和数据源”。一个 AI IDE 可能需要文件系统、代码搜索、终端命令、诊断结果和 Git Diff；一个知识助手可能需要文档、表格、会议纪要和长期记忆；一个企业内部 Agent 可能还要接审批、工单、CRM、BI 报表和各种内部服务。每多一种能力，背后就多一套认证、连接、权限、上下文和错误处理逻辑。如果每接一个系统都从头写一层适配代码，复杂度会迅速失控。

所以，今天真正值得重新理解 MCP，不是因为它“新”，而是因为它开始回答一个更底层的问题: 当模型不再孤立工作，而要持续接入外部世界时，这些连接关系应该如何被标准化、组织和治理？

如果把这段变化压缩成一条演进线，会更容易看出 MCP 为什么是在这个阶段变得重要:

MCP 真正解决的不是“能不能调用工具”，而是“怎么持续集成工具”

很多人会把 MCP 和 Function Calling 放在同一个层面理解，觉得它们都在解决“模型调用外部能力”的问题。这个理解只对了一半。Function Calling 解决的是: 模型如何按给定 schema 调用一个函数。它关注的是模型输出如何与某个预定义接口对齐。

而 MCP 更关心的是另外一层问题: 在一个长期运行的宿主环境里，工具能力如何被发现、连接、替换和复用。换句话说，Function Calling 更像模型侧的调用接口机制，MCP 更像宿主与工具生态之间的协议层。

这层差异在工程实践里非常关键。企业真正头疼的，从来不是模型能不能调一个函数，而是下面这些问题:

• 新接一个系统，是否又要写一套新的适配逻辑。
• 换一个宿主或模型，这些工具能力是否还能继续复用。
• 一个工具是如何被发现、暴露和治理的。
• 上下文、权限和错误处理是散落在各处，还是有明确边界。

当问题从“能力调用”升级为“集成治理”时，MCP 的意义才真正浮现出来。它并不直接创造业务价值，但它试图把这些长期成本最高的连接关系，抽象成一层更稳定的公共接口。

MCP 的角色分工到底是什么？

如果把 MCP 只理解成“启动一个 Server 暴露几个工具”，仍然会低估它的价值。更完整的理解方式，是把它看成宿主、连接层和能力提供层之间的协议协作。

这张图里至少有三层角色需要分清。

第一层是 Host，也就是用户真正感知到的 AI 工具，比如 Claude Desktop、Cursor，或者某个自建 Agent 应用。用户的请求、交互界面、上下文窗口，通常都在这一层。

第二层是 Client。它往往内嵌在 Host 内部，负责与不同的 MCP Server 建立连接、传递请求和接收结果。用户通常不会直接看到它，但它决定了宿主如何组织外部能力。

第三层是 Server，也就是能力暴露层。它的职责不是生成答案，也不是做界面，而是把代码搜索、文件访问、知识查询、数据库读取、内部系统操作等能力包装成宿主可以理解和调用的协议接口。

这一分层很重要，因为它说明 MCP 不是“大模型后端”，也不是“插件商店”。它更像一层连接协议: 不生产业务价值本身，但决定业务能力能否被稳定接入、持续复用，以及跨宿主迁移。

从实现上看，一个 MCP Server 往往做两件事: 声明自己是谁，以及注册自己能提供哪些工具能力。下面这个精简片段，比完整 Demo 更能说明 MCP Server 的职责边界:

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js'

const server = new McpServer({
  name: 'Figma MCP Server',
  version: '0.1.12',
})

server.tool('get_figma_data', 'Get layout information from a Figma file', schema, handler)
server.tool('download_figma_images', 'Download image assets from a Figma file', schema, handler)

这段代码真正说明的，不是 Figma 集成有多炫，而是 MCP Server 的边界非常清晰: 它不是模型本身，也不是宿主 UI，而是把外部能力整理成一个可发现、可调用、可替换的能力提供层。

从调用链角度看，MCP 为什么更适合 Agent 时代？

Agent 时代的系统有一个显著特征: 它不是执行一次调用就结束，而是在较长的上下文窗口里持续判断、持续调用、持续修正。模型可能先搜索，再读文档，再调用命令，再修改文件，最后把结果组织成一个可交付输出。这类调用链的关键，不只是“能否成功调用一次”，而是多次调用之间是否有稳定边界。

用调用链来表示，这类 Agent 工作流更像下面这样:

MCP 更适合这种场景，不是因为它神奇地提升了模型智力，而是因为它让工具发现、连接建立、能力切换和上下文回流有了更明确的接口层。对于 IDE、知识工作流和企业内部 Agent 来说，这种边界往往比单次调用成功更重要，因为真正昂贵的成本不在第一次接入，而在后续维护、替换、扩展和治理。

这也是为什么很多人会在 AI IDE 或 Agent 产品里强烈感受到 MCP 的价值。你当然可以继续为每个工具手写接入代码，但随着工具数量增加，这种做法会把系统拖回“每来一个需求就打一层补丁”的状态。MCP 的意义不在于消灭复杂性，而在于把复杂性收敛到一个更容易管理的层次上。

MCP、Function Calling 与定制集成分别是什么关系？

如果把 MCP 理解成 Function Calling 的替代品，结论通常会失真。更准确的方式，是把它们放在不同抽象层上比较。

真正决定选型的，不是哪一个词更流行，而是哪一层问题需要被解决。如果你只是让模型偶尔调用两个固定函数，Function Calling 完全够用；如果你要在 IDE、桌面助手、团队工作流和企业系统之间长期组织越来越多能力，MCP 这类协议层就会开始变得有价值；如果你只是在某个局部流程里快速试验，一个临时定制集成反而可能是最省成本的路径。

所以，MCP 的正确位置，不是“全面替代 Function Calling”，而是补上它没有解决的那一层: 宿主如何稳定接入和组织外部能力。

三类更值得关注的真实场景

旧的 MCP 文章很喜欢拿 Cursor 配合 Figma MCP 做演示，这类案例当然有传播力，因为它足够直观: 一边读设计稿，一边生成页面，很容易让人看到“模型会调工具”这件事。但如果只盯着这种 Demo，仍然容易错过 MCP 更长期的价值。更值得关注的，其实是下面三类场景。

如果把这三类场景放在同一张图里，会更容易看出它们共同依赖的其实都是同一层连接能力:

1. AI IDE

在 AI IDE 里，模型要面对的不是一个 API，而是整套研发环境: 文件系统、代码搜索、诊断信息、终端命令、测试结果、Git Diff。难点从来不是“连上某个能力”，而是如何让这些能力在宿主里形成稳定的协作关系。MCP 在这里的价值，是让 IDE 不必为每一种能力都重新设计一套私有插件语言。

2. 知识系统

当模型开始访问产品文档、团队 Wiki、会议纪要、结构化数据表和长期记忆时，问题会从“召回内容”迅速升级为“如何组织不同来源的上下文”。如果每接一个知识源就写一次特定适配器，知识系统很快就会变成一个无法迁移的本地工程。MCP 这类协议层的意义，在于把知识访问能力变成宿主可复用的连接单元，而不是把接入逻辑散落在各个产品角落。

3. 企业内部系统

在企业场景里，模型往往还要连接工单、CRM、审批流、数据分析、BI 报表和各种内部服务。这里最敏感的问题甚至不是工具数量，而是权限边界、审计要求和长期维护成本。协议层并不会自动解决这些治理问题，但它至少提供了一个更清晰的能力暴露边界，让“谁在调用什么、如何接入、如何替换”更容易被管理。

总结: MCP 的价值，在于它开始定义 AI 系统的连接层

如果只把 MCP 看成一套“让模型调用工具”的新接口，它确实容易被高估，因为调用工具这件事本身并不新鲜。但如果把它放回 AI Agent、AI IDE 和企业级工具编排正在加速落地的背景里，它的重要性就会变得更清楚: 它在尝试定义的，不是某一个工具怎么接，而是 AI 系统如何持续接入外部世界。

MCP 会不会成为未来唯一的标准，现在下结论还太早。真正值得关注的是，它揭示出的趋势已经相当明确了: 未来 AI 系统的竞争，不只在模型参数和回答质量，也在工具接入能力、上下文组织能力和系统治理能力。对工程团队来说，判断要不要投入 MCP，不是看它热不热，而是看你的系统是否已经进入多工具、多数据源、多宿主并存的复杂阶段。

参考资料

• Model Context Protocol Official Introduction
• Cursor Documentation: Model Context Protocol