《Agentic Design Patterns》第 10 章导读：模型上下文协议（MCP）

本文是对开源书籍《Agentic Design Patterns》第 10 章的解读与导读，内容忠实呈现原文，并附个人思考。

原书在线阅读：https://adp.xindoo.xyz/ ｜翻译项目代码仓库：https://github.com/xindoo/agentic-design-patterns

前 9 章我们聊了很多智能体"内部"的模式------提示词链、路由、并行、反思、工具使用、规划、多智能体协作、记忆、学习。但智能体要真正有用，光靠"脑子"不行，还得跟外部世界连接------查数据库、发邮件、调 API、控制设备......

问题是，怎么连？

传统方式是"一个工具写一套接入代码"。接 OpenAI 的工具用一套写法，接 Anthropic 的又是另一套；接 A 数据库一个 SDK，接 B 系统又一个 API。每加一个新工具，都得改应用代码、改提示词、测试联调......非常痛苦。

第 10 章讲的模型上下文协议（Model Context Protocol，MCP） ，就是来解决这个问题的：用一套标准化协议，让任何 LLM 都能连接任何外部系统。

一、什么是 MCP：AI 时代的"通用插座"

书中有个很形象的比喻：MCP 就像通用电源插座标准。

在没有标准之前，每个电器都有自己的插头形状，你得为每个电器配一个专用插座------混乱、低效、扩展性差。有了标准插座之后，任何符合标准的电器都能直接插上去用，即插即用。

MCP 就是 LLM 和外部系统之间的"通用插座"。它是一个开放标准 ，定义了 LLM（如 Gemini、GPT、Claude、Mixtral）跟外部应用、数据源、工具之间的通信方式。

图 1：模型上下文协议（MCP）------LLM 与外部系统之间的标准化通信层。

MCP 基于客户端-服务器架构：

MCP 服务器：对外暴露能力------数据（叫"资源"）、交互模板（叫"提示"）、可执行函数（叫"工具"）；
MCP 客户端：通常是 LLM 宿主应用或 AI 智能体，连接服务器、发现能力、调用工具。

有了这个标准，接入一个新工具就变成了"接一个 MCP 服务器"，不用再为每个 LLM、每个应用单独写集成代码。

但书中也特别提醒了两个容易踩的坑：

第一，MCP 不是魔法，底层 API 设计很重要。 如果只是把一个烂 API 用 MCP 包一层，那对智能体来说照样难用。比如票务系统的 API 只能逐条拉取完整票务详情，那智能体要"总结高优先级工单"时，就得拉一堆数据慢慢处理------又慢又不准。好的做法是在底层 API 里就加上过滤、排序这些确定性功能，帮非确定性的智能体减轻负担。

第二，数据格式要对智能体友好。 MCP 保证的是"能连上"，但不保证"连得上能用"。比如一个文档存储 API 返回 PDF 文件，但智能体不会解析 PDF------连上了也白搭。更好的做法是让 API 返回 Markdown 之类的纯文本格式，智能体才能真正读取和处理。

二、MCP vs 工具函数调用：有什么不一样？

你可能会问："工具调用不是已经能让 LLM 调外部函数了吗？MCP 跟它有啥区别？"

书中给了一张很清晰的对比表：

特性	工具函数调用	模型上下文协议（MCP）
标准化	专有、各厂商各搞一套	开放标准、跨厂商互操作
范围	直接调用特定预定义函数	更广泛的框架，定义发现和通信的完整方式
架构	LLM 与应用逻辑一对一交互	客户端-服务器架构，一个客户端连多个服务器
发现机制	LLM 被明确告知有哪些工具	动态发现------客户端可以查询服务器有什么能力
可重用性	跟特定应用和 LLM 紧耦合	MCP 服务器是独立的，任何兼容客户端都能用

再用个更生活化的类比：

工具函数调用就像给 AI 一套定制工具------特定型号的扳手、螺丝刀，只能干特定的活，换个牌子的 AI 可能就用不了；
MCP 就像标准化插座------它本身不提供工具，但任何符合标准的工具都能插上来用，生态可以无限扩展。

简单说：工具调用适合简单、固定的场景；MCP 适合复杂、需要扩展、需要互操作的系统。

三、MCP 的核心概念与交互流程

MCP 里有三个核心元素需要分清：

资源（Resources）：静态数据，比如 PDF 文件、数据库记录；
工具（Tools）：可执行函数，能做事情，比如发邮件、查 API；
提示（Prompts）：交互模板，指导 LLM 怎么跟资源或工具打交道，确保交互结构化、有效。

整个交互流程是这样的：

发现：MCP 客户端问服务器"你有啥能力？"，服务器返回一个清单------有哪些工具、哪些资源、哪些提示；
制定请求：LLM 决定要用某个工具，制定好参数（比如要发邮件，收件人是谁、主题是什么、正文写啥）；
客户端通信：MCP 客户端把 LLM 的请求转换成标准格式，发给对应服务器；
服务器执行：MCP 服务器验证请求、调用底层 API（比如真的发一封邮件）；
响应与上下文更新：服务器把结果返回给客户端，客户端再把结果喂给 LLM，LLM 继续下一步。

这个流程里，MCP 还涉及很多实际考量：

可发现性：客户端可以动态查询服务器能力，不用重新部署就能接入新工具；
安全性：必须有认证和授权机制，控制谁能访问什么、能执行什么操作；
错误处理：工具执行失败、服务器挂了、请求无效......这些错误都得标准化地传回 LLM，让它知道出了什么问题、能不能试别的方法；
本地 vs 远程服务器：本地服务器速度快、数据安全；远程服务器可共享、可扩展；
传输机制：本地用 STDIO（标准输入输出）上的 JSON-RPC，高效进程间通信；远程用 HTTP 流式传输和 SSE（服务器发送事件），适合 Web 环境。

四、九大应用场景

MCP 能把智能体的能力边界大大扩展。书中列举了 9 个关键用例：

数据库集成：智能体用自然语言就能查 BigQuery、生成报表、更新记录------不用写 SQL；
生成媒体编排：智能体可以调用图像生成（Imagen）、视频生成（Veo）、语音合成（Chirp 3 HD）、音乐创作（Lyria），串成完整的内容生产工作流；
外部 API 交互：查天气、拉股价、发邮件、对接 CRM------标准化方式调用任何外部 API；
基于推理的信息提取：超越传统搜索，智能体可以分析文本、精确提取特定条款/数字/陈述，直接回答复杂问题，而不是返回整篇文档；
自定义工具开发：用 FastMCP 之类的框架，开发者可以轻松把内部函数或专有系统包装成标准 MCP 工具；
标准化通信层：LLM 和应用之间有一致的通信协议，减少集成开销，促进互操作；
复杂工作流编排：组合多个 MCP 服务的工具和数据------从数据库拉客户数据 → 生成个性化营销图 → 写定制邮件 → 发送------一条智能体流水线全搞定；
物联网设备控制：用自然语言控制智能家居、工业传感器、机器人；
金融服务自动化：分析市场数据、执行交易、生成个性化理财建议、自动化合规报告------全程安全、标准化。

一句话总结：MCP 让智能体从"只会聊天的模型"变成"能操作真实世界系统的代理"。

五、实操示例：用 ADK + FastMCP 快速搭建

说了这么多概念，来看看实际怎么用。书中演示了两种方式：用现成的 MCP 服务器 和自己用 FastMCP 搭一个。

方式一：接入现成的文件系统 MCP 服务器

Google ADK 里可以直接用 MCPToolset 连接 MCP 服务器。比如连接一个文件系统服务器：

python 复制代码

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

root_agent = LlmAgent(
    model='gemini-2.0-flash',
    name='filesystem_assistant_agent',
    instruction='Help the user manage their files.',
    tools=[
        MCPToolset(
            connection_params=StdioServerParameters(
                command='npx',
                args=[
                    "-y",
                    "@modelcontextprotocol/server-filesystem",
                    TARGET_FOLDER_PATH,  # 智能体能操作的目录
                ],
            ),
            # 可选：只允许读取操作
            # tool_filter=['list_directory', 'read_file']
        )
    ],
)

就这么简单------一个 MCPToolset 配置进去，智能体就获得了文件系统操作能力。npx 会自动从 npm 下载并运行 MCP 服务器，不用手动安装。

方式二：用 FastMCP 自己写 MCP 服务器

FastMCP 是一个 Python 框架，把 MCP 协议的复杂性大大简化了。用装饰器就能把普通 Python 函数变成 MCP 工具：

python 复制代码

from fastmcp import FastMCP

mcp_server = FastMCP()

@mcp_server.tool
def greet(name: str) -> str:
    """
    生成个性化的问候语。
    
    参数：
        name: 要问候的人的名字。
    返回：
        问候语字符串。
    """
    return f"Hello, {name}! Nice to meet you."

if __name__ == "__main__":
    mcp_server.run(transport="http", host="127.0.0.1", port=8000)

就这么几行代码------一个 @mcp_server.tool 装饰器，函数就成了 MCP 工具。FastMCP 会自动读取函数的类型提示和文档字符串，生成 AI 模型需要的接口规范。省掉了大量手动配置工作。

方式三：ADK 智能体连接 FastMCP 服务器

有了 FastMCP 服务器之后，ADK 智能体怎么用呢？用 HttpServerParameters 连接就行：

python 复制代码

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

FASTMCP_SERVER_URL = "http://localhost:8000"

root_agent = LlmAgent(
    model='gemini-2.0-flash',
    name='fastmcp_greeter_agent',
    instruction='You are a friendly assistant that can greet people by their name. Use the "greet" tool.',
    tools=[
        MCPToolset(
            connection_params=HttpServerParameters(url=FASTMCP_SERVER_URL),
            tool_filter=['greet']  # 只允许用 greet 工具
        )
    ],
)

整个流程：

启动 FastMCP 服务器（python fastmcp_server.py）；
ADK 智能体通过 HTTP 连接到服务器；
智能体动态发现有 greet 工具可用；
用户说"Greet John Doe"，LLM 决定调用 greet 工具，参数 "John Doe"；
MCP 客户端把请求发给服务器，服务器执行函数，返回结果；
LLM 拿到结果，组织成自然语言回复用户。

完美的闭环。

六、速览

问题背景：LLM 要成为有效的智能体，不能只生成文本，还得跟外部环境交互------访问实时数据、使用外部软件。但没有标准化通信方式的话，每接入一个工具或数据源都得做定制集成，复杂、不可复用、扩展性差。搭建互联的 AI 系统又难又低效。
解决方案：MCP 充当 LLM 和外部系统之间的通用接口，提供标准化方案。它基于客户端-服务器模型------服务器对外暴露工具、数据资源和交互提示，LLM 驱动的应用作为客户端动态发现和使用这些能力。标准化促进了可互操作、可重用组件的生态系统，大大简化了复杂智能体工作流的开发。
实践建议：构建需要跟各种外部工具、数据源、API 交互的复杂、可扩展或企业级智能体系统时，使用 MCP。当不同 LLM 和工具之间的互操作性很重要、或者智能体需要动态发现新能力而不用重新部署时，MCP 是理想选择。简单应用、工具数量固定的话，直接工具函数调用可能就够了。

关键要点

模型上下文协议（MCP）是一个开放标准，促进 LLM 与外部应用、数据源和工具之间的标准化通信；
它采用客户端-服务器架构，定义了资源、提示和工具的公开与使用方式；
ADK 支持使用现成的 MCP 服务器，也支持通过 MCP 服务器公开 ADK 工具；
FastMCP 简化了 MCP 服务器的开发，特别是用 Python 实现的工具；
MCP 让 LLM 和智能体能与真实世界系统交互、访问动态信息、执行超越文本生成的操作。

结语与个人思考

MCP 这一章看似在讲一个技术协议，但它背后的趋势其实很重要：智能体的能力边界，正在从"模型本身能做什么"转向"生态系统能提供什么"。

在 MCP 之前，每个智能体应用都是一座孤岛------工具是定制的、接入是一次性的、换个模型就得重来。MCP 把"工具接入"这件事标准化了之后，整个生态就活了：

工具开发者只需要写一个 MCP 服务器，所有兼容 MCP 的智能体都能用；
智能体开发者只需要支持 MCP 客户端，就能接入整个 MCP 生态的工具；
最终用户受益于丰富的工具选择和即插即用的体验。

这很像当年 USB 标准之于外设，或者 HTTP 协议之于 Web 服务------标准化带来生态繁荣。

但 MCP 也不是没有挑战。我觉得有几个问题值得关注：

第一个是安全边界。智能体通过 MCP 能调用的工具越多，安全风险就越大。一个恶意的 MCP 服务器可能窃取数据，一个被劫持的智能体可能通过 MCP 搞破坏。认证、授权、审计、沙箱......这些安全机制必须跟得上生态扩展的速度。

第二个是质量参差不齐。MCP 降低了工具开发的门槛，但也意味着工具质量可能参差不齐。有的工具文档清晰、设计合理，有的可能返回格式混乱、错误处理糟糕。智能体遇到烂工具怎么办？怎么评估工具质量？怎么容错？这些都是生态成熟过程中需要解决的问题。

第三个是发现的效率。MCP 支持动态发现工具，但如果工具太多了呢？智能体每次都要先问"你有啥工具"，然后从上百个工具里找到合适的------光发现过程就消耗很多 token。怎么给工具分类、怎么让智能体快速找到最相关的工具，也是个实际问题。

总的来说，MCP 的方向是对的。智能体的未来一定是生态化的------没有任何一家公司能提供所有工具，也没有任何一个模型能搞定所有事情。标准化协议是构建这个生态的基础设施。而现在，这个基础设施才刚刚开始搭建。

下一步，建议阅读第 11 章 目标设定与监控（Goal Setting and Monitoring）------看看智能体怎么设定目标、追踪进度、确保自己走在正确的方向上。

本文基于开源书籍《Agentic Design Patterns》（https://github.com/xindoo/agentic-design-patterns ，在线阅读 https://adp.xindoo.xyz/ ）整理，供学习交流，版权归原作者所有。