近几年，大模型的发展速度实在太快了。从最初单纯依赖 Prompt 的阶段，到后来兴起的 AI Agent，再到如今的 MCP（Model Context Protocol），每一次演进都在重塑人们与模型交互的方式。AI Agent 还在半年前是人人讨论的热门话题，如今却随着 MCP 的出现，逐渐淡出了视野。

为了跟上时代的脚步，我决定深入学习 MCP，通过本篇记录下自己的理解过程，并思考它在安全性与安全应用场景上可能带来的新变化。

Prompt，Agent，MCP都是什么

Prompt

2023 年，OpenAI 发布了 ChatGPT。当时的 AI 主要以聊天框的形式存在，我们输入的消息被称为 User Prompt，即用户提示词，通常是我们提出的问题或指令。

实际上，通过不同的提示词，用户可以在一定程度上塑造AI 的性格。例如：

- 当你说：“帮我修改我的论文。”

AI 会以助理的口吻给出中立的建议；

- 而如果你说：“假设你是我的导师，请帮我修改论文。”

它的语气可能会更加犀利、批判性更强（bushi）。

在这种情况下，AI 的“性格”信息其实混在了 User Prompt 中。但在更标准的设计中，这类信息应当放在 System Prompt 中，它通常包含模型的角色、语气、背景信息等。每次我们发送 User Prompt 时，系统都会连同 System Prompt 一起发送。

在 ChatGPT 的 GPTs 功能中也有类似机制。它会根据对话自动生成该自定义模型的性格与背景设定，当然也可以由用户自行配置，例如偏好、语气风格等：

然而，从根本上看，Prompt 仍然只是“对话”层面的交互。AI 可以提供建议与引导，但具体执行任务的仍然是人类。那么，是否有办法让 AI 能够 自主执行任务 呢？这便引出了 AI Agent 的概念。

顺带一提，我之前也系统学习并在实习中应用过一些 Prompt Engineering 的内容，感兴趣的师傅可以参考我之前的博客文章：《大模型提示词 — Prompt Engineering》。

AI Agent

在传统的 Prompt 阶段，AI 就像一个顾问，只能通过语言给出建议，却无法真正“动手”。而在 Agent 出现后，AI 拥有了一套可以使用外部工具的体系。

可以这样理解：

系统提供了一整套 “工具箱”（Toolbox），里面有各种功能接口，比如浏览网页、执行代码、查询数据库、发送邮件等。
而 AI Agent 就像是一个懂得使用工具的助手。它不仅知道有哪些工具，还知道什么时候、怎么使用它们。
当我们给 AI 一个目标，比如“帮我查一下今天悉尼的天气并发邮件告诉我”，AI 并不是自己去“幻想”结果，而是会指挥 Agent 去调用“天气查询工具”和“邮件发送工具”，完成整套任务流程。

示意图：

换句话说，Prompt 告诉 AI 要做什么，而 Agent 让 AI 真的能去做。

在 Agent 的运行机制中，每个工具通常会被定义成一个标准化的结构。系统会维护一个工具描述库（Tool Registry），其中包含每个工具的名称、功能描述以及参数类型等元信息。

例如，一个用于发送邮件的工具可能会被定义为：

{
  "name": "email_someone",
  "description": "Send an email to someone",
  "parameters": {
    "address": "str",
    "name": "str"
  }
}

AI Agent 的出现让模型具备了行动能力，但随着使用场景的增多，也暴露出一些问题。每个框架（如 LangChain、AutoGPT、CrewAI 等）都有自己的一套工具定义方式、调用规范和上下文管理逻辑。这种缺乏标准化的实现，导致了几个痛点：

工具复用困难：同一个功能（例如“浏览网页”或“执行代码”），在不同框架中需要重复封装。
上下文孤立：模型在不同环境间切换（例如从 Web 环境到 IDE 插件）时，无法共享上下文信息。
安全性问题：Agent 调用外部接口时往往缺乏统一的权限约束和通信协议，容易引发数据泄露或越权访问。

于是，MCP（Model Context Protocol） 应运而生。它由 OpenAI 在 2024 年11月提出，目标是为模型与外部环境之间的交互建立一套统一的通信协议层，让任何模型都能以一致的方式访问外部资源、上下文和工具。

MCP（Model Context Protocol）

可以简单地把 MCP 理解为——让模型与世界交流的语言标准。

在前面我们提到的 Agent 体系中，每个 Agent 都需要自己维护一套工具定义（Tool Schema），而不同框架之间的定义方式往往不兼容。MCP 的出现正是为了解决这种工具复用与通信标准化的问题。

为了提升工具的复用性与可扩展性，MCP 将 Agent 中的 Tool 抽象为独立的服务模块，并通过统一的协议进行管理与调用。

换句话说，MCP 不再让每个 Agent 自己储备工具，而是通过一个中心化的“工具服务层”进行托管，任何 Agent 都可以通过协议访问这些工具。

在 MCP 的架构中：

- 运行具体工具的服务被称为 MCP Server；

- 负责调用这些服务的 Agent 被称为 MCP Client；

- 而 MCP 协议（Protocol）则定义了两者之间的通信规范，以及 MCP Server 必须提供的接口形式。

通过这种方式，MCP 实现了模型调用与工具管理的解耦：

MCP 只负责定义通信与资源管理规则，而不关心 Agent 使用的是哪种模型（GPT、Claude、Gemini 都可以）。

因此，MCP 实际上与 AI 模型本身并没有直接关系。它更像是一个底层的协调与通信协议**，用于帮助 Agent 统一管理：可调用的工具（Tools）、可访问的资源（Resources）、以及相关的提示词与上下文（Prompts & Contexts）

为什么选择MCP

无论模型多么强大，它的能力都受到上下文的限制。即便是最先进的大语言模型，如果无法访问外部数据、实时资源或工具接口，它的推理与执行能力都会被封锁在一个“封闭沙盒”中。MCP（Model Context Protocol）正是为了解决这一问题而提出的。它提供了一种标准化的方式，让模型能够在安全、可扩展的前提下访问工具、资源和提示词，实现与真实世界的连接。

上下文与工具接入为何关键

在技术实现上，MCP 采用了 Client–Server 架构。运行工具与资源的一方被称为 MCP Server，而发起任务与请求的 AI Agent 则是 MCP Client。两者之间通过协议通信，MCP 规定了通信内容、调用格式、能力声明和响应结构。这样的设计让模型端与工具端实现了解耦：模型不再直接绑定某个函数或接口，而是通过协议调用统一管理的工具服务。

这种模式的好处在于，Agent 端专注于任务规划与上下文管理，而 Server 端则负责具体工具的执行与权限控制。MCP Server 可以托管各种服务，比如网页抓取、数据库查询、代码执行、邮件发送等。MCP Client 只需要声明自己具备哪些能力（Capabilities），并在运行时通过协议调用相应的工具。由于通信格式是标准化的，任意一个 MCP 兼容的工具服务都可以被不同模型和 Agent 共享，这使得系统具备极强的复用性与模块化扩展能力。

flowchart LR
    A[AI Agent / MCP Client] -->|Send Request| B[MCP Protocol Layer]
    B -->|Invoke Tool| C[MCP Server]
    C --> D[Tools & Resources]
    D -->|Return Result| C
    C -->|Response| B
    B -->|Send Result| A

工具与资源的标准化

在传统的 Agent 框架中，每个系统往往独立定义自己的工具接口、参数格式和调用方式，结果是不同项目之间无法直接复用工具。MCP 通过统一协议层的定义，解决了这一碎片化问题。所有工具、资源和提示词都以标准 JSON 结构暴露给 MCP Client，工具描述中包含名称、功能说明、输入参数与类型约束。Agent 在使用工具时，不再需要关注实现细节，只需根据协议调用即可。

这种标准化不仅简化了开发流程，也让工具生态具备了通用性。一个工具一旦注册到 MCP Server，就能被任意兼容客户端使用，而无需额外的适配。开发者可以像部署 API 一样部署 MCP 工具服务，模型则像调用 API 一样调用它们。这种“模型即客户端，工具即服务”的思路，让大模型系统更接近微服务化架构。

{
  "tool": {
    "name": "query_database",
    "description": "Execute a SQL query and return results",
    "parameters": {
      "query": "string",
      "limit": "integer"
    }
  }
}

上述结构展示了 MCP 对工具的标准定义方式。通过描述工具名、功能说明与参数类型，任意模型都可以在不关心底层实现的前提下完成调用。

安全性与可扩展性

当模型具备了调用外部接口、访问数据库或执行命令的能力后，安全问题就成为首要考虑。MCP 在协议层设计中引入了能力声明机制。Client 需要在会话开始时声明它希望使用的能力（Capabilities），而 Server 端会根据配置授予或拒绝访问权限。同时，MCP 通过调用日志对调用过程进行结构化记录，便于后续审计与追踪。这种机制相当于给模型的“外部访问”增加了一层安全网，使得工具调用可控、透明且可监管。

此外，MCP 的可扩展性也体现在它的标准化接口设计上。协议本身与模型类型无关，任何 LLM 或 Agent 框架只要实现了 MCP Client，就能与 MCP Server 交互。这意味着同一个工具库可以同时为不同厂商或不同版本的模型提供支持，从而大幅降低生态碎片化的成本。随着 MCP 的推广，未来模型间的协作与工具共享将变得更加自然与高效。

机制	技术作用	实现层面
Capability 声明	控制模型能访问的资源范围	协议会话初始化阶段
调用日志（Audit Log）	记录工具调用与响应信息	MCP Server 层
标准化接口	提供跨模型复用能力	协议定义层

简而言之，MCP 让模型具备了“连接外部世界”的基础能力。它通过标准化协议和解耦架构，使模型调用工具的过程更加通用、安全、可扩展。这也是构建下一代富上下文 AI 应用的关键技术基础。

其实看到AI大模型这么迅猛的发展，我的身边和网络上时常会看到很多人十分焦虑，说担心自己哪一天会不会就被AI给取代了。但对我来说，这种变化更多带来的是兴奋与期待。大模型的进步让我对未来社会的发展充满好奇，也让我更加确信：技术并不是来夺走人的价值，而是推动人类走向新的可能。我觉得与其去担心自己的能力会被新的技术所取代，不如主动去了解、学习这些技术，选择让自己融入时代的浪潮，而不是去抗拒他们。我一直都觉得AI根本不是威胁，而是帮助我们，让我们变得更强大的助手和伙伴。