别再搞混了！MCP真的需要Function Calling吗？Cline源码揭秘

在快速发展的AI编程助手领域，有两个概念经常被一起提及，甚至被一些开发者和技术文章所混淆：Function Calling 和 Model Context Protocol (MCP)。是不是一定要LLM具备Function Calling能力，才能有效利用MCP与外部工具交互呢？答案可能和你想象的不一样。今天，我们就来澄清这个常见的误解，并深入流行的VSCode插件——Cline的源码，看看它是如何巧妙解决这个问题的。

Function Calling vs. MCP：先厘清概念

• Function Calling (函数调用): 这通常指的是大语言模型（LLM）本身的一种能力。当用户用自然语言提出请求时，具备Function Calling能力的LLM能够理解这个请求，并自主判断是否需要、以及需要调用哪些预定义的外部工具（函数/API）来完成任务。它还能生成符合特定格式（通常是JSON）的调用参数。简单说，Function Calling是LLM决定“用哪个工具”和“怎么用”的智能决策过程。
• Model Context Protocol (MCP，模型上下文协议): MCP则是一个标准化的交互协议。它定义了LLM Agent应用（如Cline这样的编程助手）与外部系统（MCP Server，提供各种工具或数据源）之间应该如何通信。它规范了请求和响应的格式，确保双方能够顺畅地“对话”。MCP关心的是“如何传递工具调用指令和结果”，而不是LLM如何做出调用决策。

看到这里，你可能已经有点明白了：MCP负责的是“通信管道”的标准，而Function Calling是某些LLM拥有的“智能大脑”的一部分。理论上，只要LLM应用能按照MCP规定的格式发出请求，MCP就能工作，并不强制要求LLM本身具备原生的Function Calling能力。

普遍的误解：为什么会认为MCP依赖Function Calling？

误解的产生往往源于一个看似合理的逻辑链：

1. MCP需要执行外部工具（tools）。
2. 调用哪个工具、传入什么参数，这个“决策”需要LLM来做。
3. LLM做出这种结构化决策并输出调用指令，这不就是Function Calling吗？

这个逻辑没错，但它忽略了一点：LLM产生“调用哪个工具以及如何调用”的结构化输出，不一定非要依赖其内置的Function Calling能力。

Cline的解决方案：强大的System Prompt

VSCode上广受欢迎的Cline插件就是一个很好的例子。它支持通过OpenRouter这样的平台接入上百种不同的LLM。显然，这些LLM中只有少数具备原生的Function Calling能力，但这并不妨碍用户在Cline中使用各种MCP Server提供的强大功能。

Cline是如何做到的呢？答案就藏在它的开源代码里，具体来说是src/core/prompts/system.ts文件中的SYSTEM_PROMPT函数。这个函数构建了一个极其详尽、长达近千行的系统提示词（System Prompt）。

这个System Prompt就像一份详细的说明书，告诉LLM：

1. “你有权使用工具”: 明确告知LLM它可以使用一系列工具来完成任务。
2. “工具调用的标准格式是这样的”: Cline定义了一种基于XML的工具调用格式，并清晰地展示给LLM。

<tool_name>
  <parameter1_name>value1&