上周和朋友聊天，他说公司最近在搞 AI 转型，开会时老板张口闭口就是 Agent、MCP、RAG、Skill，听得他一脸懵逼。会后他偷偷问我，这些到底是啥玩意儿？
我笑了，这不就是典型的名词诈骗吗？
今天我就帮你把这些唬人的概念全部扒个底朝天。看完你会发现，所谓的智能体，其实就是一堆不需要智能的程序拼起来的；所谓的 Skill，不过是新瓶装旧酒的提示词游戏。
一切从一个会接龙的智障开始
故事要从最早的语言模型说起。
一开始，这玩意儿就是个智障，只会做文字接龙，给它一句话，它就机械地往下续。但随着参数越来越大，突然在某个临界点，它居然涌现出了智能。为了和之前的智障模型做区分，人们在前面加了个“大”字，于是就有了现在的大语言模型，简称 LLM。
但大模型本身还是只会接龙，看起来仍然像个智障。怎么办？有人想了个办法，把角色区分一下，人为划分成一问一答两个角色，这就实现了第一个有点智能的使用方式，也就是对话。
现在你可以把自己想象成一个老板，LLM 就是你的员工，我们叫他小 L。只不过这个员工有点特别，只能一问一答，然后就结束了，不能追问。
为了更好地使用小 L，你给每次对话起了个洋气的名字叫 Prompt（提示词）。然后你发现，这部分内容还可以细分，有的是背景信息，有的是最终指示，于是你又把背景信息部分单独起名叫 Context（上下文）。
虽然小 L 不能追问，但你想了个巧妙的办法，每次沟通前把之前的对话历史放到 Context 部分，伪装成多轮对话。你又给这些特殊的上下文信息起了个新词叫 Memory（记忆）。
你看，短短几分钟，你已经发明了四个新词了。
从智障到智能体，只差一个代理程序
很快你就不满足于现状了。
你发现小 L 没有上网查资料的能力，要么不知道，要么胡说八道，说的都是过时消息。给他准备台电脑？不行，小 L 只会接龙，其他逻辑都完成不了。
那怎么办？你告诉小 L，如果需要上网搜索，就告诉你，你帮他查完再给他。但这样显得自己有点蠢，到底谁才是牛马？
于是你把上网这部分逻辑写成一段程序，让这个程序代理你和小 L 沟通，并完成搜索任务。在外人看来，你仍然是一问一答就拿到了结果，只不过面向的是这个神秘的程序。
太妙了！这个程序似乎本身就拥有了智能，而且还是能操作工具的更高级别智能。你给它取名叫智能体，也就是 Agent。
你可能觉得，这不就是个简单程序吗，怎么敢叫这么科幻的名字？千万别有心理负担，一些早期所谓的智能体，实现逻辑仅仅就是多加了一段 Prompt 而已。从现在的视角回看，当时简直就是一种诈骗。
既然 Agent 能上网搜索了，那是不是也可以增加搜索本地文档的能力？可以的，只不过要用向量数据库，通过语义匹配找出相关片段。你给这种方法起了个名字叫检索增强生成，英文缩写是 RAG。
联网搜索也起个名字吧，就叫 Search。这样 RAG 也算是 Search 的一种了，都属于获取模型参数以外信息的能力。
好了，现在看看你造的孽，这么一会儿功夫已经发明了八个新词了。
Function Calling 和 MCP，本质都是接口约定
现在的架构是，你和小 L 中间隔着一层 Agent 程序，用于减少你和大模型直接沟通的次数，并处理小 L 无法操作的东西。
但这就有个问题。如果 Agent 和大模型之间一直用自然语言沟通，程序可不好实现，鬼知道大模型会怎么描述自己的需求。所以最好有个约定，让大模型按照指定的格式回复，比如 JSON，这样程序就能直接解析了。
你给这种 Agent 和大模型之间关于工具调用的对话格式叫做 Function Calling（函数调用）。其实就是个约定罢了，就好像开发时前端和后端约定接口格式一样。
再看看右边这些工具的实现，现在是写在 Agent 主程序里的，没有解耦。如果单独写成一个服务，Agent 如何发现并调用这个服务，又需要一套约定的规范了。比如约定好 toolList 方法返回工具列表，toolCall 方法调用具体工具等等。
你给这边的约定也起了个名字叫 MCP（模型上下文协议）。
很多人问 Function Calling 和 MCP 有什么关系。其实很简单，一个是 Agent 和大模型沟通的约定，目的是让大模型回答符合格式方便解析；一个是 Agent 和工具服务之间调用的约定，目的是像接口文档一样约定怎么调用、怎么传参。这俩完全不搭嘎。
Skill 到底是个什么东西
假设我们想完成这样一个任务，从英文 PDF 文档中提取内容，翻译成中文，最后保存成 Markdown 格式。
你可以直接把需求描述给 Agent，让它自己策划流程。但如果这个流程相对稳定，每次重新让 Agent 自由发挥的话，不但不稳定，还非常浪费 token。
为了固化这样的流程，你可以通过编程方式实现，于是发明了一个新框架叫 LangChain。为了照顾非程序员用户，你又发明了低代码方式，在页面上傻瓜式拖拽，起名叫 Workflow（工作流）。
但还有个问题。如果原始文档不只有 PDF，还可能是 Word、TXT、PPT，输出格式也可能是 HTML、PDF 甚至图片，难道要给所有排列组合都写一套工作流吗？
你可以这样设计，准备一个目录，把所有可能涉及的转换脚本全都写好放在这，然后写个统一的说明文件，把整体流程描述清楚，并告诉 Agent 根据文件格式灵活选取指定脚本。
在给 Agent 下达任务之前加上这么一句话，先读取我们写好的那一大串要求，然后再按照要求完成任务。这样既保证了灵活性，又变得比较可控。
但这不就又来了优化空间吗？可以提前约定好某个指定位置，然后在 Agent 中写死一段程序去读取这个位置的 skill.md，相当于把这句话固化成了程序。
虽然你也知道这破玩意儿好像就是把提示词换了个地方存起来，但想了想还是给它起个新名字吧，就叫做 Skill，即 Agent 的技能。
也有人问 Skill 和 MCP 有什么区别。Skill 其实就是个 Prompt 加载器，唯一需要的文件就是 skill.md，和 MCP 也不是一个维度的东西。不过 Skill 是否能取代 MCP？我认为是可以的，因为你可以把 MCP 服务中提供的工具通通放在 Skill 目录下。
从刚性到柔性，谁会是最后赢家
我把 LangChain、Workflow、Skill、纯 Agent 这几个概念按顺序排列，称为从刚性到柔性，从稳定到变化。
LangChain 是纯编程形式，全是硬编码，虽然特别稳定，但失去了柔性，很难包容小问题。Workflow 只是把程序替换成了低代码拖拽，相对容易改写一些。
Skill 把由程序控制的流程走向变成了由智能体自行控制，但提前写好说明文档和可运行脚本，存在一定灵活调整空间，又不至于变得特别不可控。
纯 Agent 形式最为柔性，可以随时根据判断调整流程，甚至需要时自己给自己生成脚本来运行。但这也造成了容易不可控，你不知道它会给自己写个什么脚本，把简单任务变得非常复杂。
对于普通人来说，Skill 兼顾着灵活性和稳定性，我认为会逐渐淘汰掉 MCP 和 Workflow。MCP 常用的工具会直接内化到 Agent 主程序中，而 Workflow 既不如 LangChain 适合程序员，也不如 Skill 适合普通人，属于比较鸡肋的存在。
当然 Skill 本身也是个中间产物，未来一定会有更方便的形式出现，让所有人都可以很符合直觉地无脑使用。
本质上都是在往提示词里塞东西
从最本质的角度说，所有这些技术，最终还是离不开大模型和我们之间的提示词。
这些技术无非就是帮助我们自动往提示词里面增加上下文信息，比如 Search、RAG、Skill 等等，都是把一堆内容塞进了上下文；或者通过代理形式，帮助我们减少和大模型沟通的次数。
为什么说 Agent 是所有不需要智能的地方构成的部分？就是说一个流程当中，所有能用固定程序解决而不需要问大模型的地方，就是 Agent 发挥作用的地方。把模糊的分流逻辑交给大模型，根据语义识别出用户想做 A 还是 B；把确定的分流逻辑交给程序，比如 PDF 提取文本。
最终目标都是节省人力时间，降低人类使用门槛罢了。
但现在还有个最大的问题，就是 token 实在太贵了。越是强大的、能默默处理问题的 Agent，背后消耗的 token 就越大。但我觉得这在未来或许不是问题，因为 token 一定会越来越便宜，甚至等到生产级别的大模型可以轻松部署在普通电脑上时，token 就相当于免费了。
程序员尚且这么怕麻烦，在 Agent 领域更是如此，因为它面向的是普通人。不可能让普通人去把 Skill 放到指定目录下，配置 MCP 服务，甚至配置大模型的 API Key。这些都会被一个极为便利的产品淘汰掉。
未来究竟会是什么样？我认为只要是提供便利的方向，就是趋势。未来一定有一个打包好的超级 Agent，配置好了所有常用的功能，普通人啥都不用配置也能直接使用起来。
至于那些唬人的新词？管它叫什么呢，能用就行。
