这段时间各种AI名词一波接一波的冲击着我的屏幕，agent、mcp function它们都是什么东西？ 有人说agent是智能体，那智能体又是什么呢？ 有人说mcp是AI时代的usb协议，那么它可以接优盘吗？ 他们到底都是什么意思？ 今天我会用一期视频，用尽量简单的语言，把agent、M C P、prompt以及方身口令这几个关键概念全都串联起来。 现在就让我们开始。 2023年OpenAI刚刚发布GPT的时候，AI看起来只是一个聊天框，我们通过聊天框发送一条消息给AI模型，然后AI模型生成一个回复，我们发的消息就叫user prompt，也就是用户提示词，一般就是我们提出的问题或者想说的话。 但是现实生活中，当我们和不同人聊天时，即便是完全相同的话，对方也会根据自己的经验给出不同的答案。 比如我说我肚子疼，我妈可能会问我要不要去医院，我爸可能会让我去厕所，我女朋友可能直接就来一句，滚一边去，老娘也疼。 但是A并没有这样的人设，所以她就只能给出一个通用的四平八稳的回答，显得非常无趣，于是我们就希望给AI也加上人设，最直接的方法就是把人设信息和用户要说的话打包成一条user prompt发过去。 比如你扮演我的女朋友，我说我肚子疼，然后A就可能回复滚一边去，老娘也疼，这样就对味了。 但问题是，你扮演我温柔的女朋友这句话并不是我们真正想说的内容，显得有一点出戏。 于是人们干脆把人设信息单独的拎了出来，放到另外一个prompt里面，这就是system prompt系统提示词。 System prompt主要用来描述AI的角色、性格、背景、信息、语气等等等等。 总之只要不是用户直接说出来的内容，都可以放进system prompt里面。 每次用户发送user prompt的时候，系统会自动把system prompt也一起发给AI模型，这样整个对话就显得更加自然了。 在网页端的聊天机器人中，system prompt往往是系统预设的，用户不能随便更改。 但通常来讲，网站会提供一些设置，比如说ChatGPT里面有一个叫做customize ChatGPT的功能，用户可以在里面写下自己的偏好，这些偏好就会自动变成system prompt的一部分。 不过即使人设设定的再完美，说到底AI还是个聊天机器人。 你问一个问题，他最多给你答案或者告诉你怎么做，但实际动手的还是你自己。 那么能不能让A自己去完成任务呢？ 第一个做出尝试的是一个开源项目，叫做auto GPT t它是本地运行的一个小程序。 如果你想让auto g帮你管理电脑里的文件，那你得先写好一些文件的管理函数，比如说list fil用来列目录，read fil用来读文件等等等等。 然后你把这些函数以及它们的功能描述使用方法注册到auto GPT中，auto GPT会根据这些信息生成一个system prompt，告诉AI模型用户给了你哪些工具，他们都是干什么的，以及AI如果想要使用，他们应该返回什么样的格式。 最后把这个system prompt连同用户的请求，比如说帮我找一找原神的安装目录一起发给AI模型。 如果AI模型足够的聪明，就会按照要求的格式返回一个调用某个函数的消息auto GPT进行解析之后，就可以调用对应的函数了，然后再把结果丢回给AI，AI再根据函数调用的结果决定下一步应该做什么操作，这个过程就这样反复，直到任务完成为止。 人们把to g这种负责在模型工具和最终用户之间传话的程序就叫做AI agent，而这些提供给AI调用的函数或者服务就叫做a ent的two。 不过这个架构有一个小问题，虽然我们在system prompt里面写清楚了AI应该用什么格式返回，但AI模型嘛，说到底它是一个概率模型，还是有可能返回格式不对的内容。 为了处理这些不听话的情况，很多AI agent会在发现AI返回的格式不对时，自动进行重一次不行我们就来第二次，现在市面上很多知名的agent，比如client，仍然采用的是这种方式，但这种反复的重试总归让人觉得不太靠谱。 于是大模型厂商开始出手了，chat、gcloud等等，纷纷推出了一个叫做function col的新功能，这个功能的核心思想就是统一格式，规范描述，回到之前原神的例子，我们通过system prompt告诉AI有哪些功具以及返回的格式。 是，但是这些描述是用自然语言随意写的，只要AI看得懂就行。 Function col则对这些描述进行了标准化。 比如每个tool都用一个Jason对象来定义，工具名写在name字段，功能说明写在description字段，所需要的参数写在parameters里面等等等等。 然后这些json对象也从system prompt中被剥离了出来，单独放到了一个字段里面。 最后方co也规定了AI使用工具时应该返回的格式，所以system prompt中的格式定义也可以删掉了。 这样一来，所有的工具描述都放在相同的地方，所有工具描述也都依照相同的格式，AI使用工具时的回复也都依照相同的格式。 于是人们就能更加有针对性的训练AI模型，让他理解这种调用的场景。 甚至在这种情况下，如果AI依然生成了错误的回复，因为回复的格式是固定的，AI服务器端自己就可以检测到并且进行重试，用户根本感觉不到。 这样一来，不仅降低了用户端的开发难度，也节省了用户端重试带来的token开销。 正是由于这些好处，现在越来越多的AI agent开始从system prompt转向function col但. Function col也有自己的问题，就是没有统一的标准，每家大厂的api定义都不一样，而且很多开源模型还不支持方col所以真的要写一个跨模型通用的AI agent其实还挺麻烦的，因此system prompt和function这两种方式现在在市面上是并存的，以上我们讲的都是AI agent和AI模型之间的通信方式，接下来我们再看另一边，AI agent是怎么跟AI to来进行通信的？ 最简单的做法是把AI agent和agent的to写在同一个程序里面直接函数调用。 搞定，这也是现在大多数A枕的做法。 但是后来人们逐渐发现，有些拓的功能其实挺通用的。 比如说一个浏览网页的工具，可能多个agent都需要，但我总不能在每个agent里面都拷贝一份相同的代码吧，太麻烦了也不优雅。 于是大家想到了一个办法，把to变成服务，统一的托管，让所有的agent都来调用，这就是mcp。 Mcp是一个通信协议，专门用来规范agent和to服务之间是怎么交互的运行to的服务叫做p server，调用它的agent叫做mcp client。 P规定了mcp server如何和p client通信，以及mcp server要提供哪些接口。 比如说用来查询p server中有哪些to to的功能描述需要的参数格式等等的接口。 除了普通的to这种函数调用的形式，mcp server也可以直接提供数据，提供类似文件读写的服务，叫做resource，或者为agent提供提示词的模板叫做prompt。 Mcp server既可以和agent跑在同一台机器上，通过标准输入输出进行通讯，也可以被部署在网络上，通过http进行通信，这里需要注意的是，虽然mcp是为了AI而定制出来的标准，但实际上mcp本身却和AI模型没有关系，它并不关心agent用的是哪个模型，它只负责帮agent管理工具、资源和提示词。 最后我们梳理一下整个流程。 我听说女朋友肚子疼，于是问AI agent或者说的client，我女朋友肚子疼应该怎么办？ Agent会把问题包装在user prompt中，然后agent通过P协议从mp server里面获取所有tool的信息。 AI agent会把这些tool的信息或者转化成system prompt，或者转化成function col的格式，然后和用户请求user prompt一起打包发送给AI模型，AI模型发现有一个叫做web brow的网页浏览工具，于是通过普通回复或者function col格式产生一个调用这个tool的请求。 希望去网上搜索答案。 Agent收到了这个请求之后，通过mcp协议去调用mcp server里的y Bross工具y bro访问指定的网站之后，将内容返还给agent，agent在转发给AI模型，AI模型再根据网页内容和自己的头脑风暴生成最终的答案，多喝热水，最后由agent把结果展示给用户之后。 我的女朋友是如何夸我贴心的，这里我就不细说了。 总之，这就是system prompt、user prompt、AI agent、agent tool function Colding、mcp AI模型之间的联系与区别了。 它们不是彼此取代的关系，而是像齿轮一样，一起构成了AI自动化协作的完整体系。 很多人说AI的进步让人焦虑，说人类最终会被A取代。 未来会不会真的变成那样，我不知道，但我心里更常浮现的并不是恐惧，而是一种隐约的激动。 因为我们每个人都太渺小了，活在了时代的缝隙里。 大多数时候，我们只能眼睁睁的看着洪流呼啸而过。 过去我们所发生的每一次科技巨变，普通人也都只是被推着往前走，也许他们换了一种工作或者生活的方式，但是却始终站在了改变之外，我不想自己被这样裹挟着前行，如果说注定要与时代装个满怀的话，那这次我想清醒的迎上去，也许就从了解一个小小的a镇的开始。 这里是程序员老王，我们下期再见。
up的科学星球：https://t.zsxq.com/ubYr8
UP主: 隔壁的程序员老王 发布时间: 2025-05-01 时长: 11:38 原文链接: https://www.bilibili.com/video/BV1aeLqzUE6L/