🤖Agent进化论：从Copilot到主驾驶，MCP如何成为AI的"万能接口"？

写在开头

Hey Juejin.cn community! 😀

今是2025年05月16日，天降甘霖。。。

续集续集，今天已经是2025年05月31日，上半年的最后一天了，也是端午佳节了，朋友们吃粽子了没？ 😋 反正小编是吃上了。

这么快又过去了半个月，本来小编在半个月前就开始写这篇文章，中间因为公司业务比较繁忙就停掉了，如今终于有时间给续上了，GoGo!

那么，本章的主旨就是带大家深入剖析 AI Agent 与 MCP 之间的 "爱恨情仇" 😜，这也算是小编这段时间学习MCP的一些总结，请诸君按需食用哈。

发展背景🚀

起个头，咱们先来简单叨叨一下AI的发展历史🔉，它的历程就像打怪升级，从最初只能简单对话的Chatbot（聊天机器人），到能辅助我们查问题、写文章、写代码的Copilot（小编用AI最常干的三件事），再到如今能自主感知和行动的 AI Agent，如规划旅游、管理日程等等（自行完成部分需求的代码开发，嘿嘿）。

AI在人们日常中扮演的角色越来越重要，也越来越深入。但是呢，小编也注意到一个核心问题：这些聪明的 AI Agent 要想真正大显身手，解决咱们现实生活中的复杂问题，光靠 "脑子" 里的知识和算法可不够。它们必须能够安全、高效地与这个纷繁复杂、瞬息万变的外部世界进行 "亲密接触" ------比如，获取最新的航班信息、操作你的本地文件、调用公司内部的数据库、或者控制某个智能家居设备等等。🤔

这就对 AI Agent 的能力提出了更高的要求，总得来说，它不仅要 "聪明"，还要 "能干"；透过本质来看并以技术员角度观测，它就需要有丰富的上下文信息 和强大的工具集来支撑。🧐

而今天咱们要讲的核心 "猪脚" ------ Model Context Protocol (MCP) ！便在其中扮演不可或缺的角色。

名词小词典 🔑

• AI Agent (人工智能体) 🧠：可不是只会聊天的机器人哦！它是一种能够理解用户目标，感知周边环境（上下文信息、知识库），自主进行规划和决策，并且能够实际执行动作的智能系统。更厉害的是，它还会 "借用" 各种工具（比如API、MCP、DB等）来完成那些超出自身能力范围的复杂任务。

• Copilot (智能副驾) 🧑‍✈️：这个概念大家可能更熟悉一些，比如 GitHub Copilot（最早小编还充了钱，但现在基本已经不用了...）。它更侧重于在特定的应用场景下，像个 "副驾驶" 一样辅助人类用户，提供建议、自动完成、智能提示（就是编辑器那套过程）等。可以把它看作是 AI Agent 在某些领域的一种具体表现形态。

• MCP (模型上下文协议) 🔗：全称 Model Context Protocol。这是一种开放的、标准化的协议，就像是为 AI 应用量身定制的 "USB-C" 接口。它的核心目标是统一 AI 模型（尤其是 LLM 和 Agent）与外部世界（各种数据源、工具、服务）进行连接和通信的方式，让集成变得更简单、更通用。

• 工具 (Tool) 🛠️：指的是 AI Agent 或 AI 应用通过 MCP 协议可以调用和使用的具体外部能力。这些能力五花八门，比如查询实时天气、操作本地文件系统、操作公司的数据库、调用某个特定的API接口等等。

• 工具提供方 (Tool Provider) 👨‍💻：这些人或组织是 "工具" 的创造者和维护者。他们通过开发和部署 MCP Server，将自己拥有的数据资源或服务能力，按照 MCP 的标准封装成一个个可供 AI 应用调用的 "工具"。

• 应用研发者 (Application Developer) 👩‍💻：他们是构建各种炫酷 AI 应用或 AI Agent 的工程师。通过在自己的应用中集成 MCP Client，他们就能让应用具备连接和使用由不同 "工具提供方" 提供的各种 MCP 工具的能力，从而极大地扩展应用的功能边界。

小编读了很多AI相关的文章，文中总是时常会出现 "工具提供方" 与 "应用研发者" 这两个词汇，一开始属实是有点儿懵逼。😵

• AI 应用 (AI Application) 📱：这是一个广义的概念，泛指所有利用人工智能技术（特别是大型语言模型LLM和Agent技术）来提供特定功能或解决特定问题的软件程序。比如我们常见的智能客服系统、自动化的业务流程工具、AI 驱动的内容创作软件、智能剪辑与抠图等等，都可以归为此类。

就这些吧，更多的期待你能在评论区中补充，到时小编把它们进行汇总。😋

AI Agent的PPA决策流程🧠

相信各位小伙伴都多多少少有体会过 Agent 的神奇之处了，这里不细嗦它的前世今生。🙊

但是呢，小编希望你能够了解一下它的PPA流程，这有助于你能更透彻的看待 Agent 到底是个什么东东，这很重要❗

Agent（代理）是指能够自主感知环境并通过采取行动实现目标的智能体。简单来说，AI 可作为个人或组织的代表，执行特定行为，以此降低其工作复杂度，减少工作量并降低沟通成本。

当前，开源的 Agent 应用呈现出百花齐放的发展态势，找了张图：

图片来源：传送门。

那么，一个 Agent 到底是如何工作的呢？它可不是简单地接收一个问题，然后给一个答案。一个典型的 Agent 通常遵循着一个被称为 PPA (感知-规划-行动) 的决策流程：

• P（感知 Perception）👀：这是 Agent 与世界互动的第一步。它需要理解用户的指令，比如你对它说 "帮我订一张明天去北京的机票"（唉，小编一直想再去北京看看...）。同时，它也需要感知外部环境的信息，这些信息可能来自上下文信息或者它自身的知识库，也可能需要通过调用 "工具" 从外部获取，比如查询当前的航班信息、天气状况，或者你的日程安排等等。

• P（规划 Planning）🗺️：在理解了目标和感知到足够的信息后，Agent 就开始进行 "头脑风暴" 了,它会将用户的复杂任务（比如"订机票"）拆解成一系列更小、可执行的步骤。例如，它可能会规划出这样的步骤：

  1. 确认出发城市和日期。
  2. 查询明天从A市到上海的航班。
  3. 筛选符合时间要求的航班。
  4. 询问用户选择哪个航班。
  5. 获取乘机人信息。
  6. 调用订票API完成预订。
  7. 将订票结果反馈给用户。

  在这个规划过程中，Agent 会判断哪些步骤需要借助外部 "工具" 来完成，比如第2步需要 "航班查询工具"，第6步需要 "机票预订工具"。

• A（行动 Action）💪：规划完毕，就该撸起袖子干活了！Agent 会按照规划好的步骤逐一执行。这可能包括内部的逻辑处理，更重要的是，调用预先选定的 "工具" 与外部世界进行交互。例如，它会通过MCP Client向封装了航班查询API的MCP Server发送请求，获取航班数据。当工具执行完毕并返回结果后，Agent 会将这些结果作为新的 "感知" 信息，融入到后续的决策或反馈中，最终完成任务并告知用户结果。

⏰这里需要特别注意，整个PPA流程不是一次性完成的，它会不断循环往复，以此来完成最终的目标❗

这个 PPA 流程清晰地展示了 AI Agent 从理解用户意图到最终完成任务的完整闭环。而在这个闭环中，能够调用和利用外部工具的能力，正是 Agent 实现从 "能聊" 到 "能干" 的关键所在。没有工具，Agent 就如同被困在象牙塔里的智者，空有智慧却无法施展。而 MCP 的出现，正是为了给 Agent 配备上连接现实世界的 "传感器" 和 "执行器"（就好像让Agent变成硬件一般），让它真正能够 "大展拳脚"！

现状AI Agent面临的痛点💡

在深入了解MCP如何工作之前，咱们先来回顾一下在MCP出现之前，AI Agent开发面临的一些实际挑战，这也是MCP出现的背景和必要性。

如今，AI Agent 与各类外部服务（Tools）、存储（Memory）及大语言模型（LLMs）的交互，基本都靠 HTTP 协议撑场子。虽说 LLMs 的接口正慢慢向 OpenAI 范式（Function Call） "看齐"，但跟其他 Tools 和 Memory 打交道时，那交互方式简直像 "各唱各的调"------ 开发者得挨个研究它们的接口规范和返回格式，再吭哧吭哧做解析适配，开发复杂度直接 "原地起飞"。

咱们想象一下，当一个AI应用需要集成多个Agent，或者与众多业务服务和存储服务打交道时，开发工作量会显著增加。其中最让人头疼的两个问题就是：

1. 寻找合适的接口：无论是寻找外部三方服务接口，还是在公司内部寻找现有服务接口，都需要花费大量时间和精力。如果找不到现成的，还得自己动手开发新的接口。🛠️

2. 解析接口返回格式：不同的服务接口返回的数据格式千差万别，可能是JSON、XML、Protobuf，甚至是自定义格式。Agent需要针对每种格式编写解析代码，这不仅繁琐，而且容易出错。🐛

先说答案🔉，这两点最终都交由大模型来完成。

如果你拥有一定的求知欲或好奇心，小编能猜到你的下一个问题："大模型咋做到的"？🙊，那么答案呢？它当然是本章的 "猪脚" 担当 ------ MCP！

这些痛点导致许多AI应用只能包含少数几个Agent，甚至只有一个，限制了AI Agent向更高级阶段（Platform-Level Agents, Universal Agents）发展。

而MCP的出现，就像一道曙光，为解决这些核心问题带来了希望！🔅

当下网上大部分关于 MCP 的讨论大多聚焦于其优势层面，但看待事物需秉持辩证思维。小编之前看过一篇以批判的视角来看待MCP的，大家也可以自行瞅瞅，毕竟，唯有全面认知事物的正反两面，才能在技术浪潮中保持理性判断：传送门

什么是MCP？🤔

MCP（Model Context Protocol）是由Anthropic开发的开源协议，旨在为LLM提供一种标准化的方式，以便它们能够连接到外部数据源和工具。

小编之前读过一篇文章，里面对 MCP 的定义是这样的："MCP 的本质仍然是提示词工程（Prompt Engineering）"。小编个人觉得这个概况还挺贴切的，你说呢？😉

在MCP范式中，主要涉及三个核心角色之间的协同工作 🧑‍🤝‍🧑：

• MCP Client：通常是AI Agent或与LLM交互的应用层。它负责向LLM发起请求，并将LLM返回的工具调用指令转发给相应的MCP Server，最后接收MCP Server的执行结果。

• LLM：大语言模型。它接收MCP Client发送的用户问题和可用的MCP Server/Tool信息，经过推理，理解用户意图，并决定需要调用哪个MCP Server上的哪个MCP Tool来完成任务，然后将工具调用指令返回给MCP Client。

• MCP Server：基于MCP SDK开发的程序或服务。它将现有的功能或服务封装成符合MCP规范的Tool，接收MCP Client发来的工具调用请求，执行实际的任务，并将结果返回给MCP Client。

经典图少不了😋：

MCP的核心概念包括 🔑：

• Resources (资源)：提供结构化或非结构化数据，如文件内容、数据库查询结果等。

• Prompts (提示词)：预定义的、可复用的提示模板，用于指导LLM的行为。

• Tools (工具)：执行特定操作的功能，如调用API、执行代码、访问文件系统等。

核心架构与通信机制 🏗️：

• Client-Server 架构：正如前面角色定义中提到的，MCP 的核心是一个清晰的客户端-服务器交互模型。AI 应用 (Host)调控的 MCP Client 主动向 MCP Server 发起请求，Server 处理请求并返回响应。

• JSON-RPC 2.0：MCP 选择了 JSON-RPC 2.0 作为其主要的通信协议格式。JSON-RPC 是一种轻量级的远程过程调用 (RPC) 协议，使用 JSON 作为数据格式，易于实现和解析。

• 传输方式：MCP 支持多种传输方式，以适应不同的部署场景：

  • STDIO (标准输入/输出) ：主要用于本地通信场景。例如，一个桌面AI应用 (Host) 可以通过标准输入/输出管道与其在同一台机器上运行的本地 MCP Server 进行通信。这种方式简单直接，适合快速开发和测试。

  • HTTP + SSE (Server-Sent Events) ：主要用于远程通信场景。MCP Server 可以通过 HTTP 暴露服务，并利用 SSE 实现服务器向客户端的单向实时消息推送。这使得 Host 应用可以与部署在远程服务器上的 MCP Server 进行交互，并能接收到异步的更新或通知。

这块可能比较难以理解，小编让deepseek给了一个简单案例，可以凑合着看看：

MCP运行原理分析⚙️

先整张图：

一图胜千言，这是MCP在小编脑中的运行过程，如果你看懂了，就可以直接跳过下面的步骤解析。

MCP通过引入标准化的协议和机制，极大地简化了Agent与外部能力的交互过程，它的整个运行原理可以这样理解：

• 用户请求🙋‍♀️：用户向AI应用发起对话。

• Agent接收请求🧠：AI Agent接收到用户问题。

• Agent获取MCP信息🔍：AI Agent不再需要自己去"寻找接口"。Agent可以从一个统一的入口（例如MCP网关或注册中心）获取到当前可用的MCP Server及其提供的MCP Tool、Resource和Prompt的标准化信息（包括它们的名称、功能描述、参数和返回值的Schema等）。这就像Agent拿到了一份详细的"工具清单"和"使用说明书"。📄

• Agent发送信息给LLM📲：AI Agent将用户问题和这份标准化的MCP能力清单一起发送给LLM。

• LLM推理与决策💖：LLM分析用户问题和可用的MCP能力信息。由于MCP提供了标准化的描述（Schema），LLM能够更准确地理解每个Tool的功能和如何使用。LLM经过推理，决定需要调用哪个Tool来完成任务，并生成符合MCP规范的Tool调用指令（包含Tool名称和参数）。🎯

• Agent调用MCP Tool🔌：AI Agent接收到LLM返回的Tool调用指令后，根据指令中的信息，通过标准化的MCP协议和传输层（如Stdio或HTTP），向对应的MCP Server发起Tool调用请求，并传递参数。Agent无需关心底层服务的具体实现细节和返回格式，因为这一切都由MCP协议进行了抽象和标准化。

• MCP Server执行任务⚙️：MCP Server接收到Tool调用请求，执行对应的功能。

• MCP Server返回结果📤：MCP Server将任务执行结果封装成符合MCP规范的标准化内容块（Content Blocks）返回给AI Agent。Agent可以轻松解析这些标准化格式的结果，无需为每种服务编写特定的解析代码。

• Agent处理结果并响应用户✅：AI Agent接收到MCP Server返回的结果，进行后续处理，最后将最终结果呈现给用户。

通过这个流程，MCP成功地解决了"寻找合适的接口 "和"解析接口返回格式"这两大难题，让Agent可以更高效、更灵活地调用各种外部能力，为构建更复杂、更智能的Platform-Level Agents甚至Universal Agents铺平了道路！🚀

基础MCP开发⏰

理论铺垫了这么多，是不是已经按捺不住想亲身体验 MCP 的实战魅力了？😜（如果没有，当我没说~）

由于小编是前端出身，开发环节就以 Node 技术为例展开讲解啦。目前主流的 MCP 开发语言包括 Node、Python、Java等等，都大差不多哈。

环境准备

首先，确保你的电脑上已经安装了 Node（建议 v20 或更高版本），然后创建一个新的项目目录，并初始化：

npm init -y

安装 MCP SDK

npm install @modelcontextprotocol/sdk

@modelcontextprotocol/sdk 是 Model Context Protocol (MCP) 的官方 TypeScript 实现，它是一个用于构建 MCP 服务器和客户端的工具包，能帮你快速完成MCP的开发工作。

创建基础MCP服务器

咱们来创建一个最简单的 MCP 服务器，这个服务器仅提供一个获取当前时间的工具。

创建 index.js 文件：

#!/usr/bin/env node
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

const server = new McpServer({
  name: "mcp-server-time",
  version: "1.0.0",
});

// 添加工具
server.tool(
  "get_current_time", 
  "获取当前时间", 
  {}, 
  () => ({
    content: [
      { type: "text", text: JSON.stringify({ time: new Date() }, null, 2) },
    ],
  })
);

async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
}

main();

这段代码非常简单吧？😉它只包含一个简单的工具，接下来，咱们来看看如何测试这个服务器。

测试 MCP 服务器

要快速测试咱们编写的 MCP 服务器，可以使用 @modelcontextprotocol/inspector 包。

这个工具是 Model Context Protocol 生态系统中的重要组件，专门用于 MCP 服务器的开发、调试和测试。它提供了直观的 Web 界面，让开发者可以方便地与 MCP 服务器交互，检查服务器状态，测试已注册的工具，而不需要编写额外的客户端代码。😎

使用 npm 包执行工具 npx（这个东东都知道吧？即用即走），可以直接运行 @modelcontextprotocol/inspector 包而无需全局安装：

npx @modelcontextprotocol/inspector node ./index.js

执行上述命令后，会启动一个本地 Web 服务器，并将你的 MCP 服务器作为子进程运行。

（不用管小编的python环境问题。。。。。。）

然后你可以通过浏览器访问 http://127.0.0.1:6274 ，你就能看到如下的图形界面：

点击 Connect 按钮，就连接上咱们的MCP服务：

再点击 Tools 下的 List Tools 按钮，就可以获取咱们 MCP 服务的工具列表。

在工具列表中，可以选择你想要执行的工具，点击 Run Tool 按钮就能执行该工具，获取工具的结果：

通过 inspector，你可以轻松测试服务器功能，并直观地查看工具执行结果。这大大简化了 MCP 服务器的开发流程，让你可以专注于实现核心功能。你可以继续在代码中添加更多工具，每个工具对应不同的功能，然后继续通过 inspector 测试它们，多耍耍才熟悉。😋

虽然，通过 @modelcontextprotocol/inspector 包可以调试咱们的MCP服务，但在实际应用中，MCP 服务通常是由各种 AI Agent 来调用的，而咱们本地开发的 MCP 服务要如何来通过 Agent 调用呢❓

接下来介绍一下如何在 Trae 编辑器中配置并使用我们开发的 MCP 服务。

首先，进入 Trae 编辑器的 MCP 配置页面，操作步骤如下：

其次，添加自定义 MCP 服务，在弹出的配置框中粘贴以下 JSON 配置：

{
  "mcpServers": {
    "my-mcp-server": {
      "command": "node",
      "args": [
        "A:\\knowledge\\MCP\\base\\index.js"
      ]
    }
  }
}

注意 ：需要将 A:\knowledge\MCP\base\index.js 替换为你本地 index.js 文件的实际路径。Windows 系统使用双反斜杠 \ 作为路径分隔符，Mac 系统使用正斜杠 /。

配置完成后，点击确认保存设置。Trae 会自动启动并连接你的 MCP 服务，成功连接后，你将看到类似下图的状态：
配置失败可能是这样子的：

自行检查一下配置是否正常，特别是路径是否正确，或者是 Node 环境是否正常等等。

配置成功后，咱们就可以在 Trae 的 Agent 中通过自然语言对话来调用 MCP 服务了：

通过这种方式，你可以将自己开发的 MCP 服务无缝集成到 Trae 工作流中，让 AI Agent 具备更强大的功能。

MCP的未来展望 ✨

小编当下的个人感觉是 MCP 可能将作为连接 AI 智能与物理现实的关键桥梁，其未来发展充满了想象空间，如：

• 更丰富的工具生态 ：随着越来越多的开发者、组织、企业的加入，MCP Server 的数量和种类将持续增加，覆盖更多行业和场景，形成一个庞大而活跃的开放工具市场。愿景是美好的，即便现在看起来也已经非常多了，但小编感觉在一些特定场景的MCP还是比较少，当下的增长速度也渐渐缓慢下来了🤔。传送门1、传送门2、传送门3

• 多模态工具支持：当前 MCP 主要关注基于文本和结构化数据的交互，未来可能会扩展到支持更复杂的多模态工具，如图像生成与编辑、语音识别与合成、视频分析与操作等。🌇

• 更完善的安全与治理机制：任何时候数据安全都是第一要素，随着应用的深入，对 MCP 的安全性、隐私保护、合规性、可审计性等方面的要求会越来越高，相关的规范、工具和最佳实践会持续演进。🚫

• 智能化与自适应的工具调用：AI Agent 可能会进化出更强的能力，能够更智能地发现、理解、组合和适应 MCP 工具，甚至在没有明确指令的情况下主动探索和利用新工具。👀

• 标准化的进一步深化：MCP 可能会与其他相关AI标准（如Agent间的通信协议、数据交换格式等）进一步融合，共同构建一个更加开放和互联的AI基础设施。👏

毫无疑问，MCP 的出现和发展，将深刻改变 AI 应用的开发范式和使用体验，推动 AI 技术更快地从实验室走向千家万户、千行百业。

总结🎉

好啦，总算到结尾了，这篇文章小编写得挺久的，参考非常多的资料，自己文笔也有点差，一改再改，耗费了大量时间。😅

那么呢，要总结点啥好呢？要不......你们自己来？😉😉😉

总得来说，文章核心是讲解了一下 AI Agent 与 MCP 的 "前世与今生"，但更多的是关注于 MCP 技术本身。AI Agent 凭借其感知、规划、行动的强大能力，正引领着 AI 从 "能说会道" 向 "能干实事" 的重大转变。而 MCP 的出现，则如同一把关键的 "钥匙"，为 Agent 打开了通往现实世界的大门！

大概就这些吧，脑瓜子实在想不出其他的了，要干饭去了，最后，希望这篇文章能让你对 MCP 有更深刻的理解吧。💖

---

至此，本篇文章就写完啦，撒花撒花。