2024 年底，Anthropic 发布 MCP（Model Context Protocol）的时候，社区的反应出奇地热烈。
这种热烈是有道理的。在此之前，每个想让 AI 调用外部工具的团队，都在重复发明同一个轮子：写一段胶水代码，把工具的输入输出格式转成 LLM 能理解的形式，再处理错误、超时、重试。每换一个模型或工具，就得重新适配一遍。MCP 想解决的就是这个问题——定一套标准，让模型和工具之间的连接方式统一起来，就像电脑上的 USB 接口一样。
在 USB 出现之前，打印机、显示器、读卡器等等各用各的接口，换个设备可能要拆机箱换接口卡。USB 把这件事标准化了，现在你买一个新鼠标，插上就能用，不需要知道它内部怎么实现的。MCP 想对 AI 的工具调用做同样的事。
但如果你在企业场景里真的试过用 MCP 落地，会发现它解决的问题和你实际碰到的问题之间，存在一段明显的距离。
MCP 解决了什么
先说它确实做到的事。
MCP 定义了一套 Client-Server 协议，模型作为 Client，外部工具或数据源作为 Server，两者通过标准化的消息格式交互。工具提供方按照协议实现一个 MCP Server，之后任何支持 MCP 的模型都能直接调用，不需要为每个模型单独适配。
从开发者的角度，这件事的价值体现在如果你给公司的日历系统写了一个 MCP Server，DeepSeek 能用，Qwen 也能用，以后换模型不需要重写工具层的代码。连接标准化之后，工具的复用成本降低了。
GitHub 上已经有一批开源的 MCP Server，覆盖了文件系统、数据库、常用 SaaS 服务（Slack、GitHub、Notion）等场景。对个人开发者或小团队来说，这些现成的实现确实能快速搭起一个能用的 AI 助手。
但它没有解决的事，恰好是企业最在意的
1、行为可控性
MCP 规范本身对"AI 能不能调用这个工具"没有任何约束。它定义了工具怎么被描述、怎么被调用，但没有定义谁有权调用、在什么条件下可以调用、调用了之后要不要记录。这些问题被留给了具体的 MCP Server 实现。
换句话说，MCP 解决了"接口怎么插"，但没有解决"插上之后能做什么"。
这在个人工具或团队内部的小应用上影响不大，毕竟只有自己用，出了问题自己负责。但企业系统不是这样的。一个中型制造企业的 ERP，里面有采购数据、销售数据、成本数据，不同角色的人能看到的范围是不一样的。如果 MCP Server 不处理权限隔离，AI 就有可能以当前用户的身份访问到它本不该访问的数据，而且不会有任何警报。
2、对业务系统的侵入性
要让一个现有业务系统支持 MCP，你需要为它实现一个 MCP Server。这个 Server 需要了解业务系统的数据结构、接口设计、认证方式，并把这些转换成 MCP 的格式。
一个使用活字格低代码开发的小型应用，服务端命令可能有三四十个，背后的数据表也有几十张。如果要把这些全部包装成 MCP 工具，工作量是相当可观的。更麻烦的是，业务系统在迭代，加字段、改接口、新增功能等，每次变更都需要同步更新 MCP Server，否则 AI 拿到的是过时的工具描述，调用就会出错。
这不是 MCP 协议设计的问题，而是"为每个业务系统维护一个 MCP Server"这件事在工程上本身就有持续成本。
3、多用户场景下的会话隔离
MCP 目前的主流实现主要针对单用户或轻量集成场景。一个开发者在本地起一个 MCP Server，用 TREA 连上去调用，这个场景下会话隔离不是问题，因为就只有一个用户。
但企业部署是多用户的。张三发起了一个采购查询，李四同时在查库存，这两个会话不能互相干扰，更不能出现数据串台的情况。要在 MCP 上实现这种多用户隔离，需要在 MCP 层之外额外设计会话管理机制，这部分工作 MCP 规范没有覆盖。
4、 审计链路的缺失
调了哪个工具，传了什么参数，返回了什么，这些信息需要被记录下来，才能在出问题的时候追溯。MCP 协议本身没有内置审计日志的机制，这同样需要在具体实现里自己做。
为什么还是值得了解它
说了这么多限制，MCP 本身仍然是有意义的事情，值得关注。
它的价值不在于"解决了企业 AI 落地的全部问题"，而在于在工具层建立了一个共同语言。在此之前，Function Calling 的格式在 OpenAI 和其他模型之间是不兼容的，工具描述的写法各家不同，开发者适配一个工具往往要维护好几套代码。MCP 让这件事有了统一的规范，工具生态可以围绕这个规范积累。
而且 MCP 在某些场景下确实够用。如果你在做的是一个内部工具、个人助手，或者接入的是像 GitHub、Slack 这类已经有现成 MCP Server 的服务，MCP 是目前最省力的选项。
问题只出现在你想把它推广到企业多用户场景，同时还要保证安全可控的时候。
在企业场景里，缺的那一层是什么
回到最开始的 USB 比喻，它其实揭示了一个问题的边界：USB 解决了"怎么连接"，但它不负责"连上之后电脑要不要信任这个设备"。操作系统信任机制、驱动签名、UAC 弹窗——这些是连接标准化之上的另一层机制。
MCP 现在的处境差不多是这样。连接标准化了，但连上之后谁能调用什么、怎么审计、怎么隔离用户——这一层的答案，MCP 规范里没有。
在企业 AI 的语境下，这一层恰好是最难绕开的。它不是锦上添花的功能，而是让 IT 部门能点头放行的基础条件。
一种思路是在 MCP 之上叠加这些能力——给每个 MCP Server 加权限校验、加审计日志、加会话隔离。这在技术上是可行的，但每个 Server 都要独立实现一遍，成本不低，而且一致性很难保证。
另一种思路是换一个切入点：不从"给 AI 接上工具"出发，而是从"让业务系统理解 AI 的语义请求"出发，把语义约束和权限控制做在一个集中的层里，AI 通过这一层统一访问所有业务系统。
这两种思路解决的是同一个问题，但工程上的取舍不同。后者是接下来几篇文章会详细讨论的方向。
本文是"企业AI落地"系列的第5篇。下一篇讨论 RAG：为什么把操作手册喂给 AI，并不能让它学会操作系统。
