Agent、MCP与Function Calling的区别与关系详解

2025年的AI技术圈里，Agent、MCP、Function Calling、Prompt等概念满天飞，不少开发者和AI爱好者被绕得晕头转向。这些术语各自解决什么问题？彼此之间又是什么关系？本文从最基础的Prompt讲起，逐层递进，帮你把这些关键概念串成一条清晰的线。

从Prompt说起：AI对话的起点

2023年ChatGPT刚上线时，AI看起来就是一个聊天框。我们发一条消息，AI回一段文字——我们发送的消息就叫做User Prompt（用户提示词），通常是一个问题或一段指令。

但问题很快暴露出来：AI没有"人设"。同样一句"我肚子疼"，你爸可能让你去厕所，你妈可能问你要不要去医院，而你老婆可能直接来一句"多喝热水"。没有角色设定的AI，只能给出通用的、四平八稳的回答。

于是System Prompt（系统提示词）应运而生。开发者把角色、性格、背景、语气等信息写进System Prompt，每次用户发消息时，系统自动把System Prompt一并发给AI模型，让对话变得更自然、更有针对性。

System Prompt的概念源于大语言模型的多轮对话架构设计。在OpenAI的Chat Completions API中，每条消息都带有一个role字段，分为system、user和assistant三种角色。system角色的消息会被模型视为最高优先级的上下文指令，影响后续所有对话的生成倾向。从技术实现上看，System Prompt并不是一种特殊的模型能力，而是通过注意力机制（Attention Mechanism）中的位置权重，让模型在生成每个token时都"记住"这段前置指令。这也是为什么过长的System Prompt会挤占有效上下文窗口，导致模型对后续对话内容的理解能力下降。

在ChatGPT等产品中，System Prompt通常由平台预设，用户无法直接修改。不过平台会提供偏好设置功能，这些偏好会自动融入System Prompt。

AI Agent是什么：让AI从"动嘴"变成"动手"

人设设定得再好，AI本质上还是个聊天机器人——你问问题，它给答案，真正干活的还是你自己。那能不能让AI自己去完成任务呢？

最早做出尝试的是一个叫AutoGPT的开源项目。AutoGPT于2023年3月由开发者Significant Gravitas在GitHub上发布，上线仅一周便获得超过5万Star，成为GitHub历史上增长最快的开源项目之一。它的核心创新在于引入了"思考-行动-观察"（Reason-Act-Observe）的循环范式，这一范式后来被学术界总结为ReAct框架。在AutoGPT之前，类似的思路已经在LangChain等框架中有所体现，但AutoGPT是第一个将其包装成端到端自主运行产品的项目。

它的工作原理分三步：

1. 注册工具：预先编写好一些函数（如列目录、读文件等），把函数名、功能描述、调用方式注册到程序中
2. 生成System Prompt：程序根据注册信息自动生成System Prompt，告诉AI有哪些工具可用、怎么调用、应该返回什么格式
3. 循环执行：将System Prompt和用户请求一起发给AI，AI按约定格式返回调用指令，程序解析后执行对应函数，再把结果喂回AI，如此循环直到任务完成

不过早期AutoGPT也暴露了严重问题：由于GPT-3.5/4的推理能力有限，Agent经常陷入死循环或做出错误的工具调用决策，Token消耗巨大却完不成任务，这也推动了后续Function Calling等标准化方案的诞生。

这个负责在模型、工具和用户之间传话的程序，就是AI Agent（智能体）。而那些提供给AI调用的函数或服务，则被称为Agent Tools。

Function Calling的作用：从"自由发挥"到"标准化调用"

Agent架构虽然跑得通，但有一个绕不开的问题：即使在System Prompt里写清楚了返回格式，AI作为概率模型，仍然可能输出格式不对的内容。很多Agent会在检测到格式错误时自动重试，但这种方式终究不够稳定。

于是大模型厂商亲自下场。OpenAI、Anthropic（Claude）、Google（Gemini）等先后推出了Function Calling功能，核心思路就是把工具调用的格式统一规范起来。

Function Calling并非简单的提示词工程，而是在模型训练和推理层面做了专门优化。以OpenAI为例，GPT模型在微调阶段使用了大量函数调用的标注数据，让模型学会在合适的时机生成结构化的JSON调用指令，而非自然语言回复。在推理时，模型的输出会经过一个专门的解析层（Parser），确保生成的JSON严格符合预定义的Schema。这种"受约束解码"（Constrained Decoding）技术可以在token生成过程中实时校验语法合法性，从根本上避免格式错误。Anthropic的Claude采用了类似的Tool Use机制，而Google Gemini则将其称为Function Declaration。值得注意的是，开源社区也在跟进，Ollama、vLLM等推理框架已经开始支持部分模型的Function Calling能力。

相比纯System Prompt的方式，Function Calling在三个层面做了改进：

工具描述标准化

每个工具用一个JSON对象来定义：工具名称放在name字段，功能说明放在description字段，所需参数放在parameters字段。这些JSON对象从System Prompt中剥离出来，放到API请求的专用字段中。

返回格式固定化

Function Calling规定了AI调用工具时必须遵循的返回格式，System Prompt中关于格式的冗长说明可以直接删掉。工具描述统一存放、格式一致，AI的回复也严格遵循规范。

错误处理服务端化

回复格式固定后，AI服务端可以在内部自行检测并重试，客户端完全无感知。这既降低了开发难度，也省下了客户端重试产生的Token开销。

不过Function Calling目前也有短板：各家厂商的API定义不完全一致，不少开源模型也还不支持这一特性。所以在实际项目中，System Prompt方式和Function Calling方式是并存的。

MCP协议详解：Agent与工具之间的"USB接口"

前面讨论的是AI Agent和AI模型之间怎么通信。接下来看另一侧——AI Agent怎么跟Tools打交道。

最直接的做法是把Agent和Tools放在同一个程序里，通过函数调用直接交互。大多数早期Agent确实是这么做的。但随着工具生态不断壮大，一个现实问题浮出水面：有些工具功能非常通用（比如浏览网页、查询数据库），多个Agent都需要用，但不可能在每个Agent里都拷贝一份相同的代码。

于是Anthropic提出了MCP（Model Context Protocol，模型上下文协议）。MCP协议由Anthropic于2024年11月正式发布并开源，其设计灵感来源于微软的LSP（Language Server Protocol，语言服务器协议）。LSP通过定义编辑器与语言服务之间的标准协议，让任何编辑器都能复用同一套语言分析服务——比如你在VS Code、Vim或Sublime Text中都能获得相同的代码补全和错误检查体验，背后是同一个语言服务器在工作。MCP将这一思路迁移到AI工具生态中，让不同的Agent都能通过统一协议调用同一套工具服务。

MCP基于JSON-RPC 2.0协议构建，支持请求-响应和通知两种消息模式。JSON-RPC是一种轻量级的远程过程调用协议，使用JSON作为数据格式，天然适合Web环境下的服务间通信。

MCP的核心概念包括：

• MCP Server：运行工具的服务端，对外提供标准化接口，包括查询可用工具列表、功能描述、参数格式等
• MCP Client：调用工具的Agent端，负责发起请求并处理返回结果
• 三种能力：除了常规的Tools（函数调用），MCP Server还可以提供Resource（类似文件读写的数据服务）和Prompt（可复用的提示词模板）

在部署方式上，MCP Server既可以和Agent跑在同一台机器上，通过标准输入输出（stdio）通信；也可以部署在远程服务器上，通过HTTP协议进行网络通信。

截至2025年初，MCP生态已经涌现出数百个社区贡献的Server实现，覆盖数据库查询、文件系统操作、API集成、浏览器自动化等常见场景。Cursor、Windsurf、Claude Desktop等主流AI产品已原生支持MCP协议。不过MCP目前仍处于快速迭代阶段，协议规范尚未完全稳定，远程部署场景下的认证授权机制（OAuth 2.1）也在持续完善中。

有一点需要特别强调：MCP是为AI工具生态设计的标准，但它和AI模型之间没有直接关系。MCP不关心Agent背后用的是GPT、Claude还是开源模型，它只负责帮Agent统一管理工具、资源和提示词。

一个请求的完整生命周期

把所有概念串起来，看一个完整的例子。假设你问AI Agent："我老婆肚子疼应该怎么办？"

1. Agent接收请求，将问题包装为User Prompt
2. Agent通过MCP协议向MCP Server查询所有可用的Tools信息
3. Agent将Tools信息转化为Function Calling格式（或写入System Prompt），与User Prompt一起打包发送给AI模型
4. AI模型判断需要使用一个叫Web Browse的网页浏览工具，于是通过Function Calling格式生成一条调用请求
5. Agent收到调用请求后，通过MCP协议调用MCP Server中对应的工具，工具访问指定网站并抓取内容
6. 网页内容返回给AI模型，AI结合检索到的信息和自身知识生成最终答案
7. Agent将结果展示给用户

整个过程中，Prompt负责传递信息，Function Calling负责规范Agent与模型的对话，MCP负责规范Agent与工具的交互，AI模型负责理解和推理，Agent则是把所有环节串起来的调度中枢。

总结：五个概念各司其职

System Prompt、AI Agent、Function Calling、MCP和AI大模型之间，并不是彼此替代的关系，而是像齿轮一样咬合在一起，共同驱动AI自动化协作的完整体系：

概念	角色定位
Prompt	AI的输入信息，包括System Prompt（角色设定）和User Prompt（用户指令）
AI Agent	在模型、工具和用户之间居中调度的核心程序
Function Calling	Agent与AI模型之间的标准化工具调用方式
MCP	Agent与工具服务之间的标准化通信协议
AI模型	理解需求、规划步骤、生成回复的推理引擎

理解了这五个概念之间的分工与协作，你就掌握了当前AI应用开发的核心架构。无论是用LangChain搭建RAG系统，还是从零开发自己的AI Agent，这套认知框架都是绑不开的基础。

其中，LangChain是目前最流行的AI应用开发框架之一，由Harrison Chase于2022年创建，提供了构建Agent、管理Prompt、编排工具链的完整工具集。而RAG（Retrieval-Augmented Generation，检索增强生成）是一种将外部知识库与大语言模型结合的技术架构：先通过向量检索从知识库中找到与用户问题最相关的文档片段，再将这些片段作为上下文注入Prompt，让模型基于真实数据生成回答，从而有效缓解大模型的"幻觉"问题。RAG系统的典型流程包括文档分块、向量化（Embedding）、存入向量数据库（如Pinecone、Milvus、Chroma）、语义检索和增强生成五个步骤。在实际应用中，RAG系统往往需要与Agent架构结合，由Agent决定何时触发检索、如何组合多轮检索结果，这正是本文所述各概念协同工作的典型场景。

核心要点

• AI Agent是负责在模型、工具和用户之间传话的中间程序，通过循环调用工具来自动完成任务
• Function Calling是大模型厂商推出的标准化工具调用方式，相比System Prompt方式更规范、更可靠，但各厂商标准尚未统一
• MCP（Model Context Protocol）是规范Agent与工具服务之间通信的协议，类似AI时代的USB标准，与具体AI模型无关
• System Prompt、Agent、Function Calling、MCP和AI模型不是替代关系，而是像齿轮一样共同构成AI自动化协作的完整体系
• 目前System Prompt和Function Calling两种方式在市面上并存，开发跨模型通用Agent仍有一定挑战