AI 核心概念深度解析：从 LLM 到 Agent Skill 的完整技术体系

AI 核心概念深度解析：从 LLM 到 Agent Skill 的完整技术体系

本文从底层工程视角出发，系统拆解 LLM、Token、Context、Prompt、Tool、MCP、Agent、Agent Skill 等 AI 圈高频术语，厘清它们各自的精确定义、运行机制与相互依赖关系，帮助你真正理解当前 AI 技术栈的全貌。

核心要点

• LLM（大语言模型） 是所有 AI 技术的底层引擎，基于 Transformer 架构，本质是文字接龙游戏——逐词预测下一个最可能的词。
• Token 是大模型处理文本的最小单元，与"词"没有一一对应关系，平均 1 token ≈ 0.75 个英文单词或 1.5~2 个汉字。
• Context（上下文） 是大模型每次处理任务时接收到的信息总和，类似于临时记忆体；而 Context Window 则是这个"记忆体"的容量上限。
• Prompt 分为两类：User Prompt 是用户输入的指令，System Prompt 是开发者在后台配置的人设和规则。
• Tool（工具） 的本质是函数，作用是让大模型突破无法感知外部环境的局限；调用工具的动作并非由大模型完成，而是由平台执行。
• MCP（模型上下文协议） 是统一工具接入标准的协议，解决"同一工具需为每个平台分别写接入代码"的痛点，类比为"所有手机都用 Type-C 接口"。
• Agent 是能自主规划、自主调用工具、持续运作直至完成用户任务的系统，具备多步推理和决策能力。
• Agent Skill 本质上是给 Agent 看的说明文档（Markdown 文件），用于规定做事步骤和规则，让 Agent 按用户私人需求执行任务。

详细解析

一、LLM（大语言模型）：AI 的底层引擎

1.1 大模型的由来与发展

LLM 全称为 Large Language Model，中文即"大语言模型"，简称大模型。当前几乎所有大模型的基础架构都是 Transformer，它最早由 Google 团队在 2017 年提出，对应论文名为 *Attention Is All You Need*。

历史关键节点：

• Google 虽然发明了 Transformer 架构，但真正将其引爆全球的是 OpenAI。
• 2022 年底，GPT-3.5 横空出世，成为第一个真正达到可用级别的大模型。
• 2023 年 3 月，GPT-4 发布，将 AI 能力天花板拉到了新高度。
• GPT 系列被视为当前 AI 浪潮的绝对鼻祖。时至今日，GPT 家族依然强大（如 GPT-5.4 是业界标杆之一）。
• 目前 AI 赛道已非 OpenAI 独大，Claude、Gemini 等后起之秀在各自擅长领域同台竞技。

1.2 大模型的工作机制：文字接龙

大模型的工作方式本质上是一个文字接龙游戏：

1. 用户提问如"马克的视频怎么样"。
2. 模型在内部运算后，预测下一个概率最高的词，如"特别"。
3. 模型吐出"特别"后不会停止，而是将这个新输出的词追加到原始输入末尾，形成新的输入。
4. 用新输入继续预测下一个词（如"的"），再将"的"塞入输入，预测下一个词（如"棒"）。
5. 当模型认为内容已说完，会输出一个特殊的结束标识符，整个回答结束。

这就是为什么大模型的输出是一个词一个词逐个产生的——因为其底层运作模式就是如此。

1.3 模型与 Tokenizer 的协作

上述过程是为了方便理解而简化的链路。现实是：大模型本质是一个庞大的数学函数，内部运行的是矩阵运算，只认识数字，不认识文字。因此在人类与大模型之间必须存在中间人——Tokenizer——负责翻译工作：

• 编码：把文字变成数字。
• 解码：把数字还原成文字。

二、Token：大模型处理文本的最小单元

2.1 Tokenizer 的编码过程

以"马克的视频怎么样"为例，编码分两步走：

1. 切分（Tokenization）：把整句拆成最小片段，即 Token。该句被切分为 4 个 Token：马克、的、视频、怎么样。
2. 映射：由于模型只认数字，Tokenizer 会把每个 Token 映射为一个对应的数字，即 Token ID。Token 和 Token ID 一一对应，是同一事物的两种表达方式。

编码完成后，原来一句话就变成了一串 Token ID 组成的列表并送入模型。模型内部运算后，每次吐出一个 Token ID，Tokenizer 再次执行解码（方向与编码相反的映射），将数字还原为文字。

解码环节不需要切分，因为模型每次只会产出单个 Token。解码完成后即得到模型输出的第一个 Token；若话未说完，继续吐出第二、第三个 Token，流程循环往复。

2.2 Token 与词不是一回事

虽然"马克的视频怎么样"恰好每个 Token 各对应一个词，但 Token 和词并非一对一关系。实际案例：

• 频道名"马克的技术工作坊"如按词划分应为 4 个词，但 OpenAI 的 Tokenizer 将其切为 5 个 Token——"工作坊"被拆成"工作"和"坊"两个 Token。
• "程序员"是一个完整的词，但在 Tokenizer 中被切成两个 Token："程序"和"员"。
• 英文中常见单词如 hello、going 确实各自是 1 个 Token，但并非铁律——如 helpful 被拆为 "help" + "ful" 两个 Token。
• 某些情况下一个字符会被切分为多个 Token：如对勾（✔）需要 3 个 Token 表示，且这 3 个 Token 没有对应的显示字符（页面显示为问号）。

结论：Token 可以理解为模型自己学会的一套文本切分规则，切出的每一块是模型一次能处理的最小单位。

2.3 Token 的估算换算

换算示例：40 万个 Token 大约是 60~80 万个汉字，或 30 万个英文单词。

三、Context 与 Context Window：大模型的临时记忆

3.1 大模型"记住"的真相

大模型本质上只是个数学函数，并无真实记忆。它能"记住"聊天前文的答案是源于一个机制：每次给大模型发送消息时，后台程序会自动将之前整段对话历史找出来，连同当前问题一起发给模型。这样模型每次看到的都是完整对话内容，因此能了解之前发生过什么。

3.2 Context 的定义与构成

Context（上下文） 代表大模型每次处理任务时所接收到的信息总和，包含：

• 用户问题
• 对话历史
• 大模型正在输出的每个 Token（实时追加进来）
• 系统提示词（System Prompt）
• 工具列表

从某种程度上，Context 相当于大模型的临时记忆体。

3.3 Context Window：容量天花板

Context Window（上下文窗口） 代表 Context 所能容纳的最大 Token 数量。例如，Context Window 为 1 万，即模型最多能处理 1 万个 Token。1 万属于很小的量级，目前主流大模型的 Context Window 普遍很大：

• GPT-5.4：105 万 Token
• Gemini 3.1 Pro：100 万 Token
• Claude Opus 4.6：100 万 Token

以约 1 token ≈ 1.5 个汉字换算，100 万 Token 大约相当于 150 万汉字，能装下整部《哈利波特》全集的内容量级。

3.4 长文档场景的困境与 RAG

假如你有一份上千页的公司产品手册，希望大模型据此回答各种用户疑问，将手册全部内容连同问题一起扔给模型并非好的方案——即使 Context Window 不被撑爆，成本也无法控制。

此时需要 RAG（检索增强生成） 技术：从产品手册中抽取与用户问题最匹配的几个片段，只将这些片段发给大模型，让其据此回答问题。这样模型接收的不是整本书，可能只是几段话，既不受 Context Window 限制，成本也大幅降低。

四、Prompt：对大模型的指令与约束

4.1 Prompt 的基本概念

Prompt（提示词） 就是大模型接收的具体问题或指令。例如向大模型提出需求"帮我写一首诗"，这句话就是 Prompt。Prompt 并不复杂——不过是给大模型的一个问题或指令，模型接到这个输入后才会启动运转并生成对应答案。

4.2 提示词工程

Prompt 的写法直接决定输出质量。若只简单说"帮我写一首诗"，大模型可能写古诗，也可能写现代诗，甚至打油诗——因为 Prompt 太模糊。一个好的 Prompt 应当清晰、具体、明确：

"请帮我写一首五言绝句，主题是秋天的落叶，风格要悲凉一点。"

这种写法能让大模型输出更符合预期。这催生了 Prompt Engineering（提示词工程），研究如何把话说清楚，让大模型准确理解意图。

不过这一领域目前已鲜有人提起，原因有二：

1. 门槛太低：本质就是把话说清楚。
2. 模型能力增强：即使提示词含糊不清，大模型也能大致猜出意图，无需在提示词上过度雕琢。

4.3 System Prompt 与 User Prompt

现实中存在两种不同的 Prompt：

以数学辅导机器人为例：

• System Prompt（后台设置）："你是一个耐心的数学老师，当学生问你数学问题的时候，不要直接给出答案，而是要一步一步引导学生思考，帮助他们理解解题思路。"——这段用户看不到，但持续影响模型行为。
• User Prompt（用户在对话框中输入）："3 加 5 等于几？"

大模型看到两者后，会按系统身份约束做出引导式回答而非常直接说"8"。没有 System Prompt 时可能直接给出答案，有了它则输出完全不同的引导式回应。

五、Tool：大模型感知外部世界的桥梁

5.1 大模型的局限

假设用户问"今天上海的天气怎么样"，大模型会回答："抱歉，我无法获取实时天气信息。我的知识库截止到某年某月，无法提供当前天气数据。"

原因在于大模型只是个文字接龙游戏，它的能力只限于根据训练数据预测下一个词，确实无法去查天气预报网站获取实时数据。这就是大模型的一个弱点：无法感知外界环境。

5.2 Tool 的机制

Tool（工具） 翻译成中文是"工具"，但理解为"函数"更准确：给它输入，它给出输出。

以天气查询工具为例：

• 输入：包含城市和日期两个参数。
• 内部操作：可能调用气象局接口。
• 输出：对应天气信息。

有了工具，大模型就能回答天气等需要实时信息的问题。

5.3 完整调用流程与角色分工

从用户提问到大模型回答，涉及四个角色：用户、大模型、天气查询工具、平台。

平台本质是一段负责"上传下达"的代码——因为用户、大模型、工具三者无法直接对话，需要平台做信息传递。

完整流程：

1. 用户问题首先发给平台。
2. 平台将用户问题连同可用工具列表（如天气查询工具、计算器工具等）一起转发给大模型。
3. 大模型分析：用户想知道天气，自己没有实时数据，但看到有可用的天气查询工具，于是决定调用它。
4. 注意：大模型无法自己调用工具，它唯一的能力就是输出文本。如果要调用工具，只能借助平台的执行力量，因此大模型生成一个工具调用指令（标识要用的工具名称和对应参数）发给平台。
5. 平台接收指令后，实际执行工具调用——即调用工具背后对应的那个函数。
6. 平台拿到天气信息，将结果返回给大模型。
7. 大模型整理结果成一句通顺的话（如"今天上海的天气不错，晴天，温度 15~25 度"）输出给平台。
8. 平台转发给用户。

各角色的职责：

• 大模型（双重职责）：
• 选择工具并生成对应参数；
• 拿到工具结果后进行归纳总结。
• 工具：完成实际的查询/操作动作（如查天气）。
• 平台：串联整个流程——告诉模型哪些工具可用、依据模型指令实际调用工具等。

常见误区：初学者常以为调用工具的是大模型，但模型仅能输出文本表示"想调用哪个工具"，真正执行工具调用依靠平台。

总结：Tool 的本质是从外部为大模型提供一套可调用的能力，使模型能感知外部环境并施加影响。

六、MCP：统一工具接入协议

6.1 存在的痛点

工具使用流程中隐藏着一个工程大问题：平台必须知道工具列表及每个工具的用途、参数和调用方法，因此必须先将工具接入平台。各平台的接入规范各不相同：

• 使用 ChatGPT：必须按照 OpenAI 的规范写一套接入代码。
• 使用 Claude：必须按照 Anthropic 的规范再写一套。
• 使用 Gemini：必须按照 Google 的规范再写一套。

同一工具要为每个平台各编写一遍接入代码，效率极低。

6.2 MCP 的解决方案

MCP（Model Context Protocol，模型上下文协议） 就是统一的工具接入标准。有了 MCP：

• 工具开发者只需按照 MCP 规范开发一次，便能被所有支持 MCP 的平台使用。
• 类比：就像所有手机都统一用 Type-C 接口，有了统一标准大家都方便。

MCP 的名字（"模型上下文协议"）有些学术化、不易理解，但其核心作用是一套统一的工具接入标准。

七、Agent：能自主规划与决策的智能体

7.1 从单次调用到多步推理

有了工具和统一接入后，让大模型解决一个更有难度的问题：

今天我这边的天气怎么样？如果下雨的话，帮我查一下附近有没有卖雨伞的店。

假设可用工具：

• 定位工具：查询用户所在地区的经纬度；
• 天气工具：根据经纬度查询天气；
• 店铺工具：通过经纬度查询附近店铺。

从大模型视角看，完整过程如下：

1. 思考："用户问天气，需要知道当前位置。正好有定位工具，申请调用。"
2. 发出工具调用指令给平台——平台调用定位工具，返回经纬度（如经度 -74、纬度 40）。
3. 再次思考："拿到位置了，下一步查询天气。有天气工具，调用它。"
4. 再次发出指令，传参为经纬度——平台调用后返回天气结果。
5. 模型发现"下雨了"，根据用户要求继续执行："需要帮用户找雨伞店，这里有店铺工具，调用。"
6. 再向平台发出店铺工具调用指令，搜索雨伞——平台返回："附近 100 米有全家便利店卖伞。"
7. 大模型综合所有信息，认为目标已达成，给出最终答案后结束。

7.2 Agent 的定义与特征

上述过程已不再是简单的单次工具调用，而是大模型逐步思考当前情况并决定下一步动作的多步流程。从某种程度上说，大模型在此过程中已经具备一定的自主规划能力。

Agent 即为这种能够自主规划、自主调用工具、直至完成用户任务的系统。

主流 Agent 产品包括：Claude Code、Codex、Ja（Jarvis）等，它们的构建模式也多种多样，经典模式有 React、Plan and Execute 等。

八、Agent Skill：给 Agent 的说明书

8.1 高频使用中的痛点

假设用户希望大模型成为"出门小助手"，每次出门前帮自己检查天气并提醒携带物品。用户有自己的私人规则：

• 下雨带伞；
• 光照强戴帽子；
• 空气差戴口罩；
• 风大穿防风外套；
• 无论如何手机必带；
• 输出要按固定格式：先一句总结，再列出带原因的物品清单。

仅靠 Agent，它能查天气但不知道这些私人规则和格式要求，大概率会给出一堆废话，最终输出也无法满足格式要求。每次提问时用户若都要把所有规则、格式要求、示例写进 Prompt 复制粘贴，体验极差。

8.2 Agent Skill 的本质与结构

Agent Skill 本质上是给 Agent 看的一份说明文档。可以针对出门场景写出对应的 Agent Skill，其本身是一个 Markdown 文档，完整结构包含两部分：

第一部分：元数据层（Metadata）——相当于说明文档的封面，告诉 Agent 这个技能叫什么、负责做什么。至少包含两个属性：

• name：技能名称。如 "go_out_checklist"（出门清单）。
• description：技能描述。

第二部分：指令层——从"目标"开始到文档结束的大段内容，不限制具体格式，只要把事情向 Agent 说明白即可。在出门清单的例子中，可以包含：

• 目标：需要完成的核心任务。
• 执行步骤：先调用定位工具获取经纬度，再调用天气工具获取天气信息；然后依据天气数据，按下方判断规则整理需要携带的物品。
• 判断规则：如"下雨带伞，光照强戴帽子，空气差戴口罩……"。
• 输出格式：严格按照规定格式输出，共需要输出两段内容。
• 示例：假定用户问题为"我马上要出门，帮我看看今天要带什么东西"，工具的返回结果也做假设，Agent 必须输出符合规定格式的结果。

8.3 存放规范

定义好后需要存到硬盘中的指定位置（以 Claude Code 为例）：找到用户目录下的 .claude/skills 文件夹。存放操作有两条必须遵守的规定：

1. 在此目录下新建一个文件夹，文件夹名必须与 Agent Skill 的名称相同（例如 Skill 名是 go_out_checklist，文件夹名也必须是该名称）。
2. 进入文件夹后新建文件，将全部内容粘贴进去，文件名必须为 `SKILL.md`，其中 Skill 为大写。这是 Agent Skill 的硬性规范。如果随意改成其他文件名，系统不会识别。

8.4 工作机制

Agent Skill 存入后即创建完成。启动 Claude Code 时，系统会发现新增的 Skill，读取 SKILL.md 中的元数据（名称和描述）。指令层暂不读取——因为内容可能较大。Claude Code 只会在用户问题与 Agent Skill 的名称和描述相关时，才读取对应的指令层内容。

以演示为例，若 Skill 中要求使用定位和天气两个工具，可以提前将其做成 MCP 工具导入 Claude Code。用户输入"我要出门了，告诉我要带什么"，Agent 会：

1. 判断该问题与 go_out_checklist 这个 Skill 相关，于是读取完整指令层。
2. 按指令要求先请求调用定位工具、再调用天气工具。
3. 拿到需要的信息后，把答案整理成 Skill 要求的格式输出给用户。

此外，Agent Skill 还有高级功能，例如运行代码、引用资源等。其渐进式披露机制是一大特色，能节省大量 Token。

总结回顾：AI 概念全景回顾

将以上概念连成完整体系：

• LLM（大模型）：所有 AI 技术的核心。
• Token：大模型处理数据的最基本单元。
• Context（上下文）：大模型每次处理任务时接收到的信息总和，相当于临时记忆体，内含历史记录、系统规则、当前输入——这些数据的基本单位是 Token。
• Context Window：Context 最多能存储的 Token 量。
• Prompt：用户或系统当前给大模型的具体指令或问题，分 User Prompt（用户输入）和 System Prompt（开发者配置的人设/规则）两类。
• Tool：大模型感知和影响外部环境的函数。
• MCP：统一工具接入格式的标准协议，使开发者只需按一个标准开发，无需为每个厂商重复适配。
• Agent：能自主规划、自主调用工具、持续运作直至解决用户问题的系统。
• Agent Skill：给 Agent 看的说明文档，用来规定做事步骤和规则。

理解了这些概念，就能看懂 AI 圈的各种新产品与新技术——Claude Code、Codex、Cowork、OpenClaw 等本质上都在这个基础框架下运作。

方法与步骤

演示：将"出门提醒"需求做成 Agent Skill

1. 规划内容：确定要写入的私人规则与输出格式要求。
2. 编写 Markdown 文档：在文档顶部的元数据层写明 name 和 description。
3. 填充指令层：通过目标、执行步骤、判断规则、输出格式与示例等内容，向 Agent 交代清楚具体任务要求。
4. 存放文件：将编好的 Skill 放至用户目录下的 .claude/skills 文件夹中。
5. 创建文件夹（名称必须与 Skill 名称一致），并在其中新建 SKILL.md 文件（注意 Skill 大写），粘贴全部内容后保存。
6. 创建完成：启动 Agent，系统在启动期间检测到新增 Skill 并读取元数据，而指令层将延迟到用户问题与 Skill 相关时才被加载。
7. 执行任务：Agent 根据 Skill 指令做多步工具调用，最终按预设格式输出结果。

限制与注意事项

1. 大模型的文字接龙局限：大模型只是概率预测机器，本身无真实记忆，是依赖历史会话被整体重新附加到输入中来实现"记住"的假象。
2. Token 计数并非按词划分：Token 与词不存在明确的一对一关系；同一个词可能被切成多个 Token。某些特殊字符可能完全以 Token ID 形式存在，且 Tokenizer 页面可能无法显示对应字符。
3. 大模型不能直接调用工具：模型只擅长输出文本，实际工具执行调用动作的是平台侧的代码。
4. 不同的平台工具接入标准不统一：在没有 MCP 的情况下，同一工具需要针对不同大模型平台各自写一套接入代码。
5. RAG 是长文档任务的优选替代方案：将完整大文档直接发给模型既可能超出 Context Window 上限，也带来高昂成本。检索片段后发送可同时规避两个问题。
6. Agent Skill 文件命名有硬性要求：文件名必须用大写 SKILL.md；且用户问题无关时，不会加载 Skill 的指令层内容（渐进式披露机制），以节省 Token。
7. Agent 的实际输出效果与工具返回质量相关：演示中定位和天气工具的返回结果是预先编写的（非真实调用），主要用于演示整个运作流程。
8. 原文中出现的具体模型参数（如 GPT-5.4、Gemini 3.1 Pro 等）以原始语音稿为准，文字转录可能存在拼写误差，相关数据仅供参考，建议查阅官方最新发布文档确认。