MCP 基础：AI Agent 如何连接世界

Model Context Protocol 是一项开放标准，让 AI 模型能够以一致的方式调用工具、读取实时数据并复用提示词模板——适用于任何提供商、任何运行时。

每个 AI Agent 最终都需要做超越生成文本的事情。它需要搜索网页、读取文件、调用 API、查询数据库。问题是：怎么做？

在 MCP 出现之前，每个团队都用不同的方式解决这个问题。一个 Agent 框架有自己的插件格式，另一个有自己的工具调用规范。更换模型或运行时往往意味着重写所有集成代码。

MCP 就是解决方案。它是一个开放协议——由 Anthropic 维护，被 OpenAI、Google 以及数十家工具厂商采用——为 AI 模型连接外部能力定义了单一标准。

三种角色：Host、Client、Server

MCP 有三个参与者：

流程始终是：Host → Client → Server → Client → Host → Model。模型从不直接与服务器通信，Client 是中间人。

这种分离非常重要。Host 可以执行安全策略（允许哪些服务器），Client 可以处理身份验证，而 Server 则专注于暴露能力。

三种原语：Tools、Resources、Prompts

每个 MCP 服务器恰好通过三种原语来暴露其能力：

模型可以调用的函数。每个工具都有一个名称、一段描述（供模型用来决定何时调用它），以及一个用于输入的 JSON Schema。例如：

search_web

run_sql_query

create_github_issue

Tools 是最常用的原语。当模型决定调用某个工具时，Client 会执行它，并将结果作为上下文返回给模型的下一步。

Host 可以附加到上下文中的静态或实时数据。Resources 通过 URI 标识（例如，

file:///path/to/file.txt

postgres://db/schema

）。与 Tools 不同，Resources 是被读取的——它们不执行代码。

由 Host（而非模型）决定包含哪些 Resources。这对安全性很重要：模型可以请求 Resources，但读取操作由 Host 批准。

可以接受参数并生成结构化消息的预构建提示词模板。用户可以显式调用它们（就像 Claude Desktop 中的斜杠命令）。例如：一个

/summarize-pr

提示词，接受一个 PR URL 并生成一个评审模板。

Tools（模型控制）、Resources（应用控制）和 Prompts（用户控制）之间的划分是有意为之的。它清晰地对应了每一项决策应该由谁来做——并使权限和信任的推理更加容易。

协议：JSON-RPC 2.0

在底层，MCP 使用 JSON-RPC 2.0——一种简单的请求/响应格式，每条消息都包含 method、params 和 id：

// Client asks server what tools are available
{ "jsonrpc": "2.0", "id": 1, "method": "tools/list", "params": {} }

// Server responds
{
  "jsonrpc": "2.0", "id": 1,
  "result": {
    "tools": [
      {
        "name": "search_web",
        "description": "Search the web for current information",
        "inputSchema": {
          "type": "object",
          "properties": { "query": { "type": "string" } },
          "required": ["query"]
        }
      }
    ]
  }
}

// Client calls the tool
{
  "jsonrpc": "2.0", "id": 2,
  "method": "tools/call",
  "params": { "name": "search_web", "arguments": { "query": "MCP protocol 2025" } }
}

JSON-RPC 2.0 还支持 notifications——一种没有 id 的单向消息，不需要响应。服务器在长时间运行的操作中使用它们来推送进度更新（例如，在搜索完成时流式传输部分结果）。

两种传输方式：本地与远程

MCP 通过两种传输机制工作：

客户端启动一个本地进程（例如 Python 或 Node.js 脚本），并通过 stdin/stdout 进行通信。所有消息都是按换行符分隔的 JSON。用于本地工具：文件系统访问、运行 shell 命令、读取本地数据库。无需网络。

客户端向远程服务器发送 HTTP POST 请求。响应可以是纯 JSON，也可以是用于流式传输的服务器发送事件（SSE）。用于远程服务器：SaaS 工具、共享团队服务器、云 API。支持无状态和有状态模式。

实践中：本地开发工具使用 STDIO，因为它更简单且不需要网络配置。生产级 Agent 系统使用 Streamable HTTP，以便多个客户端可以共享一个服务器。

发现机制是如何工作的

当客户端连接到服务器时，它做的第一件事是 初始化 —— 交换协议版本和能力：

客户端发送 initialize，附带其支持的协议版本
服务器响应其版本和能力标志（是否支持资源？提示词？流式传输？）
客户端发送 initialized 通知以完成握手
客户端调用 tools/list、resources/list、prompts/list 来发现服务器暴露了什么
宿主将工具列表注入到模型的系统提示词中，使其知道自己可以调用什么

从这里开始，模型可以在对话的任何时刻调用任何工具。客户端负责执行，并将结果作为新的上下文返回。模型看到工具结果后决定下一步做什么。

这对 FDE 为什么重要

作为前沿部署工程师，你会被要求在客户系统之上构建 AI 驱动的工作流。MCP 直接影响你处理这些工作的方式：

工具设计 —— 当你把客户的 API 暴露为 MCP 工具时，工具描述的写法决定了模型能否正确使用它们。模糊的描述会导致错误的调用。
安全边界 —— 工具可能有副作用（写入数据库、发送邮件）。你需要考虑暴露哪些工具、添加什么样的审批流程，以及如何防止模型执行破坏性操作。
传输方式选择 —— 本地 STDIO 服务器更简单，但无法共享。远程 Streamable HTTP 服务器可以扩展到团队使用，但需要考虑认证和可靠性。
调试 —— 当一个 Agent 失败时，往往是因为某个工具返回了意外的 schema，或者模型选择了错误的工具。理解 JSON-RPC 跟踪信息对调试至关重要。

MCP 也越来越多地被要求作为客户项目中的标准交付物。当客户要求你“与他们的内部工具集成”时，构建一个 MCP 服务器往往是最干净的答案 —— 它可以与 Claude、Cursor 以及任何其他兼容 MCP 的宿主配合使用，且不受供应商锁定。

核心要点

主机 / 客户端 / 服务器——三种角色，界限清晰。模型从不直接调用服务器。

工具 / 资源 / 提示——用于操作、数据和模板的三种原语。

JSON-RPC 2.0——简单、可检查的传输格式。用任何 HTTP/日志工具都易于调试。

本地用 STDIO，远程用 Streamable HTTP——根据谁需要连接来选择。

发现发生在连接时——客户端列出所有内容，主机将其注入上下文。

前沿部署工程师面试准备 | FDE 手册

摘要

要点

全文