《Agentic Design Patterns：构建智能系统的实战指南》- 第十章模型上下文协议

书籍名称：Agentic Design Patterns: A Hands-On Guide to Building Intelligent Systems
本书作者：Antonio Gulli
链接地址：https://docs.google.com/document/d/18vvNESEwHnVUREzIipuaDNCnNAREGqEfy9MQYC9wb4o
内容摘要：本文是对《智能体设计模式》第十章的翻译。此章节介绍了模型上下文协议（MCP协议）。
翻译：煤矿工厂

MCP 模式概述

为使大语言模型 (LLM) 能够作为智能体有效运作，其能力必须超越多模态生成。与外部环境的互动是必需的，包括访问最新数据、利用外部软件以及执行特定的操作任务。模型上下文协议 (MCP) 通过提供一个标准化接口，使 LLM 能够与外部资源对接，从而满足了这一需求。该协议是促进一致且可预测集成的一个关键机制。

想象一个通用适配器，它允许任何 LLM 插入任何外部系统、数据库或工具，而无需为每一个都进行定制集成。这基本上就是模型上下文协议 (MCP) 的作用。它是一个开放标准，旨在标准化像 Gemini、OpenAI 的 GPT 模型、Mixtral 和 Claude 这样的 LLM 与外部应用程序、数据源和工具的通信方式。你可以把它看作一个通用的连接机制，简化了 LLM 获取上下文、执行操作以及与各种系统互动的方式。

MCP 采用客户端-服务器架构。它定义了不同的元素——数据（称为资源）、交互式模板（本质上是提示）以及可操作的函数（称为工具）——如何由 MCP 服务器暴露出来。然后，这些元素由 MCP 客户端消费，客户端可以是一个 LLM 主机应用程序或一个 AI 智能体本身。这种标准化的方法极大地降低了将 LLM 集成到不同操作环境中的复杂性。

然而，MCP 是一份关于 “智能体接口 (agentic interface)” 的契约，其有效性在很大程度上取决于其所暴露的底层 API 的设计。存在一种风险，即开发者可能只是简单地包装预先存在的、未经修改的旧版 API，这对于智能体来说可能并非最优。例如，如果一个票务系统的 API 只允许一次一个地检索完整的票据详情，那么一个被要求总结高优先级票据的智能体，在处理大量票据时会变得缓慢且不准确。要真正有效，底层 API应该通过确定性的功能（如过滤和排序）得到改进，以帮助非确定性的智能体高效工作。这凸显了智能体并不能神奇地取代确定性工作流；它们通常需要更强的确定性支持才能成功。

此外，MCP 可能会包装一个其输入或输出本身对智能体来说仍然不易理解的 API。一个 API 只有在其数据格式对智能体友好时才有用，而 MCP 本身并不强制执行这一保证。例如，为一个返回 PDF 文件的文档存储创建一个 MCP 服务器，如果消费该服务的智能体无法解析 PDF 内容，那基本上是无用的。更好的方法是首先创建一个返回文本文档（如 Markdown）的 API，这样智能体才能真正地读取和处理。这表明开发者不仅要考虑连接本身，还要考虑交换数据的性质，以确保真正的兼容性。

MCP 与工具函数调用

模型上下文协议 (MCP) 和工具函数调用是两种不同的机制，它们使 LLM 能够与外部能力（包括工具）互动并执行操作。虽然两者都旨在将 LLM 的能力扩展到文本生成之外，但它们在方法和抽象级别上有所不同。

工具函数调用可以被看作是 LLM 对一个特定的、预定义的工具或函数的直接请求。请注意，在此上下文中，我们交替使用“工具”和“函数”这两个词。这种互动的特点是一对一的通信模型，其中 LLM 根据其对需要外部操作的用户意图的理解来格式化请求。然后，应用程序代码执行此请求并将结果返回给 LLM。这个过程通常是专有的，并且在不同的 LLM 提供商之间有所不同。

相比之下，模型上下文协议 (MCP) 作为一个标准化接口运作，供 LLM 发现、通信和利用外部能力。它作为一个开放协议，促进了与广泛工具和系统的互动，旨在建立一个生态系统，其中任何兼容的工具都可以被任何兼容的 LLM 访问。这促进了不同系统和实现之间的互操作性、可组合性和可重用性。通过采用联合模型，我们显著提高了互操作性，并释放了现有资产的价值。该策略使我们能够通过简单地将分散的和遗留的服务包装在一个符合 MCP 的接口中，将它们带入一个现代化的生态系统。这些服务继续独立运作，但现在可以被组合成新的应用程序和工作流，其协作由 LLM 协调。这在不需要对基础系统进行昂贵的重写的情况下，促进了敏捷性和可重用性。

以下是 MCP 和工具函数调用之间基本区别的细分：

特性	工具函数调用	模型上下文协议 (MCP)
标准化	专有且特定于供应商。格式和实现在不同LLM提供商之间有所不同。	一个开放、标准化的协议，促进不同LLM和工具之间的互操作性。
范围	LLM请求执行特定、预定义函数的直接机制。	一个更广泛的框架，用于 LLM和外部工具如何发现并相互通信。
架构	LLM与应用程序的工具处理逻辑之间的一对一互动。	一个客户端-服务器架构，其中由LLM驱动的应用程序（客户端）可以连接并利用各种MCP服务器（工具）。
发现	LLM在特定对话的上下文中被明确告知哪些工具可用。	实现可用工具的动态发现。MCP客户端可以查询服务器以查看其提供的能力。
可重用性	工具集成通常与正在使用的特定应用程序和LLM紧密耦合。	促进可重用的、独立的“MCP服务器”的开发，任何兼容的应用程序都可以访问这些服务器。

可以把工具函数调用想象成给一个 AI 一套特定的定制工具，比如一把特定的扳手和一把螺丝刀。这对于一个拥有固定工具集的车间来说是高效的。而 MCP（模型上下文协议）则像是创建一个通用的、标准化的电源插座系统。它本身不提供工具，但允许任何来自任何制造商的兼容工具插入并工作，从而实现一个动态且不断扩展的车间。

简而言之，函数调用提供了对少数特定函数的直接访问，而 MCP 是一个标准化的通信框架，让 LLM 能够发现和使用广泛的外部资源。对于简单的应用程序，特定的工具就足够了；对于需要适应的复杂、互联的 AI 系统，像 MCP 这样的通用标准是必不可少的。

MCP 的额外考量

虽然 MCP 提供了一个强大的框架，但全面的评估需要考虑几个影响其在特定用例中适用性的关键方面。让我们更详细地看看这些方面：

工具 vs. 资源 vs. 提示：理解这些组件的具体角色非常重要。资源是静态数据（例如，一个 PDF 文件，一条数据库记录）。工具是执行一个动作的可执行函数（例如，发送一封邮件，查询一个 API）。提示是一个模板，指导 LLM 如何与资源或工具互动，确保互动是结构化且有效的。
可发现性：MCP 的一个关键优势是 MCP 客户端可以动态地查询服务器以了解其提供的工具和资源。这种“即时”发现机制对于需要适应新能力而无需重新部署的智能体来说非常强大。
安全性：通过任何协议暴露工具和数据都需要强大的安全措施。MCP 的实现必须包括身份验证和授权，以控制哪些客户端可以访问哪些服务器以及它们被允许执行哪些具体操作。
实现：虽然 MCP 是一个开放标准，但其实现可能很复杂。然而，提供商们正开始简化这个过程。例如，像 Anthropic 或 FastMCP 这样的一些模型提供商提供了 SDK，这些 SDK 抽象了大部分的样板代码，使开发者更容易创建和连接 MCP 客户端和服务器。
错误处理：一个全面的错误处理策略至关重要。协议必须定义错误（例如，工具执行失败、服务器不可用、无效请求）如何被传回给 LLM，以便它能理解失败并可能尝试替代方法。
本地服务器 vs. 远程服务器：MCP 服务器可以部署在与智能体相同的机器上（本地），也可以部署在不同的服务器上（远程）。对于处理敏感数据，可能会选择本地服务器以提高速度和安全性，而远程服务器架构则允许在整个组织内共享、可扩展地访问通用工具。
按需 vs. 批量：MCP 可以支持按需、交互式会话和更大规模的批量处理。选择取决于应用程序，从需要即时工具访问的实时对话智能体到批量处理记录的数据分析管道。
传输机制：该协议还定义了用于通信的底层传输层。对于本地交互，它使用基于 STDIO（标准输入/输出）的 JSON-RPC 进行高效的进程间通信。对于远程连接，它利用了像可流式 HTTP 和服务器发送事件 (SSE) 这样的网络友好协议，以实现持久且高效的客户端-服务器通信。

模型上下文协议使用客户端-服务器模型来标准化信息流。理解组件间的交互是 MCP 高级智能体行为的关键：

大语言模型 (LLM) ：核心智能。它处理用户请求，制定计划，并决定何时需要访问外部信息或执行操作。
MCP 客户端：这是一个围绕 LLM 的应用程序或包装器。它充当中间人，将 LLM 的意图转换为符合 MCP 标准的正式请求。它负责发现、连接并与 MCP 服务器通信。
MCP 服务器：这是通往外部世界的大门。它向任何授权的 MCP 客户端暴露一组工具、资源和提示。每个服务器通常负责一个特定的领域，例如连接到公司的内部数据库、一个邮件服务或一个公共 API。
可选的第三方 (3P) 服务：这代表了 MCP 服务器管理和暴露的实际外部工具、应用程序或数据源。它是执行所请求操作的最终端点，例如查询一个专有数据库、与一个 SaaS 平台互动或调用一个公共天气 API。

交互流程如下：

发现：MCP 客户端代表 LLM 查询一个 MCP 服务器，询问其提供的能力。服务器以一个清单 (manifest) 作为响应，列出其可用的工具（例如，send_email）、资源（例如，customer_database）和提示。
请求制定：LLM 确定需要使用一个已发现的工具。例如，它决定发送一封邮件。它制定一个请求，指定要使用的工具 (send_email) 和必要的参数（收件人、主题、正文）。
客户端通信：MCP 客户端接收 LLM 制定的请求，并将其作为标准化的调用发送到相应的 MCP 服务器。
服务器执行：MCP 服务器接收到请求。它对客户端进行身份验证，验证请求，然后通过与底层软件接口来执行指定的操作（例如，调用一个邮件 API 的 send() 函数）。
响应和上下文更新：执行后，MCP 服务器将一个标准化的响应发送回 MCP 客户端。该响应指示操作是否成功，并包含任何相关的输出（例如，已发送邮件的确认 ID）。客户端随后将此结果传递回 LLM，更新其上下文，并使其能够继续执行任务的下一步。

实际应用与用例

MCP 显著扩展了 AI/LLM 的能力，使其更加通用和强大。以下是九个关键用例：

数据库集成：MCP 允许 LLM 和智能体无缝地访问和与数据库中的结构化数据互动。例如，使用 MCP Toolbox for Databases，一个智能体可以查询 Google BigQuery 数据集以检索实时信息、生成报告或更新记录，所有这些都由自然语言命令驱动。
生成式媒体编排：MCP 使智能体能够与先进的生成式媒体服务集成。通过 MCP Tools for Genmedia Services，一个智能体可以编排涉及 Google 的 Imagen（用于图像生成）、Google 的 Veo（用于视频创作）、Google 的 Chirp 3 HD（用于逼真语音）或 Google 的 Lyria（用于音乐创作）的工作流，从而在 AI 应用程序中实现动态内容创作。
外部 API 交互：MCP 为 LLM 提供了一种标准化的方式来调用任何外部 API 并接收响应。这意味着一个智能体可以获取实时天气数据、查询股票价格、发送邮件或与 CRM 系统互动，将其能力远远扩展到其核心语言模型之外。
基于推理的信息提取：利用 LLM 强大的推理能力，MCP 促进了有效的、依赖于查询的信息提取，这超越了传统的搜索和检索系统。一个智能体不再像传统搜索工具那样返回整个文档，而是可以分析文本并提取直接回答用户复杂问题的精确条款、数字或陈述。
自定义工具开发：开发者可以构建自定义工具，并通过一个 MCP 服务器（例如，使用 FastMCP）来暴露它们。这允许将专门的内部函数或专有系统以标准化的、易于消费的格式提供给 LLM 和其他智能体，而无需直接修改 LLM。
标准化的 LLM-到-应用程序通信：MCP 确保了 LLM 与其互动的应用程序之间有一致的通信层。这减少了集成开销，促进了不同 LLM 提供商和主机应用程序之间的互操作性，并简化了复杂智能体系统的开发。
复杂工作流编排：通过组合各种通过 MCP 暴露的工具和数据源，智能体可以编排高度复杂、多步骤的工作流。例如，一个智能体可以从数据库中检索客户数据，生成一张个性化的营销图片，起草一封定制的邮件，然后通过与不同的 MCP 服务互动来发送它。
物联网 (IoT) 设备控制：MCP 可以促进 LLM 与物联网设备的互动。一个智能体可以使用 MCP 向智能家居设备、工业传感器或机器人发送命令，从而实现对物理系统的自然语言控制和自动化。
金融服务自动化：在金融服务领域，MCP 可以使 LLM 与各种金融数据源、交易平台或合规系统互动。一个智能体可以分析市场数据、执行交易、生成个性化的财务建议或自动化监管报告，同时保持安全和标准化的通信。

简而言之，模型上下文协议 (MCP) 使智能体能够从数据库、API 和网络资源中访问实时信息。它还允许智能体执行诸如发送邮件、更新记录、控制设备以及通过集成和处理来自不同来源的数据来执行复杂任务。此外，MCP 还支持 AI 应用程序的媒体生成工具。

使用 ADK 的动手代码示例

本节概述了如何连接到一个提供文件系统操作的本地 MCP 服务器，从而使 ADK 智能体能够与本地文件系统互动。

使用 MCPToolset 设置智能体

要为一个用于文件系统交互的智能体进行配置，必须创建一个 agent.py 文件（例如，在 ./adk_agent_samples/mcp_agent/agent.py）。MCPToolset 在 LlmAgent 对象的 tools 列表中被实例化。将 args 列表中的 "/path/to/your/folder" 替换为 MCP 服务器可以访问的本地系统上目录的绝对路径至关重要。该目录将成为智能体执行文件系统操作的根目录。

import os
from google.adk.agents import LlmAgent
from google.adk.tools.mcp_tool.mcp_toolset import MCPToolset, StdioServerParameters

# 创建一个指向与此智能体脚本相同目录下
# 名为 'mcp_managed_files' 文件夹的可靠绝对路径。
# 这确保了智能体能够开箱即用地进行演示。
# 对于生产环境，你会将其指向一个更持久和安全的位置。
TARGET_FOLDER_PATH = os.path.join(os.path.dirname(os.path.abspath(__file__)), "mcp_managed_files")

# 确保目标目录在智能体需要它之前就存在。
os.makedirs(TARGET_FOLDER_PATH, exist_ok=True)

root_agent = LlmAgent(
    model='gemini-1.5-flash',
    name='filesystem_assistant_agent',
    instruction=(
        'Help the user manage their files. You can list files, read '
        'files, and write files. '
        f'You are operating in the following directory: {TARGET_FOLDER_PATH}'
    ),
    tools=[
        MCPToolset(
            connection_params=StdioServerParameters(
                command='npx',
                args=[
                    "-y",  # npx 自动确认安装的参数
                    "@modelcontextprotocol/server-filesystem",
                    # 这必须是一个文件夹的绝对路径。
                    TARGET_FOLDER_PATH,
                ],
            ),
            # 可选：你可以过滤从 MCP 服务器暴露的工具。
            # 例如，只允许读取：
            # tool_filter=['list_directory', 'read_file']
        )
    ],
)

npx (Node Package Execute)，与 npm (Node Package Manager) 版本 5.2.0及更高版本捆绑在一起，是一个可以直接执行 npm 注册表中 Node.js 包的实用工具。这消除了全局安装的需要。本质上，npx 作为一个 npm 包运行器，通常用于运行许多以 Node.js 包形式分发的社区 MCP 服务器。

创建一个 __init__.py 文件是必要的，以确保 agent.py 文件被识别为智能体开发套件 (ADK) 的可发现 Python 包的一部分。此文件应与 agent.py 位于同一目录中。

# ./adk_agent_samples/mcp_agent/__init__.py
from . import agent

当然，还有其他支持的命令可供使用。例如，可以按如下方式连接到 python3：

connection_params = StdioConnectionParams(
server_params={
     "command": "python3",
     "args": ["./agent/mcp_server.py"],
     "env": {
         "SERVICE_ACCOUNT_PATH": SERVICE_ACCOUNT_PATH,
         "DRIVE_FOLDER_ID": DRIVE_FOLDER_ID
     }
 }
)

在 Python 的上下文中，UVX 指的是一个利用 uv 在临时的、隔离的 Python 环境中执行命令的命令行工具。基本上，它允许你运行 Python 工具和包，而无需在全局或项目环境中安装它们。你可以通过 MCP 服务器来运行它。

connection_params = StdioConnectionParams(
server_params={
     "command": "uvx",
     "args": ["mcp-google-sheets@latest"],
     "env": {
         "SERVICE_ACCOUNT_PATH": SERVICE_ACCOUNT_PATH,
         "DRIVE_FOLDER_ID": DRIVE_FOLDER_ID
     }
 }
)

一旦 MCP 服务器创建完成，下一步就是连接到它。

使用 ADK Web 连接 MCP 服务器

首先，执行 ‘adk web’。在你的终端中导航到 mcp_agent 的父目录（例如，adk_agent_samples）并运行：

cd ./adk_agent_samples # 或者你等效的父目录
adk web

一旦 ADK Web UI 在你的浏览器中加载完成，从智能体菜单中选择 filesystem_assistant_agent。接下来，尝试使用如下提示进行实验：

“显示这个文件夹的内容。”
“读取 ‘sample.txt’ 文件。” (这假设 sample.txt 位于 TARGET_FOLDER_PATH。)
“another_file.md 里有什么内容？”

使用 FastMCP 创建 MCP 服务器

FastMCP 是一个高级 Python 框架，旨在简化 MCP 服务器的开发。它提供了一个抽象层，简化了协议的复杂性，让开发者能够专注于核心逻辑。

该库使用简单的 Python 装饰器即可快速定义工具、资源和提示。一个显著的优势是其自动生成模式的功能，它能智能地解释 Python 函数签名、类型提示和文档字符串，以构建必要的 AI 模型接口规范。这种自动化最大限度地减少了手动配置，并减少了人为错误。

除了基本的工具创建，FastMCP 还支持像服务器组合和代理这样的高级架构模式。这使得能够进行复杂、多组件系统的模块化开发，并将现有服务无缝集成到一个 AI 可访问的框架中。此外，FastMCP 还包括了针对高效、分布式和可扩展的 AI 驱动应用程序的优化。

使用 FastMCP 设置服务器

为了说明这一点，考虑一个由服务器提供的基本 “greet” 工具。ADK 智能体和其他 MCP 客户端一旦服务器激活，就可以使用 HTTP 与此工具互动。

# fastmcp_server.py
# 这个脚本演示了如何使用 FastMCP 创建一个简单的 MCP 服务器。
# 它暴露了一个生成问候语的单一工具。

# 1. 确保你已经安装了 FastMCP：
# pip install fastmcp
from fastmcp import FastMCP, Client

# 初始化 FastMCP 服务器。
mcp_server = FastMCP()

# 定义一个简单的工具函数。
# `@mcp_server.tool` 装饰器将此 Python 函数注册为一个 MCP 工具。
# 文档字符串成为该工具对 LLM 的描述。
@mcp_server.tool
def greet(name: str) -> str:
    """
    生成一个个性化的问候语。

    Args:
        name: 要问候的人的名字。

    Returns:
        一个问候字符串。
    """
    returnf"Hello, {name}! Nice to meet you."

# 或者如果你想从脚本运行它：
if __name__ == "__main__":
    mcp_server.run(
        transport="http",
        host="127.0.0.1",

        port=8000
    )

这个 Python 脚本定义了一个名为 greet 的单一函数，它接受一个人的名字并返回一个个性化的问候语。该函数上方的 @tool() 装饰器自动将其注册为一个可供 AI 或其他程序使用的工具。FastMCP 使用该函数的文档字符串和类型提示来告知智能体该工具如何工作、需要什么输入以及将返回什么。

当脚本执行时，它会启动 FastMCP 服务器，在 localhost:8000 上监听请求。这使得 greet 函数作为一个网络服务可用。然后，可以配置一个智能体连接到此服务器，并使用 greet 工具作为更大任务的一部分来生成问候语。服务器会持续运行，直到手动停止。

使用 ADK 智能体消费 FastMCP 服务器

可以将 ADK 智能体设置为一个 MCP 客户端，以使用一个正在运行的 FastMCP 服务器。这需要配置 HttpServerParameters，并使用 FastMCP 服务器的网络地址，通常是 http://localhost:8000。

可以包含一个 tool_filter 参数来限制智能体只能使用服务器提供的特定工具，例如 ‘greet’。当收到像 “Greet John Doe” 这样的请求时，智能体嵌入的 LLM 会识别到通过 MCP 可用的 ‘greet’ 工具，用参数 “John Doe” 调用它，并返回服务器的响应。这个过程演示了通过 MCP 暴露的用户定义工具与 ADK 智能体的集成。

要建立此配置，需要一个智能体文件（例如，位于 ./adk_agent_samples/fastmcp_client_agent/ 的 agent.py）。该文件将实例化一个 ADK 智能体，并使用 HttpServerParameters 来与运行中的 FastMCP 服务器建立连接。

# ./adk_agent_samples/fastmcp_client_agent/agent.py
import os
from google.adk.agents import LlmAgent
from google.adk.tools.mcp_tool.mcp_toolset import MCPToolset, HttpServerParameters

# 定义 FastMCP 服务器的地址。
# 确保你的 fastmcp_server.py (前面定义的) 在此端口上运行。
FASTMCP_SERVER_URL = "http://localhost:8000"

root_agent = LlmAgent(
    model='gemini-1.5-flash',  # 或你偏好的模型
    name='fastmcp_greeter_agent',
    instruction='你是一个友好的助手，可以通过名字问候人们。使用 "greet" 工具。',
    tools=[
        MCPToolset(
            connection_params=HttpServerParameters(
                url=FASTMCP_SERVER_URL,
            ),
            # 可选：过滤从 MCP 服务器暴露的哪些工具
            # 在这个例子中，我们只期望 'greet'
            tool_filter=['greet']
        )
    ],
)

该脚本定义了一个名为 fastmcp_greeter_agent 的智能体，它使用一个 Gemini 语言模型。它被赋予了一个具体的指令，即作为一个友好的助手，其目的是问候人们。关键的是，代码为这个智能体配备了一个工具来执行其任务。它配置了一个 MCPToolset 来连接到一个在 localhost:8000 上运行的独立服务器，这应该是前面例子中的 FastMCP 服务器。该智能体被特别授予访问托管在该服务器上的 greet 工具的权限。本质上，这段代码设置了系统的客户端，创建了一个智能的智能体，它理解其目标是问候人们，并且确切地知道使用哪个外部工具来完成它。

在 fastmcp_client_agent 目录中创建一个 __init__.py 文件是必要的。这确保了该智能体被识别为 ADK 的一个可发现的 Python 包。

首先，打开一个新的终端并运行 python fastmcp_server.py 来启动 FastMCP 服务器。接下来，在你的终端中转到 fastmcp_client_agent 的父目录（例如，adk_agent_samples）并执行 adk web。一旦 ADK Web UI 在你的浏览器中加载，从智能体菜单中选择 fastmcp_greeter_agent。然后你可以通过输入像 “Greet John Doe” 这样的提示来测试它。智能体将使用你 FastMCP 服务器上的 greet 工具来创建响应。

概览

问题 (What): 为了作为有效的智能体运作，LLM 必须超越简单的文本生成。它们需要与外部环境互动以访问最新数据并利用外部软件的能力。没有一个标准化的通信方法，LLM 与外部工具或数据源之间的每次集成都会成为一个定制的、复杂的、不可重用的工作。这种临时性的方法阻碍了可扩展性，并使得构建复杂的、互联的 AI 系统变得困难和低效。

解决方案 (Why): 模型上下文协议 (MCP) 通过充当 LLM 和外部系统之间的通用接口，提供了一个标准化的解决方案。它建立了一个开放、标准化的协议，定义了外部能力如何被发现和使用。MCP 采用客户端-服务器模型，允许服务器向任何兼容的客户端暴露工具、数据资源和交互式提示。由 LLM 驱动的应用程序作为这些客户端，以可预测的方式动态发现并与可用资源互动。这种标准化的方法促进了一个由可互操作和可重用组件组成的生态系统，极大地简化了复杂智能体工作流的开发。

经验法则 (Rule of thumb): 在构建需要与多样化且不断变化的外部工具、数据源和 API 互动的复杂、可扩展或企业级的智能体系统时，请使用模型上下文协议 (MCP)。当不同 LLM 和工具之间的互操作性是优先考虑的事项时，以及当智能体需要能够在不重新部署的情况下动态发现新能力时，它是理想的选择。对于具有固定且数量有限的预定义函数的简单应用程序，直接的工具函数调用可能就足够了。

可视化摘要

《Agentic Design Patterns：构建智能系统的实战指南》- 第十章模型上下文协议 — 图1. 模型上下文协议

核心要点

以下是关键要点：

模型上下文协议 (MCP) 是一个开放标准，促进 LLM 与外部应用程序、数据源和工具之间的标准化通信。
它采用客户端-服务器架构，定义了暴露和消费资源、提示和工具的方法。
智能体开发套件 (ADK) 支持利用现有的 MCP 服务器以及通过 MCP 服务器暴露 ADK 工具。
FastMCP 简化了 MCP 服务器的开发和管理，特别是对于暴露在 Python 中实现的工具。
MCP Tools for Genmedia Services 允许智能体与 Google Cloud 的生成式媒体能力（Imagen、Veo、Chirp 3 HD、Lyria）集成。
MCP 使 LLM 和智能体能够与真实世界的系统互动，访问动态信息，并执行超越文本生成的动作。

结论

模型上下文协议 (MCP) 是一个开放标准，促进了大语言模型 (LLM) 和外部系统之间的通信。它采用客户端-服务器架构，使 LLM 能够通过标准化的工具访问资源、利用提示并执行操作。MCP 允许 LLM 与数据库互动、管理生成式媒体工作流、控制物联网设备并自动化金融服务。实际的例子演示了如何设置智能体与 MCP 服务器（包括文件系统服务器和使用 FastMCP 构建的服务器）通信，展示了其与智能体开发套件 (ADK) 的集成。MCP 是开发超越基本语言能力的交互式 AI 智能体的关键组件。

参考文献

Model Context Protocol (MCP) Documentation. (Latest). Model Context Protocol (MCP). https://google.github.io/adk-docs/mcp/
FastMCP Documentation. FastMCP. https://github.com/jlowin/fastmcp
MCP Tools for Genmedia Services. MCP Tools for Genmedia Services. https://google.github.io/adk-docs/mcp/#mcp-servers-for-google-cloud-genmedia
MCP Toolbox for Databases Documentation. (Latest). MCP Toolbox for Databases. https://google.github.io/adk-docs/mcp/databases/

往期回顾

《Agentic Design Patterns：构建智能系统的实战指南》- 第九章学习与适应