《一文读懂大模型三大核心技术：ReAct、Function Call 与 MCP 的奥秘》

• 前言
• ReAct
• Function Call
• MCP
• 总结

前言

在当下人工智能迅猛发展的浪潮中，大语言模型（LLMs）的应用边界持续拓展，多智能体协作规划（MCP）领域也迎来了爆发式的成长。从最初概念的提出，到如今在复杂任务处理场景中频繁崭露头角，MCP 正逐渐成为推动 AI 迈向更高智能水平的关键力量。

然而，当我们深入探究大语言模型的优化技术时，会发现 ReAct、Function Calling 与 MCP 这几个概念，在网络上的解读往往含糊不清，存在诸多混淆之处。许多技术爱好者与从业者虽对它们有所耳闻，却难以精准把握其核心差异、执行流程以及适用场景。鉴于此，撰写这篇文章，旨在抽丝剥茧，深入剖析 ReAct、Function Calling 与 MCP，为大家理清这几个重要概念，助力更好地理解与运用相关技术 。

ReAct

ReAct 是近年来在大语言模型领域备受关注的一项技术，它打破了传统模型仅基于生成文本的固有模式，将推理（Reasoning）和动作执行（Action）相结合，让模型能够更合理、更智能地完成任务。从原理上看，ReAct 通过引入思维链（Chain of Thought）的方式，让大语言模型在生成答案之前，先输出一系列推理步骤，清晰地展示其 “思考” 过程，再基于推理结果采取具体动作。

• 无思维链
  
• 有思维链
  

在上面的两个例子中，思维链的模式明显得到了正确的结果。其本质原因是大模型在输出的时候使用的是 因果注意力（Causal Attention），也就是说一段话中后面输出的 token 可以关联到前面输出的 token，而前面输出的 token 并不知道后面要输出哪些 token。可以简单理解为大模型在输出的时候是一个字一个字想的，开始并没有想好要说什么，而是 边说边想。那么使用思维链的方式，就可以理解成没有直接向大模型要答案，而是给了他自己思考的过程，准确度自然会有所提升。

使用 ReAct 框架调用工具过程与上述类似，通过提示词告诉模型有哪些工具可以调用，每一个工具是干嘛的，然后要求模型在输出的时候一步一步思考，需不需要调用提供的工具。如果需要调用工具，那么要求模型输出固定的格式，再通过编写代码的方式来调用，整个过程就完成了。需要注意的是，使用 ReAct 架构来调用工具，要求模型必须具备思考能力，也就是说模型要足够强，能够生成思维链 。很多研究表明，大模型在7B参数规模以上会涌现思考能力，所以如果要使用 ReAct 架构来构建 Agent 的话，尽量选择7B以上模型。

• ReAct 框架调用工具 Prompt
  

Function Call

在大模型的应用中，Function Call（函数调用）是一种让大模型能够与外部工具或函数进行交互的机制。通过 Function Call，大模型可以根据具体的任务需求，动态地调用相应的函数来获取特定的信息或执行特定的操作，从而扩展大模型的能力。与 ReAct 使用 Prompt 描述工具不同，Function Call 直接将工具嵌入到模型的 Template（模板）当中，来为模型提供工具支撑。

这里我们需要先理解一下什么是 Template，我们来看一个例子。

• “你好”
• “你好”
• “你吃了吗”
• “吃了”
• “你作业做完了吗？”
• “我的已经做完了”

已知上面的对话有两个角色，A和B，我们假定是A先发起的对话，你能知道哪些对话是A说的，哪些是B说的吗？思考一下，然后我们来下面的答案。

• A：“你好”
• B：“你好”
• A：“你吃了吗”
• B：“吃了”
• A：“你作业做完了吗？”
• A：“我的已经做完了”

是不是与你想的不太一样？其实大模型在理解类似对话的时候也有同样的问题，如果不能够明确说明哪些文本是用户输入的，哪些文本是大模型输出的，那么大模型的上下文就会混乱，为了解决这个问题，需要 Template。当我们和大模型产生类似 “你是谁”，“我是大模型” 这样的对话时，其实大模型的真实输入和输出是下面这样的（以Qwen2.5为例）。

<|im_start|>system
You are Qwen, created by Alibaba Cloud. You are a helpful assistant.<|im_end|>
<|im_start|>user
你是谁<|im_end|>
<|im_start|>assistant
我是大模型<|im_end|>

上面例子中多出来的部分，就是大模型的 template。不同的大模型 template 可能不同，但是角色一般都有 system，user 和 assistant 三个角色，分别代表 系统、用户 和 大模型。

明白了大模型的 template，我们就可以看看 function call 的原理了，支持 function call 的大模型可以简单理解为在角色中新加入了一种角色 tool。所以并不是所有的大模型都支持 function call，必须要在大模型训练阶段将 tool 的概念植入进去才可以。支持 function call 的大模型，不需要使用 prompt 的方式来告诉模型有哪些工具可以调用，直接将工具作为 tool 的角色全部放入就可以。

• qwen2.5 function call 输入示例，<tools></tools> 中间的部分就是传入的可用工具。
  
• 依据大模型第一轮的输出，通过代码调用函数，将数据作为大模型的知识参考，就可以得到第二轮最终输出。
  

MCP

模型上下文协议（Model Context Protocol，MCP）是一项由 Anthropic 牵头的开放标准，旨在为大型语言模型（LLMs）与外部数据源及工具之间提供一个统一、标准化的通信接口。

传统上，不同的 AI 应用要接入数据库、API 或第三方工具，都需针对每个数据源编写单独的连接器，导致维护成本高、重复劳动多。MCP 通过定义一套通用协议，将这种 “各自为政” 变为 “统一接入”，大幅降低开发者集成多种服务的成本。

MCP 主要由宿主、客户端、服务器和基础协议四部分构成。

• 宿主（Host）：是期望从服务器获取数据的 LLM 应用，如 IDE、聊天机器人等。其职责包括初始化和管理多个客户端，负责客户端 - 服务器生命周期管理，处理用户授权决策，以及管理跨客户端的上下文聚合。

• 客户端（Client）：每个客户端与单个服务器保持一对一的有状态连接，负责在宿主和其连接的服务器之间路由请求、响应和通知。客户端在初始化期间协商协议版本和功能，维护有关服务器的可用工具、资源和提示模板的信息，以及对服务器资源的订阅，并处理资源更改时的通知事件。

• 服务器（Server）：是为 LLM 提供外部数据和上下文的基本构建块，通过工具、资源和提示词提供专门的功能。其中，工具是可执行函数，允许 LLM 与外部应用交互；资源可以是任何类型的数据，为 LLM 提供额外的上下文信息；提示模板是预定义的模板或指令，用于指导语言模型的交互。

• 基础协议（Base Protocol）：定义了不同组件之间的通信方式，其核心是使用 JSON - RPC 2.0 作为消息传递格式，定义了请求、响应和通知三种基本消息类型。协议还包括生命周期管理，用于客户端 - 服务器连接初始化、功能协商和会话控制；传输机制，如用于本地服务器的 Stdio 和用于托管服务器的 SSE；以及服务器功能和客户端功能的定义。

MCP 的原理可以简单理解为 client 访问 server，获取 server 可以使用的工具列表，然后将列表使用 function call 的方式输入给大模型。没错，MCP 调用工具的实现技术依然是 function call。

• 获取 Server 工具列表，并传入模型
  

在 Server 端，工具使用 @mcp.tool() 来进行定义，但是需要遵循一定的约定规范。例如方法的入参和出参需要表明数据类型，以及方法需要写明注释等等，目的是为了更加清晰的描述给大模型。

• Server 端工具定义
  

总结

• ReAct：将推理和动作执行相结合，引入思维链让大模型在生成答案前先输出推理步骤，展示 “思考” 过程再采取动作，能提高输出准确度。调用工具时通过提示词告知模型可调用工具及用途，要求模型逐步思考是否调用工具并按固定格式输出，再通过代码调用。使用该架构要求模型具备思考能力，建议选择 7B 以上参数规模的模型。

• Function Call：是大模型与外部工具或函数交互的机制，可按需动态调用函数获取信息或执行操作。与 ReAct 不同，其将工具嵌入模型的 Template 中为模型提供支撑。支持 Function Call 的模型需在训练阶段植入该概念，可直接将工具作为 tool 角色放入。

• MCP：即模型上下文协议，是 Anthropic 牵头的开放标准，为大模型与外部数据源及工具提供统一通信接口，降低开发者集成服务成本。由宿主（管理客户端、处理授权等）、客户端（与服务器保持连接、路由请求等）、服务器（提供外部数据和上下文，含工具、资源、提示模板）和基础协议（使用 JSON - RPC 2.0 定义通信方式，包括消息类型、生命周期管理、传输机制等）四部分构成。其调用工具的实现技术是 Function Call，Server 端使用 @mcp.tool () 定义工具需遵循约定规范。