分解模型上下文协议（MCP）

MCP 的客户端-服务器架构

MCP 建立在客户端-服务器模式上，它构建了人工智能模型检索外部数据源并与之交互的方式。

• MCP 客户端是人工智能代理、应用程序或任何请求结构化数据的系统。
• MCP 服务器充当中介，从各种应用程序接口、数据库或企业系统中获取数据，并以一致的格式返回。

MCP 服务器无需人工智能模型直接发出 API 请求，而是负责处理复杂的身份验证、数据检索和响应规范化工作。这意味着人工智能代理不再需要管理多个 API 证书、不同的请求格式或不一致的响应结构。

例如，如果一个人工智能模型需要从 Google Drive、Slack 和数据库等多个服务中提取信息，它不会单独查询每个 API。它会向 MCP 服务器发送一个单一的结构化请求，MCP 服务器会处理该请求，从必要的来源收集数据，并返回一个组织良好的响应。

MCP 请求-响应生命周期

典型的 MCP 交互遵循结构化的请求-响应周期，消除了冗余的 API 调用，实现了数据检索的标准化。

1.人工智能代理向 MCP 服务器发送结构化请求。人工智能代理不需要制作单独的应用程序接口请求，而是以统一的格式定义所需的数据。

{
  "request_id": "xyz-987",
  "queries": [
    {
      "source": "github",
      "action": "get_recent_commits",
      "repo": "company/project"
    },
    {
      "source": "slack",
      "action": "fetch_unread_messages",
      "channel": "engineering"
    }
  ]
}

‍

2.MCP 服务器通过验证身份、检查权限和确定要查询的外部系统来处理请求。

3.查询以并行方式执行，这意味着同时检索多个服务的数据，而不是按顺序检索，从而减少了整体延迟。

4.将不同来源的回复标准化为人工智能模型可以轻松处理的结构化格式。

{
  "github": {
    "recent_commits": [
      {
        "author": "Alice",
        "message": "Refactored AI pipeline",
        "timestamp": "2024-03-12T10:15:00Z"
      }
    ]
  },
  "slack": {
    "unread_messages": [
      {
        "user": "Bob",
        "text": "Hey, can you review the PR?",
        "timestamp": "2024-03-12T09:45:00Z"
      }
    ]
  }
}

与需要人工解析的原始 API 响应不同，MCP 可确保所有检索到的数据都遵循可预测的结构化格式，使人工智能模型更容易理解和利用。

查询执行和响应汇总

MCP 旨在通过引入结构化执行流程，优化人工智能模型与外部系统的交互方式。

1. 请求验证可确保人工智能模型在检索任何数据之前拥有必要的权限。
2. 查询路由决定需要访问哪些外部服务。
3. 并行执行可同时从多个来源检索数据，从而减少因顺序 API 请求而造成的延迟。
4. 响应聚合可将结构化数据整合到单一响应中，从而使人工智能模型无需手动处理多个原始 API 输出。

通过减少冗余请求、规范响应和集中处理身份验证，MCP 消除了不必要的 API 开销，使人工智能驱动的自动化更具可扩展性。

认证挑战

MCP 的最大承诺之一就是让人工智能代理不再依赖于特定的 API 集成。然而，身份验证（AuthN）仍然是一大挑战。

如今，API 身份验证是一个分散的过程--有些服务使用 OAuth，有些依赖于 API 密钥，还有些需要基于会话的身份验证。这种不一致性使得新 API 的上架非常耗时，而 MCP 目前还没有一个内置的身份验证框架来处理这种复杂性。

MCP 仍需要一些外部机制来验证 API 请求，这意味着使用 MCP 的人工智能代理必须依赖 Composio 等其他解决方案来管理 API 凭据。身份验证已列入 MCP 的路线图，但在完全实现之前，开发人员仍需要变通方法来处理跨多个系统的身份验证。

身份管理不明确

另一个悬而未决的问题是身份管理--当人工智能代理通过 MCP 发出请求时，外部系统会看到谁？

例如，如果人工智能助手通过 MCP 查询Slack ，Slack 是否应识别该请求来自：

• 最终用户？
• 人工智能代理本身？(这就需要Slack 单独处理基于人工智能的交互）。
• 共享系统账户？（这可能会带来安全和访问控制问题）。

在企业环境中，这个问题更加复杂，因为在企业环境中，访问控制策略决定了谁可以检索哪些数据。如果没有明确的身份映射，MCP 集成可能会面临访问受限、安全风险或不同平台间的不一致。

计划为 MCP 提供 OAuth 支持，这可能有助于明确身份处理，但在全面实施之前，人工智能模型可能会在基于权限的第三方服务访问方面遇到困难。 

供应商锁定和生态系统分裂

MCP 目前是一项Anthropic倡议，这就对其长期标准化提出了疑问。随着人工智能生态系统的发展，其他主要参与者--如OpenAI 或 DeepSeek--很有可能开发出自己的人工智能与系统交互协议。

如果出现多个相互竞争的标准，整个行业就会支离破碎，迫使开发人员在不同的、互不兼容的方法之间做出选择。MCP 是继续占据主导地位，还是仅仅成为几种竞争方案之一，还有待观察。