AI 圈子里每天都在冒新名词LLM、token、context、prompts、tool、MCP、agents、agent skill这些词你可能都听说过但是我问大家你真的能准确地说出其中每一个概念的确切含义吗这篇文章我们不整那些虚头巴脑的商业概念我们就从最底层的工程视角出发一个一个把这些概念拆开、揉碎、讲清楚。看完这篇文章相信你对 AI 的理解绝对会上升一个台阶。我们先从最底层的东西开始一层一层往上搭。最底层的就是 LLM全称是 large language model翻译成中文就是大语言模型简称大模型。基本上现在所有的大模型都是基于 transformer 这套架构训练出来的。这个架构看起来很复杂不过不用担心这张图你现在看不懂是完全正常的我们今天也不打算研究它你只需要知道大模型的底层引擎就是它。transformer模型架构transformer 架构最早其实是由 google 团队在 2017 年的时候提出来的对应的论文名是叫做 attention is all you need。很有戏剧性的是虽然 google 发明了火种但真正把它点燃并且引爆全世界的却是 openai。大家应该都记得 2022 年底 gpt3.5 横空出世它应该算是第一个真正达到可用级别的大模型了相信当时用过的人都能感受到它的强大。但这还没完仅仅几个月之后在 2023 年 3 月份 gpt4 发布它是直接把 AI 的能力天花板拉到了一个新的高度可以说 gpt 系列就是我们今天 AI 浪潮的绝对鼻祖了。甚至时至今日gpt 家族依然非常强大比如现在的 gpt-5.4 就是业界的标杆之一。不过如今的 AI 赛道早已经不再是 openai 的独角戏了像 claude、gemini 等优秀的后起之秀都在各自擅长的领域与它同台竞技。前面我们说了大模型的大致由来那大模型到底是怎么工作的其实非常的朴素它本质上就是一个文字接龙游戏。我们来看一个具体的例子假设你向大模型提问小童鞋的文章怎么样模型接收到这句话之后经过内部的一通运算它会预测下一个概率最高的词比如 “特别”。关键点来了模型吐出 “特别” 这个词之后并不会停下来它会把这个刚吐出来的 “特别” 这个词抓回来追加到你刚才的那个输入后面然后它拿着这个新的输入再去预测下一个字比如说是 “得”。接着它再把 “得” 塞回去然后再预测下一个词比如说是 “棒”然后它会把 “棒” 这个字也塞回到输入里面。这个时候大模型会发现它要说的话已经全部说完了此时它就会输出一个特殊结束标示符整个回答到这里就算彻底结束了。这样我们就拿到了大模型的完整回答特别得棒。这就是大模型最底层的生成原理了理解了这一点你就明白了为什么大模型要一个词一个词地输出答案因为它就是这么运作的。刚才说了用户提交问题给大模型之后大模型每次都会吐出一个词但其实这是为了方便你理解而简化了一个链路。现实情况是这样的大模型本质上是一个庞大的数学函数里面跑的全是矩阵运算它接收的是数字输出的也是数字压根就不认识人类写的文字。所以在人类和大模型之间必须有一个中间人来做翻译这个中间人就叫做 tokenizer它负责的是编码和解码两件事情。编码就是把文字变成数字解码反过来是把数字还原成文字。还是拿刚才的那个例子来说用户提问小童鞋的文章怎么样这句话会先交给 tokenizer 处理它要把这些文字转换成数字这就是编码环节在发挥作用了。我们来把编码的过程拆开来仔细看一下搞清楚它究竟是怎么把文字变成数字的。这个过程分两步走。第一步切分。它把用户的问题接过来把它拆成一个一个最小的片段这些片段就叫做 token我们这里一共是切出了 6个 token。参考网站https://platform.openai.com/tokenizer第二步映射。由于模型只认数字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 的输出结果。现在我们回头看刚才的那个例子小童鞋的文章怎么样它是被切分成了6个 token小、童、鞋、的、文章和怎么样。你有没有注意到这里有的一个token对应一个汉字有的对应的是一个词并没有十分严格的对应关系。当然你也可能会说童鞋是不是也不能算作一个词那我们再看一个更明显的例子程序员这总算是一个完整的词了吧但在 tokenizer 里面它被切成了两个 token程序和员。这个是中文的情况那英文呢一个英文单词对应一个 token 吗对于常见单词确实是这样的比如 hello 是一个 tokengoing 也是一个 token。不过这个也不是铁律比如 helpful 这个单词就被拆成了两个 tokenhelp 和 ful。甚至在某些情况下一个字母会被切分成多个 token 来用比如对勾这个字母就需要三个 token 来表示它。不过这三个 token 没有对应的显示字母所以在这里面显示的就是问号了。这种情况下看 token id 可能还更直观一些你看确实是三个。所以我们总结下词和 token 并没有什么明确的一对一的关系你可以把 token 理解成模型自己学会的一套文本切分规则切出来的每一块就是它一次能够处理的最小单位。平均来讲一个 token 大概是等于 0.75 个英文单词或者是 1.5 到 2 个汉字。比如 40 万个 token 大概就是 60 到 80 万个汉字或者是 30 万个英文单词。如果你对 token 的切分原理感兴趣想详细了解一下 token 到底是怎么生成出来的可以看一下贴token生成机制文章它详细讲述了如何使用 bpe 算法来训练和使用 tokenizer。刚才讲了 token知道了它是大模型处理文本的基本单位。下面来看一件可能一直觉得理所当然但其实很值得想一想的事情。平时和大模型聊天它好像能记住之前说的话。比如开头告诉他我叫小童鞋它跟你回复了以后再问他我叫什么它还是能够回答得出来。但问题是大模型本质上只是一个数学函数给它输入就给你输出它并不像人一样真的有记忆。那它是怎么记住之前的聊天内容的答案就是每次给大模型发送消息的时候并不只会发问题背后的程序会自动把之前的整段对话历史找出来一起发过去。这样有了用户问题有了对话历史模型每次看到的就是完整的对话内容了所以它才能够知道之前发生了些什么。这就引出了 context 这个概念中文叫做上下文它代表大模型每次处理任务时所接收到的信息总和。刚才聊到用户问题和对话历史都是大模型所接收到的消息所以它们都是 context 的一部分。除了它们之外context 里面还有很多其它的内容比如大模型正在输出的每一个 token 也会被追加进来。除此之外这里面还会有工具列表、system prompt 等信息。这些概念后面会一个一个地讲到暂且不用关心。现在只需要记住一件事情context 就是大模型每次处理任务时所接收到的信息总和。从某种程度上也可以把它看成是大模型的一个临时记忆体。理解了 context下一个问题就自然而然地出来了。context 能有多大它能塞多少 token这就引出了 context window 这个概念翻译过来叫做上下文窗口它代表了 context 能够容纳的最大的 token 数量。举个例子context window 为一万就代表模型最多能够处理一万个 token。不过一万的 context window 算是很小的了目前主流的大模型都有着非常大的 context window。比如 gpt5.4 的 context window 是一百零五万Gemini 3.1 Pro 的 context window 是一百万Claude Opus 4.6 的 context window 是一百万。之前说过一个 token 大概等于一点五个汉字那么一百万个 token 差不多就是一百五十万个汉字了整个哈利波特全集的内容都能装下算是很大的了。相信大家对 context 已经有一个初步的了解了。下面来问大家一个问题假如有一个上千页的公司产品手册希望大模型根据这个产品手册来回答用户的各种疑问那这要怎么实现要把这个手册的全部内容跟着用户问题一起扔给大模型吗这其实不是一个很好的解决方案因为产品手册太长了即使模型的 context window 不会爆成本也无法控制。那这该怎么办这就需要一个叫做 RAG 的技术了它可以从产品手册中抽取与用户问题最为匹配的几个片段然后只把这几个片段发给大模型让大模型只根据这几个片段来回答用户的问题。这样大模型接到的就不是一整本书了可能只是几句话这样就不受 context window 大小限制了成本也会低很多。如果对 RAG 技术感兴趣想深入了解下它的实现原理后续也会出关于RAG的文章。prompt中文为提示词它是大模型接收的具体问题或指令。比如去向大模型提需求帮我写一首诗这句话就是 prompt。不要把 prompt 想得特别复杂、高端它只不过就是给大模型的一个问题或者是指令而已。接到了这个输入之后大模型才会开始运转然后才会给你一个对应的答案。但这里面会有个问题如果只是简单地说帮我写一首诗大模型可能会写诗就像屏幕上展示的这样但也可能写现代诗甚至可能来一首打油诗。为什么因为 prompt 太模糊了它不知道你具体想要什么。所以 prompt 怎么写直接决定了大模型的输出质量。一个好的 prompt 应该是清晰的、具体的、明确的。比如可以这样写请帮我写一首五言绝句主题是秋天的落叶风格要明亮一点。这样一来大模型就清楚多了它生成的内容也就更符合预期。这就是为什么有个专门的领域叫做 prompt engineering也就是提示词工程。说白了就是研究怎么把话说清楚让大模型更精准地理解意图。当然这个领域虽然曾经比较火但现在还在提它的人其实寥寥无几。一方面是因为门槛太低本质上就是把话说清楚。另一方面是大模型的能力越来越强了即使提示词含糊不清大模型也能大致猜出意图这种情况下也就不需要在提示词上花太多功夫了。到这里 prompt 基本概念应该是搞清楚了但是事情还没有完。有没有想过一个问题有些时候不仅要告诉大模型要处理的具体任务还要告诉它人设和做事规则也就是告诉大模型它是谁它应该按照什么规则做事。这就引出了两种不同的 prompt说明具体任务的是 User Prompt中文为用户提示词它是用户自己输入的。说明人设和做事规则的是 System Prompt中文为系统提示词它是开发者在后台配置的。用一个具体的例子解释这两个概念。假设要做一个数学辅导机器人希望它不要直接告诉学生答案而是要引导学生思考。这时候就需要两种 prompt。第一种是 System Prompt在后台这样设置你是一个耐心的数学老师当学生问你数学问题的时候不要直接给出答案而是要一步一步引导学生思考帮助他们理解解题思路。注意这段话是作为开发者在后台设置的用户根本看不到但它会一直影响大模型的行为。第二种是 User Prompt学生在对话框里输入三加五等于几这就是用户在对话框里直接输入的问题。大模型看到这两个 prompt 之后会这样想我的角色是数学老师我要引导学生思考不能直接说答案。那我就这样回答可以这样想你手里有三个苹果然后又拿了五个现在一共有多少个可以数一数。看到了吗如果没有 System Prompt大模型可能就直接说八了。但因为有了 System Prompt 的约束它知道自己要扮演一个引导式的老师所以回答就完全不一样了。相信现在可以理解 User Prompt 和 System Prompt 的区别了有了它们的配合大模型既能守住规矩又能够完成具体需求。prompt 就讲到这里了再看下一个概念 Tool。先谈一下大模型的一个弱点它无法感知外界环境。举个例子假设问大模型今天上海的天气怎么样它可能会说抱歉我无法获取实时天气信息我的知识库截止到某年某月无法提供当前的天气数据。为什么因为大模型只是个文字接龙游戏它的能力是根据训练数据来预测下一个词但它真的没有办法去查天气预报网站拿到实时的天气数据这该怎么办这就需要 Tool 了。Tool 翻译成中文就是工具工具这个词不太好理解再换一个词函数。对没错Tool 本质上就是一个函数你给它输入它就给你输出。比如一个天气查询工具它的输入可能会包含两个参数分别是城市和日期传入后它内部一通操作比如说它可能会去调用气象局的接口但不管怎么样最后它都会给你一个输出告诉你对应的天气信息。有了它大模型就可以回答天气相关的问题了。让我们来看一下从用户提问到大模型回答的完整流程。整个流程所涉及到的角色是包括用户、大模型、天气查询工具还有平台。你可能会问平台是什么你可以把平台理解为一个传话筒因为用户、大模型、天气查询工具这三个角色没办法直接对话所以就需要平台这个角色来做传递信息的工作。它本质上就是一段代码用来负责上传下达。你可能还有点懵没事现在不明白也没有关系你看完流程就懂了。在流程一开始的时候用户的问题会首先发给平台平台会把用户的问题转发给大模型。不过发给大模型的可不止有用户问题还有目前可用的工具列表比如说是天气查询工具、计算器工具等。大模型收到这个问题之后它会自己分析用户想问天气而我没有实时的天气数据但是这里面有一个天气查询工具可以用好那我就调用这个工具。注意大模型无法自己调用工具它唯一的能力就是输出文本如果它想调用某个工具它就只能借助平台的力量。所以此时大模型会生成一个调用天气查询工具的指令大概就是这样子的。这个指令标识了要用的工具名称和对应的参数它会发到平台那边去。平台接收到这个指令之后就会真的调用这个工具其实也就是调用了工具背后所对应的一个函数。调用结束之后平台会拿到对应的天气信息大概是这个样子的。后续会写关于function calling以及mcp的文章对这个过程会理解更深刻在平台拿到了工具的调用结果之后它就会把这个信息返回给大模型大模型拿到这个结果后会把它整理成一句人话输出给平台比如说是今天上海的天气不错晴天温度在十五度到二十五度之间诸如此类的。然后平台会继而把这句话转发给用户这样用户就可以看到结果了。可以看到在这个过程中每个角色都有着自己的职责其中大模型的职责是有两个第一个是选择工具具体来说就是选择需要调用的工具并生成对应的工具参数。第二个是汇总总结也就是在拿到工具的执行结果之后模型需要对工具的结果做一个汇总总结。工具的职责则是完成查询天气这个动作而剩下的一个角色平台它负责处理的就是串联整个流程了比如告诉模型哪些工具可用根据模型的工具调用指令来调用工具等。所以大家要分清楚每个角色在干什么有人可能会以为调用工具的是模型尤其是初学者很容易就会这么想但是模型能做的仅仅是输出一段文本告诉平台它想要调用哪个工具调用工具这件事最终还是要用平台来完成。所以最后总结一下Tool 的本质就是给大模型提供一套它可以调用的外部能力让大模型能够感知和影响外部环境。Tool 的概念就到这里我们来讲下一个概念 MCP。刚才我们讲了使用工具的全流程但这里面有个工程上的大问题看这两部分第一平台要把工具列表传给模型第二还要能调用工具。要做到这些我们首先就得把工具接入到平台里面。如果用的是 ChatGPT那就要遵守 OpenAI 的接入规范如果用的是 Claude就要遵守 Anthropic 的接入规范如果用的是 Gemini就要遵守 Google 的接入规范。看出问题了吗同一个工具你要写 3 遍这显然是不合理的。所以 AI 圈子里就有人想能不能制定一个统一的接入规范让所有的平台都遵循这个标准这样工具就可以像 Type-C 接口一样即插即用了。请注意这里非常容易引起误解这里只是说明工具的可以不用重复即相同的工具不用写三份有一个标准的协议就可以复用这个工具但是对于平台来说是没有办法复用的在模型与平台的交互过程中不同的模型实现不同平台要支持多模型也必须进行额外支持工作MCP 就是这个统一的接入规范它的全称叫做 Model Context Protocol翻译过来就是模型上下文协议名字不太好理解你可以把它看成是统一的工具接入标准。有了 MCP 之后这个工具就可以被所有兼容 MCP 的平台所使用就像 Type-C 接口一样。那这就是 MCP 的由来和作用了。如果你想更深入地了解 MCP 协议可以看一下《MCP 终极指南》系列文章里面把 MCP 协议扒了个底朝天相信看完之后你对 MCP 有一个非常全面的理解。现在我们知道大模型可以通过工具连接外部世界而工具又可以使用 MCP 这种方式来统一接入那现在的大模型应该很强了吧比如我们来尝试让大模型解决一个稍微复杂一点的问题今天我这里的天气怎么样如果下雨的话帮我查一下附近有没有卖雨伞的店。要解决这个问题我们需要三个工具定位工具它负责查询用户所在地区的经纬度。天气工具它是用来根据经纬度查询天气信息的。店铺工具它是通过经纬度来查询附近的店铺。整个过程应该是这样的大模型在拿到用户的问题之后首先要思考那要拿到天气信息的话得先知道用户的位置我来申请调用下定位工具。然后平台去调用定位工具平台调用工具之后返回结果比如是经度 - 74纬度 40。模型再次思考好拿到了位置下一步我需要查询这个位置的天气了申请调用天气工具参数是经度负 74 度纬度 40 度。平台调用工具之后返回结果有雨。根据用户的要求如果是下雨那我还得查一下附近卖雨伞的店这里有一个店铺工具可以调用下调用店铺工具搜索雨伞参数是经度 - 74纬度 40。平台调用工具之后返回结果附近 100 米有家全家便利店卖伞。现在所有信息都齐了我可以给用户最终答案了今天天气有雨建议携带雨伞附近 100 米有家全家便利店可以购买。整个回答就算是完整结束了。在这个过程中大模型是自己决定要调用哪些工具并且自己决定了调用工具的先后顺序这其实就是一个简单的任务编排流程了。大模型能够根据用户的问题自己拆解任务并决定下一步要做什么这说明它已经有了一定的任务规划能力。在 AI 领域我们把这种能够自主规划、自主调用工具、直至完成用户任务的系统为 Agent。比较流行的 Agent 产品包括 Claude Code、Codex、Gemini CLI 等它们所使用的 Agent 构建模式主要有两种分别是 ReAct 和 Plan And Execute。后续也会写具体的文章用于说明agent会详细讲解agent以及agent常用的react以及plan and excute运行模式如果想深入了解 Agent 的概念、原理与构建模式强烈建议去看一下我的这篇文章里面不仅详细拆解了每种构建模式的原理我还直接手写了一个简化版的 Claude Code相信看完之后你就会明白 Agent 到底是如何实现的。我们现在知道 Agent 能够自主规划、自主调用工具听起来已经很完美了对吧但实际使用的时候你马上就会遇到一个新痛点。假设你做了一个出门小助手每次出门前都帮你查一下天气然后告诉你需要带什么东西。你肯定有一套自己的出门习惯比如下雨带伞、光照强带帽子、空气差戴口罩、风大穿防风外套、无论如何手机必带。不仅如此你可能还是个强迫症必须按照特定的格式输出首先用一句话总结当天出门的重点然后再列出要带的物品清单每个物品后面还要备注原因。现在你去向 Agent 提问我马上要出门该带些什么Agent 虽然很聪明但它不知道你的这些私人规则它无法根据你的出门习惯来生成符合你要求的回答输出的格式也无法满足你的要求。那怎么办你每次提问时都不得不带上一大串尾巴把你的出门习惯、输出格式甚至示例统统塞进 Prompt 里发给它。试想一下每次出门都要敲这么一大段要求是不是很麻烦这个时候 Agent Skill 就该登场了。Agent Skill 就是你提前写好塞给 Agent 的一份说明文档有了它 Agent 就可以按照你的规则来做事了。我们就可以写这样一个 Agent Skill它的整体结构可以分为两部分。第一部分是抬头相当于是份说明文档的封面里面有 name、description 等字段。name 代表了 Agent Skill 的名字description 是对这个 Skill 的简单描述比如生成出门清单当用户询问 “出门带什么 / 需要准备什么 / 今天外出需要带哪些东西” 时使用。然后下半部分从目标开始这一大片都叫做指令层里面详细描述了要完成的目标、具体的执行步骤、判断规则、输出格式以及示例。只要能把事情向 Agent 说明白就行格式并不固定。比如我们这里就写了要完成的目标是做一个贴心的 “出门清单助手”任务是根据用户所在位置的实时天气情况告诉用户出门该携带的物品。执行步骤是调用 “定位工具”获取用户当前所在位置的经纬度。得到经纬度后再调用 “天气工具”一次性获取降雨情况、光照强度、空气湿度和风力大小这四个数据。根据天气数据按照下方的 “判断规则” 整理出门需要携带的物品。严格按照下方的 “输出格式” 向用户输出最终结果。判断规则是手机无条件必带。伞当 “天气工具” 返回 “降雨” 时必须携带。帽子当 “天气工具” 返回 “光照强” 时必须携带。口罩当 “天气工具” 返回 “空气差” 时必须携带。防风外套当 “天气工具” 返回 “风大” 时必须携带。输出格式是【结论一句话】用一句话总结当天出门需要注意的重点例如 “有雨 光照强建议‘真力大’”。【出门清单】物品原因物品原因然后在指令层的最后我们还给了它一个示例用户问题是 “我马上要出门了帮我看看今天需要带些什么”工具返回的定位是经度 - 73.9855纬度 40.7580天气工具返回的是降雨情况 “有雨”、光照强度 “强”、空气湿度 “湿”、风力大小 “强风”最终输出是【结论一句话】有雨 光照强 强风今天出门全方位备战【出门清单】- 手机必带- 伞有雨务必带好- 帽子光照强防晒需要- 防风外套强风注意保暖挡风这个就是我们所需要的 Agent Skill 的整体结构了。现在我们需要把它部署到 Agent 里面去以 Claude Code 为例首先我们需要找到它的技能目录也就是.claude/skills 文件夹大家千万不要搞错这个文件夹的路径是固定的必须与 Agent Skill 的名字相同所以我们的文件夹也必须叫这个名字然后我们需要新建一个文件这个文件名必须叫做 SKILL.md如果你随便起个名字系统是绝对不会认的。好我们把它全部粘贴进来存好之后我们这个 Agent Skill 就算是部署完成了。然后我们随便找个空文件夹在里面启动 Claude Code此时你会发现技能列表里多了一个叫做 go-out-checklist 的技能这就说明我们的 Agent Skill 已经生效了。前面的元数据也就是名称和描述平面的格式写得对不对系统并不关心它只会在用户问题匹配到 description 字段时才会去调取对应的指令层。运行这个 MCP 就可以验证下面那个 weather 就是天气工具location 是定位工具到时候你就会看出来了。好言归正传下面我们输入问题我要出门了告诉我需要带什么可以看到 Claude Code 开始工作了它首先加载了 go-out-checklist 这个技能因此就读取了 Agent Skill 的完整内容这里主要读取的就是里面的指令了。在读到了 Agent Skill 的指令层之后它首先思考用户要出门带什么需要先获取位置和天气。它首先是请求调用定位工具我们同意然后它在调用天气工具我们还是同意最后拿到了所有需要的信息之后它就按照指令层里的要求整理成 Agent Skill 中所要求的格式给我们。这就是 Agent Skill 的作用它就是一个文档里面写满了你希望 Agent 如何处理某一类任务的规则有了它之后你就不需要每次都把规则塞进 Prompt 里了。当然 Agent Skill 还有很多高级的功能比如它的变量系统、它的渐进式披露机制也是一大特色。如果你对此感兴趣希望深入了解一下的话欢迎看一下我的这篇文章一次把 Agent Skill 的使用和原理全部说明白。好到这里我们把所有的概念都讲完了来快速回顾一下LLM 代表大模型Token 是大模型处理数据的最基本单元Context 是大模型每次处理任务时接收到的信息总和里面装着历史记录、系统规则、用户问题等这些数据的基本单位都是 TokenContext Window 是大模型的 Context 最多能够存储的 Token 量Prompt 是用户或系统当前给大模型下达的具体指令或问题它分为 User Prompt代表用户给模型的输入和 System Prompt代表大模型人设和做事规则Tool 是大模型用来感知和影响外部环境的函数MCP 则是统一了工具接入格式的标准协议开发者只需要按照一个标准开发工具即可不需要为每个大模型厂商都做一遍Agent 是能自主规划和调用工具、直至解决用户问题的程序Agent Skill 是给 Agent 看的说明文档大致就是这样子的了相信现在你再听到各种新产品新技术了比如什么 Codex、Cowork 还是 OpenClaw应该都能明白它们在说什么了。