模型上下文协议（MCP）：多 LLM 协同的 AI 新纪元

大语言模型（LLM）的快速发展为人工智能应用带来了前所未有的机遇。然而，充分发挥其潜力往往需要它们与现实世界交互，访问多样化的数据，并进行无缝协作。模型上下文协议（MCP）的出现，尤其是与多个 LLM 结合使用时，将成为一种变革性的开放标准，能有效解决这些挑战。

前 MCP 时代的碎片化格局

在 Anthropic 于 2024 年底推出 MCP 之前，将 LLM 与外部工具和数据源集成是一个定制的、通常很麻烦的过程。开发者面临着一个巨大的 “N x M” 集成问题，其中 N 代表 LLM 的数量，M 代表外部系统的数量。这意味着对于每一个新的 LLM 或者每一个新的 LLM 需要与之交互的工具，都需要构建定制的连接器。

这导致了以下几个关键问题：

• 定制 API 集成： 最常见的方法是直接将 LLM 与外部 API 集成。这意味着需要为每个 API 编写特定的代码，处理不同的身份验证机制、数据格式（JSON、XML 等）以及每个服务特有的错误处理。这既繁琐又容易出错，且难以扩展。想象一下，为 LLM 需要对话的每个 Web 服务或数据库构建一个单独的“翻译器”——这几乎就是当时的真实情况。

  例如，如果一个公司内部同时使用 GPT-4 和 Claude，并且需要它们分别连接到 Salesforce 和 Jira，那么就需要分别编写四套不同的集成代码。这无疑增加了开发和维护成本。

• 供应商特定的插件框架： 一些 LLM 提供商，如 OpenAI 及其 2023 年的“函数调用” API 和 ChatGPT 插件框架，提供了他们自己的专有方法供 LLM 调用外部函数。虽然这是一个进步，但这些解决方案通常与单个供应商的生态系统绑定，限制了互操作性，并导致供应商锁定。如果想要切换 LLM 提供商或使用多个模型的组合，通常需要从头开始重建集成。

  例如，如果一个企业选择了 OpenAI 的插件框架，那么它可能很难将其他 LLM 模型集成到现有的工作流程中，因为它需要重新开发所有的插件。

• 检索增强生成（RAG）： RAG 系统作为一种强大的技术出现，它为 LLM 提供了访问其训练数据之外的最新和专有信息的能力。这涉及到从知识库（通常是向量数据库）检索相关文档或数据片段，并使用这些检索到的信息增强 LLM 的提示。虽然 RAG 对于知识检索有效，但它主要侧重于读取数据，而不是使 LLM 能够通过外部工具对数据进行操作。

  虽然 RAG 可以让 LLM 回答关于特定行业报告的问题，但它无法让 LLM 基于这些报告的数据自动更新公司的财务报表或发送电子邮件通知相关人员。

• 手动“复制粘贴探戈”： 对于许多用户来说，将 LLM 与他们的工作流程集成仅仅意味着手动将信息从一个应用程序复制到 LLM 的界面，获得响应，然后将该响应复制回另一个应用程序。这种“复制粘贴探戈”突显了对更无缝和自动化交互的迫切需求。

  例如，一个市场营销人员可能会从 CRM 系统中复制客户数据，粘贴到 LLM 中生成营销文案，然后将生成的文案复制回 CRM 系统中。

• 缺乏标准化： 缺乏通用协议意味着每次集成都是一项定制的工程工作。对于 LLM 应该如何与外界通信，没有共享的语言或指导方针，导致代码库碎片化、实现不一致和开发周期缓慢。

  这意味着不同的公司可能采用完全不同的方法来集成 LLM，导致代码库难以维护和复用。

MCP 的核心：工具、资源和提示

MCP 通过提供一个通用的 “AI USB 端口” 来解决这个问题——一种标准化的方式，使 LLM 驱动的应用程序可以连接到几乎任何外部系统。它有意地重复使用了来自语言服务器协议（LSP）的消息流思想，并通过 JSON-RPC 2.0 传输。

MCP 的核心是客户端-服务器架构，使 AI 主机（如 Claude Desktop 或 AI 增强的 IDE）能够连接到 MCP 服务器。每个服务器都公开三个核心原语：

• 工具： 这些是 LLM 可以调用以执行操作的可执行函数，例如发送电子邮件、查询数据库或与 API 交互（例如，send_email、list_unread）。这类似于传统 AI API 中发现的函数调用能力，但在标准化框架内。

  例如，一个 LLM 可以使用 send_email 工具发送电子邮件给客户，或者使用 query_database 工具查询数据库中的客户信息。

• 资源： 只读数据源，为 LLM 提供上下文。这可能包括文件、数据库记录、日志或实时传感器数据，使 LLM 能够访问其训练数据之外的最新和专有信息。

  例如，一个 LLM 可以访问公司的内部知识库作为资源，以便更好地回答员工的问题，或者访问实时传感器数据来监控设备的运行状态。

• 提示： 预定义的模板，用于指导 LLM 使用可用工具和资源完成特定任务。这些模板提供结构化指导，帮助 AI 以一致和高效的方式处理特定任务。

  例如，一个 LLM 可以使用预定义的提示模板来生成产品描述，或者使用预定义的提示模板来总结一篇新闻文章。

通过 MCP 实现多 LLM 协同

当集成多个 LLM 时，MCP 的真正力量变得显而易见。MCP 启用了一种模块化、协作的方法，而不是由单个、单体模型试图处理复杂任务的各个方面：

• 多样化的专业知识： 不同的 LLM 擅长不同的任务。一个 LLM 可能针对创意写作进行了优化，另一个可能针对逻辑推理进行了优化，第三个可能针对代码生成进行了优化。MCP 允许应用程序动态地将请求路由到最适合给定子任务的 LLM。例如，一个 “多 LLM 交叉检查 MCP 服务器” 可以并行查询各种 LLM 提供商（OpenAI、Anthropic、Perplexity AI、Google Gemini），从而可以并排比较响应，以进行事实核查、收集不同的观点或评估模型能力。

  想象一下，一个需要撰写营销文案、生成代码和进行市场调研的任务。通过 MCP，可以分别使用针对创意写作、代码生成和数据分析优化的 LLM，从而获得最佳结果。

• 专业化代理： MCP 促进了专业化 AI 代理的创建。想象一下，一个财务分析师代理利用一个 LLM 进行市场分析，一个工程代理使用另一个 LLM 进行系统诊断，一个客户支持代理利用第三个 LLM 进行富有同情心的响应，所有这些都通过 MCP 进行协调。

  例如，一个客户支持代理可以使用一个 LLM 来理解客户的情绪，使用另一个 LLM 来查询客户的订单信息，并使用第三个 LLM 来生成个性化的回复。

• 编排和工作流程自动化： MCP 充当上下文版本控制的中心注册表，并且可以包括冲突解决机制。这允许构建复杂的 LLM 工作流程，其中多个 LLM 为更大的目标做出贡献。例如，一个旅行计划代理可以使用一个 LLM 来解析用户请求，然后通过 MCP 服务器使用另一个 LLM 查询航班 API，最后使用第三个 LLM 来总结行程。

  例如，一个旅行规划应用可以使用一个 LLM 来解析用户的旅行需求，使用另一个 LLM 来查询机票和酒店信息，并使用第三个 LLM 来生成个性化的行程计划。

• 增强的上下文感知： 通过连接到通过各种 MCP 服务器的多个外部系统，LLM 可以获得对现实世界更丰富、更动态的理解。例如，客户支持聊天机器人可以从一个服务器访问实时产品信息，从另一个服务器访问用户帐户详细信息，从第三个服务器访问公司政策，从而产生高度准确且上下文相关的响应。

  一个客户服务聊天机器人可以连接到公司的 CRM 系统、知识库和产品数据库，以便为客户提供更准确和个性化的支持。

在现实世界中的应用

MCP 和多个 LLM 的结合正在为复杂的 AI 应用铺平道路：

• 开发助手： 想象一下，一个 IDE 与 GitHub 存储库、Jira 问题跟踪器和 CI/CD 管道的 MCP 服务器集成。开发人员可以提出诸如 “分配给我的未解决问题是什么？” 或 “显示我上次构建中的失败测试” 之类的问题，不同的 LLM 处理代码分析、问题跟踪和构建日志。

  开发人员可以使用一个 LLM 来生成代码片段，使用另一个 LLM 来调试代码，并使用第三个 LLM 来审查代码。

• 企业自动化： 通过连接各种企业系统（CRM、ERP、数据库）通过 MCP 服务器，自动化复杂的业务流程变得可行。然后，LLM 可以协调这些系统之间的数据流和操作。

  企业可以使用 LLM 来自动化发票处理、客户服务和供应链管理等流程。

• 高级 RAG 系统： 虽然传统的检索增强生成（RAG）侧重于从单个知识库检索信息，但 MCP 通过允许 LLM 从大量不同的资源（包括专有数据库、实时 Web 数据和内部文档）检索和合成信息来扩展这一点。

  例如，一个医疗诊断系统可以使用 RAG 从医学文献、患者病历和临床试验数据中检索信息，以便为医生提供更准确和全面的诊断建议。

• 动态工具发现： 通过 MCP 连接的 LLM 可以在运行时动态地发现和利用可用的工具，适应新的功能和服务，而无需不断地重新训练或硬编码。

  例如，一个 LLM 可以根据用户的需求动态地发现和使用不同的 API，例如天气 API、地图 API 和新闻 API。

挑战与前进之路

尽管具有巨大的前景，但采用 MCP 和多个 LLM 也有其自身的挑战：

• 安全问题： 通过 MCP 授予 LLM 访问外部系统的权限会引入潜在的漏洞，如提示注入、工具中毒和数据泄露。强大的安全实践，包括仔细的权限管理和输入验证，至关重要。

  需要对 LLM 的输入和输出进行严格的验证，以防止恶意代码或不当信息被执行或泄露。

• 上下文扩展： 在多个活动 MCP 连接中管理 LLM 的上下文窗口可能需要消耗大量资源，从而可能影响性能和推理能力。

  需要优化上下文管理策略，例如使用向量数据库来存储和检索上下文信息，或者使用更有效的上下文压缩算法。

• 身份管理： 清楚地定义谁或什么启动了请求（最终用户、AI 代理或共享系统帐户）对于审计、问责制和访问控制至关重要。

  需要建立明确的身份验证和授权机制，以确保只有经过授权的用户和系统才能访问敏感数据和功能。

• 有状态协议设计： MCP 对有状态服务器发送事件（SSE）的依赖可能会使与固有的无状态 REST API 的集成复杂化，尤其是在远程服务器方面。

  需要探索更灵活的协议设计，例如使用 WebSocket 或 gRPC，以便更好地支持无状态 API 和双向通信。

MCP 与多个 LLM 的未来是光明的。目前正在努力解决当前的局限性，重点是提高安全性、优化上下文管理和增强互操作性。 MCP 与 Agent-to-Agent (A2A) 通信等新兴的代理框架之间的协同作用有望实现更强大和灵活的 AI 系统。随着 MCP 生态系统的不断成熟，它有望成为 AI 应用程序与外部世界交互的标准，从而在各个领域释放新的智能、创造力和自动化水平。

总结来说，模型上下文协议 (MCP) 正在为 多 LLM 协同开启新的篇章，它通过标准化的 工具、资源 和 提示，打破了以往 API 集成的壁垒，让 LLM 能够更加智能、安全地与外部世界交互。虽然仍然面临安全和上下文管理等挑战，但随着技术的不断发展，MCP 有望成为未来 AI 应用的核心基础设施，驱动 AI 领域进入一个全新的发展阶段。