分述一：MCP是什么？——从“m×n困境”到“即插即用”

1.1 一个真实存在的“m×n困境”

在MCP出现之前，AI Agent的工具集成面临一个被反复验证的难题：m个大模型 × n个工具 = m×n次定制化开发。

具体来说：GPT用Function Calling，Claude用Tool Use，各家生态互不兼容。如果你有一家企业，需要接入10个内部系统（数据库、文件系统、CRM、邮件服务……），光是让每一种大模型都能调用这些工具，适配代码就可能耗费2-3名工程师数月时间。

这不仅仅是“麻烦”，而是阻碍AI Agent规模化落地的结构性瓶颈。

1.2 MCP的解法：降维打击

MCP（Model Context Protocol，模型上下文协议） 是由Anthropic于2024年11月25日发布的开放标准协议，旨在解决AI应用与外部系统之间的标准化连接问题。

它的核心思路是：不再为每一对“模型-工具”写适配器，而是让所有模型用同一种协议说话，所有工具用同一种协议暴露自己。

MCP将m×n问题降维为m+n：

• 模型侧：实现一次MCP Client，即可连接任意MCP Server

• 工具侧：实现一次MCP Server，即可被任意MCP Client调用

这正如USB-C统一了充电接口，MCP统一了AI与外部世界的连接方式。

1.3 MCP vs Function Calling：不是替代，是分层

关于MCP和Function Calling的关系，有很多混淆的说法。一个被反复传播的误解是“MCP要取代Function Calling”。

事实是：它们根本不在同一个层次上。

维度	Function Calling	MCP
定位	模型接口层的工具声明机制	工具发现与连接的标准化协议
谁定义	各模型厂商各自的API规范	Linux基金会旗下的开放标准
工具集成方式	每个工具需在应用代码中手动适配	工具封装为独立MCP Server，即插即用
工具发现	硬编码在应用代码中	通过协议动态发现和注册
跨模型兼容	不兼容（GPT的Function Calling和Claude的Tool Use不同）	所有兼容MCP的模型均可调用

一个更精确的理解是：Function Calling是大模型的“决策层”——负责选工具、生成参数；MCP是后端与工具间的“执行协议”——统一调用标准。它们分属不同链路环节，在实际架构中协同工作，而非互相替代。

分述二：MCP的三层架构——Host、Client、Server

MCP采用客户端-主机-服务器架构，每个Host可以运行多个Client实例。这套架构的核心目标是：在保持清晰安全边界的同时，实现AI能力的跨应用集成。

2.1 Host（宿主）——AI应用本身

Host是运行AI模型的主环境，是整个架构的“容器和协调者”。

Host的职责包括：

• 创建和管理多个Client实例

• 控制Client的连接权限和生命周期

• 执行安全策略和用户授权决策

• 协调AI/LLM集成和采样（Sampling）

• 管理跨Client的上下文聚合

通俗理解：Host就是你的AI应用——Claude Desktop、Cursor IDE、或者你自己构建的Agent系统。

2.2 Client（客户端）——Host内部的连接器

Client是Host内部创建的、维持与单个Server独立会话的连接组件。

Client的职责包括：

• 与每个Server建立一个有状态的会话

• 处理协议协商和能力交换

• 双向路由协议消息

• 管理订阅和通知

• 维护Server之间的安全边界

关键设计：每个Client连接是隔离的，一个Server无法“看到”另一个Server的会话。完整的对话历史由Host持有，Server只接收完成任务所必需的上下文信息。

2.3 Server（服务端）——暴露能力的轻量级服务

MCP Server是暴露Resources、Tools和Prompts的轻量级服务。它可以是本地进程，也可以是远程服务。

MCP Server的三大能力原语：

原语	说明	类比
Resources（资源）	提供上下文和数据，供用户或AI模型使用	文件系统中的“文件”
Tools（工具）	可供AI模型执行的函数	API接口
Prompts（提示词模板）	模板化的消息和工作流	预定义的对话模板

Server的设计原则：

• 极易构建：Server应该非常容易开发

• 聚焦单一职责：每个Server提供专注的、定义良好的能力

• 高度可组合：多个Server可以无缝组合使用

• 安全隔离：Server无法读取完整对话，也无法“窥视”其他Server

2.4 能力协商（Capability Negotiation）——MCP的“握手”机制

MCP使用基于能力的协商系统——Client和Server在初始化时明确声明自己支持哪些功能。

Server声明的能力：是否支持资源订阅、工具调用、提示词模板等
Client声明的能力：是否支持采样（Sampling）、通知处理等

在整个会话期间，双方必须遵守已声明的能力边界。这种机制确保了渐进式增强——核心协议只提供最小必需功能，额外能力通过协商按需启用。

分述三：实战——从零开发一个MCP Server

理解了架构之后，我们来看一个完整的MCP Server开发示例。

3.1 环境准备与SDK安装

MCP官方提供了完整的Python SDK：

pip install mcp

官方Python SDK支持stdio、SSE和Streamable HTTP等多种传输方式。

3.2 实现一个“智能运维”MCP Server

以下示例实现一个简单的服务器监控MCP Server——让AI Agent能够查询服务器状态和执行健康检查。

from mcp.server import Server, NotificationOptions
from mcp.server.models import InitializationOptions
import mcp.types as types

# 1. 创建MCP Server实例
server = Server("ops-monitor")

# 2. 暴露Tool：查询服务器状态
@server.list_tools()
async def handle_list_tools() -> list[types.Tool]:
    return [
        types.Tool(
            name="get_server_status",
            description="查询指定服务器的实时运行状态，包括CPU、内存、磁盘使用率",
            inputSchema={
                "type": "object",
                "properties": {
                    "server_id": {
                        "type": "string",
                        "description": "服务器ID或主机名"
                    }
                },
                "required": ["server_id"]
            }
        ),
        types.Tool(
            name="run_health_check",
            description="对指定服务器执行健康检查，返回检查结果",
            inputSchema={
                "type": "object",
                "properties": {
                    "server_id": {"type": "string"},
                    "check_type": {
                        "type": "string",
                        "enum": ["basic", "full"],
                        "description": "检查类型：basic(基础) / full(全面)"
                    }
                },
                "required": ["server_id"]
            }
        )
    ]

# 3. 实现Tool的执行逻辑
@server.call_tool()
async def handle_call_tool(
    name: str, 
    arguments: dict | None
) -> list[types.TextContent | types.ImageContent | types.EmbeddedResource]:
    
    if name == "get_server_status":
        server_id = arguments.get("server_id")
        # 实际项目中替换为真实的监控系统API调用
        status = {
            "server_id": server_id,
            "cpu_usage": "45%",
            "memory_usage": "62%",
            "disk_usage": "38%",
            "status": "running",
            "uptime": "72h"
        }
        return [types.TextContent(type="text", text=str(status))]
    
    elif name == "run_health_check":
        server_id = arguments.get("server_id")
        check_type = arguments.get("check_type", "basic")
        # 实际项目中执行真实的健康检查逻辑
        result = {
            "server_id": server_id,
            "check_type": check_type,
            "passed": True,
            "details": "所有检查项通过"
        }
        return [types.TextContent(type="text", text=str(result))]

# 4. 启动Server（使用stdio传输）
async def main():
    async with server.run_stdio():
        await server.wait_for_termination()

if __name__ == "__main__":
    import asyncio
    asyncio.run(main())

3.3 将MCP Server接入AI应用

开发完成后，MCP Server可以通过多种方式接入AI应用：

方式一：Claude Desktop配置

在Claude Desktop的配置文件中添加MCP Server的路径，即可让Claude直接调用你的Server。

方式二：通过LangChain集成

LangChain已全面原生支持MCP，可以通过MCP工具适配器将Server暴露的工具转换为LangChain的Tool对象。

方式三：通过阿里云百炼MCP服务

阿里云百炼已上线业界首个全生命周期MCP服务，预置20+云端服务和50+本地服务。开发者可以在百炼MCP服务广场发布和集成MCP Server。

分述四：2026年MCP的最新演进——无状态化、企业就绪与安全挑战

4.1 最大变化：从有状态到无状态

MCP发布了自发布以来最大的一次修订，核心变化是：将协议核心从有状态替换为无状态。

这意味着什么？

• 旧版MCP依赖持久会话，Server重启会导致会话丢失

• 新版MCP通过标准化的HTTP headers和_meta对象实现多轮往返请求

• Server现在可以承受负载均衡、Pod重启和水平扩展

对企业级部署的意义：MCP从“单用户本地工具”进化为“企业级云原生部署就绪的平台”。

4.2 企业就绪路线图

根据MCP官方路线图，2026年的战略优先级包括：

1. 传输演进与可扩展性

• 让Streamable HTTP在负载均衡器和代理背后无状态运行

• 定义会话的创建、恢复和迁移机制

• MCP Server Cards：通过.well-known URL暴露结构化元数据，让浏览器和注册表无需连接即可发现Server能力

2. Agent通信

• 完善Tasks原语的重试语义和过期策略

3. 治理成熟化

• 明确的贡献者晋升路径

• 工作组自治的委托模型

4. 企业就绪

• 集中访问控制、合规要求和专用认证

4.3 安全挑战：新架构带来新风险

Akamai在2026年6月发布的研究报告指出：新版MCP移除了若干类漏洞，但也引入了新的攻击面。

已修复的漏洞：

• 会话劫持的终结

• 防止未经请求的Server发起的提示

• 更强的认证标准

新增的安全挑战：

挑战一：可预测的状态ID风险
无状态架构下，Server将跟踪标识符和状态对象交给Client保管。如果ID可预测，攻击者可能：劫持活跃工作流、访问其他Agent的数据、触发未经授权的跨租户操作。

挑战二：MCP专用HTTP headers的风险
新规范引入了MCP-Method和MCP-Name等专用headers。如果开发者不小心将API密钥、Token或PII等敏感输入映射到headers，这些秘密会被推送到headers中，暴露给路径上的每一个负载均衡器、代理和日志系统。

挑战三：长期任务的DoS风险
新规范引入了长期运行任务，但任务创建对Client来说成本极低，对Server来说却资源密集。“攻击者可以发送一个请求来触发昂贵的操作（消耗CPU、内存或数据库存储），然后立即断开连接”。

一个关键认知：不是MCP协议本身变得更脆弱了，而是攻击面从协议层转移到了实现层。安全性现在高度依赖实现质量。

结尾总结：MCP——AI Agent从“单兵作战”到“万物互联”的基石

让我们回顾一下本文的核心内容：

第一，MCP解决的是“m×n困境”——让m个模型和n个工具不再需要m×n次适配，而是通过统一协议实现“即插即用” 。它和Function Calling不是替代关系，而是分层协同——Function Calling是模型的“决策层”，MCP是后端与工具间的“执行协议”。

第二，MCP的三层架构（Host-Client-Server）确保了清晰的安全边界和职责分离。Host是AI应用本身，Client是Host内部的连接器，Server是暴露能力的轻量级服务。Server无法读取完整对话、无法窥视其他Server——这种隔离设计是MCP安全模型的基石。

第三，2026年7月28日的MCP修订是“分水岭级”的。协议核心从有状态变为无状态，使其能够承受负载均衡、Pod重启和水平扩展。MCP正在从“单用户本地工具”进化为“企业级云原生就绪的平台”。

第四，MCP的生态已经成熟——9700万月SDK下载量、两万个公开Server、Linux基金会旗下的Agentic AI Foundation。LangChain、LlamaIndex、Claude Desktop、Cursor等主流框架和应用均已原生支持。

第五，安全是MCP企业级落地的“必修课”。无状态化带来了新的安全挑战——可预测的状态ID、HTTP headers泄露风险、长期任务的DoS攻击。这些不是协议的缺陷，而是实现质量的考验。

回顾我们走过的Agent技术路径：

• Function Calling：让模型“声明”想调用什么工具

• MCP协议：让工具“即插即用”，不再为每个模型写适配器

• Agent框架（LangGraph/AutoGen/CrewAI）：让多个Agent协作完成任务

MCP是这三层中最底层、最基础设施的那一层——它定义了AI Agent如何“伸手”触碰外部世界。