最近做 Agent 相关的开发，几乎绕不开一个词：MCP。GitHub 上、技术群里、招聘 JD 里，到处都在提。我自己接 AI 工具的时候也踩过"接 GitHub 写一套、接数据库写一套、接 Slack 又写一套"的胶水工程坑，所以专门把 MCP 从头研究了一遍。这篇把它的来龙去脉、核心架构、和实际怎么用讲清楚。

一、什么时候需要了解MCP？

• 给 AI 接外部工具：想让 Agent 查数据库、读文件、操作浏览器，却为每个系统各写一套接入逻辑
• 多模型切换：今天用这个模型明天用那个，工具接入代码却要跟着重写
• 企业里多个 Agent 共享工具：客服、运维、数据分析几个智能体都要调用同一批内部服务
• 面试/进阶：Agent 相关岗位面试里 MCP 已经是高频考点

核心痛点用一个词概括就是**"N×M 问题"**：N 个 AI 应用 × M 个外部工具，如果不标准化，就要写 N×M 套对接代码。MCP 想把这个矩阵压成 N+M。

二、MCP 是什么？它解决了什么问题

MCP 全称 Model Context Protocol（模型上下文协议），2024 年 11 月由 Anthropic 开源，用来让 AI 应用以统一的方式连接外部工具、数据和提示模板。

用一句话记忆：MCP 是 AI Agent 时代的"工具接入协议"，就像 USB-C 统一了不同设备的充电接口。

2025 年 12 月，Anthropic 把 MCP 捐赠给了 Linux 基金会旗下新成立的 Agentic AI Foundation（AAIF），治理交给社区主导——OpenAI、Google、Microsoft、Amazon 都作为白金会员参与。这意味着它已经不是某个厂商的私有方案，而是奔着行业基础设施去的。到 2026 年，社区构建的 MCP Server 已超过 1 万个，各家大模型平台基本都内置支持。

没有 MCP 的世界：每接一个系统，都要自己定义"工具怎么发现、参数 Schema 怎么写、调用怎么发、结果怎么返回、权限怎么控"。有了 MCP：这些全部标准化，Server 声明一次，任何支持 MCP 的 AI 应用都能连。

三、核心架构：Host、Client、Server

MCP 采用三层架构：

角色	是什么	干什么
Host	AI 应用本身	负责用户交互、模型调用、权限控制、上下文聚合
Client	Host 内部组件	和某个 Server 建立连接、协商版本、收发请求
Server	工具/数据提供方	暴露工具、资源和提示模板

一个 Host（比如一个智能客服应用）内部可以有多个 Client，每个 Client 连一个 Server（数据库 Server、工单系统 Server、日志平台 Server）。模型通过 Host 拿到所有 Server 提供的工具列表，统一调用。

三大原语（Primitives） 是理解 MCP 能力边界的关键：

• Tools（能做什么）：模型主动调用的动作，比如查数据库、发消息、搜索
• Resources（能看什么）：只读的上下文，比如文件内容、数据库 Schema、API 文档
• Prompts（怎么做更稳）：可复用的提示模板，指导模型按某个流程使用工具

很多人只把 MCP 当成"工具调用协议"，其实窄了——它标准化的还包括资源的提供和提示模板的复用。

四、一次工具调用是怎么跑的？

用一个例子串起来：用户在客服应用里问"查一下支付服务昨晚为什么变慢"，Host 已经连了监控 Server 和日志 Server。

第一步：初始化连接。Host 为每个 Server 创建 Client，做协议初始化，协商版本和能力（Server 声明自己支持 tools、resources）。

第二步：发现工具。Client 向 Server 发 tools/list，Server 返回自己的能力清单，比如 query_api_latency、search_service_logs、get_deploy_records。Host 把这些整理成模型可用的工具列表。

第三步：模型决定调用。模型看到用户问题，决定先调 query_api_latency，生成工具名和参数。

第四步：Client 调 Server。Host 通过对应 Client 发出 tools/call，Server 执行真实查询，返回结构化结果。

第五步：模型根据结果继续判断。如果发现延迟从 22:10 开始升高，模型可能接着调发布记录工具，确认 22:05 有发布，再调日志工具看详情——这就是 Agent 的 ReAct 循环，MCP 负责其中"工具接入和调用"这一段。

注意一个细节：MCP Server 通常不决定"最终怎么回答用户"。规划、判断、反思仍然由 Host 里的模型和应用逻辑负责，MCP 只管连接。

五、MCP 和 Function Calling 有什么区别？

这是最容易混淆的一组概念，面试也常问。

维度	Function Calling	MCP
定位	模型侧的能力	应用接入层的协议
解决	模型如何选择函数、生成参数	工具/资源/提示如何被 AI 应用发现和连接
架构	模型 + 函数定义	Host + Client + Server
工具发现	静态注册	Server 动态公开
多步认证	每次请求各自处理	维持会话，效率更高

一句话区分：Function Calling 是模型调用工具的一种方式，MCP 是工具接入 AI 应用的一套标准协议。 实际系统里两者是配合的——Host 通过 MCP 拿到工具列表，再转成模型支持的 Function Calling 格式让模型调用。

这层关系想清楚，就不会把两个热词混在一起了。

六、实际使用：怎么接一个 MCP Server

以 OpenAI Agents SDK 为例，接入一个 MCP Server 非常简单，把文件系统 Server 挂到 Agent 上：

from agents import Agent
from agents.mcp import MCPServerStdio

filesystem_server = MCPServerStdio(
    params={
        "command": "npx",
        "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/dir"],
    },
)

agent = Agent(
    name="Assistant",
    instructions="使用文件系统工具读取用户指定文件。",
    mcp_servers=[filesystem_server],
)

接远程 HTTP 的 MCP Server 也一样直接：

from agents import Agent, HostedMCPTool
from agents.mcp import MCPServerStreamableHttp

async with MCPServerStreamableHttp(
    name="Filesystem MCP",
    params={"url": "http://localhost:8000/mcp"},
) as server:
    agent = Agent(
        name="Assistant",
        instructions="用 MCP 工具完成用户任务。",
        mcp_servers=[server],
    )

社区里现成的 Server 覆盖面已经很广：GitHub（PR 管理、代码审查）、PostgreSQL/SQLite（数据库查询）、Slack/Notion（通信协作）、Brave Search（搜索）、Puppeteer（网页抓取）等，基本"搜一下、配一下、接上"三步就能用。

七、安全边界与注意点

MCP 让工具接入更标准，但不等于天然安全。有副作用的动作——删文件、改代码、发消息、改数据库、执行命令、调生产接口——都不能让模型"想调就调"。

几点工程上的硬要求：

1. Host 管权限：控制 Server 连接权限、上下文传递范围
2. Server 暴露最小能力：不能默认开放访问所有数据
3. 高风险工具加确认：删除、写入、发送类操作要有用户确认和审计记录
4. 认证走标准：MCP 规范建议用 OAuth 2.1，Token 要绑定到具体 Server，防止被串用

我之前接内部工单系统时就吃过教训：Server 把工具描述写得过于宽泛，模型差点把"创建工单"当成"删除工单"来用。工具描述和参数 Schema 一定要写清楚边界。

八、总结

MCP 解决的是 Agent 的连接问题——让工具、资源、提示模板以标准方式接入 AI 应用，把 N×M 的胶水工程降成 N+M。它不负责让 Agent 自动变聪明，规划、反思、可靠性仍是模型和应用逻辑的事。把它放进 Agent 工程里看，位置很清晰：Function Calling 在模型层，MCP 在接入层，Agent 在系统层，三层各司其职。随着 MCP 进入 Linux 基金会治理、生态突破一万个 Server，它大概率会成为 AI Agent 时代的"TCP/IP"级基础设施，值得现在花点时间吃透。

---

本文基于 MCP 官方规范及社区公开资料整理，涉及的 SDK 用法请以对应项目最新文档为准。