LLM 无需深度理解 MCP 协议

2025 年 8 月 6 日 - Roy Derks

在构建 Agent 时，Model Context Protocol（MCP）已经成为工具调用的标准。但与普遍认知相反，你的 LLM 并不需要理解 MCP。

你可能听说过“上下文工程”（context engineering）这个词：作为与 LLM 交互的人，你有责任提供正确的上下文，帮助它回答问题。为了收集这些上下文，你可以使用工具调用，让 LLM 能够访问一组工具，通过它们获取信息或执行操作。

MCP 的作用，是将 Agent 与这些工具之间的连接方式标准化。但对 LLM 来说，“常规”工具调用与使用 MCP 这样的标准并没有区别。它看到的只是一组工具定义，既不知道也不关心幕后发生了什么。这其实是一件好事。

通过 MCP，你无需为每个工具编写自定义集成逻辑，就能使用数千种工具。它极大简化了包含工具调用的 Agentic Loop 搭建过程，而且通常几乎不需要开发时间。你——开发者——负责实际调用工具。LLM 只负责生成一段内容，说明要调用哪些工具，以及使用哪些输入参数。

在这篇博客文章中，我会详细讲解工具调用的工作原理、MCP 实际做了什么，以及二者与上下文工程之间的关系。

LLM 理解工具调用的概念，它有时也被称为工具使用（tool use）或函数调用（function calling）。你需要将一组工具定义作为 prompt 的一部分提供给它。每个工具都包含名称、描述和预期的输入参数。LLM 会根据问题和可用工具，决定是否生成一次调用。

但关键在于：LLM 并不知道如何使用工具。它没有原生的工具调用能力，只会生成一段表示函数调用的文本。

在上图中，你可以看到 LLM 实际接收到的内容：一个由指令、之前的用户消息以及可用工具列表组成的 prompt。LLM 根据这些内容生成文本响应，其中可能包含一个需要由你的系统调用的工具。它并没有真正理解工具，只是在进行预测。

来看一个更实际的使用场景。假设你提供了一个名为 get_weather 的工具，它接收位置作为输入。然后你问模型：“What’s the weather in San Jose, CA?”，它可能会返回：

{
  "name": "get_weather",
  "input": {
    "location": "San Jose, CA"
  }
}

正如下图所示，LLM 能够根据提供给它的上下文生成这段内容。LLM 不知道如何调用 get_weather 工具，也不需要知道。你的 Agentic Loop 或 Agentic Application 负责接收这段输出，并执行真正的 API 调用或函数调用。它会解析生成的工具名称和输入参数，运行工具，然后将结果作为一条新消息传回 LLM。

这种关注点分离非常重要。LLM 只负责生成预测，你的系统负责执行。接下来，就要说到 MCP 在其中扮演的角色了。

Model Context Protocol（MCP）

Model Context Protocol，也就是 MCP，是一种标准化 Agent 与工具、prompt、资源和样本等数据源连接方式的协议。目前，MCP 最广为人知的用途，是简化其中与工具有关的部分。你不再需要为每个工具按照自定义格式手动编写代码，MCP 定义了一套统一的 schema 和通信模式。你可以把它理解成工具领域的通用适配器，就像 USB-C 一样。

MCP 通常包含三个组成部分：Host Application、MCP Client，以及一个或多个 MCP Server。Host 可以是聊天应用，也可以是 IDE（例如 Cursor），其中包含一个能够连接不同 Server 的 MCP Client。这些 Server 会暴露工具、prompt、样本或资源。

你与 LLM 交互的方式并不会发生变化。变化的是工具以何种方式提供给它。Agentic Application 与 MCP Client 通信，MCP Client 再与正确的 Server 通信。工具会以 LLM 能够使用的格式进行描述。

对于同一个问题“What’s the weather in San Jose, CA?”，LLM 仍然会收到同样的工具列表。它会根据这份列表告诉你应该调用哪个工具，而具体如何调用该工具，则由开发者决定。使用 MCP 时，这个工具会通过 MCP 调用。

这里的收益并不属于 LLM，而是属于你——开发者。随着 Agent 不断成长，MCP 可以帮助你管理同时使用大量不同工具所带来的复杂性。它让工具更容易跨项目复用，能够强制采用一致的格式，也让你无需重写所有代码就能接入新系统。

不过，LLM 永远不会知道你正在使用 MCP，除非你在 system prompt 或工具定义中明确告诉它。你——开发者——负责调用工具。LLM 只负责生成一段内容，说明要调用哪些工具以及使用哪些输入参数。

接下来，我们看看它如何融入上下文工程这一更大的体系，以及为什么 MCP 这样的抽象层简化的是人类的工作，而不是模型的工作。

上下文工程的核心，是为 LLM 提供正确的输入，使它能够生成有用的输出。听起来很简单，但实际上，这是构建高效 AI 系统时最重要的环节之一。

当你向模型提出一个问题时，实际上是在向它提供一个 prompt——一段供它预测下一段文本的文字。这个 prompt 的质量会直接影响响应的质量。

工具正是在这里发挥作用。有时，模型没有足够的上下文，无法很好地回答问题。它可能需要实时数据、访问用户资料，或者代表用户执行操作的能力。正如你在这篇博客文章中了解到的那样，工具调用可以通过让模型访问外部系统来解决这个问题。

但还是那句话：模型不需要知道这些工具如何工作。它只需要知道这些工具存在、它们有什么用途，以及应该如何调用。这正是上下文工程与工具设计相交的地方：你需要精心设计一组工具定义，并将其作为模型 prompt 的一部分。

MCP 让这个过程变得更整洁，也更容易重复使用。你不再需要硬编码工具或编写临时 wrapper，而是只需定义一次结构化接口，再通过 MCP 将其暴露出去。LLM 看到的仍然是同一类工具定义，但现在这些定义更容易维护和扩展。

所以归根结底，MCP 是为我们开发者准备的工具，而不是为 LLM 准备的。它帮助我们构建更加可靠、模块化的系统，也让我们能够专注于上下文工程，而不必每次都重新搭建底层管道。

接下来可以做什么？

学习如何在 10 分钟内构建一个 MCP Server

使用 MCP Inspector 测试 MCP Server

如果你觉得这篇教程有帮助，别忘了将它分享给你的社交网络。如果想了解更多有关 AI 和 Web 开发的内容，请订阅我的 YouTube 频道，并在 LinkedIn、X 或 Bluesky 上与我联系。