模型上下文协议概述
 |
模型上下文协议 (测试版) 目前以预览模式提供，且仅提供基本功能验证。完整的资格认证和扩展功能将在未来版本中推出。
|
传统上，每个 AI 应用程序均需要与每个后端系统自定义集成。在一个具有 M 个 AI 应用程序和 N 个数据源的环境中，这会产生 M × N 个独立的集成。
例如，在 3 个 AI 应用程序连接到 3 个数据源的情况下，已经需要 9 个独立集成，每个集成都需要单独配置身份验证逻辑、数据映射、错误处理，并进行持续维护。随着系统数量的增多，模型扩展难度也相应增加、工程开销上浮、功能交付速度降低，且会导致应用程序使用企业数据的方式不一致。
MCP 将通过对 AI 应用程序与外部系统的交互方式进行标准化来消除这种碎片化。
下图旨在说明 M×N 个集成中存在的挑战，其中展示了在多个 AI 应用程序和数据源的环境中是如何让自定义连接网络创建快速变复杂的。
MCP 如何对集成进行简化
MCP 在 AI 应用程序和后端系统之间引入了标准化的交互层。MCP 不要求每个 AI 应用程序与每个数据源单独集成，而是通过 MCP 客户端和 MCP 服务器提供统一的框架：
• AI 应用程序与 MCP 客户端集成一次。
• 数据源与 MCP 服务器集成一次。
然后，由 MCP 来管理交互模型，包括工具执行、模式交换和上下文通信。这将集成模式从 M×N 个模型 (需要将每个应用程序与每个数据源进行直接自定义集成) 转变为 M+N 模型 (只需将每个系统连接到 MCP 生态系统一次)。
在实践中，一个包含 3 个 AI 应用程序和 3 个数据源的环境，集成计数将从 9 个下降到 6 个。这种标准化方法提高了可伸缩性，减少了维护开销，且会在不同系统之间实现一致的互操作性。
下图展示 MCP 如何将集成模式从 M×N 个自定义连接简化为 M+N 个模型，从而在降低复杂性的同时提高可伸缩性的。
跨多站点 ThingWorx 部署的 MCP 集成
下图旨在说明 MCP 如何在 AI 系统与跨多个制造地点的分布式 ThingWorx 环境之间实现智能、统一的交互。
AI 交互层
在顶层，ThingWorx AI 助手可作为 MCP 客户端运行，允许 AI 代理通过标准化的 MCP 交互调用 ThingWorx 服务。这支持数据查询、诊断或智能自动化等工作流。
自定义应用程序和 ThingWorx 应用程序 (例如 DPM 和 AMU) 也可能通过同一 MCP 接口进行通信。
ThingWorx MCP 服务器
每个 ThingWorx 实例 (在每个制造地点或地区部署) 充当 MCP 服务器，通过 MCP 公开平台功能 (工具、提示和资源)。这可让 AI 应用程序使用一致的接口连接到任何站点，而无需自定义集成。
图中显示的站点部署示例包括：
• 服务器 1 - 站点 1 和站点 2 (波士顿、底特律)
• 服务器 2 - 站点 3 (慕尼黑)
• 服务器 3 - 站点 4 (墨西哥城)
每台服务器都集成了本地操作系统，例如 ERP、MES、PLM 和 Kepware 互联工业设备。
采用 MCP 的多站点数字主线
MCP 在所有站点的 AI 客户端和 ThingWorx 服务器之间提供了标准化通信层。优点包括：
• AI 通过统一、一致的接口与运营数据进行交互
• 降低了跨异构系统集成的复杂性
• 访问任何 ThingWorx 部署中的上下文信息
• 可扩展多站点编排和分析由 AI 提供支持
使用 MCP 进行代理到系统集成
MCP 客户端，例如 Claude Desktop、Cursor、VS Code 扩展或自定义 AI 应用程序，可以与任何符合 MCP 标准的系统集成，包括：
• ThingWorx MCP 服务器
• 公开 MCP 接口的第三方系统
这允许 AI 代理在没有自定义连接器的情况下跨多个企业系统运行，并利用 MCP 实现对工具、提示及数据资源的结构化访问。
集成了 AI 代理和互联系统的生态系统
借助 MCP，代理不仅可以与 ThingWorx 进行交互，还可以与支持 MCP 的系统进行交互，例如：
• SAP
• Salesforce
• Microsoft 365
• Slack
• GitHub
• 其他 ThingWorx 服务器
主要优点
• 标准化 - 通过提供用于 AI 到系统通信的通用协议，MCP 消除了自定义点对点集成。
• 可伸缩性 - 无需重新构建集成即可添加新站点或应用程序。
• AI 驱动的洞察 - 集中式 AI 助手可以对分布式运营数据进行推理。
• 扩展性 - ThingWorx 工具和资源仍可插入任何符合 MCP 的主机 (例如 Claude Desktop 和 VS Code 扩展)。