MCP 协议是什么？企业如何用 Model Context Protocol 打通 AI 与业务系统

很多企业的 AI 项目卡在同一个地方：模型能力够了，但接不进业务系统。查个库存要写一套对接代码，读个 CRM 又要写一套，每接入一个系统都是一次定制开发。2024 年 11 月 Anthropic 开源的 MCP（Model Context Protocol）正在改变这个局面，2025 年 OpenAI、Google 相继宣布支持之后，它迅速成为 AI 与外部世界连接的事实标准。对企业来说，MCP 的意义不是又多了一个技术名词，而是 AI 集成成本结构的根本变化。

1. MCP 是什么：AI 应用的“USB-C 接口”

MCP 的官方定义是一套开放协议，标准化了大模型应用与外部数据源、工具之间的连接方式。业内常把它比作 AI 应用的 USB-C 接口：以前每个外设都要有自己的接口和驱动，现在只要符合统一标准，插上就能用。

技术上，MCP 采用客户端-服务端架构，包含三个角色：

• Host（宿主）：用户直接使用的 AI 应用，比如对话助手、IDE 插件、企业内部的智能办公入口
• Client（客户端）：运行在 Host 内部，负责与某个 MCP Server 维持一对一连接
• Server（服务端）：把某个系统的能力以标准方式暴露出来，可以连接数据库、ERP、文件系统或第三方 API

MCP Server 对外提供三类原语：Tools（可执行的操作，例如“创建采购单”）、Resources（可读取的数据，例如“最新库存表”）、Prompts（预设的提示词模板）。传输层面支持本地 stdio 和远程 Streamable HTTP 两种方式，分别对应个人工具和企业级部署两种形态。

2. MCP 解决了什么问题：从 M×N 集成到 M+N

MCP 出现之前，AI 应用接业务系统是一个 M×N 问题：M 个 AI 应用接 N 个业务系统，理论上要写 M×N 套对接代码。每换一个模型平台、每加一个业务系统，集成工作量都成倍上涨，大量预算消耗在“管道工程”而不是业务价值上。

有了 MCP 之后，问题变成 M+N：每个 AI 应用实现一次 MCP Client，每个业务系统封装一次 MCP Server，两边就能自由组合。这个变化对企业 IT 的含义非常实际：

• 业务系统的能力封装一次，可以被对话助手、办公自动化、审批机器人等多个 AI 应用复用
• 更换或增加大模型供应商时，不需要重写系统对接层
• 新系统上线，只要补一个 MCP Server，就能进入企业的 AI 能力版图

2025 年以来，国内外生态都在向这个标准收敛。OpenAI 在 Agents SDK 和 ChatGPT 桌面端支持 MCP，Google 宣布 Gemini 接入，国内的阿里云百炼、腾讯云等平台也上线了 MCP 服务托管和 Server 市场。当主流玩家都站在同一个协议上时，自建私有集成方案的性价比就越来越低了。

3. 企业落地 MCP 的四类典型场景

从企业 AI 项目的实践看，MCP 的价值在四类场景中最先兑现：

• 数据查询类：把 ERP、CRM、报表库封装成只读的 MCP Server，管理层用自然语言问“上个月华东区回款情况”，Agent 自动调用查询工具并生成解读。这类场景边界清晰、风险最低，适合作为第一站
• 知识检索类：把合同库、制度库、产品手册以 Resources 形式暴露，配合 RAG 让 AI 的回答有据可查
• 流程操作类：把审批发起、工单创建、库存调整等操作封装成 Tools，AI 在人工确认下跨系统执行多步任务，例如“发现客户投诉、查订单、建工单、通知负责人”一条链路走完
• 开发提效类：研发团队把代码仓库、CI/CD、监控系统接入 MCP，让编程助手直接读懂项目上下文、查日志、提合并请求

这四类场景大致按照“先读、后写，先人审、后自动”的顺序推进，风险和价值都比较可控。

4. 自建 MCP Server 还是接入生态？

MCP 生态里已经有数千个开源 Server，覆盖 GitHub、Slack、PostgreSQL、飞书、企业微信等常见系统。企业的选择策略可以分三层：

第一层，通用系统直接用社区成熟方案，比如数据库、代码仓库、主流 SaaS，经过安全审查后接入即可。第二层，国内业务系统（用友、金蝶、企业微信、钉钉）优先选择官方或头部厂商维护的 Server，避免使用来源不明的第三方实现。第三层，企业自研系统必须自建 MCP Server，把内部 API 做一层标准化封装。这部分工作量最大，但价值也最持久——它本质上是给企业系统建了一个“AI 可读的接口层”。

自建时有一个常见误区：把内部 API 一对一照搬成 MCP Tools。实际上 Tool 的设计要面向“任务”而不是面向“接口”。例如把“查客户等级、查历史订单、算折扣”三个 API 组合成一个“获取客户报价上下文”的 Tool，Agent 的调用成功率和安全性都会高得多。

5. 安全与治理：MCP 不是免检通道

MCP 让 AI 触达业务系统变得容易，也意味着风险传导变得容易。2025 年以来披露的多项安全研究指出，恶意或粗心的 MCP Server 可能通过工具描述注入提示词、过度索取权限、间接泄露数据。企业接入时必须建立治理边界：

• 权限最小化：每个 Server 只暴露当前场景必需的 Tools，写操作和敏感数据默认收紧
• 身份与授权：远程 MCP 连接采用 OAuth 2.1 等标准授权框架，杜绝“一个密钥走天下”
• 人机协同：涉及资金、合同、客户数据变更的操作必须保留人工确认环节
• 审计留痕：记录每一次工具调用的输入、输出和调用链，满足合规追溯
• 来源审查：第三方 MCP Server 视同引入外部依赖，要做代码审查和持续监控

简单说，MCP 降低了集成的技术门槛，但企业级的身份、权限、审计体系一个都不能少。

数舵科技如何做 MCP 企业集成？

数舵科技在企业 AI 落地中，已经把 MCP 作为智能体平台的标准集成层。我们的做法是先梳理企业希望 AI 触达的系统清单，按“查询类优先、操作类审慎”的原则划分接入批次，再为自研系统设计和开发面向任务的 MCP Server，并统一接入身份认证、权限控制和调用审计。

对于数据敏感的企业，我们支持私有化部署：大模型、MCP Server、业务系统全部运行在企业内网，AI 能力不出域。无论是从零建设 AI 集成层，还是在现有 ERP、CRM、OA 之上叠加智能体能力，都可以按场景分期实施，先让一个高价值流程跑通，再逐步扩大版图。

写在最后

MCP 的价值不在于它有多新，而在于它把 AI 集成从“每个项目重新发明轮子”变成了“遵循同一个标准拼装”。当 OpenAI、Google、Anthropic 和国内主要云平台都支持同一个协议时，企业最合理的策略就是尽早把自己系统的接口层标准化，而不是继续堆砌一次性的对接代码。

对企业决策者来说，现在需要回答的问题不是“要不要用 MCP”，而是“哪些系统的能力应该先被 AI 调用”。从只读查询场景起步，建好权限和审计体系，再让 AI 逐步参与流程操作，是一条投入产出比和风险都可控的路径。