AI人工智能中的各个名词解读

• 引言
• 推理服务是什么？
• Memory 是什么？
• RAG 是什么？
• MCP 是什么？
• Skills 是什么？
• AI Agent 是什么？
• 内容二
• 参考资料

引言

AI人工智能中的各个名词解读。

推理服务是什么？

GPT、DeepSeek 这类大模型本质上就是个超大文件，它躺在磁盘上，文件里装的就是训练时学到的知识参数。要让它工作，得有个程序把它加载到内存里，对外暴露 HTTP 接口，接收用户请求做推理返回结果，这就是推理服务。给它配个前端网页聊天框，就成了我们熟悉的聊天 AI。

Memory 是什么？

推理服务本质是个 HTTP 服务，每个请求进来处理完就结束，本身不保存任何状态。而且为了扛住高并发，一般会部署多个推理服务实例做负载均衡。你第1次请求可能打到机器A，第2次请求可能打到机器B，完全是两个不同的进程。

但问题来了：我们在 AI 聊天页面里明显感觉它能记得我们之前的对话，这是怎么做到的？

其实大模型本身什么都不记得。每次请求时，系统会把之前的聊天记录重新拼到对话里，一起发给大模型。这些拼起来发给大模型的内容统称上下文（Context）。大模型看到完整上下文，自然就能接上话了。

但问题又来了：如果每次请求都把所有历史对话发出去，上下文会超长大模型处理不了，怎么办呢？

我们可以分两类管理：当前会话最近几轮对话完整保存，这叫短期记忆。很久之前的对话提取关键信息压缩成摘要，这叫长期记忆。每次请求时都将它们拼成对话发给大模型，这样大模型看起来就像有记忆一样。

这套管理上下文的机制就叫 Memory。

RAG 是什么？

有了记忆，大模型就能记住历史对话了。但新问题又来了：大模型的训练数据都是从互联网上抓的，历史公开数据训练完成后知识就固定了。你问它今天的新闻或公司内部文档，它根本不可能知道，怎么办？

给它配个外部知识库，里面可以放最新新闻、公司内部文档。这些资料数据量大的话就存到数据库里。用户提问时，先从数据库里做匹配，获得相关知识，再一起喂给大模型。大模型就能基于这些外部知识回答。

这种检索外部知识给到大模型做回答的方案，就是检索增强生成（Retrieval Augmented Generation），简称 RAG。

但问题又来了：传统数据库只能做字面匹配。但土豆、马铃薯、洋芋虽然意思一样，字面却完全不同，匹配不到怎么办呢？

我们可以把文本转成向量，用向量距离衡量语义相似度，这样语义相近的文本就能匹配上了。所以 RAG 用的数据库里存的是向量数据，这种数据库也叫向量数据库，比如 Milvus。数据量不大的话，也可以用我们的老朋友 PostgreSQL。

MCP 是什么？

有了 Memory 和 RAG 的加持，大模型能记住历史聊天和获取外部知识了。但新问题又来了：现在大模型只能对话和思考，就像光有大脑没有手脚，怎么让它具备操作工具的能力呢？

好办。我们可以在对话里约定一种消息格式。外部先告诉大模型有哪些工具可用，格式像这样。大模型想用工具时，输出一段特定格式，格式比如发邮件，里面写清楚发给谁和发什么。外部收到消息后执行发送邮件，完成后将返回的结果再回喂给大模型。大模型就能基于工具执行结果生成最终回复。

这种让大模型通过结构化消息来调用外部工具的方式，在工程上可以被抽象成一套协议规范，也就是 Model Context Protocol，简称 MCP 协议。

这个在外部负责解析格式并操作工具的程序，就是 MCP 后端。比如我们用来写代码的 Cursor、Claude Code，能被调用的具体工具就叫 MCP 插件。MCP 插件还可以拆分成本地的 MCP Client 和远端的 MCP Server。比如 GitHub MCP 插件，本地的 MCP Client 负责接收调用请求，远端的 MCP Server 部署在 GitHub 服务器上，真正执行 GitHub API 操作。

Skills 是什么？

MCP 协议和插件解决了工具调用问题，但新问题又来了：这么多插件，大模型怎么知道该按什么顺序用、怎么组合用呢？

这就好比给了一个大学生一堆钳子扳手，他也不一定能修好车，他缺的是经验和流程。那好办，我们可以写一份操作手册，里面详细说明遇到什么场景用什么工具，先做什么后做什么，有什么注意事项。这份结构化的操作指南就叫 Skills。

以排查线上事故为例：MCP 只是把查监控、查日志、查配置、回滚版本这些工具能力给到大模型；而排查问题 Skills 则明确规定了：先看监控判断影响范围，再查日志和配置定位模块，必要时执行回滚，这一整套固定流程。

换句话说：大模型就像大脑，负责思考和决策；MCP 协议就像神经系统，让大脑能连接并指挥外部工具；MCP 插件就是手上的工具，如钳子、扳手、螺丝刀……具体能力；而 Skills 是操作经验，规定在什么场景下按什么顺序组合使用哪些工具。

AI Agent 是什么？

大模型本来就能思考和规划。给它加上了 Memory，让它能记住历史；加上 RAG，让它能获取外部知识；加上 MCP 和 Skills，让它能操作工具。它们共同构成了一个在某些功能上能代替人类自主行动完成目标的 AI 系统，又叫 AI Agent。

它本质上就是一个智能工具。人通过提示词设定角色，它可以是智能客服、程序员、私人律师等各种角色，听从你的指令完成任务。

最近很火的 Claude Code 其实本质上就是个帮你自动操作电脑的 AI Agent。你能用电脑干什么，它就能干什么——比如发邮件、投简历，甚至做交易。所以权限安全是个大问题。

客观地说，Claude Code 做的事情并没有技术上的突破。它跟前段时间很火的 Manus 其实是类似的产品，只不过 Claude Code 主要面向本地电脑，Manus 考虑到安全问题，它将操作环境放到远端虚拟机里。

如果将 Claude Code 部署到远端服务器上，就有点开源版 Manus 那味道了。安不安全是用户该考虑的问题，Claude Code 只管开源。

内容二

AI圈子里每天都在冒新名词，LLM、context、prompt、tool、MCP、Agents、agent skill，这些词你可能都听说过，但是我问大家，你真的能准确地说出其中每一个概念的确切含义吗？

我们就从最底层的工程视角出发，一个一个地把这些概念拆开揉碎讲清楚。

我们先从最底层的东西开始，一层一层地往上搭。最底层的就是 LLM。

LLM全称是 Large Language Model，翻译成中文就是大语言模型，简称大模型。

基本上现在所有的大模型都是基于 Transformer 这套架构训练出来的。这个架构看起来很复杂，不过不用担心，这张图你现在看不懂是完全正常的，我们今天呢也不打算研究它，你只需要知道大模型的底层引擎就是它。Transformer 架构最早其实是由 Google 团队在 2017 年的时候提出来的，对应的论文名是叫做 Attention Is All You Need。很有戏剧性的是，虽然 Google 发明了火种，但真正把它点燃并且引爆全世界的却是 OpenAI。大家应该都记得 2022 年底 GPT-3.5 横空出世，它应该算是第 1 个真正达到可用级别的大模型了，相信当时用过的人都能感受到它的强大。

但这还没完，仅仅几个月之后，在 2023 年的 3 月份 GPT-4 发布，它呢是直接把 AI 的能力天花板拉到了一个新的高度。可以说 GPT 系列就是我们今天 AI 浪潮的绝对鼻祖了。甚至时至今日，GPT 家族依然非常强大，比如现在的 GPT-5.4 就是业界的标杆之一。不过如今的 AI 赛道早已经不再是 OpenAI 的独角戏了，像 Claude、Gemini 等优秀的后起之秀，都在各自擅长的领域与它同台竞技。

好，前面我们说了大模型的大致由来，那大模型到底是怎么工作的呢？

其实非常朴素，它本质上呢就是一个文字接龙游戏。我们来看一个具体的例子，假设你向大模型提问：”马克的视频怎么样？”

模型接收到这句话之后，经过内部的运算，它会预测下一个概率最高的词，比如”特别”。关键点来了，模型输出”特别”这个词之后，它并不会停下来，它会把刚才吐出来的”特别”这个词抓回来，追加到你刚才的那个输入的后面，然后它拿着这个新的输入再去预测下一个字，比如”棒”。

接着它再把”棒”塞回去，然后再预测下一个词，比如说是”。”。然后呢它会把”。”这个字也塞回到输入里面。这个时候大模型会发现它要说的话已经全部说完了，此时它就会输出一个特殊的结束标识符，整个回答到这里就算是彻底结束了。这样我们就拿到了大模型的完整回答：”特别的棒。”

这是大模型最底层的生成原理了。理解了这一点你就明白了为什么大模型要一个词一个词地输出答案，因为它就是这么运作的。

好，我们刚才说了用户提交问题给大模型之后，大模型每次都会输出一个词。但其实这是为了方便你理解而简化的一个链路。现实情况是这样的，大模型本质上是一个庞大的数学函数，里面跑的全是矩阵运算，它接收的呢是数字，输出的也是数字，压根就不认识人类写的文字。

所以呢在人类和大模型之间必须有一个中间人来做翻译，这个中间人呢就叫做 Tokenizer，它负责的是编码和解码两件事情。编码就是把文字变成数字，解码，反过来是把数字还原成文字。

还是拿刚才的那个例子来说，用户提问”马克的视频怎么样？”这句话呢会先交给 Tokenizer 处理，它要把这些文字转换成数字，这个呢就是编码环节在发挥作用了。

我们来把编码的过程拆开来仔细看一下，搞清楚它究竟是怎么把文字变成数字的。这个过程分两步走：

第1步：切分。 它把用户的问题接过来，把它拆成一个一个最小的片段，这些片段呢就叫做 Token。我们这里呢一共是切出了 4 个 Token。

第2步：映射。 由于模型只认数字 Token，那 Tokenizer 呢就会把每一个 Token 对应到一个数字上去，这个数字呢就叫做 Token ID。Token ID 和 Token 是一对一绑定的，Token 是文字，Token ID 是数字，这两个呢其实本质上是一个意思，只不过是换了一种表达方式而已。

经过了这两步，原来的一句话就变成了一串 Token ID 组成的列表，然后 Tokenizer 呢就会把这串列表送进模型，在内部一顿运算，最终吐出了一个 Token ID。这个时候 Tokenizer 再次出场，把这个 Token ID 翻译回 Token，这个呢就是解码环节的工作了。解码只有一步，那就是映射，方向呢是跟编码反过来，把数字转化成文字。

要注意的是，解码环节是不需要切分的，因为模型每次只会给出一个 Token，并没有什么好切分的。解码完之后我们就拿到了大模型输出的第 1 个 Token：”特别”。如果模型的话还没有说完，就继续吐第 2 个、第 3 个 Token，后面的流程呢其实都是一样的，这里就不再重复了。

所以你看到了吗？Token 才是大模型处理文本的最基本单元。大模型一个 Token 一个 Token 地接收输入，然后再一个 Token 一个 Token 地输出结果。

现在我们回头看刚才的那个例子，”马克的视频怎么样”，它呢是被切分成了 4 个 Token：马克、的、视频、怎么样。

你有没有注意到这里每个 Token 好像都正好对应一个词？所以你可能会想 Token 就是词，对吧？但其实不一定，Token 和词呢并不是 1 对 1 的关系，刚才那个例子只是恰好而已。

我们换几个例子你就明白了。比如我的频道呢是叫做”马克的技术工作坊”，如果按照词的标准来划分的话，那应该是有 4 个 Token，分别是：叫做、马克、的技术、工作坊。那真的是这样吗？

OpenAI 提供了一个把文本转换为 Token 的页面，我们不妨去试一下。首先粘贴上我们要切分的文本，也就是”马克的技术工作坊”。你看它把我的频道名转换成了 5 个 Token，其中每个颜色代表一个 Token，这里还能看到对应的 Token ID。

这要注意了，OpenAI 把”工作坊”拆成了两个 Token：”工作”和”坊”，分别代表一个 Token。这跟我们预想的不一样，在我们的预想中”工作坊”应该是一个词，那它应该正好对应一个 Token 才对。不过呢实际上它会被拆成两个 Token。

当然你可能会说”工作坊”是不是也不能算作一个词？好，那我们再看一个更明显的例子。”程序员”这总算是一个完整的词了吧？但在 Tokenizer 里面它被切成了两个 Token：”程序”和”员”。这个呢是中文的情况。

那英文呢？一个英文单词对应一个 Token 吗？对于常见单词确实是这样的，比如 “hello” 是一个 Token，”going” 也是一个 Token。不过这个呢也不是铁律，比如 “helpful” 这个单词就被拆成了两个 Token：”help” 和 “ful”。甚至在某些情况下一个字符会被切分成多个 Token 来表示，比如”✅”这个字符就需要三个 Token 来表示它。不过这三个 Token 没有对应的显示字符，所以在这里面显示的就是问号了。

这种情况下看 Token ID 可能还更直观一些，你看确实是三个。

所以我们总结下，词和 Token 并没有什么明确的 1 对 1 的关系。你可以把 Token 理解成模型自己学会的一套文本切分规则，切出来的每一块就是它一次能够处理的最小单位。平均来讲，一个 Token 大概是等于 0.75 个英文单词，或者是 1.5~2 个汉字。比如 40 万个 Token，大概呢就是 60~80 万个汉字，或者是 30 万个英文单词。

如果你对 Token 的切分原理感兴趣，想详细了解一下 Token 到底是怎么生成出来的，可以看一下我的这个视频，它详细讲述了如何使用 BPE 算法来训练和使用 Tokenizer。

我们刚才讲了 Token，知道了它是大模型处理文本的基本单位。下面我们来看一件你可能一直觉得理所当然，但其实很值得想一想的事情。

我们平时和大模型聊天，它好像能记住之前说的话。比如你开头告诉它”我叫马克”，它跟你回复了以后，你再问它”我叫什么”，它还是能够回答得出来。但问题是，大模型本质上只是一个数学函数，你给它输入它就给你输出，它并不像人一样真的有记忆。那它是怎么记住之前的聊天内容的呢？

答案就是：我们每次给大模型发送消息的时候，并不只会把我们的问题发过去，背后的程序会自动把你之前的整段对话历史找出来，一起发过去。这样的话呢，有了用户问题，有了对话历史，模型每次看到的就是完整的对话内容了，所以它才能够知道之前发生了些什么。

这就引出了 Context 这个概念。中文呢是叫做上下文，它代表大模型每次处理任务时所接收到的信息总和。

我们刚才聊到用户问题和对话历史都是大模型所接收到的消息，所以呢它们都是 Context 的一部分。除了它们之外，Context 里面还有很多其他的内容，比如大模型正在输出的每一个 Token 也会被追加进来。除此之外呢，这里面还会有工具列表、System Prompt 等信息。这些概念呢我们后面会一个一个地讲到，你暂且不用关心。现在你只需要记住一件事情：

Context 呢就是大模型每次处理任务时所接收到的信息总和。 从某种程度上我们也可以把它看成是大模型的一个临时记忆体。

理解了 Context，下一个问题就自然而然地出来了：这个 Context 能有多大？它能塞多少 Token 呢？

这个呢就引出了 Context Window 这个概念，翻译过来呢就叫做上下文窗口，它呢就代表了 Context 能够容纳的最大的 Token 数量。

举个例子，Context Window 为 1 万就代表模型最多能够处理 1 万个 Token。不过 1 万的 Context Window 算是很小的了，目前主流的大模型都有着非常大的 Context Window。比如说 GPT-5.4 的 Context Window 是 128 万，Gemini 3.1 Pro 的 Context Window 是 100 万，Claude Opus 4.6 的 Context Window 是 100 万。

我们之前说过一个 Token 大概是等于 1.5 个汉字，那么 100 万个 Token 呢差不多就是 150 万个汉字了。那整个《哈利波特》全集的内容都能装下，算是很大的了。

好，相信大家对 Context 已经有一个初步的了解了。下面我来问大家一个问题：假如你有一个上千页的公司产品手册，你希望大模型根据这个产品手册来回答用户的各种疑问，那这要怎么实现呢？

你要把这个手册的全部内容跟着用户问题一起扔给大模型吗？这其实不是一个很好的解决方案，因为这个产品手册太长了，即使模型的 Context Window 不被撑爆，你的成本也无法控制。那这该怎么办呢？

这就需要一个叫做 RAG 的技术了。它可以从产品手册中抽取用户问题最为匹配的几个片段，然后只把这几个片段发给大模型，让大模型只根据这几个片段来回答用户的问题。这样大模型接到的就不是一整本书了，可能只是几段话，这样就不受 Context Window 大小限制了，成本也会低很多。

如果你对 RAG 技术感兴趣，想深入了解一下它的实现原理的话，欢迎看一下我的这个视频。

Prompt，中文叫提示词，它是大模型接收的具体问题或指令。比如你去向大模型提需求：”帮我写一首诗。”这句话呢就是 Prompt。对，不要把 Prompt 想成特别复杂高端的东西，它只不过就是给大模型的一个问题，或者是指令，而已。接到了这个输入之后，大模型才会开始运转，然后呢才会给你一个对应答案。

但这里面会有个问题。如果你只是简单地说”帮我写一首诗”，大模型可能会给你写古诗，就像屏幕上给你展示的这样，但也可能给你写现代诗，甚至可能来一首打油诗。为什么呢？因为你的 Prompt 太模糊了，它不知道你具体想要什么。

所以 Prompt 怎么写，直接决定了大模型的输出质量。一个好的 Prompt 应该是清晰的、具体的、明确的。比如你可以这样写：”请帮我写一首五言绝句，主题是秋天的落叶，风格要悲凉一点。”这样一来大模型就清楚多了，它生成的内容也就更符合你的预期。

这就是为什么有个专门的领域叫做 Prompt Engineering，也就是提示词工程。说白了就是研究怎么把话说清楚，让大模型更精准地理解你的意图。

当然这个领域虽然曾经比较火，但现在还在提它的人其实寥寥无几。一方面是因为门槛太低，本质上就是把话说清楚嘛；另一方面呢是大模型的能力越来越强了，即使提示词含糊不清，大模型也能大致猜出你的意图来，这种情况下也就不需要在提示词上花太多功夫了。

好，到这里 Prompt 的基本概念应该是搞清楚了，但是事情还没有完。

你有没有想过一个问题？有些时候我们不仅要告诉大模型它要处理的具体任务，还要告诉它人设和做事规则，也就是告诉大模型它是谁，它应该按照什么规则做事。

所以呢这就引出了两种不同的 Prompt：说明具体任务的是 User Prompt，中文为用户提示词，它是用户自己输入的；说明人设和做事规则的是 System Prompt，中文为系统提示词，它是开发者在后台配置的。

让我们来用一个具体的例子解释这两个概念。假设你要做一个数学辅导机器人，你希望它不要直接告诉学生答案，而是要引导学生思考。这时候呢你就需要两种 Prompt：

第 1 种呢是 System Prompt，你在后台这样设置：”你是一个耐心的数学老师。当学生问你数学问题的时候，不要直接给出答案，而是要一步一步引导学生思考，帮助他们理解解题思路。”注意这段话是你作为开发者在后台设置的，用户根本看不到，但它会一直影响大模型的行为。

然后学生在对话框里输入”3+5=几”，这就是第 2 种 User Prompt，用户在对话框里直接输入的问题。

大模型看到这两个 Prompt 之后，它会这样想：”我的角色是数学老师，我要引导学生思考，不能直接说答案。好，那我就这样回答：我们可以这样想，你手里有三个苹果，然后又拿了五个，现在一共有多少个呢？你可以数一数看。”

看到了吗？如果没有 System Prompt，大模型可能就直接说”8”了。但因为有了 System Prompt 约束，它知道自己要扮演一个引导式的老师，所以回答就完全不一样了。

相信你现在可以理解 User Prompt 和 System Prompt 的区别了。有了它们的配合，大模型既能守住规矩，又能够完成你的具体需求。

好，Prompt 呢我们就讲到这里了。我们再来看下一个概念：Tool。

我们先来谈一下大模型的一个弱点：它无法感知外界环境。我来举个例子，假设你问大模型”今天上海的天气怎么样”，它可能会说：”抱歉，我无法获取实时天气信息，我的知识截止到某年某月，无法提供当前的天气数据。”

为什么呢？因为大模型只是个文字接龙游戏，它的能力是根据训练数据来预测下一个词，但它真的没有办法去查天气预报网站拿到实时的天气数据。这该怎么办呢？

这就需要 Tool 了。Tool 翻译成中文就是工具。这个词不太好理解，我们再换一个词：函数。对没错，Tool 本质上呢就是一个函数，你给它输入它就给你输出。比如一个天气查询工具，它的输入呢可能会包含两个参数，分别是城市和日期。传入后它内部一通操作，比如说它可能会去调用气象局的接口。但不管怎么样，最后它都会给你一个输出，告诉你对应的天气信息。有了它，大模型就可以回答天气相关的问题了。

让我们来看一下从用户提问到大模型回答的完整流程。整个流程所涉及到的角色呢是包括：用户、大模型、天气查询工具，还有平台。你可能会问平台是什么？你可以把平台理解为一个传话人。因为用户、大模型、天气查询工具这三个角色没有办法直接对话，所以呢我们就需要平台这个角色来做传递信息的工作，它本质上呢就是一段代码，用来负责上传下达。

你可能还有点懵，没事，现在不明白也没有关系，你看完流程就懂了。

在流程开始的时候，用户的问题会首先发给平台，平台会把用户的问题转发给大模型。不过发给大模型的可不止是用户问题，还有目前可用的工具列表，比如说是天气查询工具、计算器工具等等。

大模型收到这个问题之后，它会自己分析：用户想知道天气，而我没有实时的天气数据，但是这里面有一个天气查询工具可以用。好，那我就调用这个工具。

注意：大模型无法自己调用工具，它唯一的能力就是输出文本。如果它想调某个工具的话，它就只能借助平台的力量。所以此时大模型会生成一个调用天气查询工具的指令，大概就是这样子的。这个指令标识了要用的工具名称和对应的参数，它呢会发到平台那边去。

平台接收到这个指令之后就会真的调用这个工具，其实也就是调用了工具背后所对应的一个函数。调用结束之后平台会拿到对应的天气信息，大概呢是这个样子的。

在平台拿到了工具的调用结果之后，它就会把这个信息返回给大模型。大模型拿到这个结果后会把它整理成一句人话输出给平台，比如说是：”今天上海的天气不错，晴天，温度在 15 度到 25 度之间。”诸如此类的。然后呢平台会继而把这句话转发给用户，这样用户就可以看到结果了。

可以看到在这个过程中每个角色都有着自己的职责：

• 其中大模型的职责呢有两个：第 1 个是选择工具，具体来说就是选择需要调用的工具，并生成对应的工具参数；第 2 个是归纳总结，也就是在拿到工具的执行结果之后，模型需要对工具的结果做一个归纳总结。
• 工具的职责呢则是完成查询天气这个动作。
• 而剩下的一个角色平台，它负责处理的就是串联整个流程了，比如告诉模型哪些工具可用，根据模型的工具调用指令来调用工具等等。

所以呢大家要分清楚每个角色在干什么。有人可能会以为要干活的是模型，尤其是初次接触这个很容易就会这么想。但是模型能做的呢仅仅是输出一段文本，告诉平台它想要调哪个工具。调工具这个事情最终还是要靠平台来完成。

所以最后总结一下，Tool 的本质呢就是给大模型提供一套它可以调用的外部能力，让大模型能够感知和影响外部环境。

好，Tool 的概念呢就到这里了。我们来讲下一个概念：MCP。

刚才我们讲了使用工具的全流程，但这里面有个工程上的大问题。看这两部分：第 1，平台要把工具列表传给模型；第 2，还要能调用工具的指令。这些我们首先就得把工具接入到平台里面，这样平台才知道可用工具列表以及每个工具的用途、参数和调用方法等等。

那问题来了，这套接入的规范每个平台都不一样。如果你用的是 ChatGPT，你得按照 OpenAI 的规范接入工具，写一套接入代码。如果你用的是 Claude，你得按照 Anthropic 的规范再写一套接入代码。如果你用的是 Gemini，你得按照 Google 的规范再写一套。看出问题了吗？同一个工具你要写三遍，因为每个平台的接入标准都不一样。

所以呢 AI 圈子里就有人想：能不能我们搞一个统一的标准呢？让所有的平台都遵循这个标准，这样工具的开发者只需要写一次代码，就可以在所有平台上使用了。

这个呢就是 MCP 的由来了。MCP 就是这个统一的接入规范。

MCP 的全称呢是叫做 Model Context Protocol，翻译过来是叫做模型上下文协议。这个名字起得有点学术，不太好理解，你就把它理解成一套统一的工具接入标准就好了。有了 MCP 之后，工具的开发者只需要按照 MCP 的规范开发一次工具，这个工具就可以被所有支持 MCP 的平台使用。

这就像是所有的手机都用 Type-C 接口一样，有了同一个标准大家都会方便很多。

那这个就是 MCP 的由来和作用了。如果你想更深入地了解 MCP 协议的内容的话，可以看一下我之前出过的 MCP 中级指南系列，分 3 期，从实用到原理把 MCP 协议扒了个底朝天，相信看完之后呢你会对 MCP 有一个非常全面的理解。

好，现在我们知道了大模型能借助工具感知外部世界，而工具又可以使用 MCP 这种方式来统一接入。按理说有了这两个东西，大模型应该很强了吧？但实际上还差一点东西。

比如我们来尝试让大模型解决一个更有难度的问题：”今天我这里的天气怎么样？如果下雨的话帮我查一下附近有没有卖雨伞的店。”

然后呢我们假设有这些工具可用：首先是定位工具，它负责查询用户所在地区的经纬度；然后是天气工具，它呢是用来根据经纬度查询天气信息；还有店铺工具，它呢是通过经纬度来查询附近的店铺。

相信有些同学已经看出来了，要解决这个问题，我们需要调用多次工具。从大模型的视角来看，整个过程应该是这样的：

首先大模型思考：用户问天气，那要拿到天气信息的话，肯定是要知道用户的当前位置的。正好这里有个定位工具，我来申请调用一下。之后呢，大模型就发出了工具调用指令，让平台去调用这个定位工具，获取用户所处位置的经纬度。

然后平台就返回了工具结果：经度是 -74 度，纬度是 40 度。

模型再次思考：好，拿到了位置，下一步我就需要查询这个位置的天气了。我来看看，有一个天气工具可以用，那就利用它。大模型再一次向平台发出了指令，调用天气工具，参数是经度 -74 度，纬度 40 度。平台调用工具之后返回结果。

由于模型再次思考发现下雨了。根据用户的要求，如果是下雨我还需要帮他找雨伞店。这里有一个店铺工具，我来调用一下。然后大模型就向平台发出了工具调用指令，调用店铺工具搜索雨伞。平台返回结果：附近 100 米有家全家的便利店卖伞。

大模型综合了所有信息，心想：目标已经全部达成，我可以给用户最终答案了。在大模型给出的最终答案之后，整个回答就算是全部结束了。

看到了吗？这不再是一个简单的工具调用流程了。在这个步骤中大模型需要一步一步思考当前的情况，并决定下一步该做什么。从某种程度上来说，大模型已经有了一定的自主规划能力。

我们称这种能够自主规划、自主调用工具、直至完成用户任务的系统为 Agent。目前市面上有很多 Agent 产品，比较流行的是包括 Claude 的 Codex、Gemini 的 Code Execution 等等。它们所使用的 Agent 的构建模式呢也是五花八门，比较经典的有 ReAct、Plan-and-Execute 等等。

如果你对构建模式这个词比较陌生，甚至根本就没有听说过的话，强烈建议去看一下我的这期视频，里面不仅详细拆解了每种构建模式的运行流程，甚至还抛开了所有现成的 Agent 框架，直接手写了一个简化版的 Claude Code，相信看完之后你就会彻底明白 Agent 到底是如何实现的。

我们现在知道 Agent 能够自主规划、调用工具、持续工作，直到完成任务了。听起来已经很厉害了，对吧？

但在实际的高频使用中，你马上就会遇到一个新的痛点。举个例子，假设你希望大模型成为你的出门小助手，每次出门前帮你扫一眼天气，并提醒你带东西。你肯定有一套自己的出门习惯，比如下雨带伞、光照强戴帽子、空气差戴口罩、风大穿防风外套，无论如何呢手机必带。

不仅如此，你可能还是个强迫症，希望它的回答不要太啰嗦，必须按照特定的格式来输出，比如先来一句总结，然后呢再列出要带的物品清单。

在没有额外设定的情况下，假定你只问一句：”我马上要出门该带些什么呢？”它呢虽然会查天气，但它不知道你的这些私人规则和格式要求，大概率呢会给你一堆废话。它不能按照你的出门习惯来判断要带的东西，最终的输出格式也无法满足你的要求，毕竟它都不知道嘛。

为了拿到让你满意的结果，你每次提问的时候呢就不得不带上一大串尾巴，把你的所有的规则、所有的格式要求，甚至示例全部复制粘贴到 Prompt 里面发给它。试想一下每次出门都要敲这么一大长串要求，是不是太反人类了？

别担心，这个时候呢就该 Agent Skill 登场了。Agent Skill 本质上就是你提前写好塞给 Agent 的一份说明文档。

比如刚才的那个出门的场景，我们就可以写成这样的一个 Agent Skill。可以看出它本质上呢就是一个 Markdown 大文档。

它的整体结构可以分成两部分：

上面的这一部分呢是叫做元数据层，它相当于这本说明文档的封面，告诉 Agent 这个 Skill 叫什么、是负责做什么事情的。这一部分呢至少要有两个属性，分别是 name 和 description。name 呢代表这个 Agent Skill 的名字，比如我们的 Agent Skill 名称是叫做 Door Checklist，也就是出门清单的英文。剩下的 description 呢就是描述了。

然后下面的这一段，从目标开始到这个说明文档的结束，这一大片都叫做指令层。 这一层的格式不做具体要求，只要能把事情向 Agent 说明白就行，格式自己来定。比如我这里就写了：要完成的目标、执行步骤、判断规则、输出格式及示例。

比如你看，我们在执行步骤里面就告诉 Agent：需要先调用定位工具获取经纬度，然后呢再调用天气工具获取天气信息。拿到天气信息之后呢，需要根据天气的数据结果，按照下方的判断规则整理出门所需要携带的物品。判断规则呢就写在这里面。

最后呢是需要严格按照下方的输出格式向用户输出最终的结果。输出格式呢我们就写在这里，一共是需要输出两段话。

在指令层的最后我们还给了它一个示例。在这个示例里面，我们假定用户的问题呢是这个样子的：”我马上出门，帮我看看今天要带什么东西。”然后工具的返回呢我们假设是这样子的：定位工具返回假设这样，天气工具返回假设是这样。在这种情况下 Agent 呢就必须输出这样一份结果。

这个就是我们所需要的 Agent Skill 的整体结构了。定义好之后我们需要把它存到硬盘里面指定的地方。拿 Claude Code 举例，你需要找到用户目录下面的 .claude/skills/。

然后接下来的操作呢有两个规定，大家千万不要搞错：

第 1 点：我们需要在这个目录下面新建一个文件夹，而且文件夹名字必须和 Agent Skill 的名字相同。我们 Agent Skill 叫做 go-out-checklist，所以我们文件夹必须叫这个名字。

第 2 点：进入到这个文件夹里面之后，我们需要新建一个文件，把刚才的内容全部贴进来。重点来了，这个文件名必须叫做 skill.MD，其中 skill 是小写。这个呢是 Agent Skill 的硬性规范，算是个接头暗号，如果你随便起别的名字系统是绝对不会认的。

好，我们把它全部给粘贴进来，然后保存退出。整好之后呢我们这个 Agent Skill 就算是创建完成了。

然后我们来随便找一个空的文件夹，启动 Claude Code。在启动过程中，Claude Code 就会发现 .claude 里面多了一个叫做 go-out-checklist 的 Agent Skill，它呢就会去读取对应的 skill.MD 文件里面的元数据，也就是名称和描述。下面的指令层暂时先不读，因为指令层内容有可能会比较大，所以呢 Claude Code 只会在用户问题与 Agent 的名称描述相关的时候才会去读取对应的指令层。

另外顺便提一下，这个 Agent Skill 有明确要求需要定位和天气这两个工具，我已经提前把它们做成 Function Calling 工具导入到 Claude Code 里面。运行这个 Agent Skill 就可以验证，这个 location 呢就是定位工具，下面那个 weather 呢就是天气工具。这两个工具的返回结果都是我编的，到时候你就会看出来，主要呢是为了演示整个流程。

好，言归正传，下面呢我们输入问题：”我要出门了，告诉我要带什么。”提交。

可以看到 Claude Code 开始工作了，让我们稍微等待一下。

它首先是发现这个问题与 go-out-checklist 的这个 Agent Skill 相关，因此呢就读取了这个 Agent Skill 的完整内容。这里主要读取的就是里面的指令层，毕竟元数据层已经在 Claude Code 启动的时候加载过了。

在读取到了 Agent Skill 的完整内容之后，Claude Code 就开始了。它首先是请求调用定位工具，我们同意。然后呢它再调用天气工具，我们还是同意。

最后拿到了所有需要的信息之后，Claude Code 就会把答案整理成 Agent Skill 中所需要的格式给到我们。

没错，Agent Skill 的基本功能呢就是这么简单，它就是一个文档，一个给 Agent 看的说明文档。当然 Agent Skill 呢还有很多高级的功能，比如说运行代码、引用资源等等。它的按需加载机制呢也是一大特色，可以节省很多的 Token。

如果你对此感兴趣，希望深入了解一下的话，欢迎看一下我的这个视频，一次把 Agent Skill 的使用和原理全部都说明白。

那这里我们把所有的概念都讲完了，让我们回顾一下这个体系：

大致呢就是这个样子的了。理解了这些概念你就能看懂 AI 圈子里面的各种新产品新技术了。无论是 Claude Code 的 Agent Skill 还是 OpenAI 的 Code Interpreter，它们本质上都是在这个框架下运作的。

参考资料