AI Agent、MCP、Prompt 与 Function Calling：关键概念全解
聊天机器人的起点：Prompt
2023年 OpenAI 发布 GPT 时，AI 看起来只是一个聊天框。我们发送一条消息给 AI 模型，模型生成一个回复。我们发的消息叫做 User Prompt（用户提示词），一般就是提出的问题或想说的话。
但现实生活中，即便是完全相同的话，不同的人也会根据自己的经验给出不同的回答。比如你说肚子疼，妈妈可能会问要不要去医院，爸爸可能会让你去厕所，女朋友可能直接来一句"滚一边去"。AI 没有这种人设，只能给出一个通用的、四平八稳的回答，显得非常无趣。
于是人们希望给 AI 加上人设。最初的做法是把人设信息和用户要说的话打包成一条 User Prompt。但这样做有一个问题——人设描述并不是我们真正想说的内容，显得有点出戏。于是人们把人设信息单独拎出来，放到另外一个 Prompt 里，这就是 System Prompt（系统提示词）。
System Prompt 主要用来描述 AI 的角色、性格、背景、语气等。只要不是用户直接说出来的内容，都可以放进去。每次用户发送 User Prompt 时，系统会自动把 System Prompt 一起发给 AI 模型，整个对话就更加自然了。在网页端的聊天机器人中，System Prompt 往往是系统预设的，用户通常不能直接更改，但一般会提供一些设置入口，比如 ChatGPT 的 Customize ChatGPT 功能，让用户写下自己的偏好，这些偏好会自动变成 System Prompt 的一部分。
从聊天到执行：AI Agent 的诞生
即便人设设定得再完美，AI 说到底还是个聊天机器人。你问一个问题，它最多给你答案或告诉你怎么做，实际动手的还是你自己。那么能不能让 AI 自己去完成任务呢？
第一个做出尝试的开源项目叫做 AutoGPT，它是本地运行的一个小程序。如果你想让 AutoGPT 帮你管理电脑里的文件，你需要先写好一些文件管理函数，比如 list_files 用来列目录、read_file 用来读文件等，然后把这些函数及其功能描述、使用方法注册到 AutoGPT 中。
AutoGPT 会根据这些信息生成一个 System Prompt，告诉 AI 模型：用户给了你哪些工具、它们是干什么的、如果想使用应该返回什么格式。最后把这个 System Prompt 连同用户的请求一起发给 AI 模型。如果 AI 足够聪明，就会按照要求的格式返回一个调用某个函数的消息。AutoGPT 解析后就可以调用对应的函数，再把结果丢回给 AI，AI 再根据函数调用的结果决定下一步操作。这个过程反复进行，直到任务完成。
人们把这种负责在 AI 模型、工具和最终用户之间传话的程序叫做 AI Agent，而这些提供给 AI 调用的函数或服务就叫做 Agent Tool。
从 System Prompt 到 Function Calling
上述架构有一个问题：虽然在 System Prompt 中写清楚了 AI 应该用什么格式返回，但 AI 模型本质上是概率模型，还是有可能返回格式不对的内容。为了处理这些情况，很多 AI Agent 会在发现格式不对时自动重试。现在市面上很多知名的 Agent，比如 Claude，仍然采用这种方式，但反复重试总归让人觉得不太靠谱。
于是大模型厂商开始出手了。ChatGPT、Claude 等纷纷推出了一个叫做 Function Calling 的新功能。其核心思想是：统一格式，规范描述。
每个 Tool 都用一个 JSON 对象来定义：工具名写在
name字段，功能说明写在description字段，所需的参数写在parameters里。这些 JSON 对象从 System Prompt 中被剥离出来，单独放到了一个专门的字段中。
Function Calling 也规定了 AI 使用工具时应该返回的格式，因此 System Prompt 中的格式定义也可以删掉了。
这样一来，所有工具描述都放在相同的地方、依照相同的格式，AI 使用工具时的回复也遵循统一的格式。开发者能更有针对性地训练 AI 模型理解调用场景。即使 AI 生成了错误的回复，由于格式是固定的，AI 服务器端自己就能检测并重试，用户根本感觉不到。不仅降低了开发难度，也节省了重试带来的 Token 开销。
不过 Function Calling 也有自己的问题：没有统一标准，每家大厂的 API 定义都不一样，很多开源模型还不支持。所以要写一个跨模型通用的 AI Agent 其实挺麻烦。因此 System Prompt 和 Function Calling 两种方式在市面上是并存的。
工具共享：MCP 协议
以上讲的都是 AI Agent 和 AI 模型之间的通信方式。接下来看另一边：AI Agent 是怎么跟 Tool 进行通信的？
最简单的做法是把 Agent 和 Tool 写在同一个程序里，直接函数调用。这也是现在大多数 Agent 的做法。但人们逐渐发现，有些 Tool 的功能其实很通用，比如一个浏览网页的工具，可能多个 Agent 都需要。总不能在每个 Agent 里都拷贝一份相同的代码。
于是大家想到了一个办法：把 Tool 变成服务，统一托管，让所有 Agent 都来调用。这就是 MCP。
MCP 是一个通信协议，专门用来规范 Agent 和 Tool 服务之间的交互。运行 Tool 的服务叫做 MCP Server，调用它的 Agent 叫做 MCP Client。MCP 规定了 Server 如何和 Client 通信，以及 Server 要提供哪些接口——比如查询 Server 中有哪些 Tool、Tool 的功能描述、需要的参数格式等接口。
除了普通的 Tool（函数调用形式），MCP Server 还可以提供数据（类似文件读写的 Resource），或者为 Agent 提供提示词模板（Prompt）。MCP Server 既可以和 Agent 跑在同一台机器上通过标准输入输出通信，也可以部署在网络上通过 HTTP 通信。
需要注意的是，虽然 MCP 是为 AI 定制出来的标准，但它本身和 AI 模型没有直接关系。它并不关心 Agent 用的是哪个模型，只负责帮 Agent 管理工具、资源和提示词。
完整流程梳理
假设你听说女朋友肚子疼，于是问 AI Agent："我女朋友肚子疼应该怎么办？"
Agent 把问题包装在 User Prompt 中。
Agent 通过 MCP 协议从 MCP Server 里获取所有 Tool 的信息。
Agent 把这些 Tool 的信息转化成 System Prompt 或 Function Calling 的格式，和 User Prompt 一起打包发送给 AI 模型。
AI 模型发现有一个叫
web_browse的网页浏览工具，于是通过普通回复或 Function Calling 格式产生一个调用请求，希望去网上搜索答案。Agent 收到请求后，通过 MCP 协议调用 MCP Server 里的 Web Browse 工具，该工具访问指定网站后将内容返还给 Agent，Agent 再转发给 AI 模型。
AI 模型根据网页内容和自身知识生成最终答案。
Agent 把结果展示给用户。
总结
System Prompt、User Prompt、AI Agent、Agent Tool、Function Calling、MCP、AI 模型——它们不是彼此取代的关系，而是像齿轮一样，共同构成了 AI 自动化协作的完整体系。
✦ 值得思考的句子
即便是完全相同的话，对方也会根据自己的经验给出不同的答案。
说到底 AI 还是个聊天机器人。你问一个问题，它最多给你答案或者告诉你怎么做，但实际动手的还是你自己。
它们不是彼此取代的关系，而是像齿轮一样，一起构成了 AI 自动化协作的完整体系。
我们都太渺小了，活在了时代的缝隙里。大多数时候，我们只能眼睁睁地看着洪流呼啸而过。
过去每一次科技巨变，普通人也都只是被推着往前走，也许换了一种工作或生活的方式，却始终站在了改变之外。如果说注定要与时代撞个满怀的话，那这次我想清醒地迎上去。