视频
Prompt
好，咱们从梦开始的地方说起：Prompt。
想当初，AI 刚火的时候，我们和它互动，就跟微信聊天一样，你在对话框里输入”你好”，它就回你一个”你好，有什么可以帮您？“。你发过去的这条消息，就叫 User Prompt，也就是用户提示词。
但这有点单调，对吧？有时候我们希望 AI 能有点”人设”，比如，让它扮演我的女朋友。我总不能每次都说：“请注意，你现在是我的女朋友，我跟你说 Hi”。这也太出戏了！
于是，聪明的工程师就想了个办法，把这些”人设”信息，单独拎出来，放到一个叫 System Prompt 的地方。这个 System Prompt 就像一个演员的背景设定，告诉 AI：“你是一个什么样的角色，你的性格是什么，说话要用什么语气”。
这样，每次我们和 AI 聊天，系统都会把这个”人设”和我们的”聊天内容”一起发给 AI。整个对话就自然多了。
但说到底，这时的 AI 还只是个聊天机器人。你问它问题，它最多告诉你怎么做，真要干活，还得我们自己来。
AI Agent
那能不能让 AI 自己”动手”呢？比如说，让它帮我看看我电脑上某个文件夹里都有啥文件？
这时候，AI Agent 闪亮登场了！
你可以把 AI Agent 想象成一个”管家”。我们这些当主人的（程序员），先要给这个管家配备一套”工具箱”，比如”罗列文件”的工具，“读取文件”的工具。
然后，我们要给管家一本”工具说明书”，这本说明书就是前面提到的 System Prompt 的升级版。里面写着：“管家你好，你现在有这些工具，它们分别是干啥的，怎么用。如果你要用，就按照这个格式告诉我”。
现在，我们作为终极老板，跟管家说：“去，帮我总结一下我所有文件里的内容！”
管家（AI Agent）收到指令，就会把我们的要求和那本”工具说明书”一起，汇报给它背后真正的大脑——AI 大模型。
如果这个 AI 大模型够聪明，它就会看懂说明书，然后跟管家说：“好的老板，我需要先用一下那个’罗列文件’的工具”。
管家一听，得嘞！马上就去执行这个操作，把罗列出来的文件列表，再汇报给 AI 大模型。AI 大模型一看，哦，有这些文件啊，那下一步就是把它们一个个读一遍。于是它又对管家下指令…
这个过程就这么来来回回，直到任务完成。这个在我们和 AI 大模型以及工具之间来回传话、干脏活累活的”管家”，就是 AI Agent。那些我们提供给它用的函数或者服务，就是 Agent Tools。
不过，这个管家有时候会犯迷糊。虽然我们在说明书里写清楚了沟通的”格式”，但 AI 大模型毕竟是个概率模型，偶尔会”上头”，不按套路出牌，返回一个格式错误的消息。这时候管家就只能懵圈，然后一遍遍地去问，直到大脑清醒过来给个正确的格式。这显然不是个事儿，效率太低了。
Function Calling
为了解决这个”沟通障碍”，大模型厂商们，像 OpenAI，Google，Anthropic，亲自下场了。他们推出了一个叫 Function Calling 的功能。
这玩意儿的核心思想就八个字：统一格式，规范描述。
还记得我们之前那本自然语言写的”工具说明书”吗？太随意了，容易有歧义。Function Calling 就把它变成了标准化的”简历”。
每个工具（Tool）都得填一张表，用 JSON 格式，清清楚楚地写上你的”名字”（name），“特长”（description），需要”提供什么信息”才能干活（parameters）。
这些标准化的”工具简历”不再和 System Prompt 混在一起，而是被单独放在一个专门的字段里。同时，Function Calling 也规定了 AI 大模型在想使用工具时，回复的”格式”也必须是标准化的。
这么一来，大家说的都是”普通话”，AI 大模型就能被更好地训练，因为它天天都在看这种标准化的简历和请求，对这个流程熟得不能再熟了，犯错的概率自然就大大降低了。
MCP (Model Context Protocol)
好，现在 AI Agent 和 AI 大模型之间的沟通顺畅了。我们再来看另一边：AI Agent 和它的工具箱（Tools）之间是怎么沟通的。
最开始，大家图省事，就把管家（Agent）和工具（Tool）写在同一个程序里，直接调用就行。
但慢慢地人们发现，有些工具是”万金油”，比如”上网搜索” web_browse 这个工具，张三这个管家要用，李四那个管家也想用。总不能每个管家都配一套一模一样的工具吧？这代码传来传去，也太不优雅了。
于是，MCP（Model Context Protocol） 协议应运而生。你可以把它理解为 AI 界的 USB 协议。
有了这个协议，我们就可以把各种工具（Tools）做成独立的服务，放到一个”工具共享中心”里，这个中心就叫 MCP Server。而那些需要使用工具的管家（Agent），就变成了 MCP Client。
MCP 这套协议，就是专门用来规定 Client（管家）和 Server（工具中心）之间应该怎么交流，怎么借用工具的。
比如，管家可以问工具中心：“你这儿都有啥工具啊？”，“这个’上网’的工具具体怎么用啊？需要我提供网址吗？“等等。
除了这种干活的工具，MCP Server 还能提供别的东西，比如直接提供数据（Resources），或者提供各种场景下的提示词模板（Prompts）。
最关键的是，MCP 不关心你的管家背后是哪个大模型，是 GPT-4 还是 Gemini。它只负责一件事：帮你的 Agent 高效、规范地管理和使用工具、资源和提示词。
总结
好了，概念都讲完了，我们来把整个流程串一遍，看看它们是怎么合作的。
假设，我想知道”明天天气怎么样？”
- 我把这个问题抛给了我的管家，也就是 MCP Client（或者说 AI Agent）。
- 管家先把我的问题包装成一个 User Prompt。
- 然后，管家通过 MCP 协议，向”工具中心”（MCP Server）发出请求，拿到了所有可用工具的”标准化简历”。
- 管家把这些工具简历，按照 Function Calling 的格式，连同我的问题（User Prompt）一起，打包发给了它背后的大脑——AI 大模型。
- AI 大模型一看，哟，有个叫上网搜索”web_browse”的网页浏览工具，这不正是我需要的吗！于是，它按照 Function Calling 的标准格式，回复了一个调用工具的请求，告诉管家：“快，去网上给我搜一下天气预报！”
- 管家收到指令，立刻通过 MCP 协议，去调用”工具中心”里的”web_browse”工具。
- “web_browse”工具访问了天气网站，把查到的信息返还给了管家。
- 管家再把这个信息转发给 AI 大模型。
- AI 大模型结合网上的信息和自己的知识，进行了一番头脑风暴，最后生成了最终答案：“明天天气晴朗，适合出去浪！”
- 最后，管家把这个结果展示给了我。
所以你看，System Prompt，User Prompt，AI Agent，AI 模型，Agent Tools，Function Calling 和 MCP，它们谁也替代不了谁，而是像一套精密的齿轮，互相配合，共同完成一项复杂的任务。正是因为有了它们的协同工作，AI 才从一个只能聊天的玩具，变成了真正能为我们所用的强大工具。
