MCP vs API：有何区别
模型上下文协议 (MCP) 是一项较新的技术，为 AIGNE 和 AI 提供了更多可能性。MCP 可被视为 AI 驱动应用获取数据、调用 API 和执行任务的新型 API 高速公路，使它们成为真正的问题解决者。但是，MCP 是如何工作的？它们与 API 又有何不同？
什么是传统 API？
传统 API（应用程序编程接口）是一套允许不同软件应用程序相互通信的规则和协议。它们充当中介，使一个系统能够请求另一个系统的数据或功能。最常见的传统 API 是 RESTful，依靠 HTTP 来定义应用程序用于交互的特定端点（例如 GET /data）。这些 API 具有以下特点：
- 通用型：专为各种软件集成设计，从 Web 服务到移动应用。
- 预定义：开发人员必须知道确切的端点和方法才能使用它们。
- 基于请求-响应：通常情况下，客户端发送请求，服务器做出响应；除非实现 Webhooks 等额外设置，否则实时交互有限。
例如，天气应用可能会使用传统 API 通过固定端点从服务器获取当前温度数据。这种方法一直是软件开发的基础，从 SOAP 演变到 REST 及更远，每一次迭代都解决了特定的需求或局限。
什么是 MCP？
模型上下文协议 (MCP) 是一种开放标准，旨在高效地将 AI 模型（特别是大语言模型，即 LLM）连接到外部工具和数据源。可以把它想象成一个通用连接器，通常被比作“AI 应用的 USB-C 接口”。MCP 使 AI 系统能够：
- 访问外部资源：无缝获取实时数据或触发其他系统中的操作。
- 动态发现工具：无需事先配置即可识别可用工具。
- 实时通信：支持类似于 WebSockets 的双向交互式交换。
MCP 作为 Anthropic 发起的一项开源计划，旨在标准化 AI 模型与外部世界的集成方式，减少对传统 API 通常需要的自定义代码的需求。
相似之处：为什么 MCP 感觉像是 API 的新版本
从宏观上看，MCP 和传统 API 有一个核心目的：促进软件组件之间的通信。以下是为什么 MCP 看起来可能像是 API 的“新版本”的原因：
- 标准化集成：两者都为系统交互提供了结构化方式。传统 API 标准化了软件与软件之间的通信，而 MCP 标准化了 AI 与工具/数据之间的通信。
- 互操作性：正如 API 培育了服务生态系统（如支付网关或社交媒体平台），MCP 也鼓励建立一个 AI 模型可以无缝接入各种工具的生态系统。
- 演进模式：API 经历了演进——从 SOAP 到 REST 再到 GraphQL——每一个阶段都在应对新的需求。MCP 符合这一模式，作为一种量身定制的协议，它建立在 API 概念之上，以适应 AI 日益增长的重要性。
从专注于去中心化应用的平台 ArcBlock 的视角来看，MCP 将使 AIGNE（其无代码 AI 应用平台）变得更加易于访问，并赋予其立即触达外部数据源的能力。
区别：是什么让 MCP 与众不同
然而，MCP 不仅仅是传统 API 的翻版——它专门针对 AIGNE 的需求（特别是针对 LLM）引入了创新。以下是关键区别：
- 动态发现：MCP 允许 AI 模型即时发现可用的工具和资源，而无需预定义的端点。传统 API 要求开发人员预先了解并针对特定接口编写代码。
- 实时双向通信：MCP 支持交互式的双向交换（例如，AI 获取数据并传回命令），这超越了 RESTful API 典型的请求-响应模型。虽然 API 可以通过复杂的设置实现这一点，但 MCP 将其优雅地嵌入其中。
- 针对 AI 的特定设计：MCP 是为 AI 模型量身定制的，简化了 LLM 从外部系统获取上下文的方式。传统 API 是通用的，服务于任何软件，这可能会导致在 AI 用例中产生更多的自定义集成工作。
- 简化集成：MCP 减少了连接 AI 与外部系统时对定制代码的需求，而这正是传统 API 常见的障碍。
例如，假设你使用 AIGNE 创建了一个 Agent，用于管理 ArcBlock 平台上的去中心化市场。通过 MCP，它可以动态发现库存工具、获取实时库存数据并更新列表——所有这些都通过一个标准协议完成。而传统的 API 方法可能需要多次自定义集成，从而减慢开发速度。
对比表：MCP vs. 传统 API
| 维度 | 传统 API | MCP (现代 API 平台) |
|---|---|---|
| 架构 | 单体式 一个在单一单元中处理所有事务（如用户登录、数据、支付）的庞大系统。 | 微服务 小型、独立的服务，每个服务处理特定任务（例如，一个负责登录，另一个负责支付）。 |
| 可扩展性 | 难以扩展 必须同时扩展整个系统，即使只有一个部分需要更多资源。 | 易于扩展 可以根据需要扩展单个服务，而不影响其他部分。 |
| 协议 | 通常使用 SOAP 一种较旧、较复杂的协议，可能显得臃肿且难以处理。 | 使用现代协议，如 REST 或 GraphQL。更轻量、更快速且更易于使用。 |
| 管理 | 手动管理 开发人员必须自己处理安全和路由等任务，这很耗时。 | 通过 API 网关实现自动化 自动处理安全、路由和其他任务，节省时间和精力。 |
| 灵活性 | 灵活性较低 做出更改可能会影响整个系统，因此更新具有风险，需要周密计划。 | 高度灵活 可以在不影响其他服务的情况下更新某个服务，使更改更快速、更安全。 |
| 部署 | 需要部署整个应用程序 即使是很小的更新也意味着重新部署所有内容，这可能会导致停机。 | 向单个服务部署更新 可以更新一个部分而不触及其他部分，从而减少停机时间。 |
| 故障隔离 | 一个故障可能影响整个系统 如果一个部分损坏，可能会导致整个 API 崩溃。 | 故障是隔离的 如果一个服务失败，其他服务将继续运行，从而防止大范围问题。 |
为什么说 MCP “其实只是 API 的新版本”（但也带点新花样）
那么，为什么 MCP 会被看作仅仅是 API 的新版本呢？从我的观点来看，这是因为 MCP 采用了熟悉的 API 概念（连接系统）并使其适应了 AI 时代。这是一种演进，就像 REST 对 SOAP 的改进一样，它提供了一种标准化的、开发者友好的方式将 AI 功能集成到应用程序中。传统 API 和 MCP 都旨在搭建系统间的桥梁，而 MCP 利用这一传统，以一种让精通 API 的开发人员感到直观的方式使 AI 变得触手可及。
然而，这种看法可能会低估 MCP 的重要性。它不仅是为 API 刷了一层新漆，还是一个专门的协议，通过以 AI 为中心的功能增强了 API 框架。对于 ArcBlock 而言，将 MCP 集成到其去中心化生态系统中，意味着赋予 AI 驱动的 dApp 无缝、实时的交互能力，这是传统 API 无法如此高效实现的。这是一种战略进步，与其构建互操作性、去中心化解决方案的目标相一致。ArcBlock 的 AIGNE + MCP，意味着 AIGNE Framework、Agent 等都将获得超强动力。欢迎访问 https://www.aigne.io 开始体验 AIGNE 无代码 AI 应用平台。请继续关注更多 MCP 更新。