AI 圈子里每天都在冒新名词，LLM、Token、Context、Prompt、Tool、MCP、Agent Skill。这些词你可能都听说过，但是我问大家：你真的能准确地说出其中每一个概念的确切含义吗？这期视频，我们不整那些虚头巴脑的商业概念，我们就从最底层的工程视角出发，一个一个把这些概念拆开、揉碎、讲清楚。看完这期视频，你对 AI 的理解绝对会上升一个台阶。我们先从最底层的东西开始，一层一层往上搭。
最底层的，就是 LLM。LLM 全称 Large Language Model，翻译成中文就是大语言模型，简称大模型。基本上现在所有的大模型，都是基于 Transformer 这套架构训练出来的。这个架构看起来很复杂，不过不用担心，这张图你现在看不懂是完全正常的，我们今天也不打算研究它。你只需要知道：大模型的底层引擎就是它——Transformer 架构。
Transformer 架构最早其实是由 Google 团队在 2017 年的时候提出来的，对应的论文名是叫做《Attention Is All You Need》。很有戏剧性的是，虽然 Google 发明了火种，但真正把它点燃并且引爆全世界的，却是 OpenAI。大家应该都记得 2022 年底 GPT-3.5 横空出世，它应该算是第一个真正达到可用级别的大模型了。
相信当时用过的人都能感受到它的强大，但这还没完。仅仅几个月之后，在 2023 年 3 月份 GPT-4 发布，它是直接把 AI 的能力天花板拉到了一个新的高度。可以说 GPT 系列就是我们今天 AI 浪潮的绝对鼻祖，甚至时至今日 GPT 家族依然非常强大。
比如现在的 GPT-5.4 就是业界的标杆之一。不过如今的 AI 赛道，早已经不再是 OpenAI 的独角戏了。像 Claude、Gemini 等优秀的后起之秀，都在各自擅长的领域与它同台竞技。前面我们说了大模型的大致由来，那大模型到底是怎么工作的呢？
其实非常的朴素。它本质上就是一个文字接龙游戏。我们来看一个具体的例子：假设你向大模型提问“马克的视频怎么样”，模型接收到这句话之后，经过内部的一通运算，它会预测下一个概率最高的词。比如“特别”。
关键点来了：模型吐出“特别”这个词之后，它并不会停下来。它会把这个刚吐出来的“特别”这个词抓回来，追加到你刚才的那个输入后面，然后它拿着这个新的输入再去预测下一个字。比如说是“得”。
接着它再把“得”塞回去，然后再预测下一个词，比如说是“棒”，然后它会把“棒”这个字也塞回到输入里面。这个时候大模型会发现，它要说的话已经全部说完了。此时它就会输出一个特殊结束标示符，整个回答到这里就算彻底结束了。
这样我们就拿到了大模型的完整回答：“特别得棒”。这就是大模型最底层的生成原理了。理解了这一点，你就明白了为什么大模型要一个词一个词地输出答案——因为它就是这么运作的。
刚才说了用户提交问题给大模型之后，大模型每次都会吐出一个词。但其实这是为了方便你理解而简化了一个链路。现实情况是这样的：大模型本质上是一个庞大的数学函数，里面跑的全是矩阵运算。它接收的是数字，输出的也是数字，压根就不认识人类写的文字。
所以在人类和大模型之间必须有一个中间人来做翻译，这个中间人就叫做 Tokenizer。它负责的是编码和解码两件事情：编码就是把文字变成数字，解码反过来是把数字还原成文字。还是拿刚才的那个例子来说：用户提问“马克的视频怎么样”。
这句话会先交给 Tokenizer 处理，它要把这些文字转换成数字。这就是编码环节在发挥作用了。我们来把编码的过程拆开来仔细看一下，搞清楚它究竟是怎么把文字变成数字的。这个过程分两步走：第一步切分。
它把用户的问题接过来，把它拆成一个一个最小的片段，这些片段就叫做 Token。我们这里一共是切出了 4 个 Token：马克、的、视频和怎么样？第二步，映射。由于模型只认数字，Tokenizer 就会把每一个 Token 对应到一个数字上去。
这个数字就叫做 Token ID。Token ID 和 Token 是一一对应绑定的，Token 是文字，Token ID 是数字。这两个其实本质上是一个意思，只不过是换了种表达方式而已。经过了这两步，原来的一句话就变成了一串 Token ID 组成的列表。
然后 Tokenizer 会把这串列表送进模型，模型在内部一顿运算，最终吐出了一个 Token ID。这个时候 Tokenizer 再次出场，把这个 Token ID 翻译回 Token。这就是解码环节的工作了：解码只有一步，那就是映射，方向是跟编码反过来，把数字转换成文字。
要注意的是解码环节是不需要切分的，因为模型每次只会给出一个 Token，并没有什么好切分的。解码完成后，我们就拿到了大模型输出的第一个 Token：“特别”。如果模型的话还没有说完，就继续吐第二个、第三个 Token。后面的流程其实都是一样的，这里就不再重复了。
所以你看到了吗？Token 才是大模型处理文本的最基本单元。大模型一个 Token 一个 Token 地接收输入，然后再一个 Token 一个 Token 地输出结果。现在我们回过头看刚才的那个例子：“马克的视频怎么样”，它是被切分成了 4 个 Token：马克、的、视频和怎么样？
你有没有注意到，这里每个 Token 好像都正好对应一个词啊。所以你可能会想：Token 就是词对吧？但其实不一定，Token 和词并不是一一对应的关系。刚才那个例子只是恰好而已。我们换几个例子你就明白了：比如我的频道是叫做“马克的技术工作坊”。
如果按照词的标准来划分的话，那应该是划分成 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 来用。比如对于对勾这个字符（✓），就需要 3 个 Token 来表示它。不过这 3 个 Token 没有对应的显示字符，所以在这里面显示的就是问号了（?）。这种情况下看 Token ID 可能还更直观一些，你看确实是 3 个。
所以我们总结一下：词和 Token 并没有什么明确的一一对应的关系。你可以把 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 是 105 万，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：第一种是 System Prompt，你在后台这样设置：“你是一个耐心的数学老师。当学生问你数学问题的时候不要直接给出答案，而是要一步一步引导学生思考帮助他们理解解题思路。”
注意这段话是你作为开发者在后台设置的，用户根本看不到。但它会一直影响大模型的行为。然后学生在对话框里输入“3 加 5 等于几”，这就是第二种 User Prompt：用户在对话框里直接输入的问题。大模型看到这两个 Prompt 之后它会这样想：“我的角色是数学老师，我要引导学生思考不能直接说答案。好那我就这样回答。”
“我们可以这样想：你手里有 3 个苹果然后又拿了 5 个，现在一共有多少个呢？你可以数一数看。”看，如果没有 System Prompt，大模型可能就直接说“8”了。但因为有了 System Prompt 的约束它知道自己要扮演一个引导式的老师，所以回答就完全不一样了。
相信你现在可以理解 User Prompt 和 System Prompt 的区别了：有了它们的配合，大模型既能守住规矩又能够完成你的具体需求。好，Prompt 呢我们就讲到这里了。我们再来看下一个概念：Tool（工具）。
我们先来谈一下大模型的一个弱点：它无法感知外界环境。我来举个例子，假设你问大模型“今天上海的天气怎么样”，它可能会说：“抱歉我无法获取实时天气信息，我的知识库截止到某年某月无法提供当天的天气数据。”为什么呢？因为大模型只是个文字接龙游戏，它的能力是根据训练数据来预测下一个词。
但它真没有办法去查天气预报网站拿到实时的天气数据。这该怎么办呢？这就需要 Tool 了。Tool 翻译成中文就是工具，工具这个词不太好理解我们再换一个词：函数。对没错 Tool 本质上就是一个函数，你给它输入它就给你输出。比如一个天气查询工具它的输入可能包含两个参数：分别是城市和日期。
传入后它内部一通操作，比如说它可能会去调用气象局的接口但不管怎么样最后它都会给你一个输出告诉你对应的天气信息。有了它大模型就可以回答天气相关的问题了。让我们来看一下从用户提问到大模型回答的完整流程，整个流程所涉及到的角色是包括：用户、大模型、天气查询工具还有平台。
你可能会问：平台是什么？你可以把平台理解为一个传话筒，因为用户、大模型、天气查询工具这三个角色没有办法直接对话。所以我们就需要平台这个角色来做传递信息的工作，它本质上就是一段代码用来负责上传下达。你可能还有点懵没事现在不明白也没有关系看完流程就懂了。
这个指令标示了要用的工具名称和对应的参数，它发到平台那边去。平台接收到这个指令之后，就会去真正地调用这个工具，其实也就是调用了工具背后所对应的一个函数。调用结束之后，平台会拿到对应的天气信息，大概是这个样子的。在平台拿到了工具的调用结果之后，它就会把这个信息返回给大模型。
大模型拿到这个结果后，会把它整理成一句人话输出给平台，比如说今天上海的天气不错，晴天，温度在15度到25度之间诸如此类的。然后平台继而把这句话转发给用户，这样用户就可以看到结果了。可以看到在这个过程中，每个角色都有着自己的职责。
其中大模型的职责有两个：第一个是选择工具，具体来说就是选择需要调用的工具并生成对应的工具参数；第二个是归纳总结，也就是在拿到工具的执行结果之后，模型需要对工具的结果做一个归纳总结。
工具的职责是完成查询天气的这个动作，而剩下的一个角色平台，它负责处理的就是串联整个流程了。比如告诉模型哪些工具可用、根据模型的指令去调用工具等等，所以大家要分清楚每个角色在干什么。
有人可能会以为调用工具的是模型，尤其是初学者很容易就会这么想。但是模型能做的仅仅是输出一段文本，告诉平台它想要调用哪个工具；调用工具这个事情，最终还是要由平台来完成。
所以最后总结一下Tool的本质：就是给大模型提供一套它可以调用的外部能力，让大模型能够感知和影响外部环境。好Tool的概念就到这里了，我们来讲下一个概念MCP。
刚才我们讲了使用工具的全流程，但这里面有个工程上的大问题：看这两部分，第一平台要把工具列表传给模型；第二还要能调用工具。要做到这些，我们首先就得把工具接入到平台里面，这样平台才知道可用工具列表以及每个工具的用途、参数和调用方法等等。
那问题来了，这套接入的规范每个平台都不一样：如果你用的是ChatGPT，你得按照OpenAI的规范接入工具写一套接入代码；如果你用的是Claude，你得按照Anthropic的规范接入再写一套接入代码。
如果你用的是Gemini，你得按照Google的规范接入然后再写一套。看出了问题了吗？同一个工具你要写3遍，因为每个平台的接入标准都不一样。所以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 Code、Codex、Gemini CLI等等。它们所使用的Agent构建模式也是五花八门，比较经典的有ReAct、Plan and Execute等等。
如果你对“构建模式”这个词比较陌生甚至根本就没有听说过的话，强烈建议去看一下我的这期视频。里面不仅详细拆解了每种构建模式的运行流程甚至还抛弃了所有现成的Agent框架直接手写了一个简化版的Claude Code。相信看完之后你就会彻底明白Agent到底是如何实现的。
我们现在知道Agent能够自主规划、调用工具持续工作直到完成任务，听起来已经很完美了对吧？但在实际的高频使用中你马上就会遇到一个新痛点。举个例子：假设你希望大模型成为你出门前的小助手，每次出门前都帮你查一下天气并提醒你带东西。
你肯定有一套自己的出门习惯，比如下雨带伞、光照强带帽子、空气差带口罩、风大穿防风外套，无论如何手机必带。不仅如此你可能还是个强迫症希望它的回答不要太啰嗦必须按照特定的格式输出，比如先来一句总结然后再列出要带的物品清单。
如果在没有任何预设的情况下假定你只问一句“我马上要出门该带些什么呢？”Agent虽然会查天气但它不知道你的这些私人规则和格式要求，大概率会给你一堆废话。它无法根据你的出门习惯来判断要带什么输出的格式也无法满足你的要求毕竟它都不知道。
为了得到满意的结果你每次提问时都不得不带上一大串尾巴，把你所有的规则、格式要求甚至示例统统塞进Prompt里发给它。试想一下每次出门都要敲这么一大段要求是不是太反人类了？别担心，这个时候Agent Skill就该登场了。
Agent Skill本质上就是你提前写好塞给Agent的一份说明文档，比如刚刚那个出门的场景我们就可以写成这样一个Agent Skill。可以看出它本质上就是一个Markdown文档它的整体结构可以分为两部分：上半部分是元数据层相当于这份说明文档的封面。
告诉Agent这个技能叫什么、负责做什么事情，这部分至少要有两个属性Name和Description：Name代表这个Agent Skill的名字比如我们的Agent Skill名称叫做Go out checklist也就是出门清单的英文；剩下的Description就是描述了。
然后下半部分从目标开始到这份说明文档的这一大片都叫做指令层，这层格式不做具体要求只要能把事情向Agent说明白就行格式自己来定。比如我这里就写了要完成的目标、执行步骤、判断规则、输出格式以及示例。
比如你看我们在执行步骤里面就告诉Agent需要先调用定位工具获取经纬度然后再调用天气工具获取天气信息。拿到天气信息之后需要根据天气的数据结果，按照下方的判断规则整理出门需要携带的物品。
判断规则就写在这里面，最后是需要严格按照下方的输出格式向用户输出最终的结果：输出格式我们就写在这里总共需要输出两段话。在指令层的最后我们还给了它一个示例，在这个示例中我们假定用户的问题是这个样子的：“我马上要出门帮我看看今天带什么东西。”
然后工具的返回我们假设是这样的：定位工具返回假设这样，天气工具返回假设这样。在这种情况下Agent就必须输出这样的一份结果这个就是我们所需要的Agent Skill的整体结构了。
定义好之后我们需要把它存到硬盘里指定的地方，拿Claude Code举例你需要找到用户目录下的.claude/skills文件夹。接下来的存放操作有两个规定大家千万不要搞错：第一我们需要在这个目录下新建一个文件夹并且文件夹的名字必须与Agent Skill的名字相同。
我们的Agent Skill叫做go-out-checklist所以我们的文件夹也必须叫这个名字。第二点进入到这个文件夹里面之后我们需要新建一个文件把刚才的内容全部贴进来，重点来了：这个文件名必须叫做SKILL.md其中SKILL是大写。
这是Agent Skill的硬性规范算是个接头暗号，如果你随便起个名字系统是绝对不会认的。好我们把它全部粘贴进来然后保存退出存好之后我们这个Agent Skill就算是创建完成了。
然后我们随便找个空文件夹启动Claude Code，在启动的过程中Claude Code就会发现skills文件夹里面多了一个叫做go-out-checklist的Agent Skill。它就会去读取对应的SKILL.md文件里面的元数据也就是名称和描述，下面的指令层暂时先不读。
因为指令层的内容有可能会比较大所以Claude Code只会在用户问题与Agent Skill的名称和描述相关的时候才会去读取对应的指令层。顺带提一句这个Agent Skill明确要求需要定位和天气这两个工具，我已经提前把它们做成MCP工具导入到Claude Code里面了。
运行这个MCP就可以验证：这个location是定位工具下面那个weather就是天气工具，这两个工具的返回结果都是我编的到时候你就会看出来了主要是为了演示整个流程。好言归正传，下面我们输入问题：“我要出门了告诉我带什么”，提交可以看到Claude Code开始工作了。
让我们稍微等待一下，它首先是发现这个问题与go-out-checklist这个Agent Skill相关因此就读取了Agent Skill的完整内容这里主要读取的就是里面的指令层了因为元数据层已经在Claude Code启动的时候加载过了。
在读取到了Agent Skill的完整内容之后Claude Code就开始按照Agent Skill的要求做事了：它首先是请求调用定位工具我们同意；然后它在调用天气工具我们还是同意。
最后拿到了所有需要的信息之后Claude Code就会把答案整理成Agent Skill中所要求的格式给到我们。没错，Agent Skill的基本功能就是这么简单：它就是一个文档一个给Agent看的说明文档。
当然Agent Skill还有很多高级的功能比如运行代码、引用资源等等，它的渐进式披露机制也是一大特色可以节省很多的Token。如果你对此感兴趣希望深入了解一下的话欢迎看一下我的这个视频《一次把Agent Skill的使用和原理全部都说明白》。
好到这里我们把所有的概念都讲完了，让我们回顾一下这个体系：LLM代表大模型它是所有AI技术的核心；Token是大模型处理数据的最基本单元。
Context是大模型每次处理任务时接收到的信息总和，你可以把它看作是大模型的临时记忆体里面装着历史记录、系统规则以及当前的输入等等。这些数据的基本单位都是Token，而Context Window则是代表大模型Context最多能够容纳的Token数量。
Prompt是用户或系统当前给大模型下达具体指令或问题，它分为User Prompt和System Prompt两大类：User Prompt代表用户给模型的输入而System Prompt则是开发者在后台配置的大模型人设和做事规则。
Tool是大模型用来感知和影响外部环境的函数，MCP则是统一了工具接入格式的标准协议。有了MCP之后开发者只需要按照一个标准来做工具就可以了不需要为每个大模型厂商都做一遍。
Agent是能自主规划、自主调用工具持续运作直到解决用户问题的一个程序；Agent Skill是给Agent看的说明文档主要用来规定做事的步骤和规则。大致就是这样子的了，理解了这些概念你就看懂了AI圈子里面的各种新产品新技术了。
无论是Claude Code、Codex、Cowork还是OpenClaw它们本质上都在这个框架下运作的。好，这期视频到这里就结束了如果对你有帮助别忘了点赞关注我是马克用最通俗的语言讲最硬核的技术我们下期再见拜拜。