MCP 到底是什么：企业该怎样用它接系统

MCP（Model Context Protocol，模型上下文协议）是一套开放协议，用来规范"模型如何统一接入外部工具与数据源"。它由 Anthropic 在 2024 年底开源，随后被多家模型与工具厂商采纳，也可以独立用在企业自建的系统集成里。

它解决的问题：N×M 变成 N+M

在没有统一协议之前，每个模型要接每个业务系统，都要单独开发一套对接逻辑。有 N 个模型和 M 个系统，就是 N×M 份工作量。协议把这个矩阵拆开：系统侧按协议暴露一次能力，模型侧按协议实现一次接入，工作量降到 N+M。

工作方式：客户端与服务端

协议把参与方分成两类：一边是运行在宿主环境里的客户端（例如智能体应用本身），一边是暴露能力的服务端。服务端把自己的能力声明出来，客户端在需要时调用。能力通常分为三类——可执行的工具、可读取的资源、可复用的提示模板。

企业接入时要做的三类适配工作

1. 封装现有接口。把内部系统的 API 包装成协议规定的形式，明确每个工具的名称、用途说明和参数结构。参数结构描述得越清晰，模型调用出错的概率越低。
2. 定义权限边界。协议本身不解决授权问题。必须明确每个工具能被哪些角色调用、能操作哪些范围的数据，并在服务端而不是模型侧做校验。
3. 处理脏数据与异常。真实系统的返回往往包含字段缺失、格式不一、超时。这些必须在封装层处理干净，否则模型会把数据问题当成事实来推理。

五个容易踩的坑

• 把写操作当成读操作接。查询类工具和提交类工具必须分开定义，后者需要额外的人工确认环节。
• 工具粒度太粗。一个"处理订单"的工具不如"查订单"、"改地址"、"取消订单"三个工具好用，后者模型更容易正确调用。
• 在描述里写业务黑话。工具说明是给模型读的，需要用准确、无歧义的语言描述适用条件与副作用。
• 忽略调用的可观测性。每次工具调用都应有日志，否则出问题时无法判断是模型选错工具还是工具本身出错。
• 以为接上就万事大吉。协议只保证接得上，数据是否准确、口径是否统一，仍然要靠企业自己的数据治理。

把一个协议当成万能钥匙是常见的期待错位。它降低的是连接成本，不是数据治理成本——后者往往才是项目里真正的大头。