为什么AI Agent需要一个"USB接口"

如果你最近关注AI开发领域，一定听说过MCP（Model Context Protocol）这个词。它由Anthropic在2024年底提出，并迅速成为整个AI工具链领域最热门的话题之一。但很多人对它的理解停留在"一个连接工具的协议"这个层面，没有真正搞清楚它解决了什么问题、为什么重要，以及怎么用好它。这篇文章就来把MCP拆开讲透。想象你在2023年构建一个AI Agent，需要让它能够访问数据库、调用外部API、读取文件系统。你会怎么做？大概率是这样：为每个工具写一套function calling描述，在代码里硬编码工具的调用逻辑，每次换一个LLM提供商就要重写一遍适配层。这个过程繁琐、不可复用，而且极度依赖具体的模型实现。MCP要解决的，正是这种"每次都从零开始"的困境。它的核心思路是：定义一套标准的通信协议，让AI模型和外部工具之间的交互方式统一化，就像USB-C让不同设备之间的物理连接标准化一样。## MCP的核心架构MCP采用典型的Client-Server架构，由三个角色组成：MCP Host：这是运行AI模型的宿主应用，比如Claude Desktop、Cursor、你自己构建的Agent应用。Host负责管理与多个MCP Server的连接，以及和用户的交互。MCP Client：内嵌在Host中，负责与具体的MCP Server建立一对一的连接。每个Client维护一个独立的会话状态。MCP Server：这是真正提供能力的一侧，每个Server暴露一组工具（Tools）、资源（Resources）或提示模板（Prompts）。Server可以是本地进程，也可以是远程HTTP服务。三者之间的通信使用JSON-RPC 2.0协议，支持两种传输层：- Stdio传输：Host通过标准输入输出与本地Server进程通信，适合本地工具- SSE传输：通过HTTP Server-Sent Events实现，适合远程Server这种设计的美妙之处在于：模型不需要知道工具是怎么实现的，工具也不需要知道是哪个模型在调用它。协议层完全解耦了两边。## MCP暴露的三类能力### Tools（工具）Tools是最常用的能力类型，对应的是模型可以主动调用的函数。每个Tool有名称、描述和输入参数的JSON Schema定义。json{ "name": "search_database", "description": "在用户数据库中搜索匹配的记录", "inputSchema": { "type": "object", "properties": { "query": { "type": "string", "description": "搜索关键词" }, "limit": { "type": "integer", "description": "返回结果数量上限", "default": 10 } }, "required": ["query"] }}模型通过分析用户意图，决定是否调用某个Tool，以及传入什么参数。Host负责实际执行并将结果返回给模型。### Resources（资源）Resources代表模型可以读取的数据，类似于"只读文件系统"。每个Resource有一个URI标识符，可以是文本内容或二进制数据。Resources的设计意图是让模型能够访问上下文数据，比如用户的文档、数据库记录、配置文件等，而不是执行操作。这个区分很重要：Tools是动词，Resources是名词。resource://users/profile/12345resource://documents/meeting-notes-2026-05-07### Prompts（提示模板）Prompts允许Server向Host提供预定义的提示模板，模板可以包含参数。这让Server能够将领域知识打包成可复用的交互模式。比如一个代码审查Server可以提供这样的Prompt模板：对以下{language}代码进行审查，重点关注{focus_areas}方面的问题：{code}请按照{severity}级别对问题进行分类。## 实战：构建一个MCP Server让我们来写一个真实可用的MCP Server，以Python SDK为例：pythonfrom mcp.server import Serverfrom mcp.server.stdio import stdio_serverfrom mcp.types import Tool, TextContentimport httpximport asyncio# 初始化Serverapp = Server("weather-server")@app.list_tools()async def list_tools() -> list[Tool]: """声明本Server提供的工具列表""" return [ Tool( name="get_weather", description="获取指定城市的当前天气信息", inputSchema={ "type": "object", "properties": { "city": { "type": "string", "description": "城市名称（中文或英文）" } }, "required": ["city"] } ) ]@app.call_tool()async def call_tool(name: str, arguments: dict) -> list[TextContent]: """处理工具调用""" if name == "get_weather": city = arguments.get("city", "") # 调用天气API（示例） async with httpx.AsyncClient() as client: response = await client.get( f"https://api.weather.example.com/current", params={"city": city, "lang": "zh"} ) data = response.json() result = f"""城市：{data['city']}温度：{data['temperature']}°C天气：{data['condition']}湿度：{data['humidity']}%风速：{data['wind_speed']} km/h """.strip() return [TextContent(type="text", text=result)] raise ValueError(f"Unknown tool: {name}")async def main(): async with stdio_server() as (read_stream, write_stream): await app.run( read_stream, write_stream, app.create_initialization_options() )if __name__ == "__main__": asyncio.run(main())将这个Server配置到Claude Desktop的config.json中：json{ "mcpServers": { "weather": { "command": "python", "args": ["/path/to/weather_server.py"] } }}重启Claude Desktop后，它就能自动发现并使用你的天气工具了。## MCP的生态现状截至2026年中，MCP生态已经相当成熟：官方集成：Anthropic维护了一批高质量的参考Server实现，包括Filesystem（文件操作）、GitHub（代码仓库操作）、PostgreSQL（数据库查询）、Brave Search（网络搜索）等。社区生态：GitHub上已有超过5000个公开的MCP Server实现，覆盖从Slack集成到本地代码执行的几乎所有场景。IDE集成：Cursor、Windsurf、Continue等AI代码编辑器都已支持MCP，开发者可以在IDE里直接使用MCP Server提供的能力。企业采用：越来越多的企业开始将内部工具封装为MCP Server，构建统一的AI工具层，让不同的AI应用都能访问同一套公司能力。## 与Function Calling的核心区别很多人问：MCP和OpenAI的Function Calling有什么区别？这是个好问题。Function Calling是模型级别的协议，它定义了模型如何描述和调用工具，但实际的工具执行逻辑由应用层自己处理，没有标准化。每个应用都要自己管理工具注册、权限控制、结果处理。MCP是系统级别的协议，它不仅定义了工具的描述格式，还规范了工具提供方（Server）和消费方（Client/Host）之间完整的通信流程，包括能力发现、会话管理、错误处理等。用一句话概括：Function Calling告诉你怎么描述工具，MCP告诉你怎么构建工具生态。## 安全性考量MCP的广泛采用也带来了新的安全挑战，这里有几个必须关注的点：工具调用权限：Host应该实现严格的权限控制，用户应该能够明确看到和审批AI发起的工具调用，尤其是有副作用的操作（写文件、发邮件、执行代码）。Prompt注入风险：恶意的Resource内容可能试图通过嵌入指令来操控AI的行为。要在Server侧对返回内容进行严格验证，不信任外部数据源的任何结构化指令。Server身份验证：对于远程MCP Server，必须实现适当的认证机制，防止未授权访问。OAuth 2.0是目前推荐的方案。最小权限原则：每个Server只应暴露完成其功能所必需的最小工具集，避免过度授权。## 未来展望MCP的发展方向正在向几个维度延伸：一是多步骤工作流支持，允许Server声明复杂的工具调用链，而不仅仅是单次调用。二是跨模型标准化，目前OpenAI、Google的模型也在逐步支持MCP，标准化程度越来越高。三是服务网格集成，企业级的MCP部署开始引入服务发现、负载均衡、熔断等微服务概念。对于正在构建AI应用的工程师来说，现在就开始学习和使用MCP，是一个相当值得的投入。它代表的不只是一个协议，而是AI工具集成的未来范式。