MCP Featured

模型上下文协议 (MCP)：连接人工智能与业务的协议

04 Jun 2026 • 6 min read

提出问题，人工智能即刻回答。这令人印象深刻。但几乎立刻，下一个问题就出现了：我们能否让它处理我们实际的数据？

大多数人工智能项目复杂之处就在于此。而模型上下文协议（MCP）正是解决这一难题的途径。

MCP 不是产品，也不是平台，而是一种标准。它是一种公认的方式，使人工智能应用能够与贵公司现有的工具和数据源进行通信。理解 MCP 不仅能帮助您更自信地评估人工智能方案，还会改变您提出的问题。

为什么人工智能模型不了解你的业务

这是其他一切的基础，所以有必要把它说清楚。

人工智能模型是在海量数据集上训练的。但这些训练数据是有截止日期的。而您的业务数据从未包含在其中。

您的客户、您的订单、您的产品目录、您的内部流程、您的定价逻辑，这些都不包含在模型中。

这并非缺陷，而是模型的工作原理。从本质上讲，模型是一个数学系统。它接收输入，检测模式，并预测输出。它在这方面非常出色。但它只能处理它已知的信息。而它已知的信息仅限于训练数据的边缘。

所以，当你问人工智能“我们前十个未完成订单的状态如何？”而它没有任何反应时，这并不是人工智能出了故障。这只是人工智能它无法获取到能够回答这个问题的数据。

MCP是改变这一切的桥梁。

MCP 代表模型上下文协议（Model Context Protocol）。

最简单的理解方式是：HTTP 协议规范了 Web 浏览器与 Web 服务器之间的通信方式。MCP 协议规范了 AI 应用与数据源和业务工具之间的通信方式。

在 MCP 出现之前，每个 AI 集成都是定制开发的。如果想让 AI 与 Salesforce 通信，就得构建一个定制的 Salesforce 集成；如果想让它与数据库通信，就得构建一个定制的数据库集成。每个新的连接都是一个独立的项目。

MCP 通过标准化对话改变了现状。一款专为 MCP 而构建的 AI 应用可以连接到任何 MCP 服务器，无论另一端是什么。一次构建，随处连接。

而且这种应用是真实存在的。如今几乎所有主流人工智能应用，包括 Claude、ChatGPT 和大多数开源替代方案，都原生支持 MCP。

使用 MCP 的 AI 应用包含三个层次。理解它们能让整个过程更加清晰明了。

这是用户看到并与之交互的内容。

它可以是浏览器中的聊天界面，可以是 Slack 机器人，可以是带有 AI 功能的 FileMaker 布局，也可以是你们团队内部开发的自定义工具。形式并不重要。

之所以称之为人工智能应用，是因为它可以与模型进行通信，并且在 MCP 到位的情况下，当需要获取模型自身没有的信息时，可以联系外部数据源。

AI应用程序是MCP客户端，它负责发起与MCP服务器的连接。请注意，AI应用程序本身并不直接连接到您的数据，它只是连接到MCP服务器。

这是智能层。它处理语言，生成响应，并决定何时调用外部工具来获取所需信息。

模型本身无法直接访问您的数据。它依赖于人工智能应用程序来获取所需数据并返回。该模型可以由 OpenAI 或 Anthropic 等商业服务提供商托管，也可以托管在您自己的基础设施上，还可以部署在私有云环境中。托管位置对数据隐私有着重大影响，我们稍后会详细讨论这一点。

这才是真正干活的地方。

MCP 服务器位于您的 AI 应用程序和业务系统之间。它向 AI 应用程序公开特定的、由开发人员定义的功能，在 MCP 术语中，这些功能被称为“工具”。

工具的功能可能包括：查找客户记录；获取该客户的最近 10 个订单；检查此发票的状态；运行此工作流程。

MCP 服务器通过现有 API 连接到您现有的业务系统。如果是 Salesforce，则使用 Salesforce API；如果是 FileMaker，则使用 Data API 或 OData API；如果是自定义数据库，则使用您已构建的任何访问层。

无需重建数据层。MCP 服务器会将您现有的数据封装起来，并以结构化、标准化的方式使其可供 AI 访问。

就像之前的 API 一样，随着它逐渐融入标准实践，最终也会变得不那么显眼。但就目前而言，了解它是一项优势。它能让你更清晰地评估 AI 集成方案，提出更有价值的问题，并就如何将业务数据连接到 AI 做出深思熟虑的决策。

人工智能应用与业务数据之间的桥梁已经存在。问题在于，你是否制定了构建这座桥梁的计划。

如需与我们讨论业务选型，或预约一场关于 FileMaker 能为您做什么的探索性讨论，请发送邮件至 lance.zhou@aoguu.com 访问 https://aoguu.com/about/