深入理解MCP的工作原理

引言：如果你听过 MCP ，或者已经一直在使用 MCP 了，但一直没搞明白它到底是什么，或者你以为"大模型可以直接调用外部工具"——这篇文章就是为你写的。

本文将从最基础的概念讲起，帮你建立对大模型、Agent 和 MCP 三者关系的正确认知。

首先，纠正一个最常见的误解

很多文章和文档在介绍 MCP 时会说：

"MCP 让大模型能够调用外部工具。"

这句话是有误导性的。

大模型，也就是常说的 LLM，全称是 Large Language Model（大语言模型）。从名字就能看出，它的本质是一个文本处理引擎——接收一段纯文本输入，经过推理后输出一段文本。仅此而已。它 没有网络连接能力，没有文件系统访问权限，更不可能直接和数据库、API 或任何外部系统交互。

如果你所在公司的内网部署了一个 MCP 服务，外部的大模型怎么可能直接调用它呢？显然不可能。

那谁来做这些和外部世界打交道的事情呢？答案是 Agent。

三个核心角色：大模型、Agent、MCP

要理解 MCP，首先要搞清楚三个角色各自的定位和分工。

角色	定位	职责边界
大模型（LLM）	决策中心	只负责"思考"——分析信息、做出判断、输出指令，不执行任何操作
Agent	执行引擎	负责一切实际操作——组装请求、解析响应、调用工具、管理上下文
MCP Server	能力提供方	封装具体的外部能力（数据库查询、API 调用、文件操作等），等待被 Agent 调用

它们的协作关系可以这样理解：

大模型是决策层，只做判断，不碰任何外部资源
Agent 是执行层，是大模型和外部世界之间的唯一桥梁
MCP Server 是能力层，按照标准协议暴露工具，供 Agent 调用

整个流程中，大模型自始至终都不会直接接触任何外部系统。所有与外部世界的交互，都由 Agent 代为完成。

Agent 的工作循环

Agent 的运行逻辑其实很简单，它始终在循环执行三个步骤：

Agent 的工作循环.png

这个循环会一直进行，直到大模型判断任务已经完成、不再需要调用工具为止。

Tool Calling：大模型如何"指挥"Agent

现在有一个关键问题：大模型怎么知道有哪些工具可以用？

答案是：Agent 在每次请求时，都会把一份"工具清单"附在请求中一起发给大模型。 大模型根据用户的问题，从清单中选择合适的工具，然后把工具名称和参数以结构化的格式返回给 Agent。

工具清单长什么样？

以 Kiro IDE 为例，它内置了文件读取、编辑、写入、搜索、终端命令执行等多种工具。每个工具的定义大致如下：

{
  "name": "read_file",
  "description": "读取指定路径的文件内容",
  "parameters": {
    "type": "object",
    "properties": {
      "path": {
        "type": "string",
        "description": "要读取的文件路径"
      }
    },
    "required": ["path"]
  }
}

每个工具都包含名称、功能描述、参数类型、参数说明、是否必传等信息。

再次强调：大模型只做决策，不做执行

这一点非常重要，值得反复说明：

✅ 大模型查看工具清单，返回结构化的调用指令（"请调用 XX 工具，参数是 YY"）
✅ Agent 接收指令后，自己去执行实际的工具调用
❌ 大模型直接执行工具调用（这在技术上不可能发生）

这种机制最早叫 Function Calling（函数调用），现在普遍改称 Tool Calling（工具调用），几乎所有主流大模型（OpenAI、Anthropic Claude、DeepSeek 等）都已支持。

实际演示：用 DeepSeek API 观察完整流程

为了让你直观地理解这个过程，我们用 DeepSeek 的 API 来做一个对比实验。

场景：查询 GitHub 仓库信息

假设用户想知道某个开源项目的 Star 数量和最近更新时间。这类信息存储在 GitHub 的服务器上，大模型自身显然无法访问。

实验一：不提供任何工具

请求：facebook/react 这个仓库现在有多少 Star？
工具列表：[]（空）

大模型回复：抱歉，我无法实时访问 GitHub，建议你直接前往
https://github.com/facebook/react 查看。

大模型很诚实——它知道自己没有访问 GitHub API 的能力，所以直接告诉你它做不到。

实验二：提供 GitHub 查询工具

请求：facebook/react 这个仓库现在有多少 Star？
工具列表：[{ name: "get_repo_info", parameters: { owner: "string", repo: "string" } }]

大模型回复：
{
  "tool_calls": [{
    "function": "get_repo_info",
    "arguments": { "owner": "facebook", "repo": "react" }
  }]
}

这次大模型发现工具清单里有一个 <code>get_repo_info</code> 工具，于是它返回了一条结构化指令："请调用 <code>get_repo_info</code>，参数是 <code>owner: facebook, repo: react</code>"。

关键观察：大模型只是返回了"要调用什么"和"传什么参数"这样一段 JSON 文本，它并没有真的去请求 GitHub API。 实际的 HTTP 请求、网络连接、响应解析，全部是 Agent 拿到这段 JSON 后自己完成的。

那 MCP 到底是什么？

理解了上面的内容后，MCP 就很好解释了。

问题：工具不够用怎么办？

Agent 内置的工具是有限的。如果你想让 AI 助手连接 GitHub、查询数据库、操作 Figma 设计稿、管理 AWS 资源……难道每个 Agent 都要自己实现这些功能吗？

更合理的做法是：设计一个插件扩展机制，让社区和企业都能开发插件来扩展 Agent 的工具库。

但插件需要一个统一的规范。如果每个 Agent 都定义自己的插件格式，插件就无法跨 Agent 复用，生态就会碎片化。

MCP 就是这个统一规范

MCP（Model Context Protocol，模型上下文协议） 是 Anthropic 在 2024 年 11 月提出的开放标准。它定义了 AI Agent 与外部工具服务之间的通信协议，让任何人都可以按照这个规范开发工具服务（MCP Server），并且这些服务可以被任何支持 MCP 的 Agent 使用。

换句话说，MCP 解决的是工具互操作性问题：

MCP 之前：每个 AI Agent 都有自己的工具扩展方式，A 的插件不能用在 B 上
MCP 之后：统一协议，一个 MCP Server 可以同时被 Kiro、Claude Code、Cursor 等任何支持 MCP 的 Agent 使用

所以 MCP 的本质是 Agent 工具清单的标准化扩展协议。它不是让大模型获得了新能力，而是让 Agent 可以通过标准接口接入更多的外部工具。

MCP 的完整交互流程

以 Kiro IDE（或 Kiro CLI）连接一个 MCP Server 为例，完整流程如下：

阶段一：启动连接（只在 Agent 启动时执行一次）

启动连接.png

阶段二：用户交互（每次提问都会执行）

用户交互.png

开发一个 MCP Server 需要实现什么？

如果你想自己开发一个 MCP Server，核心只需要实现三个接口：

接口	作用	说明
<code>initialize</code>	初始化握手	返回 MCP 服务的基本信息：协议版本、服务名称、服务版本
<code>tools/list</code>	暴露工具清单	返回该服务提供的所有工具，包括名称、描述、参数定义
<code>tools/call</code>	执行工具调用	通过 JSON-RPC 方式调用指定工具，传入参数，返回结果

⚠️ 注意：这些接口的名称是 MCP 规范规定的，不能随意更改。协议版本号也有严格要求——MCP 使用日期格式（如 <code>2024-11-05</code>）而非常规的语义化版本号，写错了会导致连接失败。

一个容易被忽略的问题：Token 消耗

使用 MCP 时有一个很多人忽略的性能问题：MCP 工具列表会显著增加 Token 消耗。

原因在于 Agent 的工作机制——它在每次向大模型发送请求时，都会把所有可用工具的完整描述附在请求中。这意味着：

一个 MCP Server 可能提供几十个工具
你的项目可能同时连接了五六个 MCP Server
每个工具都有名称、描述、参数定义等详细信息
这些信息在每次请求中都会重复发送

所以如果你启用了大量 MCP 工具后发现 Token 消耗飞快，原因就在这里。建议只启用当前真正需要的 MCP Server，不用的及时禁用。

在 Kiro 中使用 MCP

Kiro（包括 IDE 和 CLI）从发布之初就支持 MCP。根据 Kiro 官方文档，Kiro 支持两种类型的 MCP Server：

远程 MCP Server：通过 <code>streamable-http</code> 或 <code>sse</code> 协议连接，适合云端部署的服务
本地 MCP Server：通过 <code>stdio</code> 协议连接，支持 npm、PyPI、OCI 三种包管理器，使用 <code>npx</code>、<code>uvx</code> 或 <code>docker</code> 来运行

Kiro IDE 和 Kiro CLI 共享 MCP 配置，在一端配置好的 MCP Server，另一端可以直接使用。

配置文件位于项目根目录的 <code>.kiro/settings/mcp.json</code>，格式示例：

{
  "mcpServers": {
    "my-mcp-server": {
      "command": "uvx",
      "args": ["my-mcp-server@latest"],
      "env": {
        "API_KEY": "your-api-key"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

💡 对于企业用户，Kiro 还提供了 MCP 治理功能，管理员可以通过 MCP 注册表（Registry）统一管控团队可使用的 MCP Server，确保安全合规。

总结

概念	一句话解释
大模型（LLM）	纯粹的决策引擎，只输出文本形式的指令，不能连接任何外部系统
Agent	大模型与外部世界之间的桥梁，负责所有实际的工具调用和结果传递
Tool Calling	Agent 和大模型之间约定好的"工具清单"机制，让大模型可以选择要调用的工具
MCP	一个开放标准协议，让 Agent 的工具清单可以通过标准化接口无限扩展
MCP Server	按照 MCP 规范开发的工具服务，封装具体的外部能力供 Agent 调用

一句话总结：MCP 不是让大模型获得了调用外部工具的能力，而是为 Agent 的工具扩展提供了一套标准化的通信协议。