MCP 是为开发者设计的工具，而非为 LLM 而设
编者按： 你在开发 AI 智能体时，是否也曾为这些事头疼不已：每接入一个新工具就要重写集成代码？工具一多就难以统一管理？LLM 时而"幻觉"出根本不存在的工具调用？
这些问题不仅拖慢开发节奏，更让智能体的稳定性和扩展性大打折扣。
今天推荐的这篇文章，正来自一线开发者对 Model Context Protocol (MCP) 的深度实践与思考。对 LLM 来说，"常规"的工具调用和使用 MCP 这样的标准没有任何区别。它只看到一组工具定义（tool definitions），它不知道也不关心幕后发生着什么 ------ 而这恰恰是件好事...
作者 | Roy Derks
编译 | 岳扬
Model Context Protocol (MCP) 已成为构建智能体时使用工具调用（tool calling）的标准，但恰恰相反，你的 LLM 并不需要理解 MCP。你可能听说过"上下文工程（context engineering）"这一术语，在这项技术中，作为与 LLM 交互的人，你需要负责提供正确的上下文来帮助它回答问题。为了收集这些上下文，你可以使用工具调用，让 LLM 能够访问一组可以用于获取信息或执行操作的工具。
MCP 通过标准化 AI 智能体连接到这些工具的方式来提供帮助。但对你的 LLM 来说，"常规"的工具调用和使用 MCP 这样的标准没有任何区别。 它只看到一组工具定义（tool definitions），它不知道也不关心幕后发生着什么 ------ 而这恰恰是件好事。
通过使用 MCP，你可以访问成千上万的工具，而无需为每个工具编写自定义的集成逻辑。它极大地简化了涉及工具调用的智能体循环（agentic loop）的设置过程，而这一过程的开发时间通常情况下几乎为零。开发者负责调用工具，LLM 只生成一个片段，说明需要调用什么工具（单个或多个）以及使用哪些输入参数。
在这篇博客文章中，我将详细解释工具调用是如何工作的、MCP 实际上做了什么，以及这两者与上下文工程的关系。
01 工具调用 Tool Calling
LLMs 理解工具调用【有时也称为工具使用（tool use）或函数调用（function calling）】的概念。你需要在提示词中提供工具定义列表。每个工具都包含名称、功能描述和所需的输入参数。根据用户问题和现有工具，大语言模型可能会生成对应的调用指令。
但关键点在于：LLMs 并不懂得如何使用工具。它们没有原生的工具调用支持，它们只会生成代表函数调用的文本。
与 LLM 交互时的输入与输出
在上方的示意图中，我们可以看到 LLM 实际看到的内容：一个由指令、之前的用户消息和可用工具列表组成的提示词。基于这些信息，大语言模型会生成文本响应，其中可能包含系统应当调用的工具指令。它并非真正理解工具的实际意义，只是在基于概率生成预测性响应。
让我们来看一个更实际的应用场景。例如，如果你提供一个名为 get_weather的工具，它接受一个地理位置作为输入，然后问模型："加利福尼亚州圣何塞的天气怎么样？" 它可能会回应：
{
"name":"get_weather",
"input":{
"location":"San Jose, CA"
}
}
LLM 能够根据所提供的上下文生成这个代码片段，如下方示意图所示。LLM 并不了解如何调用 get_weather工具，它也无需知道。你的智能体循环（agentic loop）或智能体应用（agentic application）负责获取该输出，并将其转换为实际的 API 调用或函数调用。系统会解析模型生成的工具名称及输入参数，执行对应工具，并将执行结果作为新消息反馈给大语言模型。
工具调用流（Tool Calling flow）与 LLM 的交互
这种职责分离很重要。大语言模型仅负责生成预测结果，而执行环节交由您的系统处理。这正是 MCP（模型上下文协议）发挥作用的关键所在。
02 模型上下文协议 (MCP)
Model Context Protocol（简称 MCP）是一种标准化智能体与数据源（如工具、提示词、资源服务及样本示例）连接方式[1]的协议。现阶段，MCP 最显著的价值在于简化了工具集成这一关键环节。 MCP 通过定义统一的接口规范和通信协议，取代了为每个工具手动编写定制化代码的方式。您可以将其理解为工具领域的通用适配器（如同 USB-C 接口）。
MCP 通常包含三个核心组件：宿主应用 (host application)、MCP 客户端 (MCP client) 和若干 MCP 服务器 (MCP servers)。宿主应用可能是聊天软件或 IDE（例如 Cursor），其中内置了能连接不同 MCP 服务器的 MCP 客户端。这些 MCP 服务器则对外提供工具、提示词、样本示例或资源服务。
与 LLM 的交互方式并未改变，改变的是工具数据的接入方式：智能体应用与 MCP 客户端通信，再由客户端对接目标服务器。所有工具均以 LLM 可识别的格式进行描述。
工具调用流与 LLM 及 MCP 的交互
当面对同样的问题"加利福尼亚州圣何塞的天气怎么样？"时，LLM 接收到的仍是相同的工具列表。根据该列表，它将告诉你需调用的工具，而具体的执行策略仍由开发者掌控。当采用 MCP 时，该工具将通过 MCP 协议执行。
该机制的核心受益方并非大语言模型，而是作为开发者的你。随着智能体系统的扩展，MCP 能有效管理复杂的多工具协作：实现跨项目的工具复用，统一数据格式规范，以及无需重构即可无缝接入新系统。
但除非在系统提示词中明确告知，否则 LLM 永远无法感知你是否使用了 MCP。 开发者始终承担工具调用的执行职责，大语言模型仅生成包含目标工具及对应输入参数的指令片段。
接下来，本文将解析该机制是如何融入上下文工程体系的，并阐释为何 MCP 这样的抽象层本质是为人类而非模型服务。
03 上下文工程 Context Engineering
Context engineering（上下文工程）的核心在于为 LLM 提供精准恰当的输入，使其生成有效的输出。这看似简单，却是构建高效 AI 系统最关键的环节之一。
当我们向模型提问时，本质上是在向其提供提示词（prompt） ------ 即模型用于预测后续文本的文本块。该提示词的质量直接影响响应质量。
这正是工具调用的价值所在。当模型缺乏足够上下文时（如需实时数据、用户画像或代用户执行操作的能力），通过工具调用可使其接入外部系统 ------ 正如本文所述。
但在此再次强调，模型无需理解这些工具的实现逻辑。它只需知晓三点：工具的存在性、功能定位及调用方式。这正是上下文工程（context engineering）与工具设计（tool design）的交汇点 ------ 我们所设计的工具定义集本质上是提示词的组成部分。
LLM 视角下的工具调用
MCP 使该过程更简洁规范且可复用。通过 MCP 协议，开发者只需一次性定义结构化接口并对外发布，即可避免硬编码工具（hardcoding tools）或编写临时封装器（writing ad hoc wrappers）。LLM 接收到的工具定义格式保持不变，但现在它们更容易维护和扩展。
综上所述，MCP 本质上是一个为开发者设计的工具，而非为 LLM 而设。 它可以帮助我们构建更可靠的、更模块化的系统，使工程师能专注于上下文工程，而无需每次都重复搭建基础架构。
END
本期互动内容 🍻
❓文中的核心观点是："MCP 是为开发者，而非为 LLM 服务的"。你是否认同？有没有反例或不同的角度？
文中链接
本文经原作者授权，由 Baihai IDP 编译。如需转载译文，请联系获取授权。
原文链接：
