MCP 是為開發(fā)者設(shè)計(jì)的工具，而非為 LLM 而設(shè) 原創(chuàng)
編者按： 你在開發(fā) AI 智能體時(shí)，是否也曾為這些事頭疼不已：每接入一個(gè)新工具就要重寫集成代碼？工具一多就難以統(tǒng)一管理？LLM 時(shí)而“幻覺”出根本不存在的工具調(diào)用？
這些問題不僅拖慢開發(fā)節(jié)奏，更讓智能體的穩(wěn)定性和擴(kuò)展性大打折扣。
今天推薦的這篇文章，正來自一線開發(fā)者對(duì) Model Context Protocol (MCP) 的深度實(shí)踐與思考。對(duì) LLM 來說，“常規(guī)”的工具調(diào)用和使用 MCP 這樣的標(biāo)準(zhǔn)沒有任何區(qū)別。它只看到一組工具定義（tool definitions），它不知道也不關(guān)心幕后發(fā)生著什么 —— 而這恰恰是件好事...
作者 | Roy Derks
編譯 | 岳揚(yáng)
Model Context Protocol (MCP) 已成為構(gòu)建智能體時(shí)使用工具調(diào)用（tool calling）的標(biāo)準(zhǔn)，但恰恰相反，你的 LLM 并不需要理解 MCP。你可能聽說過“上下文工程（context engineering）”這一術(shù)語，在這項(xiàng)技術(shù)中，作為與 LLM 交互的人，你需要負(fù)責(zé)提供正確的上下文來幫助它回答問題。為了收集這些上下文，你可以使用工具調(diào)用，讓 LLM 能夠訪問一組可以用于獲取信息或執(zhí)行操作的工具。
MCP 通過標(biāo)準(zhǔn)化 AI 智能體連接到這些工具的方式來提供幫助。但對(duì)你的 LLM 來說，“常規(guī)”的工具調(diào)用和使用 MCP 這樣的標(biāo)準(zhǔn)沒有任何區(qū)別。 它只看到一組工具定義（tool definitions），它不知道也不關(guān)心幕后發(fā)生著什么 —— 而這恰恰是件好事。
通過使用 MCP，你可以訪問成千上萬的工具，而無需為每個(gè)工具編寫自定義的集成邏輯。它極大地簡(jiǎn)化了涉及工具調(diào)用的智能體循環(huán)（agentic loop）的設(shè)置過程，而這一過程的開發(fā)時(shí)間通常情況下幾乎為零。開發(fā)者負(fù)責(zé)調(diào)用工具，LLM 只生成一個(gè)片段，說明需要調(diào)用什么工具（單個(gè)或多個(gè)）以及使用哪些輸入?yún)?shù)。
在這篇博客文章中，我將詳細(xì)解釋工具調(diào)用是如何工作的、MCP 實(shí)際上做了什么，以及這兩者與上下文工程的關(guān)系。
01 工具調(diào)用 Tool Calling
LLMs 理解工具調(diào)用【有時(shí)也稱為工具使用（tool use）或函數(shù)調(diào)用（function calling）】的概念。你需要在提示詞中提供工具定義列表。每個(gè)工具都包含名稱、功能描述和所需的輸入?yún)?shù)。根據(jù)用戶問題和現(xiàn)有工具，大語言模型可能會(huì)生成對(duì)應(yīng)的調(diào)用指令。
但關(guān)鍵點(diǎn)在于：LLMs 并不懂得如何使用工具。它們沒有原生的工具調(diào)用支持，它們只會(huì)生成代表函數(shù)調(diào)用的文本。
與 LLM 交互時(shí)的輸入與輸出
在上方的示意圖中，我們可以看到 LLM 實(shí)際看到的內(nèi)容：一個(gè)由指令、之前的用戶消息和可用工具列表組成的提示詞。基于這些信息，大語言模型會(huì)生成文本響應(yīng)，其中可能包含系統(tǒng)應(yīng)當(dāng)調(diào)用的工具指令。它并非真正理解工具的實(shí)際意義，只是在基于概率生成預(yù)測(cè)性響應(yīng)。
讓我們來看一個(gè)更實(shí)際的應(yīng)用場(chǎng)景。例如，如果你提供一個(gè)名為 get_weather的工具，它接受一個(gè)地理位置作為輸入，然后問模型：“加利福尼亞州圣何塞的天氣怎么樣？” 它可能會(huì)回應(yīng)：
{
"name":"get_weather",
"input":{
"location":"San Jose, CA"
}
}LLM 能夠根據(jù)所提供的上下文生成這個(gè)代碼片段，如下方示意圖所示。LLM 并不了解如何調(diào)用 get_weather工具，它也無需知道。你的智能體循環(huán)（agentic loop）或智能體應(yīng)用（agentic application）負(fù)責(zé)獲取該輸出，并將其轉(zhuǎn)換為實(shí)際的 API 調(diào)用或函數(shù)調(diào)用。系統(tǒng)會(huì)解析模型生成的工具名稱及輸入?yún)?shù)，執(zhí)行對(duì)應(yīng)工具，并將執(zhí)行結(jié)果作為新消息反饋給大語言模型。
工具調(diào)用流（Tool Calling flow）與 LLM 的交互
這種職責(zé)分離很重要。大語言模型僅負(fù)責(zé)生成預(yù)測(cè)結(jié)果，而執(zhí)行環(huán)節(jié)交由您的系統(tǒng)處理。這正是 MCP（模型上下文協(xié)議）發(fā)揮作用的關(guān)鍵所在。
02 模型上下文協(xié)議 (MCP)
Model Context Protocol（簡(jiǎn)稱 MCP）是一種標(biāo)準(zhǔn)化智能體與數(shù)據(jù)源（如工具、提示詞、資源服務(wù)及樣本示例）連接方式[1]的協(xié)議。現(xiàn)階段，MCP 最顯著的價(jià)值在于簡(jiǎn)化了工具集成這一關(guān)鍵環(huán)節(jié)。 MCP 通過定義統(tǒng)一的接口規(guī)范和通信協(xié)議，取代了為每個(gè)工具手動(dòng)編寫定制化代碼的方式。您可以將其理解為工具領(lǐng)域的通用適配器（如同 USB-C 接口）。
MCP 通常包含三個(gè)核心組件：宿主應(yīng)用 (host application)、MCP 客戶端 (MCP client) 和若干 MCP 服務(wù)器 (MCP servers)。宿主應(yīng)用可能是聊天軟件或 IDE（例如 Cursor），其中內(nèi)置了能連接不同 MCP 服務(wù)器的 MCP 客戶端。這些 MCP 服務(wù)器則對(duì)外提供工具、提示詞、樣本示例或資源服務(wù)。
與 LLM 的交互方式并未改變，改變的是工具數(shù)據(jù)的接入方式：智能體應(yīng)用與 MCP 客戶端通信，再由客戶端對(duì)接目標(biāo)服務(wù)器。所有工具均以 LLM 可識(shí)別的格式進(jìn)行描述。
工具調(diào)用流與 LLM 及 MCP 的交互
當(dāng)面對(duì)同樣的問題“加利福尼亞州圣何塞的天氣怎么樣？”時(shí)，LLM 接收到的仍是相同的工具列表。根據(jù)該列表，它將告訴你需調(diào)用的工具，而具體的執(zhí)行策略仍由開發(fā)者掌控。當(dāng)采用 MCP 時(shí)，該工具將通過 MCP 協(xié)議執(zhí)行。
該機(jī)制的核心受益方并非大語言模型，而是作為開發(fā)者的你。隨著智能體系統(tǒng)的擴(kuò)展，MCP 能有效管理復(fù)雜的多工具協(xié)作：實(shí)現(xiàn)跨項(xiàng)目的工具復(fù)用，統(tǒng)一數(shù)據(jù)格式規(guī)范，以及無需重構(gòu)即可無縫接入新系統(tǒng)。
但除非在系統(tǒng)提示詞中明確告知，否則 LLM 永遠(yuǎn)無法感知你是否使用了 MCP。 開發(fā)者始終承擔(dān)工具調(diào)用的執(zhí)行職責(zé)，大語言模型僅生成包含目標(biāo)工具及對(duì)應(yīng)輸入?yún)?shù)的指令片段。
接下來，本文將解析該機(jī)制是如何融入上下文工程體系的，并闡釋為何 MCP 這樣的抽象層本質(zhì)是為人類而非模型服務(wù)。
03 上下文工程 Context Engineering
Context engineering（上下文工程）的核心在于為 LLM 提供精準(zhǔn)恰當(dāng)?shù)妮斎耄蛊渖捎行У妮敵觥＿@看似簡(jiǎn)單，卻是構(gòu)建高效 AI 系統(tǒng)最關(guān)鍵的環(huán)節(jié)之一。
當(dāng)我們向模型提問時(shí)，本質(zhì)上是在向其提供提示詞（prompt） —— 即模型用于預(yù)測(cè)后續(xù)文本的文本塊。該提示詞的質(zhì)量直接影響響應(yīng)質(zhì)量。
這正是工具調(diào)用的價(jià)值所在。當(dāng)模型缺乏足夠上下文時(shí)（如需實(shí)時(shí)數(shù)據(jù)、用戶畫像或代用戶執(zhí)行操作的能力），通過工具調(diào)用可使其接入外部系統(tǒng) —— 正如本文所述。
但在此再次強(qiáng)調(diào)，模型無需理解這些工具的實(shí)現(xiàn)邏輯。它只需知曉三點(diǎn)：工具的存在性、功能定位及調(diào)用方式。這正是上下文工程（context engineering）與工具設(shè)計(jì)（tool design）的交匯點(diǎn) —— 我們所設(shè)計(jì)的工具定義集本質(zhì)上是提示詞的組成部分。
LLM 視角下的工具調(diào)用
MCP 使該過程更簡(jiǎn)潔規(guī)范且可復(fù)用。通過 MCP 協(xié)議，開發(fā)者只需一次性定義結(jié)構(gòu)化接口并對(duì)外發(fā)布，即可避免硬編碼工具（hardcoding tools）或編寫臨時(shí)封裝器（writing ad hoc wrappers）。LLM 接收到的工具定義格式保持不變，但現(xiàn)在它們更容易維護(hù)和擴(kuò)展。
綜上所述，MCP 本質(zhì)上是一個(gè)為開發(fā)者設(shè)計(jì)的工具，而非為 LLM 而設(shè)。 它可以幫助我們構(gòu)建更可靠的、更模塊化的系統(tǒng)，使工程師能專注于上下文工程，而無需每次都重復(fù)搭建基礎(chǔ)架構(gòu)。
END
本期互動(dòng)內(nèi)容 ??
?文中的核心觀點(diǎn)是：“MCP 是為開發(fā)者，而非為 LLM 服務(wù)的”。你是否認(rèn)同？有沒有反例或不同的角度？
文中鏈接
本文經(jīng)原作者授權(quán)，由 Baihai IDP 編譯。如需轉(zhuǎn)載譯文，請(qǐng)聯(lián)系獲取授權(quán)。
原文鏈接：
??https://hackteam.io/blog/your-llm-does-not-care-about-mcp/??
