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

一个 Agent 的边界困境

你有没有想过一个问题：为什么现在的 AI 助手，哪怕模型本身能力很强，用起来还是经常被「关在笼子里」的感觉？

你让它帮你查一下今天的股价——它说不知道，因为没有实时资料。你让它看看你的 GitHub 仓库里有没有安全漏洞——它说看不到，因为没有访问权限。你让它帮你发一封邮件——它给你生成了草稿，还是得你自己去发。

模型能力不是问题，问题是工具接入。

这就是 MCP（Model Context Protocol，模型上下文协议）要解决的事。

MCP 是什么，一句话讲清

MCP 是 Anthropic 在 2024 年末提出的开放协议，解决的是 AI Agent 和外部工具之间的标准化连接问题。

以前，每个 AI 产品要接一个外部工具，都得自己造轮子：定义工具描述格式、处理认证、解析返回值。20 个产品接同一个工具，就要写 20 套代码，维护 20 套接口。既浪费，又碎片化。

MCP 的思路是：把这件事标准化。工具提供方实现一个 MCP Server，AI 应用方集成一个 MCP Client，两边按同一套协议通讯——工具描述、调用格式、返回格式，全都统一。

就像 HTTP 统一了 Web 通讯一样，MCP 想统一 Agent 和工具之间的通讯。

架构：三个角色

MCP 生态里有三个角色：

MCP Host（宿主）：就是你在用的 AI 应用，比如 Claude Desktop、Cursor、OpenClaw。它运行着 MCP Client，负责和 Server 通讯，把工具的能力暴露给模型。

MCP Server：工具的实现端。一个 MCP Server 可以暴露多个工具（Tools）、资源（Resources）和提示词模板（Prompts）。比如 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
AI（LLM）识别到这个任务需要实时股价数据，决定调用 get_stock_price 工具
MCP Client 向已连接的 Server 发出工具调用请求（JSON-RPC）
MCP Server（股票数据服务）执行查询，返回结果
结果注入 AI 的上下文，AI 基于真实数据给出回答

整个过程对用户透明，就像跟一个真的知道实时股价的人在聊天。

关键点在第 2 步——模型是自主决定用哪个工具的。不是用户说「用工具查一下」，而是模型自己判断任务需要什么能力，然后去调用。这才是 Agent 行为，而不是普通的 function calling。

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 可以提供预定义的提示词模板，让 AI 应用复用专业化的提问方式。比如代码审查 Server 提供「code-review」模板，里面已经包含了审查要求。

这三类能力组合起来，一个 MCP Server 就能提供相当完整的「专业域服务」。

实际生态：已经有哪些 MCP Server

2025 年，MCP 生态扩张很快。截至 2026 年初，常用的开源 MCP Server 包括：

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

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

我们在 SFD 实验室的实践

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

几个实际感受：

工具复用变容易了。以前小章鱼（后端 Agent）和小灰狼（全栈 Agent）都需要访问数据库，得各自维护一套工具描述。现在共用一个 PostgreSQL MCP Server，两边都能用，更新一次全部生效。

调试比以前好做。MCP 的 JSON-RPC 通讯是明文的，出问题时直接看日志就知道 Client 发了什么、Server 返回了什么。以前工具调用失败了，很难定位是模型没调对还是工具实现有 bug。

踩过的坑：本地 stdio Server 在进程管理上要小心。Server 异常退出后，Host 不会自动重连，需要手动重启或者加健康检查脚本。我们有一次小猎鹰（安全审计 Agent）的 GitHub MCP Server 静默死掉了，连续两次审计任务都失败，排查了近半小时才发现是 Server 进程挂了。

安全边界：必须知道的风险

MCP 带来便利的同时，安全风险也是真实的。

工具权限过大：一个能读写文件系统的 MCP Server，如果 Agent 被注入了恶意指令，可能被诱导删除文件或泄露敏感数据。我们的原则是：每个 Server 只开放最小权限，读和写分开，正式数据库只给只读权限。

提示注入攻击：如果 Agent 的工具能读取外部内容（比如爬虫），外部内容里可能藏着「ignore previous instructions」之类的注入。我们在抓取外部数据的 Agent 上都套了一层 moltguard 做过滤。

Server 可信度：用第三方 MCP Server 时，要审查它的代码。你不知道一个远程 MCP Server 的服务端在干什么——它可能在记录你的所有请求，或者返回被篡改的数据。

安全这件事，MCP 本身不管，靠的是使用者的设计规范。

2026 年值得关注的方向

远程 MCP（HTTP+SSE）的成熟：目前大多数 MCP Server 还是本地执行的，远程 Server 的生态刚起步。一旦远程 MCP 成熟，「Agent 即服务」的模式就能跑通——你不需要在本地部署任何 Server，直接连云服务。

MCP 的安全标准化：现在 MCP 没有内置的认证标准，靠的是 HTTP Basic Auth 或者环境变量传 token。社区在讨论更统一的方案，这块 2026 年可能有进展。

Agent 间的 MCP：一个 Agent 作为另一个 Agent 的 MCP Server——这个模式正在被探索。在我们的多 Agent 协作里，这有很大的想象空间。

SFD 编者注

我们的实际体会是：MCP 是一个方向正确、规范合理的协议，但生态还在早期。真正用起来，你会发现不少 Server 的稳定性参差不齐，文档也不够完整。

建议的姿态是：先从 Anthropic 官方的参考 Server 开始用，稳定性有保障；社区 Server 用之前先看代码；自己写 Server 时，先只暴露只读操作，等测试稳定后再开放写操作。

MCP 的价值不在于它现在有多完善，而在于它是一个大家都在往里投入的标准。越来越多的工具在支持它，这件事本身就有价值。