AI 系列2026-08-05 · 12 分钟

MCP 是什么：给 AI 一套标准化工具接口

工具调用解决"AI 如何做事"，MCP 解决"AI 如何用统一方式认识和连接这些工具"。读完你能分清它和 Function Calling 的关系，并知道哪些能力值得被标准化暴露。

MCP 工作流程示意图 — Host / Client / Server 三者的消息流向

难度：进阶适合：想统一接入工具/数据源的 AI 应用开发者

它解决的是"接入碎片化"

在 MCP 之前，每个 AI 客户端（Claude Desktop、VS Code 插件、自研 Agent）要连一个数据库、一个文件系统、一个 SaaS，就得各自写一套适配器。十个客户端 × 十个服务 = 一百套对接代码，参数格式、权限模型、错误约定全不统一，维护成本随规模平方上涨。

MCP（Model Context Protocol，模型上下文协议）干的事，相当于给 AI 生态做了一个"USB 接口"：服务端按统一协议暴露能力，客户端按统一协议发现与调用。一次写好 Server，所有兼容 MCP 的客户端都能直接用，不再重复造轮子。

架构：Host / Client / Server

MCP 是客户端-服务端模型，三个角色要分清：

Host（宿主）：真正跑 AI 的那个应用（如桌面客户端、IDE）。它内部管理一个或多个 Client。
Client（客户端）：Host 里的一个连接实例，负责和某个具体 Server 维持一条会话、收发消息。一个 Host 可以同时连多个 Server。
Server（服务端）：暴露能力的进程，背后连着文件、数据库或第三方 API。它只管"我能提供什么"，不关心是谁在调。

MCP 架构

Host
(AI 应用)⇄Client
(每 Server 一条)⇄MCP Server⇄文件 / 数据库 / API

Host 与 Server 不直接耦合：中间由 Client 隔离，Server 可独立部署、独立升级

传输层：stdio / SSE / Streamable HTTP

双方怎么通信，由传输层决定。本地场景常用 stdio：Server 作为子进程启动，通过标准输入输出走 JSON-RPC，零网络暴露、最安全。SSE（Server-Sent Events）用于远程 Server，服务端单向推事件、客户端用 HTTP 回发。Streamable HTTP 是后续的演进，把请求/响应与流式推送统一到一条 HTTP 通道，更适应当代云部署。选哪种取决于 Server 跑在本地还是远端。

Primitives：Tools / Resources / Prompts

MCP 把"能力"分成三类原语，这是它比"只有函数调用"更周到的地方：

原语	谁来控制	用途	举例
Tools	模型决定调用	可执行动作、有副作用	写文件、发消息、查 API
Resources	应用/用户决定读取	上下文数据、只读	日志、文档、配置片段
Prompts	用户主动选用	预设提示模板	"总结这段""生成周报"

为什么区分：Tools 是"让模型自主做的事"，Resources 是"喂给模型的资料"，Prompts 是"用户选的模板"。把控制权归属讲清，才能分别设权限——模型能自动跑只读 Resource，但不该自动跑有副作用的 Tool。

与 Function Calling 的本质区别

很多人混淆二者。一句话：Function Calling 是"模型怎么表达一次调用意图"的协议细节；MCP 是"应用怎么连上外部能力"的传输与组织标准。二者不冲突，而是分层：

维度	Function Calling	MCP
解决什么	模型如何请求调用	应用如何接入工具/数据源
耦合度	常和某家模型 API 绑定	跨模型、跨应用、解耦
范围	单次调用意图	发现、鉴权、传输、原语整套
关系	可被 MCP 的 Tool 内部使用	把 Function Calling 标准化并托管

落到工程上：MCP 让"我有一个查订单的能力"变成一个可被任何兼容客户端复用的 Server，而不再是写死在某段 prompt 里的函数声明。这正是它能降低接入成本的原因。

安全：本地信任、OAuth 与敏感边界

MCP 带来便利，也放大了攻击面，三点必须正视：

本地服务信任：stdio 模式 Server 在本机以你的权限运行，等于把一部分系统控制权交给它。只装可信来源的 Server，审查它的清单（它声明能读哪些路径、调哪些 API）。
远程鉴权用 OAuth：远端 Server 必须走标准 OAuth 拿到访问令牌，不能把凭证硬编码进配置。2025 年 MCP 规范已把远端鉴权流程标准化。
不要暴露敏感 Server：能读生产数据库、能发邮件的 Server 不应在不受信网络裸奔；最小权限、按需开放、全程留痕。

踩坑提醒：Tool 的 description 由 Server 提供，模型据此决定是否调用。恶意 Server 可用诱导性描述让模型触发危险动作（"提示注入"的延伸）。对未知来源 Server，默认把它的 Tool 设为"需人工确认"再放行。

2025 生态与落地姿势

2025 年起 MCP 迅速被主流客户端与框架接纳，官方与社区 Server 覆盖了 Git、数据库、浏览器、云存储等常见能力，"写一次 Server、到处复用"已成现实。落地建议：

从只读 Resource 起步：先暴露知识库、日志这类只读数据，跑通发现-读取链路。
Tool 逐步开放且带确认：写操作默认 HITL，别一上来就全自动。
把工具描述清楚、权限收紧、调用留痕，新的 Host 就能直接复用，无需重写适配器。

# 一个最小 MCP Server 的能力声明（示意）
server = MCPServer(name="order-db")
server.tool("query_order",  description="按订单号只读查询状态与金额",
            parameters={"order_id": str}, run=read_only_query)
server.resource("recent_logs", uri="log://recent", read=last_100_lines)

MCP 的真正价值不在"接最多工具"，而在把接入方式标准化、解耦化：Server 一次写好，所有兼容 Host 复用。想清楚哪些能力值得被标准化暴露、把权限收紧到最小、对未知来源保持确认，你就能在享受生态红利的同时，不把系统控制权轻易交出。