Claw Paper Notes

Appearance

第19章 MCP——模型上下文协议 ​

本章来源：综合自 Hello-Agents 第十章（协议基础与实战视角）、Agentic Design Patterns 第十章（模式分析与工程视角）、Practical-Guide（上下文工程视角）、ce101（基础概念视角）

核心问题 —— 本章要解答什么 ​

当智能体的能力从"理解语言"扩展到"操作世界"时，一个根本性的工程问题浮现：如何让智能体以标准化、可扩展的方式访问外部工具和数据？

传统做法要求开发者为每个外部服务（GitHub API、数据库、文件系统、Slack等）编写专门的适配器。这种方式存在四个结构性缺陷：代码重复（每个工具都要处理HTTP请求、错误处理、认证等）、难以维护（API变更需要修改所有相关工具）、无法复用（其他开发者的工具无法直接使用）、扩展性差（添加新服务需要大量编码工作）。更严重的是，不同LLM平台的Function Calling实现差异巨大，切换模型时需要重写大量代码。

MCP（Model Context Protocol）正是为解决这一系列问题而设计的开放标准 [Anthropic, 2024]。本章将从协议的设计理念出发，深入分析MCP的架构决策、核心机制和生态系统，为读者提供一份关于"智能体如何与外部世界对话"的系统参考。

设计空间 —— 可选方案与取舍 ​

19.1 从Function Calling到MCP的演进 ​

在MCP出现之前，智能体与外部工具的交互主要依赖Function Calling机制。要理解MCP的设计决策，首先需要理清它与Function Calling的关系——两者并非竞争关系，而是不同抽象层次上的互补方案。

Function Calling是LLM的内在能力，它让模型能够理解何时需要调用函数，并精准生成相应的调用参数。这是模型推理能力的体现。而MCP是基础设施层的协议，它在工程层面解决了工具与模型如何连接的问题，通过标准化的方式来描述和调用工具。

一个形象的类比：Function Calling相当于你学会了"如何打电话"这项技能——何时拨号、如何与对方沟通、何时挂断；而MCP则是全球统一的"电话通信标准"——确保任何一部电话都能顺利拨通另一部。

MCP与Function Calling对比

两者的核心区别体现在五个维度：

维度Function CallingMCP
标准化专有且供应商特定，格式在不同LLM提供商间各异开放标准化协议，促进不同LLM和工具间互操作
范围LLM请求执行特定预定义函数的直接机制更广泛的框架，定义LLM和外部工具如何相互发现和通信
架构LLM与应用程序工具处理逻辑间的一对一交互客户端-服务器架构，LLM驱动应用可连接多种MCP服务器
发现LLM被明确告知特定对话上下文中哪些工具可用支持动态发现，客户端可查询服务器以查看其提供的能力
可重用性工具集成通常与所用特定应用程序和LLM紧密耦合促进开发可重用的独立MCP服务器，可被任何兼容应用访问

19.2 三种协议的设计理念 ​

MCP并非智能体通信的唯一选择。在当前的协议生态中，MCP、A2A和ANP分别针对不同的通信场景，形成了互补的协议栈。

三种协议设计思想对比

MCP的设计哲学是"上下文共享"。它不仅仅是一个RPC协议，更重要的是允许智能体和工具之间共享丰富的上下文信息。当智能体访问一个代码仓库时，MCP服务器不仅能提供文件内容，还能提供代码结构、依赖关系、提交历史等上下文信息，让智能体做出更智能的决策。

MCP设计思想

A2A的设计哲学是"对等通信"。在A2A网络中，每个智能体既是服务提供者也是服务消费者，智能体可以主动发起请求，也可以响应其他智能体的请求。这种对等设计避免了中心化协调器的瓶颈。

ANP的设计哲学是"去中心化服务发现"。它解决的是"如何在大规模网络中发现和连接智能体"的问题，提供了服务注册、发现和路由机制。

选择协议的关键在于理解需求：需要访问外部服务选MCP，需要多智能体协作选A2A，需要构建大规模智能体生态考虑ANP。目前MCP的生态最为成熟。

架构解析 —— 深入分析MCP架构 ​

19.3 三层架构设计 ​

MCP采用Host-Client-Server三层架构，这种分层设计的核心价值在于关注点分离。

MCP架构示例

Host（宿主层）：用户直接交互的界面，如Claude Desktop、IDE插件等。Host负责接收用户请求并与LLM交互，管理整个对话流程。

Client（客户端层）：当LLM决定需要访问外部资源时，Host中内置的MCP Client被激活。Client负责与适当的MCP Server建立连接，将LLM的意图转换为符合MCP标准的正式请求，发送请求并接收响应。

Server（服务器层）：通往外部世界的网关。每个Server通常负责特定领域（如文件系统、数据库、GitHub API），向任何授权的MCP Client公开一组工具、资源和提示。

这种三层架构的优势在于：Host专注于用户体验，Client专注于协议通信，Server专注于具体功能实现。开发者只需专注于开发MCP Server，无需关心Host和Client的实现细节。

19.4 核心能力三要素 ​

MCP协议提供三大核心能力，构成完整的工具访问框架：

MCP核心能力

Tools（工具）：可执行的函数，执行具体操作。例如发送电子邮件、查询API、执行计算等。Tools是主动的——它们"做"事情。

Resources（资源）：静态数据，提供上下文信息。例如PDF文件、数据库记录、配置文件等。Resources是被动的——它们"提供"数据。

Prompts（提示模板）：交互模板，指导LLM如何与资源或工具交互，确保交互是结构化且有效的。Prompts是指导性的——它们"引导"行为。

这三种能力的设计体现了一个重要的架构洞察：智能体与外部世界的交互不仅仅是"调用函数"，还包括"获取上下文"和"遵循交互模式"。

19.5 交互流程详解 ​

MCP的完整交互流程包含五个阶段：

MCP工作流程

1. 发现阶段：MCP Client连接到Server后，首先调用list_tools()获取所有可用工具的描述信息（工具名称、功能说明、参数定义）。

2. 上下文构建：Client将工具列表转换为LLM能理解的格式，添加到系统提示词中。

3. 模型推理：LLM分析用户问题和可用工具，决定是否需要调用工具以及调用哪个工具。这个决策基于工具描述和当前对话上下文。

4. 工具执行：如果LLM决定使用工具，Client通过MCP Server执行所选工具，获取结果。Server对客户端进行身份验证，验证请求，然后与底层系统交互执行指定操作。

5. 响应和上下文更新：Server将标准化响应发送回Client，Client将结果传递回LLM，更新其上下文并使其能够继续任务的下一步。

这个过程是完全自动化的，LLM会根据工具描述的质量来决定是否使用以及如何使用工具。因此，编写清晰、准确的工具描述至关重要。

19.6 传输机制 ​

MCP定义了两种底层传输层以适应不同的部署场景：

本地传输（Stdio）：使用基于标准输入/输出的JSON-RPC实现高效的进程间通信。适用于工具和智能体运行在同一台机器上的场景，具有低延迟和高安全性的优势。

远程传输（HTTP）：利用可流式HTTP和服务器发送事件（SSE）实现持久高效的客户端-服务器通信。适用于工具部署在远程服务器上的场景，支持组织内共享和可扩展的访问。

选择本地还是远程取决于具体需求：本地服务器因速度和安全性适合处理敏感数据，远程服务器架构则支持跨组织的共享访问。

关键实现决策 —— 工程实践中的选择点 ​

19.7 MCP的设计约束与陷阱 ​

MCP作为一份"智能体接口"契约，其有效性很大程度上取决于底层API的设计质量。以下是实践中需要关注的关键决策点。

API设计质量决定MCP效果。存在这样的风险：开发者简单地包装现有的遗留API而不做任何修改，这对智能体来说可能并不是最优的。例如，如果一个票务系统的API只允许逐个检索完整的票务详情，那么当智能体需要总结高优先级票务时，在处理大量数据时会变得缓慢且不准确。要真正发挥效用，底层API应该通过过滤和排序等确定性功能进行增强。这凸显了一个重要原则：智能体无法神奇地替代确定性工作流，它们通常需要更强的确定性支持才能成功。

数据格式必须对智能体友好。API只有在其数据格式对智能体友好时才有用，而MCP本身并不保证这一点。例如，为一个返回PDF文件的文档存储创建MCP服务器，如果消费端的智能体无法解析PDF内容，那么这基本上是无用的。更好的做法是创建返回文本版本（如Markdown）的API。开发者必须考虑的不只是连接，还有所交换数据的性质。

按需与批处理的选择。MCP可以支持按需交互式会话和大规模批处理。选择取决于应用场景——从需要即时工具访问的实时对话智能体，到批量处理记录的数据分析管道。

19.8 FastMCP与工具开发 ​

据 MCP 官方统计，截至 2025 年初已有超过 1000 个社区贡献的 MCP Server 覆盖了从文件系统、数据库到各类 SaaS 服务的广泛领域，Claude Desktop、Cursor、Windsurf 等主流 AI 产品均已原生支持 MCP 协议。

FastMCP是简化MCP服务器开发的高级Python框架。它的核心优势在于自动模式生成——智能地解释Python函数签名、类型提示和文档字符串来构建接口规范，最大限度地减少手动配置。

python
from fastmcp import FastMCP

mcp_server = FastMCP()

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

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

这个示例展示了FastMCP的核心设计理念：通过@mcp_server.tool装饰器将普通Python函数注册为MCP工具，函数的文档字符串和类型提示自动成为工具描述，开发者只需关注业务逻辑。

在使用MCP客户端连接时，代码同样简洁：

python
from hello_agents.protocols import MCPClient

# 连接到社区提供的文件系统服务器
client = MCPClient([
    "npx", "-y", "@modelcontextprotocol/server-filesystem", "."
])

async with client:
    # 自动发现工具
    tools = await client.list_tools()
    # 调用工具（标准化接口）
    result = await client.call_tool("search_repositories", {"query": "AI agents"})

19.9 实际应用场景 ​

MCP的应用范围涵盖了智能体与外部世界交互的几乎所有场景：

  • 数据库集成：智能体无缝访问结构化数据，执行查询、生成报告、更新记录
  • 外部API交互：获取实时天气数据、股票价格、CRM系统等
  • 复杂工作流编排：组合多种MCP服务完成多步骤任务
  • 自定义工具开发：将内部系统以标准化格式暴露给智能体
  • 物联网设备控制：通过自然语言控制智能家居、工业传感器
  • 生成媒体编排：编排图像生成、视频创建、语音合成等工作流

前沿动态 —— 最新进展 ​

19.10 MCP生态系统演进 ​

MCP生态正处于快速发展期。Anthropic、Google等主要供应商都提供了SDK来简化开发。社区贡献的MCP服务器覆盖了从文件系统、GitHub到各类SaaS服务的广泛领域。

一个值得关注的趋势是MCP与A2A协议的融合。MCP专注于智能体与工具的通信，A2A专注于智能体之间的通信，两者组合形成了完整的智能体通信栈。Google ADK同时支持使用现有MCP服务器和通过MCP服务器公开ADK工具，展示了这种融合的实际路径。

另一个重要方向是远程MCP服务器的标准化。随着企业级应用的需求增长，远程部署、身份验证、访问控制和审计日志等企业特性正在成为MCP规范的核心关注点。

19.11 协议安全与治理 ​

MCP实现必须包含身份验证和授权机制来控制访问权限。安全考虑包括：

  • 传输安全：本地通信使用进程隔离，远程通信使用TLS加密
  • 认证授权：控制哪些客户端可以访问哪些服务器以及允许执行哪些操作
  • 错误处理：定义如何将错误传达回LLM，使其理解失败并尝试替代方法
  • Agent Card端点保护：通过访问控制、mTLS或网络限制保护元数据

⚠️ 已知局限：MCP 协议在实践中面临两个突出问题。第一是安全边界模糊——MCP Server 运行在用户本地环境中，恶意或设计不当的 Server 可能访问文件系统、环境变量甚至凭据信息，而当前协议缺乏细粒度的权限沙箱机制。第二是工具描述质量参差不齐——LLM 对工具的选择和参数构造完全依赖工具描述的质量，社区贡献的 MCP Server 在描述规范性上差异很大，模糊或误导性的描述会导致工具调用失败率显著上升（实测中描述质量差的工具调用成功率可低至 40-50%）。此外，远程 MCP Server 的标准化认证和授权机制尚未完善，企业级部署仍需额外的安全封装。

本章小结 ​

MCP作为智能体与外部世界交互的开放标准，解决了工具集成碎片化的根本问题。其三层架构（Host-Client-Server）实现了关注点分离，三种核心能力（Tools/Resources/Prompts）覆盖了完整的交互需求，多种传输机制适应了从本地到远程的部署场景。

MCP的设计给出了两个关键启示：第一，标准化协议的价值不在于它本身做了什么，而在于它使生态系统中的所有参与者能够以可预测的方式协作；第二，好的协议设计需要同时考虑"连接"和"数据性质"——仅仅建立连接是不够的，确保数据对智能体友好同样重要。

在实际选型中，对于需要与外部工具交互的场景优先考虑MCP，对于需要智能体间协作的场景则需要引入A2A（下一章讨论），对于大规模智能体网络的服务发现则考虑ANP。这三种协议不是非此即彼的关系，而是互补的协议栈。