详细介绍：一篇文章讲清Prompt、Agent、MCP、Function Calling
如果你最近关注AI 领域，一定会被一堆新名词“轰炸”：Agent、MCP、Function Call……
每个人的说法都不一样——有人把Agent 翻译成 智能体，有人把 MCP 比喻成 AI 时代的 USB 协议，还有人说 Function Call是大模型最关键的能力之一。
但它们到底是什么？之间又有什么关系？
别担心，今天我会用一篇文章，把Agent、MCP、Prompt 和 Function Call全部串联起来，让你彻底不再混淆。
1. Prompt
1.1. User Prompt
在最初用 GPT 的时候，我们只是单纯地跟它聊天。
比如说：
“我今天考试没考好。”
这句话，就是User Prompt（用户提示词）—— 用户直接说出口的内容。
1.2. System Prompt
单靠 User Prompt，AI 的回答往往都是中规中矩、客观理性的：
- “别灰心，可能总结一下错题。”
- “考不好没关系，努力就好。”
但现实中，不同的人会给出截然不同的反应：
- 老师：你要复习基础知识，多刷题。
- 好朋友：哈哈，没事，下次我带你去玩，放松一下。
- 妈妈：是不是手机玩太多了？
为了让 AI 带上这些“角色感”，我们需要额外告诉它：
“你现在是我的好朋友友。”
再输入同样的 User Prompt：
“我今天考试没考好。”
AI 这时就可能说：
哈哈，没事，下次我带你去玩，放松一下。
这种“角色设定”的信息，就是System Prompt（体系提示词）。
它专门用来规定 AI 的身份、语气和风格。
System Prompt主要用来描述 AI 的角色、性格、背景、信息、语气等等——总之，凡是不是用户直接说出来的内容，都可以放进 System Prompt。每次用户发送User Prompt时，系统都会自动把System Prompt一起发送给 AI 模型，这样整个对话就显得更加自然、连贯。
在网页端的聊天机器人中，System Prompt 往往是 系统预设，用户无法随意更改。但通常平台会供应一些自定义机制，比如 ChatGPT 里的Customize ChatGPT，用户可以在其中写下自己的偏好，这些偏好会自动成为System Prompt的一部分，从而影响 AI 的表现风格。
2. Agent
在前面我们讲了User Prompt 和 System Prompt，也就是 AI 的输入和角色设定。即使 System Prompt 再完美，AI本质上还是一个聊天机器人——它许可给你答案，或者告诉你该怎么做，但实际动手的还是你自己。
那么问题来了：
能不能让 AI自己去完成任务，而不是只给出建议呢？
这就引出了 Agent 的概念。
第一个尝试让 AI 自主执行任务的开源项目是Auto-GPT。
Auto-GPT 本质上是一个本地运行的小程序：把 AI 的思考和操作分开，让 AI 可以就是，它的核心思想调用工具完成任务。
举个例子：
假如你想让 Auto-GPT 帮你管理电脑里的记录，你必须先准备一些函数：
list_files：列出目录read_file：读取文件- ……其他文件管理函数
然后，你把这些函数以及它们的功能描述和运用手段注册到 Auto-GPT 中。
Auto-GPT 会根据这些信息生成一个System Prompt，告诉 AI：
- 用户给了你哪些工具
- 这些软件是干什么的
- 倘若想启用它们，AI 应该返回什么格式的调用信息
接下来，当用户发送请求，例如：
“帮我找一下元神的安装目录”
AI 会根据 System Prompt 判断：
- 调用哪个函数（比如
list_files） - 返回指定格式的信息
Auto GPT 解析 AI 的输出后，会自动调用对应函数，随后把结果再返回给 AI。AI 会根据函数结果继续决定下一步操作，这个循环不断进行，直到任务结束。
该过程就这样反复，直到任务完成为止，人们把 Auto GPT此种负责在模型工具和最终用户之间传话的程序，就叫做AI Agent, 而这些献出给AI调用的函数或者服务就叫做 Agent Tool
- AI Agent：负责在模型、工具和最终用户之间传话的程序，让 AI 能够自主执行任务
- Agent Tool：供应给 AI 调用的函数或服务，AI 可以通过它们完成具体操作
简单来说 AI 类似于大脑，Agent 相当于传话员，Tool 类似于手和脚（执行操作）。
3. Function Calling —— 规范化的应用调用方式
在前面介绍的AI Agent架构中，我们通过System Prompt告诉模型有哪些工具、该怎么调用、返回的格式是什么。但问题是：
按照你要求的格式返回结果，往往会出现“答非所问”或者“格式不对”的情况。为了纠正这种“调皮”的行为，很多Agent框架会在发现AI返回错误时进行就是AI模型本质上是一个概率模型，它并不总自动重试。虽然此种办法能解决问题，但重试过多会浪费 Token 成本，也显得不够稳定。
于是，大模型厂商开始出手，推出了Function Calling功能。它的核心思想就是：统一格式、规范描述。
- 在 Function Calling 中，每个工具都用JSON 对象来定义：
- 工具名写在
name字段 - 功能说明写在
description字段 - 所需参数写在
parameters字段 - 这些工具描述被单独放在一个字段中，不再混在 system prompt 里。
- 模型在调用设备时，也必须返回符合规定的 JSON 格式
这样一来：
- 工具描述和调用结果都标准化，方便 AI 理解。
- 服务器可以自动检测和纠正错误的回复，用户几乎无感知。
- 减少了用户端的开发复杂度，也节省了 Token。
不过，Function Calling 也有一个明显疑问：没有统一标准。不同大厂（OpenAI、Anthropic、Google 等）定义的 API 格式各不相同，很多开源模型甚至完全不支持 Function Calling。这意味着如果你要写一个跨模型通用的 AI Agent，会非常麻烦。
4. MCP —— 让 Agent 和工具解耦的通信协议
到这里，我们讲的都是AI Agent 和模型之间的通信方式。接下来我们看另一边怎么和就是：Agent Agent Tools 交互的。
最简单的方式是：把 Agent 和 Tools 写在一个程序里，直接用函数调用解决。这也是大多数框架一开始的做法。但问题是：
- 有些工具功能很通用，比如“浏览网页”、“读取文件”，可能多个 Agent 都需要。
- 如果每个 Agent 都内置一份代码，就会造成重复和维护困难。
于是人们提出了一个更优雅的方案：把 Tools 做成服务，统一托管，让多个 Agent 来调用。这就是MCP (Model Context Protocol)。
：就是MCP 的核心作用
- 规定 Agent（MCP Client） 和 Tool 服务（MCP Server）之间的交互方式。
- MCP Server 需要提供接口，说明自己有哪些设备、功能描述、参数格式等等。
- 除了普通的工具（函数调用），MCP Server 还能献出：
- Resource：文件读写类的数据接口
- Prompt：提示词模板
通信方式也很灵活：
- 通过Agent 和 MCP Server 能够跑在同一台机器上，用标准输入输出（stdio）通信；
- 也可以部署在网络上，用 HTTP 通信。
这里要注意一点：MCP 本身和 AI 模型没有关系。它不管 Agent 用的是什么模型，只负责帮 Agent 管理工具、资源和提示词。
总结来说：Function Calling：解决“AI 调用工具时不规范”的问题，但各家标准不一。MCP：解决“Agent 和工具耦合太紧”的问题，用统一协议管理工具和资源。
5. 总结
MCP Client）：就是结果，把整个流程梳理一下。假设我明天要考试，但还没复习，于是我问 AI Agent（也就“我明天考试该怎么复习比较高效？”
- 用户提问
这个问题会被包装成User Prompt，交给 AI Agent。 - Agent 获取工具信息
Agent 通过MCP 协议，从 MCP Server那里获取所有工具的信息。
这些工具信息可能会被 Agent 转换成System Prompt的形式，也可能转成Function Calling的 JSON 格式，然后和用户的 User Prompt 一起打包，发送给AI 模型。 - AI 模型决定用哪个工具
AI 模型收到后，发现有一个名叫Web Browse的网页浏览工具。它便产生一个调用请求（普通回复或 Function Calling 格式），表示要上网搜索“考试复习方法”。 - 工具调用
Agent 收到这个请求，再通过 MCP 协议去调用 MCP Server 里的Web Browse 工具。
Web Browse 访问指定网站，把内容返回给 Agent。 - AI 模型生成答案
Agent 把搜索结果交还给 AI 模型，模型结合网页内容和自身知识，终于给出答案：“先整理重点，再做历年真题，末了保证充足睡眠。” - 结果展示
Agent 再把最终结果展示给用户。
这就是 System Prompt、User Prompt、AI Agent、Agent Tool、Function Calling、MCP、AI 模型之间的联系与区别。它们不是互相取代的关系，而是像一个个齿轮一样，彼此配合，最终构成了完整的AI 自动化协作完整体系。