MCP 为什么会成为企业 AI 的统一插头

这轮企业 AI，很多人还在盯模型。

但真做过几个场景就会发现，最重的活往往不在模型层，而在接口层。

你想让 AI 读知识库，要接文档系统。 想让它查订单，要接业务数据库。 想让它改状态，要接工单系统。 想让它先做一轮分析，还要接搜索、文件、代码执行和内部服务。

问题不在于这些事做不到，而在于过去每做一个新场景，接口层几乎都要重写一遍。

所以 MCP 开始变重要，不是因为技术圈又多了一个缩写，而是因为它第一次在认真解决企业 AI 里最贵、也最重复的一层工作。

MCP 不是插件，它是协议

很多人第一次听到 MCP，会把它理解成“给 AI 装插件”。这只对了一半。更准确一点说，MCP 不是插件本身，而是工具怎么被发现、怎么被调用、怎么返回结果的一套协议约定。

Anthropic 在 2024 年 11 月 25 日发布 MCP 时，把它定义成连接模型、数据源、工具和开发环境的开放标准。这个定义真正重要的地方，不是“开放”，而是“标准”。

过去每个 AI 框架接外部系统，做法都不一样：

• 工具描述格式不一样
• 权限边界不一样
• 返回结果格式不一样
• 上下文传法不一样

最后就会出现一个很现实的问题：

模型可以复用，场景逻辑可以复用，但接口层很难复用。

MCP 想统一的，就是这一层。

从技术上看，MCP 至少做了 4 件事

在 MCP 里，基本是三层结构：

• Host：真正运行 AI 应用的主体，比如桌面客户端、IDE、Agent 容器
• Client：Host 里负责和 MCP server 通信的那一层
• Server：真正暴露能力的一方，负责挂出工具、资源、提示模板

这意味着“模型在哪”“工具在哪”“谁负责通信”第一次从工程上被拆开了。以后换模型，不一定要重做工具层；换后端系统，也不一定要把整套 Agent 重写一遍。

MCP 底层走的是 JSON-RPC 2.0 思路。双方不是随便传一段字符串，而是按明确的方法、参数、结果、错误码通信。

AI 调工具，开始更像系统和系统在说话，而不是几段 prompt 在硬拼。

MCP 里最关键的不是一个泛泛的“tool”，而是几类不同能力：

• Tools：发起动作，比如查库、调接口、执行函数
• Resources：读取上下文，比如文件、文档、数据库视图
• Prompts：标准化暴露提示模板

翻成人话，它其实在做三件事的协议化：

能做什么、能读什么、该怎么调。

MCP 不是连上就直接乱调。两边会先初始化，声明自己支持什么、不支持什么，之后才进入发现和调用。

企业接 AI 最怕的，不是不会调，而是“本来以为能调，结果边界根本没说清”。MCP 把这件事前置了。

一次 MCP 调用，到底怎么走

一条典型调用链，基本是这样：

1. Host 连上某个 MCP server 2. Client 发 initialize，带上协议版本、capabilities 和 client 信息 3. Server 回 initialize 结果，声明自己支持哪些能力 4. Client 发 notifications/initialized 5. 如果要发现工具，走 tools/list 6. 如果要读资源，走 resources/list 和 resources/read 7. 如果要拿提示模板，走 prompts/list 和 prompts/get 8. 模型选中某个能力后，真正执行时走 tools/call 9. Server 返回结构化结果，Host 再把结果放回上下文，继续推理

工具调用第一次从 prompt 拼接，变成了协议化的能力发现、能力选择和能力执行。

这会直接影响稳定性。因为系统终于可以区分推理、调工具和工具返回结果，日志、审计、回放、权限控制这些事才有机会真正做起来。

最小消息流大概长这样：

``json { "jsonrpc": "2.0", "id": 1, "method": "initialize", "params": { "protocolVersion": "2025-03-26", "capabilities": { "tools": {}, "resources": {}, "prompts": {} }, "clientInfo": { "name": "my-agent-host", "version": "1.0.0" } } } ``

工具真正执行时，会更像这样：

``json { "jsonrpc": "2.0", "id": 12, "method": "tools/call", "params": { "name": "get_project_status", "arguments": { "project_id": "PJT-1024" } } } ``

这两段不是为了背协议，而是为了说明：

MCP 不是“AI 自己想办法去调工具”，而是把调用过程收进了一套可验证、可记录、可审计的消息流。

stdio 和 Streamable HTTP，决定了它更像本地能力还是企业接口

MCP 现在最关键的两种传输方式，一个是 stdio，一个是 Streamable HTTP。

stdio 很直接：Client 把 server 当成一个本地子进程拉起来，通过标准输入输出传 JSON-RPC 消息。

它特别适合本地工具链：

• 本地 IDE
• 本地命令行
• 本地代码、文件、终端能力

优点是简单、快，而且天然更适合本地信任边界。

另一种是 Streamable HTTP。这是更像企业级接法的远程传输方式，服务端作为独立进程存在，通过 HTTP 端点对外提供 MCP 能力，必要时还能配合流式消息。

Streamable HTTP 已经在规范里替代了更早的 HTTP+SSE 说法。对企业来说，这不是名词变化，而是远程传输方式开始收敛，后面的鉴权、代理、网关接入也更容易标准化。

它们背后其实对应着两种完全不同的场景：

• stdio 更像“本地 Agent 接本地能力”
• Streamable HTTP 更像“多个 Agent / 客户端共享一层远程能力服务”

只要你从 stdio 走向远程 HTTP，就会立刻撞上真正的企业问题：

• 身份认证怎么做
• 哪些 client 能连
• session 怎么管
• MCP-Protocol-Version 这类版本协商头怎么管
• Origin 怎么校验
• 本地服务是否只绑定 localhost
• 权限是不是按最小授权原则切
• 有没有跨团队复用的一层共享 server

这就是为什么我一直说，MCP 碰到的不只是开发体验，而是企业架构。

为什么 2025 年它突然变重

一个协议能不能从“技术社区讨论”走向“企业里真的要看”，关键不看概念漂不漂亮，要看平台是不是开始接。

MCP 这次真正升温，是因为两件事先后发生了。

第一，Anthropic 把它抛出来之后，围绕 MCP 的 server 生态开始长出来。

第二，更关键。OpenAI 在 2025 年 5 月 21 日宣布，Responses API 支持 remote MCP server。

MCP 不再只是某一家模型公司的接口偏好，而是开始进入主流 agent 平台。

再往前看，Google 在 2025 年 4 月 9 日发布 A2A 协议时，也明确把它和 MCP 放在互补位置上。A2A 解决的是 agent 和 agent 怎么协作，MCP 更像 agent 和工具、上下文、服务怎么对接。

企业 AI 开始标准化的，不只是模型接入，还有工具接入。

它真正改掉的，是企业 AI 的成本结构

过去企业做 AI，最容易陷进去的坑是“一个场景一个项目”。

客服做一个机器人，接一遍；销售做一个助手，再接一遍；运营做一个知识问答，又接一遍。模型层能复用，但接口层没有统一标准，所以每次都像新项目。

一旦 MCP 这种协议层被越来越多平台接受，事情就会变：

不是每个业务场景都从零开始接系统，而是公司开始有机会沉淀一层公共的能力接入层。

这会直接改掉企业 AI 的成本结构。以前最贵的是一次次重复集成，以后真正能拉开差距的，是谁先把内部常用系统抽成一层可复用的 MCP server 或兼容能力层。

如果再写得更工程一点，它其实是在把企业 AI 技术栈拆成三层：

• 上层：模型和 Agent 编排
• 中层：MCP 这一类能力接入层
• 下层：企业原有系统、数据源、内部服务

这三层一旦拆开，后面换模型、换 Agent、换应用入口，都不一定要把最底下那层系统接法全部重来。

这就是为什么它不像“又一个工具协议”，更像企业 AI 的中间件信号。

企业真要落地，最容易做坏的是 server 边界

很多团队第一反应是按现有系统来拆：一个系统一个 server。这个办法不一定错，但很容易把历史系统边界原样搬进 AI 层，最后模型能连很多东西，却还是很难完成一个完整动作。

我更建议按“能力域”去拆，而不是只按“系统名”去拆。

比如：

• project_mcp：项目进度、风险、阻塞、里程碑
• docs_mcp：当前版方案、制度、FAQ、模板
• ops_mcp：工单查询、状态更新、异常提报

这样做的好处是，模型拿到的是“完成任务需要的能力集合”，而不是“某个旧系统原样暴露出来的接口集合”。

再往下走，工具设计至少有三个原则：

• resource 尽量放只读、当前态、可引用的东西
• tool 尽量放有明确输入、明确输出、最好幂等的动作
• 参数 schema 要比 prompt 更严格

企业里很多工具调用失败，不是模型不会选，而是参数太松，最后每次都靠自然语言猜。

真正该先紧张的，不是“怎么接”，而是“接到哪里为止”

一听到“标准化接入”，很多人第一反应通常是效率会更高。会更高，但先被抬上桌的，不只是效率，还有权限、审计和责任。

因为 AI 只要更容易接进系统，管理层就得更早回答几件以前还能往后拖的问题：

• 什么能力只能读，什么能力允许写
• 什么数据能暴露给模型，什么不能
• 调用是全量开放，还是按角色、按场景、按审批开放
• OAuth 或企业内部身份体系怎么接
• 调用日志留到什么粒度
• 哪些动作必须设置人类接管点

所以 MCP 最值得管理者关注的，不是它让开发更顺，而是它会把企业 AI 从“能不能做”推进到“怎么受控地做”。

以前很多公司讨论 AI，主要还停留在问答层，所以权限问题经常被放在最后补。到了 MCP 这一层，顺序会反过来。因为一旦模型真的能调工具、读资源、触发动作，治理就不再是附属问题，而会直接进入架构层。

再往前走一步，企业真把 MCP 接起来以后，不能只看“有没有跑通”，还要看它跑得稳不稳。

至少有四类指标，值得被单独盯住：

• tool_call_success_rate
• fallback_to_human_rate
• resource_freshness
• unsafe_action_block_rate

很多 AI 系统看上去能用，真正的问题都藏在这里：调用经常失败，工具结果不稳定，资源读到旧版本，高风险动作没有被及时拦下。

这些都不是模型分数能解释的，它们是能力层和治理层的问题。

最后

如果只把 MCP 当成一个技术协议，你会低估它。

如果把它当成万能接口，你又会高估它。

它现在更准确的位置，是企业 AI 的接口层标准开始成形的信号。

这件事一旦跑顺，最先变化的不会是概念更多了，而是企业终于可以把一部分重复、分散、难复用的集成工作，从“每个项目重来一遍”，往“公共能力层”上收。

很多人还在讨论哪家模型更强。

我更关心另一件事：

谁会最先把自己的系统，接成 AI 真能调用的一层标准能力。

那家公司后面做的，就不再只是单点 AI 应用，而是一整层可复用的组织能力。

下一篇，我想继续拆另一条同样关键、但更容易被误读的技术线。

Deep Research 真正改掉的，可能不是搜索，而是公司里那些一直很贵、但一直被低估的前置调研动作。

AI大同学 | 在职管理者，管理学博士，正在经历 AI 对管理与组织协作方式的重塑。这是 TC 系列的第二篇。