Agent、Function Calling、
MCP、Skills、
Manus、OpenClaw…
要搞懂AI领域这些层出不穷的名词,
还不轻易忘记,
就不能只满足于它是什么,
还要知道它的提出是为了解决什么问题。
今天就基于这个原则,
带你看到这些AI名词背后的因果,
让你找到那种原来如此的感觉。
2022年底,
一个叫ChatGPT的大语言模型横空出世,
你让它给你讲了个不出意外的话,
就出意外的故事,
讲完之后,你说再加点反转,
发现它真的能续上。
然后,你所有的好奇都变成了震撼。
你把ChatGPT招到麾下,成为你的员工,
给他取了个花名,叫大M。
日子一天天过,
有一次你心血来潮,
跟大M说,帮我看看大盘,
然后大M开始和你聊什么是大盘,
但就是不帮你看。
你找来真人员工小P,
问他怎么办。小P告诉你,大M虽博古通今,
但巧妇难为无米之炊,你给它工具,它才能干活。
在小P的改造下,
大M变成了一个能调用工具的大M,
它有了一个新名字叫“Agent”。
小P告诉你:
Agent
= 大M + 提示词 + 工具调用程序 + 工具 + 工具清单
你问小P:“工具调用程序是个什么东西?”
小P说:“工具调用程序是一段调用工具的代码,
而工具,在计算机程序里,
是用函数来定义的,
比如访问大盘数据这个工具,
可以定义成这样一个函数,
然后,需要用一段代码来调用这个工具函数:
这段代码就是“工具调用程序”,
虽然实际情况会稍复杂一些,
但是对于理解概念足够了。
而工具清单,会列出所有可以调用的工具,
是为了让大M知道有哪些工具可以用。
至于提示词,
就是告诉大M如何找到干活要用的工具,
以及…”。
不等小P说完,你迫不及待对Agent说:
“原来如此,那么,Agent,你帮我看看大盘”。
这时,Agent开始工作,
你看到大M理解了你的问题,
并从“工具清单”中找到了“大盘访问工具”,
然后生成了“调用大盘访问工具看看今天的大盘数据”这句话,
直接丢给了“工具调用程序”,
然后“工具调用程序”就挂掉了…
小P向你解释说:“老板别急,工具调用程序是一段计算机程序,只能理解类似Json这种结构化格式的语言:
理解不了“调用大盘访问工具看看今天的大盘数据”这种非结构化的人类语言。
所以,我们必须在Agent的提示词里增加一个约定:“要求生成这种Json格式的语言,而不是自然语言”,
这样大M和“工具调用程序”才能沟通的起来。”
你说:“原来如此,既然这个约定是为了让工具调用程序正常解析大M生成的工具信息用的,
而工具在计算机程序里是用函数定义的,所以调用什么工具的约定就是调用什么函数的约定,
那这个约定就叫它Function Calling吧。”
从此,Function Calling就是
为了解决Agent的大M和工具调用程序间的沟通而存在。
有了“Function Calling”,大M果然按照提示词的要求,给你生成了大盘的数据摘要,还加了大M自己的评论。
你不禁感叹,Agent比大M有用多了,
于是招呼小P给Agent多开发一些工具,
一段时间后,Agent有了99个可以用的工具。
日子一天天过,
真人员工小P按照你的要求,
给Agent又加了一个工具,
但因为一个bug,
Agent的工具调用程序出了问题,
导致其它99个工具都不能用了。
你说什么也不敢再让小P给Agent加新工具了,
但不加新工具,Agent就不能继续帮你干新活,
怎么办?
小P提出了一个想法,
既然改动工具可能会影响Agent,
那如果把所有工具放到Agent的外面呢?
这样新增或修改某个工具,都不会对Agent和其它工具造成任何影响。
你觉的可行,但很快就面临一个问题,
工具在Agent内部的时候,
所有工具都自然适配工具调用程序来开发,
所以工具调用程序可以正确调用所有的工具,
但如果工具放到外部,Agent和工具的开发很可能不是同一波人,
如何保证开发出来的工具可以和Agent兼容呢?
这又是一个沟通问题,
是Agent内部的“工具调用程序”和外部工具之间的沟通问题,
小P效仿Function Calling,
又设计了一个约定,
要求开发Agent的人,和开发外部工具的人,都要遵守这个约定,
就像电脑和U盘都要遵守USB约定一样。
这样不仅工具的调整不会影响Agent本身,
而且任何工具都可以随时像U盘一样接入到任何Agent上使用,
维护和复用的成本都大大降低。
真人员工小P告诉你,
有了这个新的约定后,
工具清单和工具都可以移到Agent的外面维护,
此时Agent内部变成了:
Agent = 大M + 提示词 + 工具调用程序
由于这个约定的内容是关于Agent如何获取外部工具清单,
以及如何调用外部工具,
而这一切都是为了给Agent内部的大M提供上下文信息,
所以,小P给这个约定起了个名字叫 Model Context Protocol,
也就是模型上下文协议。
你惊呼小P真是个天才,
但觉得这个名字太长记不住,
于是取了首字母缩写,管它叫MCP。
从此,MCP就是为解决Agent的“工具调用程序”和“外部工具”之间的沟通问题而存在。
日子一天天过,
真人员工小P突然汇报,说你上个月刚充的500钞票还剩5毛。
你心里一紧,赶紧问:
“那个需要用到100个工具的任务,
Agent执行的如何了?“
小P说:
“出了点问题,
Agent掉进了无限循环,不能自拔。”
你觉得这样不行,
钱花了,Agent的执行还这么不稳定,
于是看着小P说:“搞不定,你下周就不用来了。”
小P临危不乱,开始思考:
工具调用程序是计算机程序,一旦优化好,就会按照固定逻辑执行,
不会消耗token,也几乎不会出错。
大M内部太复杂了,并且已经使用了最好的模型,没什么优化的空间。
那就只剩提示词了,
如何优化提示词,才能降低Agent对token的消耗,以及提升Agent的稳定性呢?
小P发现Agent不稳定的原因,
在于大M每次要根据提示词的逻辑,来规划这99个工具的执行逻辑,
但实际上,有些工具完全可以按照某个固定的逻辑封装成一个技能,
比如语音转文本工具+文本翻译工具可以封装成一个语音翻译技能,
如果把Agent选择语音转文本工具、文本翻译工具,变成选择语音翻译技能,
Agent就不用思考技能内部的工具执行逻辑,
提示词的复杂度降低了,就意味着token的消耗变少了。
而且由于技能内部的工具执行逻辑,是提前用代码脚本固定下来的,
所以Agent的稳定性也得到了提升。
小P还发现一个问题,
Agent每次运行都要读技能清单,
如果把技能清单分为用途和使用方法两部分,
Agent选择技能时,只需要看用途的部分,
确定使用什么技能后,再看使用方法的部分,
而技能需要的其它的资源文件,
比如示例、模板、图片等等,也可以在“使用方法”部分定义成按需加载。
这样一来,就能再次减少Agent对token的消耗。
小P把这个称为渐进式披露的想法告诉了你,
你第二次惊呼:“小P真是个天才。”
然后,你们给这个和提示词优化有关的想法,提出了一个新的概念叫Skill,
并要求按照文件夹的组织方式来构造Skill:
其中,SKILL.md是必须要的,md是markdown格式文档的后缀名,SKILL.md用两部分内容定义了大M需要的指令提示词:
被分隔符—框起来的,放在最前面的部分,称为Frontmatter reference,
中文意思是前置参考材料,
是给大M选技能时看的数据,
因为是关于技能数据的数据,
所以也叫技能的元数据;
而分隔符外面的内容,也就是第二块内容,
是这个技能的具体操作细节,包括怎么用,以及会用到哪些脚本和资源。
除了SKILL.md以外,
其它文件都是可选的,包括:
Scripts(代码脚本),比如python脚本,
Resources(资源),比如模板.md、样例.md、图片、音频等资源文件。
所以,Skill就是由
“指令文档 + 可运行脚本代码 + 资源文件”
组成的,并且可以定义很多个这样的Skill。
有了Skill这个概念后,
真人员工小P说:
“老板,以后我们用Agent可能只要配配Skill就行了,不用再和MCP打交道了。”
你问小P:“那MCP是不是没用了?”
小P继续说:
“MCP会是那些开发Skill的人考虑的东西。这取决于Skill要不要使用外部的工具。”
你明白了,
以后Agent就只包含:大M + Skills了。
日子一天天过,
一个叫Manus和OpenClaw的名词闯入你的视野。
你问真人员工小P:
“这两个东西是什么,听说好厉害,
我们要不要跟?”
小P说:
“老板,
它们都是Agent平台,宣称全自动代替人工,
区别是Manus 跑在云端虚拟机里;OpenClaw跑在本地电脑里。
而它们的共同之处是,巨量的Token 消耗。
如果不是非要从多个聊天软件作为任务下达入口,
其实,从一个统一的软件或命令行界面下达任务,比如ClaudeCode,
也足够满足需求了。“
你继续问:
“Claude Code不是用来生成代码的吗?”
小P说:
“Claude Code的名字有点限制了它实际可以提供的能力,
但它其实可以做很多事了,比如总结会议纪要,批量处理文件,
还有其它很多活,都可以帮你干。”
你陷入了沉思,然后说:
“技术的发展总会有些泡沫,
但毕竟Manus 验证了AI的任务闭环,
OpenClaw 打开了AI的渠道接入。”
你说你相信有一天,真正的通用智能会降临,会让我们这些普通人也用的起,
那时可能真的不需要那么多真人员工了,而且这一天并不遥远。
真人员工小P问你:
“老板,那到时候我做什么?”
你看着窗外,沉默了一会说:
“去做生而为人,本应该做的事”,
小P问:
“人不会被AI取代吗?”,
你说:
“照相机发明100多年了,
画家并没有消失,不是吗?”
以上就是今天的全部内容,
如何系统的学习大模型 AI ?
由于新岗位的生产效率,要优于被取代岗位的生产效率,所以实际上整个社会的生产效率是提升的。
但是具体到个人,只能说是:
“最先掌握AI的人,将会比较晚掌握AI的人有竞争优势”。
这句话,放在计算机、互联网、移动互联网的开局时期,都是一样的道理。
我在一线互联网企业工作十余年里,指导过不少同行后辈。帮助很多人得到了学习和成长。
我意识到有很多经验和知识值得分享给大家,也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑,所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限,很多互联网行业朋友无法获得正确的资料得到学习提升,故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。
一直在更新,更多的大模型学习和面试资料已经上传带到CSDN的官方了,有需要的朋友可以扫描下方二维码免费领取【保证100%免费】👇👇
01.大模型风口已至:月薪30K+的AI岗正在批量诞生
2025年大模型应用呈现爆发式增长,根据工信部最新数据:
国内大模型相关岗位缺口达47万
初级工程师平均薪资28K(数据来源:BOSS直聘报告)
70%企业存在"能用模型不会调优"的痛点
真实案例:某二本机械专业学员,通过4个月系统学习,成功拿到某AI医疗公司大模型优化岗offer,薪资直接翻3倍!
02.大模型 AI 学习和面试资料
1️⃣ 提示词工程:把ChatGPT从玩具变成生产工具
2️⃣ RAG系统:让大模型精准输出行业知识
3️⃣ 智能体开发:用AutoGPT打造24小时数字员工
📦熬了三个大夜整理的《AI进化工具包》送你:
✔️ 大厂内部LLM落地手册(含58个真实案例)
✔️ 提示词设计模板库(覆盖12大应用场景)
✔️ 私藏学习路径图(0基础到项目实战仅需90天)
第一阶段(10天):初阶应用
该阶段让大家对大模型 AI有一个最前沿的认识,对大模型 AI 的理解超过 95% 的人,可以在相关讨论时发表高级、不跟风、又接地气的见解,别人只会和 AI 聊天,而你能调教 AI,并能用代码将大模型和业务衔接。
- 大模型 AI 能干什么?
- 大模型是怎样获得「智能」的?
- 用好 AI 的核心心法
- 大模型应用业务架构
- 大模型应用技术架构
- 代码示例:向 GPT-3.5 灌入新知识
- 提示工程的意义和核心思想
- Prompt 典型构成
- 指令调优方法论
- 思维链和思维树
- Prompt 攻击和防范
- …
第二阶段(30天):高阶应用
该阶段我们正式进入大模型 AI 进阶实战学习,学会构造私有知识库,扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架,抓住最新的技术进展,适合 Python 和 JavaScript 程序员。
- 为什么要做 RAG
- 搭建一个简单的 ChatPDF
- 检索的基础概念
- 什么是向量表示(Embeddings)
- 向量数据库与向量检索
- 基于向量检索的 RAG
- 搭建 RAG 系统的扩展知识
- 混合检索与 RAG-Fusion 简介
- 向量模型本地部署
- …
第三阶段(30天):模型训练
恭喜你,如果学到这里,你基本可以找到一份大模型 AI相关的工作,自己也能训练 GPT 了!通过微调,训练自己的垂直大模型,能独立训练开源多模态大模型,掌握更多技术方案。
到此为止,大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗?
- 为什么要做 RAG
- 什么是模型
- 什么是模型训练
- 求解器 & 损失函数简介
- 小实验2:手写一个简单的神经网络并训练它
- 什么是训练/预训练/微调/轻量化微调
- Transformer结构简介
- 轻量化微调
- 实验数据集的构建
- …
第四阶段(20天):商业闭环
对全球大模型从性能、吞吐量、成本等方面有一定的认知,可以在云端和本地等多种环境下部署大模型,找到适合自己的项目/创业方向,做一名被 AI 武装的产品经理。
- 硬件选型
- 带你了解全球大模型
- 使用国产大模型服务
- 搭建 OpenAI 代理
- 热身:基于阿里云 PAI 部署 Stable Diffusion
- 在本地计算机运行大模型
- 大模型的私有化部署
- 基于 vLLM 部署大模型
- 案例:如何优雅地在阿里云私有部署开源大模型
- 部署一套开源 LLM 项目
- 内容安全
- 互联网信息服务算法备案
- …
学习是一个过程,只要学习就会有挑战。天道酬勤,你越努力,就会成为越优秀的自己。
如果你能在15天内完成所有的任务,那你堪称天才。然而,如果你能完成 60-70% 的内容,你就已经开始具备成为一名大模型 AI 的正确特征了。