MCP 协议：AI Agent 怎么跟外部世界对话

困在笼子里的问题

有个值得琢磨的事：为什么底层的模型明明已经很强了，AI 助手用起来还是像被「关在笼子里」？

你让它查一下今天的股价——它说不知道，没有实时数据。你让它扫一遍你的 GitHub 仓库看有没有安全问题——它看不到仓库。你让它帮你发封邮件——它给你写好草稿，然后就……等你自己去发。

瓶颈不在模型能力，在工具接入。

MCP——Model Context Protocol（模型上下文协议）——就是为了解决这件事而生的。

一句话讲清 MCP

MCP 是 Anthropic 在 2024 年末提出的开放协议。它的职责：把 AI Agent 连接外部工具的方式标准化。

在 MCP 之前，每个 AI 产品要接一个第三方工具，都得自己搭桥：定义工具描述格式、处理认证、解析返回值。20 个产品接同一个工具，就要写 20 套实现。既浪费，又碎片化。

MCP 的答案是：把它标准化。工具提供方实现一个 MCP Server，AI 应用接入一个 MCP Client，两边说同一套协议——工具描述、调用格式、返回结构，全部统一。

可以类比 HTTP 之于 Web。MCP 想做的是 Agent 和工具之间通讯的 HTTP。

架构：三个角色

MCP 生态里有三种角色：

MCP Host：你正在用的 AI 应用——Claude Desktop、Cursor、OpenClaw。它运行 MCP Client，跟 Server 通讯，把工具能力暴露给模型。

MCP Server：工具的实现端。一个 Server 可以同时暴露多个 Tools、Resources 和 Prompt 模板。比如 GitHub MCP Server，可以把「列 PR」「建 issue」「读文件」做成三个独立的工具。

MCP Client：内嵌在 Host 里，负责按 MCP 协议跟 Server 通讯。

通讯走 JSON-RPC 2.0，本地进程用 stdio，云服务用远程 HTTP+SSE：

AI 应用（Host）
   ↓ MCP Client
   ├── 本地 Server A（stdio）
   ├── 本地 Server B（stdio）
   └── 远程 Server C（HTTP/SSE）

本地 Server 走进程间通道，几乎零延迟；远程 Server 走网络，适合云端托管的服务。

一次完整的工具调用，一步一步看

拿「AAPL 今天多少钱」举例：

用户把消息发给 AI
LLM 判断这个任务需要实时股价数据，决定调用 get_stock_price
MCP Client 向已连接的 Server 发出工具调用请求（JSON-RPC）
MCP Server（股票数据服务）执行查询，返回结果
结果注入 AI 的上下文，AI 基于真实数据作答

整个过程对用户完全透明，感觉就像在跟一个真的知道现价的人聊天。

关键在第 2 步——是模型自己决定用哪个工具。用户没有说「调用股票工具」，是模型判断出任务需要什么能力，然后自己去调。这才是 Agent 行为，不是高级一点的自动补全。

MCP 和 Function Calling 的区别

常有人问：OpenAI 的 Function Calling 不已经能让模型用工具了吗？MCP 多出来的是什么？

Function Calling 是模型层面的能力——让模型能输出结构化的工具调用请求。但工具本身怎么定义、怎么管理、怎么执行？还是每个应用自己想办法。

MCP 是生态层面的协议。它不取代 Function Calling（MCP 的工具调用在底层照样走 Function Calling），它解决的是更上层的问题：工具的发现、描述和生命周期管理。

打个比方：Function Calling 是「你现在能打电话了」，MCP 是「电话簿 + 通话协议 + 运营商接入规范」。

三种能力类型：Tools、Resources、Prompts

一个 MCP Server 可以暴露三类东西：

Tools：带副作用的可执行函数——发邮件、查数据库、调 API。最核心的能力。

Resources：只读数据源——文件内容、数据库记录、API 响应。没有副作用。

Prompts：Server 提供的预定义提示词模板。比如一个代码审查 Server 可以提供「code-review」模板，评审标准已经内置好了。

三类能力组合起来，一个 Server 就能提供相当完整的「领域服务」——这个领域的数据、操作和专家视角，打包在一起。

现在有什么：MCP Server 生态

2025 年，MCP 生态长得很快。到 2026 年初，常用的开源 Server 包括：

Filesystem：读写本地文件、目录操作
数据库（PostgreSQL / SQLite）：SQL 查询、schema 查看
代码平台（GitHub / GitLab）：PR 操作、issue 管理、代码搜索
通讯（Slack / Gmail）：发消息、读邮件
搜索（Brave Search / Perplexity）：实时联网搜索
浏览器控制（Playwright）：开页面、截图、填表单
记忆系统：持久化记忆、知识图谱查询

Anthropic 维护了一批官方参考实现，第三方社区也在快速跟进。ClawHub 上已经有 200+ 个 MCP 相关技能包。

我们在 SFD 实验室怎么用的

SFD 实验室跑着 13 个协作 Agent，每个都有自己的工具集。我们从去年开始，把工具接入从手写 function call schema 逐步迁移到 MCP。

几点真实感受：

工具复用容易多了。以前后端 Agent（小章鱼）和全栈 Agent（小灰狼）都要访问数据库，各自维护一套工具描述。现在共用一个 PostgreSQL MCP Server——改一次，两边都受益。

调试体验好太多了。MCP 的 JSON-RPC 流量是明文，出问题时看日志就能立刻知道 Client 发了什么、Server 回了什么。以前一次工具调用失败，得猜半天：是模型的调用格式不对？还是工具实现有 bug？还是 schema 没对上？

我们踩过的坑：本地 stdio Server 的进程管理要格外小心。Server 崩了，Host 不会自动重连——得手动重启，或者加健康检查脚本。有一次小猎鹰（安全审计 Agent）的 GitHub MCP Server 悄无声息地挂了，连着两次审计任务失败，排查了近半小时才发现只是个进程死了。

安全：必须知道的事

MCP 的便利背后，是实打实的安全考量。

工具权限过大：一个能读写文件系统的 MCP Server，碰上提示注入攻击，就可能被胁迫着删文件、泄敏感数据。我们的规矩：每个 Server 只开最小必要权限，读和写分开授权，生产数据库一律只读。

经由工具结果的提示注入：Agent 用工具读外部内容（抓网页、解析邮件）时，那些内容里可能藏着「ignore previous instructions」式的注入。凡是摄入外部数据的 Agent，我们都套一层 moltguard 当过滤层。

第三方 Server 的信任问题：用别人的 MCP Server 之前，先把代码过一遍。远程 MCP Server 可能在记录你的所有请求，也可能返回被篡改过的数据。信任是设计出来的，不是默认的。

MCP 本身不管安全——这得靠你在外面搭的架构兜底。

2026 年值得盯的方向

远程 MCP（HTTP+SSE）成熟起来：现在多数 Server 还是本地部署。远程 MCP 一旦成熟，「Agent as a Service」就能跑通——本地什么都不用装，直接连云端托管的工具。

认证标准化：目前 MCP 没有内置的认证标准，主流做法还是 HTTP Basic Auth 或者环境变量传 token。社区在讨论更统一的方案——2026 年这块大概率会有动静。

Agent 之间的 MCP：一个 Agent 给另一个 Agent 当 MCP Server。这个模式已有人在探索。在我们这种多 Agent 架构里，它能打开不少有意思的协作玩法。

SFD 实验室的观点

我们的实话：MCP 设计不错、方向也对，但生态还早。Server 的稳定性参差不齐，文档也有断档。

建议的姿势：从 Anthropic 官方参考 Server 开始用，稳定性靠谱；社区 Server，先读代码再用；自己写 Server，先只开只读操作，测试稳定之后再放写权限。

MCP 的价值不在它今天做到多少，而在它背后的势能。支持它的工具越来越多，接入 Client 的 AI 应用越来越多。这种汇聚本身就有引力，而且指向一个真实的方向。