AI应用开发课程

模型上下文协议（MCP）的起源在于解决应用人工智能开发中的一个根本且普遍存在的挑战：外部上下文的集成。虽然像Claude这样的大型语言模型（LLM）拥有从海量训练数据集中学习到的非凡通用知识，但它们的真正力量在于能够与来自外部系统的特定、及时且往往私密的信息进行交互。这包括从搜索企业数据库、调用第三方API，到读取本地文件或抓取实时网页等一切操作。没有这种上下文，大型语言模型就只是一个聪明但孤立的头脑。核心问题一直在于 如何 这种集成的。传统上，开发者们不得不为人工智能应用程序所需的每一个工具和数据源编写自定义的、硬编码的集成。如果一个聊天机器人需要查询Salesforce API和Google Calendar API，开发者就需要编写两段不同的“粘合代码”，每段代码对应一个服务。这些代码将处理每个API特有的身份验证、请求格式化、响应解析和错误处理。

这种传统方法存在几个关键缺陷，这些缺陷共同导致了开发环境的碎片化和低效。首先，它造成了大量的重复劳动。一个团队在构建客户支持机器人，另一个团队在构建内部销售助手，这两个团队可能都需要与Salesforce进行交互。在MCP（多租户云平台）出现之前，这两个团队很可能会分别构建自己的集成方案，浪费宝贵的开发时间。其次，这种方法创建的系统脆弱且维护成本高。如果Salesforce更新了其API，那么每一个具有自定义集成的应用程序都需要被单独找到并进行更新。随着工具和应用程序数量的增加，这种维护负担呈指数级增长。第三，它阻碍了创新和协作。自定义集成与其所服务的应用程序紧密耦合，使得这些集成难以共享、重用或开源。一个为特定项目构建的、用于与ArXiv学术数据库交互的出色工具，却只能被困在该项目的代码库中，无法被更广泛的社区所使用。

MCP的创建旨在打破这些孤岛。它在人工智能应用与其所使用的工具之间引入了一个标准化的通信层，即一种“通用语言”。人工智能应用不再需要直接与十几个用不同语言编写的API进行通信，而是可以通过一种统一的协议——MCP，与所有这些API进行交互。反过来，这些工具被封装在MCP服务器中，MCP服务器将MCP请求转换为在其特定底层系统上的操作。这种从紧密耦合、多对多集成的混乱局面到解耦、标准化的客户端-服务器模型的根本转变，带来了变革性的益处。它促进了 模块化和可重用性; 可以一次性构建一个用于Salesforce的单一MCP服务器，并由公司内任何兼容MCP的应用程序使用。这极大地 减少维护开销如果Salesforce API发生变化，只需更新单一的MCP服务器，所有客户端应用程序将继续无缝运行。最重要的是，它促进了 协作生态系统开发者现在可以构建并共享作为独立、可重用组件的MCP（机器学习平台）服务器。这为建立公共或私有MCP服务器注册表打开了大门，使AI应用程序能够以最小的集成工作量动态发现并与各种工具连接，从而加快AI开发速度，提高可扩展性，并显著减少碎片化。

模型上下文协议（MCP）建立在经典且稳健的客户端-服务器架构之上。选择这种设计模式是出于其简洁性、可扩展性以及清晰的职责分离。它实现了人工智能应用与（其他组件）的解耦 消耗 上下文，来自外部系统的 提供 在那个上下文中，该架构由两个主要组件构成：MCP客户端和MCP服务器，它们通过标准化协议进行通信。

MCP 架构图

graph LR
  subgraph "User's Device"
      User(👤 User)
      App["AI Application"]
      LLM[("LLM Core (e.g., Claude)")]
  end

  subgraph "MCP Server Ecosystem (Local or Remote)"
      Server["MCP Server (e.g., ArXiv Search)"]
  end

  External[("🌐 External API / Service")]
  
  User -- "1. Prompt: 'Find papers on AI'" --> App
  App -- "2. MCP Client receives prompt" --> LLM
  LLM -- "3. LLM decides to use a tool" --> App
  App -- "4. MCP Request 📞" --> Server
  Server -- "5. Executes logic (e.g., calls external API)" --> External
  External -- "6. API Response" --> Server
  Server -- "7. MCP Response 📦" --> App
  App -- "8. Passes result to LLM" --> LLM
  LLM -- "9. LLM processes result and generates answer" --> App
  App -- "10. Final Answer" --> User

  style User fill:#0c172b,stroke:#333,stroke-width:2px
  style App fill:#31b1b5,stroke:#0f0f0f,stroke-width:2px
  style LLM fill:#78401a,stroke:#00bcd4,stroke-width:2px
  style Server fill:#702bba,stroke:#0f0f0f,stroke-width:2px
  style External fill:#0a6141,stroke#0f0f0f,stroke-width:2px

核心组件：

1. MCP 客户端： MCP客户端是一个驻留组件，它 里面 该人工智能应用。它作为大型语言模型（LLM）推理引擎与多客户端处理器（MCP）服务器网络之间的中介。其主要职责包括：

   • 服务器发现与连接： 客户端被配置为包含一个或多个MCP服务器的地址。连接时，它会向每个服务器发送请求以获取其“清单”或功能。该清单详细列出了服务器提供的工具、资源和提示模板，包括它们的名称、描述以及输入/输出模式。
   • 请求制定（或：请求表述）： 当大型语言模型（LLM）决定需要使用外部工具时（这一过程通常被称为“工具使用”或“函数调用”），客户端会根据LLM的意图（例如，“读取文件'report.md'”）构建一个结构化的机器通信协议（MCP）请求。这个请求是一条标准化的消息，可能采用JSON-RPC等格式，指明了要调用的工具（readFile) 及其参数 (path: 'report.md'）。
   • 沟通： 客户端通过网络（或通过子进程在本地）向适当的MCP服务器发送此请求。
   • 响应处理： 客户端等待服务器的响应，解析标准化的MCP响应消息，并提取结果（例如，“report.md”的内容）。然后，将此结果传递回大型语言模型（LLM），LLM利用新信息继续其任务或为用户制定最终答案。 关键是客户端是通用的；它不需要知道 如何 要读取一个文件，只需按照协议向MCP服务器请求执行此操作即可。

2. MCP 服务器： MCP服务器是一个独立进程，为任何MCP客户端提供一系列功能。它可以是本地同一台机器上运行的简单脚本，也可以是部署在云端的健壮网络服务。它的职责与客户端的职责相对应：

   • 展示能力 服务器的核心功能是定义和实现一组工具、资源和/或提示模板。例如，一个 filesystem 服务器将实现诸如……等功能 readFile， writeFile，以及 listFiles。
   • 服务宣言（或：履行宣言使命） 当客户端连接时，服务器会返回其清单文件，宣告其可用的功能。这使得客户端（以及由此推及，大型语言模型LLM）能够了解其能做什么。
   • 监听请求： 服务器监听来自客户端的MCP请求。
   • 执行与逻辑： 收到有效请求后，服务器会调用相应工具的实现。对于一个 readFile 请求时，它会与操作系统的文件系统进行交互。对于一个 search_papers 在ArXiv服务器上请求时，它会向实际的ArXiv API发送HTTP请求。
   • 回应构建： 执行工具后，服务器将结果（或任何发生的错误）打包成一个标准化的MCP响应消息，并发送回客户端。至此，请求-响应周期完成。

他们之间的交流是 协议；规程；方案 它本身定义了用于发现功能、调用工具、获取资源和处理错误的请求和响应消息的确切结构。这种严格的标准化使得整个生态系统能够无缝运行。

为了充分理解MCP（假设为某种技术或方法，此处未给出具体名称，故保留原样）的变革性影响，让我们通过一个实际的、分步骤的例子来说明：构建一个旨在辅助研究人员的聊天机器人。这个聊天机器人的初步目标是让用户能够询问关于ArXiv（一个流行的开放获取学术论文存档网站）上最新学术论文的问题。

第一阶段：预MCP阶段，单一聊天机器人

在传统的开发方法中，我们会直接将这一功能构建到聊天机器人的代码库中。应用程序的逻辑大致如下：

1. 用户输入： 用户输入提示：“帮我找一些关于‘因果推断’的最新论文。”
2. 使用硬编码工具调用大型语言模型（LLM）： 聊天机器人的后端代码将被设计成能够识别搜索论文的意图。它将包含一个特定的Python函数，比如说： search_arxiv_directly(query: str)在它的源代码中定义。大型语言模型（LLM）将被提示以鼓励其“调用”这个特定的、已知的函数。
3. 自定义集成逻辑： 该 search_arxiv_directly 该函数将包含与ArXiv API交互所需的所有必要逻辑。这包括：
   • 根据用户的查询构建正确的HTTP请求URL。
   • 使用像（某个库名，原文未给出具体库名）这样的库来发送HTTP GET请求 requests。
   • 处理潜在的网络错误（超时、连接问题）。
   • 解析来自ArXiv API的XML或JSON响应。
   • 提取每篇论文的相关信息（标题、作者、摘要）。
   • 将这些数据格式化为一个整洁的字符串或数据结构。
4. 将上下文返回给大型语言模型（LLM）： 然后，将格式化后的论文列表传递给大型语言模型（LLM）的后续提示中。
5. 最终回复生成： 大型语言模型（LLM）接收搜索结果，并为用户综合生成自然语言回复，例如：“我找到了三篇关于因果推断的最新论文。第一篇题为《一种新的……方法》，由……撰写。”

这个聊天机器人确实能运行，但它的结构脆弱且不够灵活。如果我们现在想添加一个新功能，即在PubMed上搜索论文，就必须回到聊天机器人的核心代码中，编写一段 新 函数 search_pubmed_directly并重复整个编写自定义集成逻辑的过程。聊天机器人的代码库变得越来越臃肿，并且与其使用的特定工具紧密耦合。

第二阶段：将聊天机器人转变为MCP兼容的应用程序

现在，我们正在对应用程序进行重构，以使用MCP（机器学习平台/中间件通信协议，具体根据上下文确定）。目标是将聊天机器人的核心逻辑与工具的实现相解耦。

1. 创建一个MCP服务器： 首先，我们采用我们（之前的）逻辑 search_arxiv_directly 将其功能提取出来并融入一个完全独立的应用程序中：一个ArXiv MCP服务器。这个服务器的唯一任务就是提供一个工具： search_academic_papers(query: str)我们使用一个类似框架的 FastMCP 为了轻松封装我们现有的逻辑，该逻辑为我们处理所有协议级别的通信。我们运行这个服务器（它可以在本地或远程运行）。
2. 将聊天机器人修改为MCP客户端： 接下来，我们对聊天机器人本身进行修改。我们完全 移除 这个 search_arxiv_directly 功能及其自定义集成代码。取而代之的是，我们添加了一个通用的MCP客户端。
3. 新的工作流程： 现在，用户交互在底层看起来有所不同：
   • 用户输入： “给我找一些关于‘因果推断’的最新论文。”
   • MCP 发现： 在启动时（或动态连接时），我们的聊天机器人的MCP客户端会连接到ArXiv MCP服务器的地址。它向服务器询问其功能，并了解到一个名为 search_academic_papers 存在，它需要一个 query 将字符串作为输入，其描述为“在ArXiv数据库中搜索学术论文”
   • 使用发现的工具调用大型语言模型（LLM）： 聊天机器人现在将这一动态发现的工具信息呈现给大型语言模型（LLM）。LLM的推理引擎看到用户的请求后，判断出 search_academic_papers 这个工具非常合适。它决定使用这个工具并传入参数 query='causal inference'。
   • 客户端-服务器通信： MCP客户端接收此指令，创建一个标准化的MCP请求，并将其发送到ArXiv MCP服务器。
   • 服务器执行： ArXiv MCP服务器接收请求，调用其内部实现（即我们迁移的逻辑），与ArXiv API进行交互，并以标准化的MCP响应格式发送格式化后的结果。
   • 背景与回应： MCP客户端将结果返回给大型语言模型（LLM），然后LLM就像之前一样，为用户生成最终答案。

这里的巧妙之处在于，聊天机器人的代码不再包含任何关于ArXiv的特定知识。它只知道如何使用MCP（模块化聊天协议）进行交流。如果我们现在想要添加PubMed搜索功能，完全不需要改动聊天机器人。我们只需创建一个新的PubMed MCP服务器，并告知聊天机器人的客户端其地址。聊天机器人将自动发现这个新的搜索工具，并将其提供给大型语言模型（LLM）使用，这充分展示了模块化和动态工具集成的强大能力。

创建MCP服务器的过程是将一组功能（无论是与API、数据库还是本地文件系统交互）通过标准化的模型上下文协议暴露给世界。这是MCP生态系统中的一项关键技能，因为服务器是为AI应用程序提供上下文的基本构建模块。本课程模块侧重于构建、测试和运行您自己的服务器的实际步骤，使用诸如（此处省略具体框架名称）等专用框架 FastMCP 以抽象化的方式消除协议本身的底层复杂性。该过程可以分解为一系列清晰、逻辑的步骤。

步骤1：定义能力（即“做什么”） 在编写任何代码之前，第一步是构思你的服务器将要执行的任务。你需要定义具体的 tools， resources，和 prompt templates 它将提供。以我们的ArXiv聊天机器人示例来说，其主要功能是一个工具。我们可以将其定义如下：

• 工具名称： search_academic_papers
• 描述： “一个基于查询字符串搜索ArXiv.org数据库的学术论文工具。返回最近论文的列表，包括论文标题、作者和摘要。”这一描述至关重要，因为它是大型语言模型（LLM）用来理解何时以及如何使用该工具的关键依据。
• 输入模式（或输入架构）： 该工具需要一个参数， query，其类型为 string。
• 输出模式： 该工具将返回一个对象列表，其中每个对象包含 title （字符串）， authors （字符串列表），以及 summary (字符串)。 首先定义这个“接口”是至关重要的设计步骤。它迫使你清晰地思考服务器的用途以及客户端将如何使用它。

步骤2：实现核心逻辑（“如何做”） 这是你编写实际执行工作代码的地方。这是我们之前嵌入在单体聊天机器人中的逻辑。例如，你会编写一个Python函数， def execute_arxiv_search(query: str) -> list:在这个函数内部，你会放置所有负责以下任务的代码：

1. 对输入进行消毒处理（或净化处理） query.
2. 为ArXiv API构建适当的URL。
3. 使用一个HTTP客户端库（requests， httpx) 以进行API调用。
4. 实现强大的错误处理机制（例如，如果ArXiv服务宕机怎么办？如果查询返回无结果又该如何处理？）。
5. 解析来自API的复杂响应（该响应可能是XML或其他格式）。
6. 将解析后的数据转换为您在第一步中定义的干净、简单的输出结构。 这个核心逻辑是纯粹的功能性代码；在现阶段，它还不了解MCP（管理控制协议/模块等，具体含义需根据上下文确定）。它是一段自包含、可测试的代码。

步骤3：使用MCP框架封装逻辑（即“服务器化”） 这就是一个像（某种框架）这样的东西所起的作用 FastMCP 开始发挥作用。你无需手动实现一个网络服务器、解析原始的MCP请求以及格式化MCP响应（这些工作既繁琐又容易出错），而是可以利用框架来完成这些繁重的工作。这个过程通常如下所示：

1. 实例化服务器： 您创建了一个该类的实例 FastMCPServer。
2. 注册工具： 你将你的核心逻辑函数“注册”到服务器实例中。这包括向框架介绍你的工具——包括它的名称、描述、模式（或架构），以及当工具被调用时应执行哪个函数。框架可能会使用装饰器或注册函数，例如 server.add_tool(name="search_academic_papers", description=..., func=execute_arxiv_search)。
3. 运行服务器： 你只需用一条命令即可启动服务器，比如 server.run(host="0.0.0.0", port=8000)。 这个 FastMCP 框架会自动处理其余部分。它将启动一个Web服务器，创建一个监听MCP请求的端点，提供清单文件（基于您注册的工具），解析传入的工具调用请求，并调用您的 execute_arxiv_search 使用正确的参数调用函数，获取返回值，并将其封装在一个有效的MCP响应中发送回客户端。

步骤4：测试服务器（“验证”） 一旦您的服务器运行起来，您需要验证它是否运行正常。这就是使用像（某种工具，此处原文未指明具体工具名称）这样的工具的用处 MCP 检查员 变得极为宝贵。MCP Inspector 是一款专为调试设计的 MCP 客户端。你可以将 Inspector 指向你的服务器地址（例如。， http://localhost:8000）。 它将首先尝试获取服务器的清单，以便您查看您的工具是否正确地进行了广告宣传。然后，您可以使用检查器的用户界面手动调用您的 search_academic_papers 工具，提供测试查询。您可以检查发送的原始MCP请求，以及最重要的是，检查返回的原始MCP响应，确保您的服务器在连接到实际AI应用之前完全符合协议要求。这种构建、运行和测试的迭代循环是开发可靠MCP服务器的关键。

如果MCP服务器是上下文的提供者，那么MCP客户端就是消费者。创建MCP客户端需要将一个专用组件集成到您的AI应用程序中（如我们的研究人员聊天机器人），以便它能够与任何符合MCP标准的服务器进行通信。这种架构的美妙之处在于，您编写的客户端代码是通用的。它不需要了解任何特定工具的具体细节，比如如何搜索ArXiv或如何读取文件。它只需要理解如何与MCP服务器进行交互即可 语言 关于MCP（管理控制平台）——如何发现功能、如何请求工具执行以及如何解析响应。本课程的这一模块重点在于构建客户端逻辑，这将有效地使您的应用程序成为通往整个MCP生态系统的大门。

MCP客户端的职责可以划分为一个明确的生命周期：

1. 初始化与配置： 第一步是在您的应用程序中初始化客户端。这通常涉及从MCP库中创建一个客户端类的实例。所需的主要配置是一个服务器地址列表。这个列表告诉客户端在哪里查找工具和资源。

# Pseudocode for client initialization
mcp_server_urls = [
    "http://localhost:8000",  # Our local ArXiv server
    "[http://mcp.anthropic.com/filesystem](http://mcp.anthropic.com/filesystem)", # A public reference server
]
mcp_client = MCPClient(servers=mcp_server_urls)

这种配置可以是静态的，从文件中加载，甚至可以动态发现，但核心思想是为客户端提供进入MCP网络的入口点。

2. 能力发现与清单聚合： 一旦初始化完成，客户端的首要操作是连接到每个已配置的服务器并请求其清单。清单是一个JSON对象，详细列出了该服务器提供的所有工具、资源和提示。客户端的任务是：

• 遍历每个服务器URL。
• 向每个（例如，一个）发送标准化的MCP请求 GET /mcp 请求或特定的RPC调用，如 mcp_getServerInfo）。
• 接收并解析来自每个服务器的清单文件。
• 将所有这些功能汇总到一个统一的列表中。这个汇总列表代表了 总计；总和 人工智能应用程序可用的一套外部工具。 这一发现过程至关重要，因为它使系统具有了动态性。当你在配置列表中添加一台新服务器时，其工具会自动出现在这个汇总列表中，而无需进行任何其他代码更改。客户端为大型语言模型（LLM）创建了一个包含所有可用操作的综合“菜单”。

3. 向大型语言模型（LLM）提供工具： 大型语言模型（LLM）无法使用其未知的工具。客户端的下一个关键角色是将聚合的工具列表格式化为LLM能够理解的结构。这通常是通过将工具描述注入到系统提示中来完成的。对于发现的每个工具，客户端将格式化一个描述块，包括其名称、用自然语言描述的功能以及输入参数。例如：

<tools>
  <tool>
    <name>search_academic_papers</name>
    <description>Searches the ArXiv.org database for academic papers...</description>
    <parameters>
      <param name="query" type="string" />
    </parameters>
  </tool>
  <tool>
    <name>readFile</name>
    <description>Reads the content of a file from the local filesystem...</description>
    <parameters>
      <param name="path" type="string" />
    </parameters>
  </tool>
</tools>

当用户与聊天机器人互动时，这个XML块（或类似格式）会被包含在提示中，有效地告诉大型语言模型（LLM）：“这是你可利用的外部功能。”

4. 处理来自大型语言模型（LLM）的工具使用请求： 像Claude这样的现代大型语言模型（LLM）可以被提示来指示何时想要使用工具。当LLM决定调用工具时，其响应将包含一个特殊结构，指示要使用哪个工具以及使用哪些参数。例如，LLM的输出可能包含：

<invoke_tool>
  <name>search_academic_papers</name>
  <parameters>
    <query>causal inference</query>
  </parameters>
</invoke_tool>

监控大型语言模型（LLM）输出的应用程序代码将检测到这种结构，然后将其信息传递给MCP客户端。

5. 通过MCP执行工具调用： 这是核心的通信步骤。MCP客户端从应用程序接收工具调用请求，然后：

1. 确定哪台服务器提供了所需的工具search_academic_papers）。 它在发现阶段就知道这一点。
2. 构建一个正式的MCP工具调用请求消息（例如，一个JSON-RPC对象）。
3. 将此请求发送到正确的服务器URL。
4. 等待服务器的响应。
5. 解析MCP响应以提取工具执行的结果。
6. 将此结果返回给主应用程序逻辑。然后，应用程序将此结果反馈给大型语言模型（LLM）以进行最后一步，完成整个循环。这个发现、呈现、调用和执行的循环是MCP客户端正常运行的核心。

这个模块充分展现了模型上下文协议（Model Context Protocol, MCP）的强大功能与优雅之处。在成功构建了一个自定义的MCP服务器（用于ArXiv搜索）并将其与我们的聊天机器人集成后，我们现在可以展示该协议的主要优势：轻松扩展性。将我们的聊天机器人连接到新的、已存在的服务器时，无需对聊天机器人的核心逻辑或其自定义的ArXiv服务器进行任何更改。唯一需要做的就是更新MCP客户端配置中的服务器URL列表。这展示了MCP所带来的显著的解耦和互操作性。本课程使用由Anthropic的MCP团队构建的参考服务器来阐述这一概念，其中两个突出的例子是 filesystem 服务器和 fetch 服务器。

1. 文件系统服务器

该 filesystem 服务器是一个MCP服务器，旨在将基本文件系统操作作为工具提供。当我们的聊天机器人MCP客户端配置了此服务器的地址后，它将在初始化阶段自动发现一组新的工具。这些工具可能包括：

• readFile(path: string)读取指定路径下文件的全部内容。
• writeFile(path: string, content: string)使用提供的内容写入或覆盖文件。
• listFiles(path: string)列出给定路径下的所有文件和目录。
• createDirectory(path: string)创建一个新目录。

对聊天机器人的影响： 突然间，我们之前只能在网页上搜索学术论文的研究员聊天机器人，如今增添了一种全新的互动维度。大型语言模型（LLM）通过系统提示了解了这些新发现的工具后，现在能够满足更广泛的用户需求。用户现在可以进行如下对话：

• 用户： “帮我找一些关于‘Transformer架构’的论文，并将结果保存到一个名为 transformers_reading_list.md。”
• 聊天机器人的内部处理流程：
  1. LLM看到请求后，决定首先使用 search_academic_papers 工具。
  2. MCP客户端调用我们的ArXiv服务器，获取结果。
  3. 结果被反馈给大型语言模型（LLM）。现在，LLM看到了请求的第二部分。
  4. LLM将论文列表格式化为Markdown格式，并决定使用 writeFile 工具。
  5. MCP客户端调用 filesystem 带有服务器的 path='transformers_reading_list.md' 以及格式化后的内容。
  6. 该文件已创建在本地磁盘上。
  7. 大型语言模型（LLM）向用户确认：“我已经找到了这些论文，并将列表保存到了 transformers_reading_list.md。"

在聊天机器人中，我们没有编写任何一行新的集成代码，就成功地无缝扩展了其功能。

2. 获取服务器

这个（或“该”） fetch 服务器是另一种强大的参考工具。其目的是从网络上检索内容。它可能提供一个单一且多功能的工具：

• fetch(url: string)它接收一个URL，获取网页内容，并智能地提取主要文本部分，通常将其转换为干净的Markdown格式，并去除广告、导航栏和其他模板内容。

对聊天机器人的影响： 只需简单地添加 fetch 将服务器地址添加到我们客户端的配置中后，我们的聊天机器人的能力再次得到了扩展。现在，它不仅可以作为研究助手来查找论文，还能阅读并总结网页文章。

• 用户： “这是关于一个新AI模型的博客文章的链接： [some-url]你能总结一下它的要点，然后找找相关的学术论文吗？"
• 聊天机器人的内部处理流程：
  1. 大型语言模型（LLM）看到了URL并决定使用它 fetch 工具。
  2. MCP客户端调用 fetch 带有URL的服务器。
  3. 服务器抓取页面，并返回文章的纯净Markdown格式内容。
  4. 大型语言模型（LLM）接收内容并为用户生成摘要。
  5. 然后，它从摘要中识别出关键词，并决定使用这些关键词 search_academic_papers 工具。
  6. MCP客户端调用了我们的ArXiv服务器。
  7. 大型语言模型（LLM）综合生成最终回复，既呈现了博客文章的摘要，也列出了一系列相关论文。

这个模块有力地证明了，与MCP（多协议客户端/服务器通信协议）兼容的应用程序的价值会随着生态系统的发展而增长。通过构建一个单一、通用的MCP客户端，我们的聊天机器人具备了未来适应性，能够轻松连接并利用当前及未来任何数量的MCP服务器，用于数据库、日历、代码执行等多种功能，且几乎无需或只需极少的额外开发工作。

虽然动态工具使用可以说是MCP（假设为某系统或协议的缩写）最显著的特点，但该协议的功能远不止于简单的函数调用。MCP为服务器提供了一种标准化的方式来提供另外两种至关重要的上下文类型： 提示模板 并且 资源本模块深入探讨了这些特性，展示了它们如何使大型语言模型（LLM）与外部系统之间实现更复杂、更易维护且富含上下文的交互。通过利用提示和资源，开发者可以集中并重用专业知识，将其从单个应用程序中的硬编码方式转变为可通过MCP服务器进行发现和共享的方式。

1. 提示模板

提示工程是获取大型语言模型（LLM）最佳性能的关键学科。为特定任务（如总结法律文件与总结随意的博客文章）设计完美的提示可能非常复杂，且需要深厚的专业知识。在大型组织中，多个不同的AI应用可能需要执行相同的总结任务。如果没有机器学习编排平台（MCP，此处根据上下文假设MCP为某类编排或管理平台的缩写，实际翻译可能需根据具体背景调整），每个开发团队都可能会在其应用代码中创建并嵌入自己版本的总结提示。这会导致不一致性、重复劳动，以及在集中更新和改进这些提示时遇到困难。

MCP的提示模板功能解决了这一问题。可以设计一个MCP服务器来提供预定义的、由专家精心设计的提示模板。

• 工作原理： 例如，我们的ArXiv服务器可以得到增强，以提供一个名为（此处可添加具体名称）的快速模板 academic_summary_prompt这不会是 工具 不是要执行的代码，而是一个客户端可以请求的字符串模板。
• 服务器端： 服务器的清单文件将宣传这个提示模板。服务器存储模板文本，其内容可能如下所示：“您是一位资深的学术研究者。基于以下论文摘要： {abstract}请提供一个简洁的段落总结，重点阐述研究方法和主要发现。尽可能避免使用专业术语。“
• 客户端： MCP客户端发现了这个可用的提示。然后，可以设计AI应用程序的逻辑，通过名称请求这个模板。客户端发送一个 getPromptTemplate 向服务器发出请求，服务器返回模板字符串。然后应用程序可以填充 {abstract} 用论文中的实际摘要替换占位符，然后将完成后的提示发送给大型语言模型（LLM）。

好处：

• 集中化与一致性： 所有需要总结学术论文的应用程序都可以使用完全相同、经过专家认可的提示，从而确保输出质量的一致性。
• 轻松更新： 如果提示工程师发现一种更好的方式来表述摘要提示，他们只需在一个地方进行更新：即MCP服务器。所有客户端应用程序将在下次请求时自动开始使用改进后的提示，无需进行任何代码更改或重新部署。
• 专业知识封装： 一位非程序员领域的主题专家（例如律师）可以通过设计高质量的提示语，并通过MCP服务器提供这些提示语，从而为人工智能系统做出贡献。

2. 资源

资源是为大型语言模型（LLM）提供静态或半静态上下文的另一个强大功能。资源本质上是服务器暴露出来以供检索的、具有名称的文本或数据块。这对于那些不需要像工具一样执行，但对LLM准确执行任务至关重要的信息来说，是非常理想的。

• 工作原理： 想象一下，我们有一个内部公司的MCP服务器。这个服务器可以提供多种资源：
  • company_faq.txt一个包含公司常见问题解答的文本文件。
  • style_guide.md一份概述公司官方沟通风格的Markdown文档。
  • api_documentation.json一个包含内部API架构的JSON文件。
• 服务器端： 服务器的清单文件按名称列出了这些可用资源。服务器本身只是存储这些文件或数据块，随时准备在收到请求时提供服务。
• 客户端： 一个AI应用程序，比如内部支持机器人，可以被提示来回答用户的问题。如果大型语言模型（LLM）判断需要更多信息，它可以请求相关资源。例如，如果用户问：“我们关于远程工作的政策是什么？”大型语言模型可以决定检索 company_faq.txt 资源。MCP客户端发送一个 getResource 向服务器发出请求，服务器返回常见问题解答（FAQ）的全文。然后，将这段文本输入到大型语言模型（LLM）的上下文窗口中，使其能够基于官方公司文件生成准确且最新的答案。

好处：

• 将大型语言模型（LLMs）建立在事实数据的基础之上： 资源是大型语言模型（LLM）“扎根”的主要机制，通过为其提供具体、权威的文档作为回答依据，从而降低产生幻觉的风险。
• 数据与逻辑的分离： 数据（常见问题解答）在服务器上进行管理，与人工智能应用程序的代码完全分离。内容可以轻松更新，而无需改动应用程序。
• 高效上下文提供： 当需要时，让大型语言模型（LLM）动态地调用特定资源，比试图将其所有可能的信息都塞进初始上下文窗口要高效得多。

虽然课程的很大一部分内容侧重于在您的应用程序中从头开始构建MCP客户端，但本模块将探讨一种强大的替代方案：利用预构建的、复杂的MCP客户端。 Claude Desktop（中文可译为“Claude桌面版”或根据具体语境简化为“Claude桌面”） 它作为此类应用的一个典型范例。这是一款功能丰富的独立AI助手，已经完全兼容MCP（可能是指某种通信协议或平台）。这意味着，你无需编写自己的客户端代码来管理服务器连接、发现工具和处理通信，而是可以直接将你自定义构建的MCP服务器“插入”到一个现成的专业级应用程序中。这种方法极大地降低了使用你自定义工具的门槛，并展示了MCP生态系统的力量，在这个生态系统中，一个单一的工具服务器可以被众多不同的客户端应用程序所使用。

这里的核心概念是工具提供者（您的MCP服务器）与工具消费者（AI应用程序）的分离。通过遵循MCP标准，您的ArXiv服务器不会关心是被我们之前构建的简单聊天机器人调用，还是被像Claude Desktop这样复杂的应用程序调用。它对两者都使用相同的语言进行通信。本模块将向您介绍实现这种连接的实际步骤。

配置过程： 配置Claude Desktop以使用您服务器的过程设计得非常直观，通常只需通过设置文件或图形用户界面即可完成。

1. 定位配置文件： 首先，你需要在本地机器上找到Claude Desktop的配置文件。这个文件通常是一个位于标准应用程序数据目录中的JSON或YAML文件。
2. 添加服务器端点： 在这个配置文件中，会有一个特定的部分用于定义MCP服务器。您只需添加您希望Claude Desktop连接的服务器的网络地址。例如，您可以添加您本地构建并部署的ArXiv服务器的URLhttp://127.0.0.1:8000) 并且可能还有参考文献的公开URL filesystem 和 fetch 服务器。

// Example snippet from a hypothetical Claude Desktop config file
"mcp_servers": [
  {
    "url": "[http://127.0.0.1:8000](http://127.0.0.1:8000)",
    "name": "Local ArXiv Search",
    "enabled": true
  },
  {
    "url": "[https://mcp.anthropic.com/filesystem](https://mcp.anthropic.com/filesystem)",
    "name": "Anthropic Filesystem Server",
    "enabled": true
  }
]

3. 重启与验证： 保存配置更改后，您将重启Claude Desktop。启动时，Claude Desktop内置的MCP客户端将执行我们之前了解的发现过程。它将连接到 http://127.0.0.1:8000获取清单文件，并了解您的 search_academic_papers 工具。

用户体验： 从现在开始，当你与Claude Desktop交互时，它将完全了解你自定义的工具。你现在可以直接在Claude Desktop界面中输入：“帮我找一下Yoshua Bengio的最新论文。”Claude Desktop强大的大型语言模型（LLM）后端会看到这个提示，并识别出需要 search_academic_papers 工具（它从您的本地服务器发现该工具）是合适的工具，您应使用该工具并执行它。请求将从Claude Desktop发送到您本地运行的服务器，服务器将执行搜索并返回结果。然后，Claude Desktop将在其原生界面中向您展示这些结果。

为何这很重要： 这项能力之所以具有变革性，原因有以下几点：

• 快速原型制作与测试： 您可以使用功能强大且稳定的客户端，无需编写任何客户端代码，即可快速测试您的新MCP服务器。这样，您可以专注于完善服务器的逻辑。
• 赋能非开发者： 数据科学家可以创建一个MCP服务器，将复杂的统计模型作为工具暴露出来。然后，他们可以将其添加到自己的Claude Desktop配置中，并开始使用自然语言与模型进行交互，而无需围绕它构建一个完整的应用程序。
• 展示生态系统： 它提供了MCP（多云协议？）承诺的切实证明。您构建了一个组件（服务器），该组件可以被由不同组织（Anthropic）构建的完全独立的应用程序立即使用。这凸显了该协议旨在实现的互操作性和模块化。它抽象了客户端实现的所有底层逻辑，使用户能够专注于真正重要的事情：扩展其AI工具的功能。

到目前为止，在本课程中，我们搭建的MCP服务器很可能是在我们开发机器上本地运行的（例如，在 http://localhost:8000）。 这非常适合使用像Claude Desktop这样的应用程序进行开发、测试和个人使用。然而，MCP生态系统的真正潜力在于这些服务器能够通过互联网访问。团队成员、其他应用程序甚至公众都可以使用远程服务器，从而将个人工具转变为共享、可重用的服务。本模块将涵盖必要的软件工程实践，帮助您将本地测试的MCP服务器部署到云端，使其成为更大网络中一个强大且易于访问的部分。

第一步：打包应用程序（容器化） 准备部署的第一步是以一致且可重复的方式打包您的服务器应用程序。行业标准的方法是使用容器化技术，最常见的是使用 **Docker（注：Docker是一个用于开发、部署和运行应用程序的开源平台，它允许开发者将应用程序及其依赖打包到一个可移植的容器中，从而确保应用程序在任何环境中都能一致地运行。）**一个Dockerfile是一个脚本，用于定义一个完整且自包含的环境，以供您的应用程序使用。对于我们ArXiv MCP服务器，Dockerfile将指定：

• 一个基础操作系统镜像（例如，Python的轻量级版本）。
• 将我们的服务器源代码复制到容器中的命令。
• 安装所有必要依赖项的命令（例如。， pip install -r requirements.txt 这将包括 fastmcp， requests等）。
• 容器启动时要执行的命令（例如。， python server.py）。 通过根据这个文件构建一个Docker镜像，我们创建了一个便携式的软件包，它可以在任何安装了Docker的机器上以完全相同的方式运行，无论是开发者的笔记本电脑还是强大的云服务器。这解决了“在我的机器上运行正常”的问题，并且是实现可靠部署的关键一步。

步骤2：选择部署目标（云服务提供商） 一旦你有了Docker镜像，就需要一个地方来运行它。市面上有众多云提供商和服务都适合托管容器化应用。选择往往取决于成本、可扩展性和易用性等因素。一些流行的选择包括：

• 基础设施即服务（IaaS）： 像Amazon EC2或Google Compute Engine这样的服务为你提供一台虚拟机。你可以在虚拟机上安装Docker并手动运行你的容器。这种方式提供了最大的控制权，但需要更多的设置工作。
• 容器即服务（CaaS）： 像AWS Fargate、Google Cloud Run或DigitalOcean App Platform这样的平台是专门设计来运行容器的。你只需提供你的Docker镜像，平台就会为你处理底层服务器、扩展和网络连接。对于部署像MCP服务器这样的单服务应用，这通常是最快捷且最高效的选择。
• 平台即服务（PaaS）： 像Heroku或Vercel这样的服务有时可以直接从源代码部署Python应用程序，并自动为你处理容器化，提供更加简便的部署体验。

第三步：部署过程 具体的部署流程因供应商而异，但通常遵循以下工作流程：

1. 将镜像推送到注册表： 你将本地构建的Docker镜像推送到容器注册表，如Docker Hub、Amazon ECR或Google Artifact Registry。这样，云服务提供商就可以访问该镜像。
2. 配置服务： 您配置所选的云服务（例如，Google Cloud Run）。您需要指定要使用的容器镜像、分配的CPU和内存数量，并且重要的是，您需要配置网络设置，以将容器的端口（例如，8000端口）通过标准的HTTP/S端口（80/443）暴露给公共互联网。
3. 设置环境变量： 如果您的服务器需要任何密钥或配置（如ArXiv API的API密钥），您应在云服务中将这些配置为安全的环境变量，而不是在Docker镜像中硬编码。
4. 部署： 你点击“部署”按钮。云平台会从注册表中拉取你的镜像并启动你的容器。它会为你提供一个公共URL（例如。， https://my-arxiv-server-xyz.a.run.app）。

步骤4：测试与验证 您的服务器现已在互联网上运行。最后一步是进行测试。您将使用 MCP 检查器 再次（尝试），但这次，不是指向（某处），而是 localhost你会将其指向你的新公共URL。你可以验证清单文件是否正确提供，并且工具调用在公共互联网上是否按预期工作。你也可以更新你的聊天机器人客户端配置或Claude桌面设置，以使用这个新的远程URL。现在，你的工具已成为一个全球可访问的服务，随时准备集成到世界上任何地方的MCP兼容应用程序中。这个模块填补了从个人开发项目到生产就绪、可共享的AI能力之间的鸿沟。