模型上下文协议（MCP）：把 AI 连接到 ERP、CRM 与业务系统

许多企业已经尝试用 AI 助手写邮件、总结文档或回答一般性问题。可一旦要求 AI 处理涉及公司数据的工作，例如查询库存、读取 CRM 中的客户历史，或在 ERP 中准备订单草稿，障碍几乎总是相同的：AI 没有一条安全、规范的通道进入这些系统。每个连接都必须单独开发，而且每个模型、每个应用的做法都不一样。

模型上下文协议（Model Context Protocol，简称 MCP）正是为解决这一问题而出现的。MCP 是一项开放标准，规定 AI 应用如何连接数据源和工具。本文从企业主和 IT 经理的角度解释 MCP：它到底标准化了什么、什么时候有用、需要控制哪些风险，以及如何在已经运行的 ERP、CRM 或定制系统之上落地。

要点摘要

• MCP 是连接 AI 应用与数据、工具的标准协议，作用类似电器的标准插头
• MCP 服务器把您的某个系统（如 ERP 或 CRM）包装起来，只开放您允许的特定功能
• 主要好处是同一个连接可以被多个 AI 助手和模型复用，无需每次从零开发集成
• MCP 本身并不自动安全：权限、身份认证、日志记录和人工审批仍需专门设计
• 先为一个系统搭建只读的 MCP 服务器，衡量效果后，再逐步加入写入操作

MCP 想解决的问题

设想一家分销企业：用 ERP 管理库存和财务，用 CRM 管理销售，用共享文件夹存放合同。团队希望 AI 助手能回答诸如「分仓某商品还有多少库存」「这位客户上次下单是什么时候」「合同里的付款条件是什么」之类的问题。没有标准时，IT 团队必须为所选模型与每个系统分别编写集成代码。一旦企业更换模型，或想使用另一个 AI 助手，大部分工作就得重做。

这和有文档的 API 普及之前的系统集成很像：每个连接都独一无二、脆弱且维护成本高。MCP 提供了一种统一的方式：业务系统只需包装一次成为 MCP 服务器，任何支持该协议的 AI 应用都能在您设定的权限范围内使用它。

MCP 的基本工作方式

MCP 中有三个角色。宿主（host）是用户使用的 AI 应用，例如桌面助手、内部聊天应用或自动化智能体。客户端（client）是宿主内部负责使用 MCP 协议通信的组件。服务器（server）是您开发或安装的程序，用来开放对某个系统的访问，例如为 ERP 提供的 MCP 服务器。

MCP 服务器可以提供几类能力。对企业最重要的是工具（tools），即 AI 可以调用的函数，例如查询客户、检查库存或创建报价草稿。其次是资源（resources），即可作为上下文读取的数据，例如价目表或流程文档。还有提示模板（prompts），由服务器所有者预先准备，使某些任务以一致的方式完成。

MCP 服务器不是通往整个数据库的大门

常见的误解是认为 MCP 让 AI 直接访问数据库。好的 MCP 服务器恰恰相反：它只提供范围窄、定义清晰的函数，每个函数都有输入校验和权限检查。「按商品编码查询库存」与「允许 AI 对库存表执行任意查询」完全不同。函数越窄，越容易测试、审计和控制。

MCP 与现有 API 的关系

MCP 并不取代 API。实践中，MCP 服务器通常调用系统已有的 API。如果您的 ERP 已经有库存和订单 API，MCP 服务器只需把这些功能转换成 AI 应用能理解的形式，并配上清晰的说明，让模型知道何时、如何使用。如果老系统还没有 API，搭建规范的 API 层往往是第一步，而这一步对 AI 之外的其他集成同样有价值。

什么时候值得考虑 MCP

并非每家企业都需要 MCP。当以下几个条件同时成立时，它的价值最大。

• 需要把不止一个系统接入 AI，例如 ERP、CRM 和客服工单系统
• 企业希望可以自由更换 AI 模型或应用，而不必重建集成
• 多个团队或应用会使用同一个连接，标准化可以减少重复开发
• 存在真实且反复出现的需求，而不只是想尝试新技术
• IT 团队或开发合作伙伴愿意像维护其他生产系统一样维护 MCP 服务器

反之，如果您只需要一个简单的自动化，例如总结收到的邮件并保存到某个系统，通过 API 或 Webhook 直接集成可能更快、更便宜。连接数量和使用者增多时，MCP 才更具吸引力。

企业中的应用示例

读取 CRM 和 ERP 的销售助手

销售人员在给客户打电话前，常常在 CRM 和 ERP 之间来回切换。为两者搭建 MCP 服务器后，AI 助手可以准备一份简报：订单历史、未结应收款、最近一次投诉以及常购产品。初期所有功能都可以是只读的。谈什么仍由销售人员决定，AI 只是减少查找数据的时间。

带订单上下文的客户服务

客服处理物流状态咨询时，通常要打开好几个页面。提供订单跟踪和退货状态函数的 MCP 服务器，能让 AI 助手准备完整的回复草稿，客服核对后再发送。对于政策类问题，MCP 资源可以存放公司的正式文件，这与 RAG 的思路一致。

处理重复流程的自动化智能体

当企业开始使用 AI 智能体 完成诸如根据内部申请准备采购订单草稿等任务时，MCP 就成为智能体调用工具的标准通道。此时权限设计尤为关键，因为智能体在没有人逐步输入的情况下行动。

风险与安全控制

MCP 简化了连接，也正因如此，如果设计草率，就会扩大风险面。以下几点应从一开始就纳入设计，而不是事后补上。

身份认证与用户身份

MCP 服务器需要知道是谁在请求数据，而不只是哪个应用。理想情况下，用户在 ERP 或 CRM 中的权限在通过 AI 访问时依然有效。在 ERP 中无权查看销售毛利的仓库员工，也不应通过 AI 助手看到。请把身份认证与企业身份系统（例如 SSO）集成，并遵循与用户权限设计相同的原则。

提示注入与外部内容

AI 会读取并不总是可信的内容：客户邮件、供应商文件或任何人输入的备注。这些内容可能包含伪装成指令的句子，例如要求 AI 把数据发送给他人。缓解措施包括：限制能向外发送数据的工具、把读取工具和写入工具分开，以及对影响公司外部的操作要求人工审批。

第三方 MCP 服务器

现成 MCP 服务器的生态增长很快。这很方便，但每个服务器都是能访问您数据的代码。请像对待其他软件依赖一样对待第三方 MCP 服务器：检查来源、维护者、所请求的权限和更新记录。软件供应链安全的原则在这里完全适用。

日志与审计追踪

记录每一次工具调用：用户是谁、调用了哪个工具、发送了哪些参数、返回了什么结果。没有这些记录，就很难回答「为什么这份报价草稿的价格不一样」这样简单的问题。把 MCP 日志与 ERP 审计追踪关联起来，使每一次数据变更都能追溯到来源。

在企业中落地 MCP 的步骤

1. 01选择一个高频且易于衡量的用例，例如在销售电话前准备客户简报
2. 02列出所需的最少数据和功能，然后删掉所有并非真正必要的部分
3. 03确保源系统有稳定的 API；如果没有，先搭建 API 层
4. 04搭建只读功能的 MCP 服务器，配备清晰的工具说明、用户认证和完整日志
5. 05先让小范围用户测试，包括空数据、错误编码和越权请求等困难情况
6. 06与初始状态对比衡量效果，例如准备时间或无需升级处理即可解答的问题数量
7. 07逐步加入写入功能，从需要审批的草稿开始

工具说明常被低估，但 AI 模型正是根据这些说明决定调用哪个工具。请像给新员工写文档一样编写说明：工具做什么、何时使用、何时不能使用，以及正确输入的示例。含糊的说明会导致 AI 调用错误的工具，或凭猜测填写参数。

成本与维护

MCP 的成本包括服务器开发、源系统 API 调整、测试，以及随请求量增长的 AI 模型使用费用。此外还有维护成本：ERP 升级或数据结构变化时，MCP 服务器也必须随之调整。请把 MCP 服务器当作内部产品来管理，明确负责人、记录版本，并配备自动化测试，避免变更破坏许多人依赖的工具。

长期收益在于复用。为 ERP 构建一次的 MCP 服务器，可以同时服务销售助手、客服智能体和财务自动化。即使将来更换 AI 模型供应商，与业务系统的连接也无需重建。

常见错误

• 为了让 AI 看起来无所不能，一次开放过多功能
• MCP 服务器使用管理员账号，导致用户权限失效
• 未审查代码和所需权限就安装第三方 MCP 服务器
• 不记录工具调用，出错后无法追溯
• 把 MCP 当作没有负责人、没有维护预算的实验项目
• 从技术出发，而不是从需要改进的业务流程出发

MCP 在企业 AI 路线图中的位置

MCP 最好被视为集成基础设施的一部分，而不是独立的 AI 项目。它在干净的数据、有文档的 API 和清晰的 AI 使用政策之上效果最好。已经整理好主数据和系统集成的企业，会比数据仍然分散的企业更快感受到 MCP 的好处。

MCP 标准及其生态仍在发展，包括认证方式和推荐的安全实践。请参考协议官方文档和您所用 AI 供应商的最新说明，并把服务器设计得易于更新。

结论

模型上下文协议让 AI 与业务系统之间的连接更统一、更易复用，也不会被锁定在单一供应商上。对于希望 AI 使用 ERP、CRM 和内部文档数据的企业，它的价值是实实在在的。但连接标准并不等于安全保障。权限、日志、读写工具分离和人工审批，仍然是系统设计者的责任。

从小处着手：一个系统、一个用例、只读功能，以及明确的成功指标。在此基础上稳步扩展，因为每一步都可以解释、也可以控制。