简介

本文详细解析了AI编程中的关键概念：Prompt（用户提示词和系统提示词）用于设定AI角色与上下文；Agent（智能体）能自主完成任务并调用工具函数；Function Calling提供标准化工具调用方式；MCP（模型上下文协议）作为Agent与Tool间的通信标准。这些技术共同构成了AI自动化协作体系，不是彼此取代而是相互配合的关系。理解这些概念有助于开发者更好地利用大模型进行AI应用开发。

---

这几天在尝试使用AI编程工具，试用了Cursor、Trae、CodeBuddy这三个工具，编辑器都大同小异，区别主要集中在模型上，这几天体验下来，国内外的模型差别还是挺明显的。

不过今天不是讲模型的区别，而是使用过程中我发现很多问题，比如AI编写确实快，但是错误比较多，而且它喜欢自己头脑风暴，想解决这个就得提示词优化的很好，需求做的更详细。

不单单是这个问题，在出现错误的时候，本地部署访问去排错一个找很麻烦，所有我就想着怎么让IDE里的模型有别的功能，可以和外界交互，就像智能体一样，集成很多工具进去，我就发现了有一个叫MCP的东西。

所以这篇文章啰嗦半天，主题就是想给大家介绍一下MCP、提示词、智能体分别是什么。

有人说Agent是智能体，那智能体又是什么呢？有人说MCP是AI时代的USB协议，那么它可以接U盘吗？他们到底都是什么意思？今这篇文章我会用尽量简单的语言，把Agent、MCP、Prompt以及Function Calling这几个关键概念全都讲清楚。

---

Prompt

2023年OpenAI刚刚发布GPT的时候，AI看起来只是一个聊天框。我们通过聊天框发送一条消息给AI模型，然后AI模型生成一个回复。

我们发的消息就叫User Srompt，也就是用户提示词。一般就是我们提出的问题或者想说的话，但是现实生活中，当我们和不同人聊天时，即便是完全相同的话，对方也会根据自己的经验给出不同的答案。

比如我说我肚子疼，我妈听见了可能会问我要不要去医院，我爸可能会让我去厕所，我女朋友可能直接就来一句，滚一边去，老娘也疼。

但是AI并没有这样的人设，所以他就只能给出一个通用的回答，显得非常无趣。如身体不适，请就医！在其他不同的场景时候，也是这样，回答的我们并不满意，所以就需要给AI也加上人设，最直接的方法就是把人设信息用户要说的话打包成一条User Prompt发过去。

比如告诉大模型：你扮演我的女朋友，我说我肚子疼，然后AI就可能回复滚一边去，老娘也疼，这样就对味儿了。

但问题是如果你不给他加一个更立体的人设，或告诉它什么样的预期输出，那么它给出的结果并不是我们真正想要的内容，甚至会显得有一点出戏。

于是干脆把人设信息单独的拎了出来，放到另外一个Prompt里面。这就是System Prompt系统提示词。

System Prompt主要用来描述AI的角色、性格、背景、信息、语气等等等等。你可以当作是一个基础的人设，总之只要不是用户直接说出来的内容，都可以放进System Prompt里面，毕竟用户的提问也不可能面面俱到。

每次用户发送user prompt的时候，系统会自动把system prompt也一起发给AI模型，这样整个对话就显得更加自然了。

在网页端的聊天机器人中，system prompt往往是系统预设的，用户不能随便更改。但通常来讲网站会提供一些设置，比如说ChatGPT里面有一个叫做Customized ChatGPT的功能，用户可以在里面预设自己的偏好，这些偏好就会自动变成system prompt的一部分。

不过即使人设设定的再完美，系统还只是个聊聊天机器人，你问一个问题他最多给你答案，或者告诉你怎么做，但实际动手的还是你自己。

Agent

那么能不能让AI自己去完成任务呢？

第一个做出尝试的是一个开源项目叫做Auto GPT，它是本地运行的一个小程序。如果你想让Auto GPT帮你管理电脑里的文件，那你得先写好一些文件的管理函数。比如说list files用来列目录，read files用来读文件等等。

然后你把这些函数以及它们的功能描述、使用方法注册到auto GPT中。Auto GPT会根据这些信息生成一个System Prompt，告诉AI模型用户给了你哪些工具，他们都是干什么的，以及AI如果想要使用它们应该返回什么样的格式。

然后把这个System Prompt连同用户的请求，比如说帮我找一下某个游戏的安装目录，一起发给AI模型。如果AI模型足够聪明，就会按照要求的格式，返回一个调用某个函数的消息。Auto GPT进行解析之后就可以调用对应的函数了。然后再把结果丢回给AI。

AI再根据函数调用的结果决定下一步应该做什么操作。这个过程就这样反复，直到任务完成为止。我们把Auto GPT这种负责在模型工具和最终用户之间传话的程序，就叫做AI Agent。

而这些提供给AI调用的函数或者服务就叫做Agent Tool。

不过这个架构有一个小问题，虽然我们在System Prompt里面写清楚了AI应该用什么格式返回，但AI模型嘛，说到底它是一个抽盒，用过AI生图的都知道，它有可能返回格式不对的内容。

为了处理这些不听话的情况，很多AI Agent会在发现AI返回的格式不对时，自动进行重试。一次不行我们就来第二次。现在市面上很多知名的Agent，比如Clien仍然采用的是这种方式。

但这种反复的重试总归让人觉得不太靠谱。

于是大模型厂商开始出手了，ChatGPT、Claude、Gemini等等，推出了一个叫做Function Calling的新功能。

这个功能的核心思想就是统一格式规范描述。回到之前游戏的例子，我们通过System Prompt告诉AI有哪些工具以及返回的格式。不过这些描述是用自然语言写的，只要AI看得懂就行。

而Function Calling则对这些描述进行了标准化。

比如每个Tool都用一个Json对象来定义工具名，将工具名写在name字段，功能说明写在description字段，所需要的参数写在parameters里面等等。

然后这些Json对象也从System Prompt中被剥离了出来，单独放到了一个字段里面。最后Function Calling也规定了AI使用工具时，应该返回的格式，所以System Prompt中的格式定义也可以删掉了。

这样一来，所有的工具描述都放在相同的地方，所有工具描述也都依照相同的格式。AI使用工具时的回复也都依照相同的格式。然后我们就能更加有针对性的训练AI模型，让它理解这种调用的场景。

甚至在这种情况下，哪怕AI依然生成了错误的回复，因为回复的的格式是固定的。AI服务器端自己就可以检测到并且进行重试，用户根本感觉不到。

这样一来不仅降低了用户端的开发难度，也节省了用户端重试带来的Token消耗。因为有这些好处，现在越来越多的AI Agent开始从System Prompt转向Function Calling。

但Function Calling也有自己的问题，就是没有统一的标准。每家大厂的API定义都不一样，而且很多开源模型还不支持Function Calling。所以真的要写一个跨模型通用的AI Agent其实还挺麻烦的。

因此System Prompt和Function Calling这两种方式现在在市面上是并存的。以上我们讲的都是AI agent和AI模型之间的通信方式。

MCP

接下来我们再看另一边，AI Agent是怎么跟AI Tools来进行通信的。最简单的做法是把AI agent和Agent Tool写在同一个程序里面，直接函数调用就搞定的，这也是现在大多数Agent的做法。

但是后来人们逐渐发现，有些Tool的功能其实挺通用的。比如说一个浏览网页的工具，可能多个Agent都需要，但我总不能在每个Agent里面都拷贝一份相同的代码吧，太麻烦了。

于是大家想到了一个办法，把Tool变成服务统一的托管，让所有的Agent都来调用，这就是MCP（Model Context Protocol）即模型上下文协议。

MCP是一个开放的标准化通信协议，专门用来规范Agent和Tool服务之间是怎么交互的。

运行Tool的服务叫做MCP Server，调用它的Agent叫做MCP Client。

MCP规定了MCP Server如何和MCP Client通信，以及MCP Server要提供哪些接口。比如说用来查询MCP Server中有哪些Tool的功能，描述需要的参数、格式等接口。

除了普通的Tool这种函数调用的形式，MCP Server也可以直接提供数据，提供类似文件读写的服务叫做Resources，或者为Agent提供提示词的模板叫做Prompt。

MCP Server既可以和Agent跑在同一台机器上，通过标准输入输出进行通信，也可以被部署在网络上通过HTTP进行通信。这里需要注意的是，虽然MCP是为了AI而定制出来的标准，但实际上MCP本身却和AI模型没有关系。

他并不关心agent用的是哪个模型，MCP只负责帮Agent管理工具、资源和提示词。

总之这就是System Prompt、User Prompt、AI Agent,、Agent Tool、Function Calling、MCP、AI模型之间的联系与区别了。它们不是彼此取代的关系，而是像齿轮一样，一起构成了AI自动化协作的完整体系。

很多人说AI的飞速发展让人焦虑，说人类最终会被AI取代。未来会不会真的变成那样我不知道，但我心里更常浮现的并不是恐惧，而是一种隐约的激动。

因为我们正处在一个大变革时代的初期，每个人都太渺小了，我们在时代的缝隙里，大多数时候我们只能眼睁睁的看着洪流呼啸而过。

过去我们所发生的每一次科技巨变，普通人也都只是被推着往前走，也许他们换了一种工作或者生活的方式，但是却始终站在了改变之外。

在这次的AI浪潮中，我不想自己被这样裹挟着前行。如果说注定要与时代撞个满怀的话，那我想张开双臂拥抱上去。

洪流呼啸而过。

AI大模型学习路线

如果你对AI大模型入门感兴趣，那么你需要的话可以点击这里大模型重磅福利：入门进阶全套104G学习资源包免费分享！

这份完整版的大模型 AI 学习和面试资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

这是一份大模型从零基础到进阶的学习路线大纲全览，小伙伴们记得点个收藏！

第一阶段： 从大模型系统设计入手，讲解大模型的主要方法；

第二阶段： 在通过大模型提示词工程从Prompts角度入手更好发挥模型的作用；

第三阶段： 大模型平台应用开发借助阿里云PAI平台构建电商领域虚拟试衣系统；

第四阶段： 大模型知识库应用开发以LangChain框架为例，构建物流行业咨询智能问答系统；

第五阶段： 大模型微调开发借助以大健康、新零售、新媒体领域构建适合当前领域大模型；

第六阶段： 以SD多模态大模型为主，搭建了文生图小程序案例；

第七阶段： 以大模型平台应用与开发为主，通过星火大模型，文心大模型等成熟大模型构建大模型行业应用。

100套AI大模型商业化落地方案

大模型全套视频教程

200本大模型PDF书籍

👉学会后的收获：👈

• 基于大模型全栈工程实现（前端、后端、产品经理、设计、数据分析等），通过这门课可获得不同能力；

• 能够利用大模型解决相关实际项目需求： 大数据时代，越来越多的企业和机构需要处理海量数据，利用大模型技术可以更好地处理这些数据，提高数据分析和决策的准确性。因此，掌握大模型应用开发技能，可以让程序员更好地应对实际项目需求；

• 基于大模型和企业数据AI应用开发，实现大模型理论、掌握GPU算力、硬件、LangChain开发框架和项目实战技能， 学会Fine-tuning垂直训练大模型（数据准备、数据蒸馏、大模型部署）一站式掌握；

• 能够完成时下热门大模型垂直领域模型训练能力，提高程序员的编码能力： 大模型应用开发需要掌握机器学习算法、深度学习框架等技术，这些技术的掌握可以提高程序员的编码能力和分析能力，让程序员更加熟练地编写高质量的代码。

LLM面试题合集

大模型产品经理资源合集

大模型项目实战合集

👉获取方式：
😝有需要的小伙伴，可以保存图片到wx扫描二v码免费领取【保证100%免费】🆓