一文讲透 AI 九大核心概念

AI 圈每天都在冒新词。但你真的能准确说出每一个概念的确切含义吗？本文从最底层的工程视角出发，逐层拆解，帮你建立完整的 AI 技术认知体系。

LLM —— 一切的基础

LLM，全称 Large Language Model，中文译作大语言模型，简称大模型。

当前几乎所有主流大模型，底层都基于同一套架构——Transformer。这个架构最早由 Google 团队在 2017 年提出，对应的论文标题叫做《Attention Is All You Need》（注意力机制就是全部所需）。

虽然 Google 发明了这把火，但真正点燃全世界的是 OpenAI。

• 2022 年底，ChatGPT（GPT-3.5）横空出世，成为第一个真正达到"可用级别"的大模型；
• 2023 年 3 月，GPT-4 发布，把 AI 的能力天花板拉到了新高度。

GPT 系列是这轮 AI 浪潮的绝对引路人。时至今日，GPT 系列依然非常强大，如 GPT-4.5 仍是行业标杆之一。但如今 AI 赛道早已不是 OpenAI 一家独大，Claude、Gemini 等后起之秀都在各自擅长的领域与之同台竞技。

大模型是如何工作的？

大模型本质上是一个文字接龙游戏。

举个例子，你向大模型提问：「马克的视频怎么样」

1. 模型接收这句话，经过内部运算，预测下一个概率最高的词：「特」
2. 模型把「特」追加到输入后面，再预测下一个词：「别」
3. 如此循环，直到预测出特殊的结束标记

最终输出：「特别棒」

这就是大模型最底层的生成原理——一个词一个词地输出答案，因为它就是这么运作的。

Token —— 大模型的"最小单位"

大模型本质上是一个庞大的数学系统，接收的是数字，输出的也是数字，根本不认识人类书写的文字。

因此，在人类和大模型之间必须有一个中间人来做翻译，这个中间人就叫做 Tokenizer。它负责两件事：

• 编码（Encode）：把文字变成数字
• 解码（Decode）：把数字还原成文字

Token 化的过程

编码分两步：

第一步：切分 把输入文本拆成若干最小片段，这些片段就叫做 Token。

第二步：映射 把每个 Token 映射到对应的数字，这个数字叫做 Token ID。

Token 是文字表示，Token ID 是数字表示，两者是同一个概念的两种形式。

Token ≠ 词

很多人以为一个 Token 就是一个词，其实不一定。

Token 是模型自己学会的一套文本切分规则，切出来的每一块就是它能够处理的最小单位。

平均来讲：

• 1 个 Token ≈ 0.75 个英文单词
• 1 个 Token ≈ 1.5 到 2 个汉字
• 40 万个 Token ≈ 60 至 80 万汉字 ≈ 30 万英文单词

Context —— 大模型的"临时记忆"

你可能有过这样的体验：跟大模型聊天时，它好像能记住你之前说过的话。比如你告诉它「我叫马克」，后来再问「我叫什么」，它还是能回答出来。

但大模型本质上只是一个数学函数——给它输入，它给你输出，它并不像人一样真的有记忆。

它是怎么"记住"的呢？

答案是：每次给大模型发消息，背后的程序会自动把你之前的整段对话历史一起发过去。

这样，模型每次看到的都是完整的对话内容，自然就知道之前发生了什么。

这就引出了 Context（上下文） 的概念：

Context 是大模型每次处理任务时所接收到的信息总合。

它包含：

• 用户的当前问题
• 历史对话记录
• System Prompt（系统提示词）
• 工具列表
• 模型正在输出的内容（也会被追加进来）
• 等等……

你可以把 Context 理解为大模型的临时工作台，它的基本计量单位就是 Token。

Context Window

Context 能装多大？这就引出了 Context Window（上下文窗口） 的概念：

Context Window 代表 Context 能够容纳的最大 Token 数量。

目前主流大模型的 Context Window：

100 万 Token ≈ 150 万汉字，整个《哈利·波特》全集都能装下。

RAG —— 突破上下文长度限制

假设你有一份上千页的公司产品手册，希望大模型根据这份手册回答用户的各种问题。

把整本手册塞进 Context？不现实。即使 Context Window 够大，成本也无法控制。

这就需要 RAG（Retrieval-Augmented Generation，检索增强生成） 技术。

RAG 的核心思路：

不把整本书都发给模型，而是先从文档中检索出与用户问题最相关的几个片段，只把这几个片段发给大模型，让模型根据这些片段来回答问题。

这样：

• 大模型接收的不是一整本书，可能只是几段话
• 不受 Context Window 大小限制
• 成本大幅降低

Prompt —— 你说话的方式决定输出的质量

Prompt（提示词） 就是你给大模型的具体问题或指令。

比如「帮我写一首诗」——这就是一个 Prompt。不要把它想成什么高端的东西，本质就是你发给大模型的话。

Prompt 的质量至关重要

Prompt 怎么写，直接决定了大模型的输出质量。

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

不过这个领域如今已经不那么热门了：一方面门槛太低（本质就是把话说清楚），另一方面大模型能力越来越强，即使提示词说得不够清晰，模型往往也能猜出你的意图。

User Prompt vs System Prompt

Prompt 分两种：

User Prompt（用户提示词）：用户自己在对话框里输入的内容，说明当前具体任务。

System Prompt（系统提示词）：开发者在后台预先配置的内容，用来设定大模型的角色和行事规则。用户看不到，但它会一直影响大模型的行为。

以一个数学辅导机器人为例：

1System Prompt（后台配置）：
2你是一个耐心的数学老师。当学生问你数学问题的时候，
3不要直接给出答案，而是要一步一步引导学生思考，
4帮助他们理解解题思路。
5
6User Prompt（学生输入）：
73 加 5 等于几？

有了 System Prompt 的约束，模型不会直接说"8"，而是会说：「我们可以这样想：你手里有 3 个苹果，然后又拿了 5 个，现在一共有多少个？你可以数一数……」

Tool —— 让大模型感知和影响外部世界

大模型有一个根本弱点：它无法感知外界环境。

比如你问大模型「今天上海天气怎么样」，它会说：「抱歉，无法获取实时天气信息，我的知识截止到某年某月……」

为什么？因为大模型本质上是个文字接龙游戏，它的能力是根据训练数据预测下一个词，它真的没有办法去查天气预报网站。

这该怎么办？这就需要 Tool（工具） 了。

Tool 本质上就是一个函数：你给它输入，它给你输出。

比如一个天气查询工具：

• 输入：城市 + 日期
• 内部操作：调用气象局接口
• 输出：对应的天气信息

工具调用的完整流程

整个流程涉及四个角色：用户、大模型、工具、平台。

平台：负责串联整个流程的中间层（可以理解为传话筒）

关键点：大模型本身无法调用工具。它唯一的能力是输出文本。 它通过输出一段包含工具名称和参数的指令文本，委托平台去真正执行工具调用。

平台在这里负责：

• 告诉模型哪些工具可用
• 根据模型的工具调用指令执行调用
• 把工具结果反馈给模型

MCP —— 工具接入的统一标准

工具很好用，但有一个工程上的大问题：

每个 AI 平台的工具接入规范都不一样。

• 用 ChatGPT？按 OpenAI 的规范写一套接入代码
• 用 Claude？按 Anthropic 的规范再写一套
• 用 Gemini？按 Google 的规范再写一套

同一个工具，你要写三遍。随着 AI 平台越来越多，这个问题会越来越严重。

于是 AI 圈里有人想：能不能搞一个统一的标准，让所有平台都遵循？

这就是 MCP（Model Context Protocol，模型上下文协议） 的由来。

MCP 是统一的工具接入标准协议。

有了 MCP，工具开发者只需要按照 MCP 规范开发一次，就可以被所有支持 MCP 的平台使用。

这就像智能手机统一使用 Type-C 接口一样——有了统一标准，大家都方便了。

Agent —— 能自主规划的智能程序

有了工具，大模型就能感知和影响外部世界了。但如果任务需要多步骤、多工具的组合调用呢？

来看一个更复杂的例子：

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

可用工具：定位工具（查经纬度）、天气工具（根据经纬度查天气）、门店工具（根据经纬度查附近门店）

从大模型的视角，整个过程如下：

这不再是简单的单次工具调用，而是一步一步思考、持续调用工具，直到完成任务。

我们把这种能够自主规划、自主调用工具、持续运作直至解决用户问题的系统，称为 Agent（智能体）。

目前市面上流行的 Agent 产品包括：Claude Code、Codex、Gemini CLI 等。它们使用的 Agent 构建模式，经典的有 ReAct、Plan-and-Execute 等。

Agent 的核心能力

• 自主规划：根据目标拆解步骤，决定下一步做什么
• 工具调用：选择合适工具并生成参数
• 状态感知：根据每步结果调整后续计划
• 持续执行：循环运转直到目标完成

Agent Skill —— 给 Agent 的说明书

Agent 能自主规划和调用工具了，听起来已经很厉害了。但在实际高频使用中，你很快会遇到一个新的痛点。

举个例子： 假设你希望大模型成为你的出门小助手，每次出门前帮你查天气并提醒你带东西。

你有一套自己的出门习惯：

• 下雨带伞
• 光照强带帽子
• 空气差带口罩
• 风大穿防风外套
• 无论如何，手机必带

你还希望输出格式很具体：先来一句天气总结，再列出需要带的物品（带原因）。

问题来了： 如果每次提问只说「我要出门了，该带什么」，Agent 虽然会查天气，但它不知道你的这些个人规则和格式要求。你每次都需要把规则和格式要求全部粘贴进 Prompt。

想象一下，每天出门都要把这么一大段要求复制粘贴一遍，是不是很烦？

这时就该 Agent Skill 登场了。

什么是 Agent Skill？

Agent Skill 本质上是一份提前写好的说明文档，用来规定 Agent 的工作流程和行事规则。

它是一个 Markdown 文档，结构分为两层：

元数据层：相当于文档封面，至少包含 name（技能名称）和 description（技能描述），用于 Agent 在启动时快速识别有哪些技能可用。

指令层：正文部分，格式不做硬性要求，只要能把事情说清楚就行。通常包含：

• 要完成的目标
• 执行步骤（哪些工具按什么顺序调用）
• 判断规则（根据结果如何决策）
• 输出格式（最终如何呈现给用户）
• 示例（给 Agent 一个参考）

Agent Skill 的工作原理

Agent（如 Claude Code）在启动时会扫描指定目录下的所有 Skill 文件，读取每个 Skill 的元数据层（名称和描述）。

当用户的问题与某个 Skill 的名称/描述相关时，Agent 才会完整读取该 Skill 的指令层，然后按照指令层的要求去执行。

这种"按需加载"的机制非常重要——指令层可能很长，如果每次都完整加载所有 Skill，会消耗大量 Token，成本高昂。

Agent Skill 的存储规范

以 Claude Code 为例：

1~/.claude/
2  skills/
3    go-checklist/      ← 文件夹名 = Skill 名称
4      SKILL.md         ← 固定文件名（大写）
5    另一个skill/
6      SKILL.md

两个硬性规则：

1. 文件夹名称必须与 Skill 的 name 字段一致
2. 文件名必须叫 SKILL.md（大写，不可更改）

概念全景图

让我们用一张图把所有概念串起来：

概念速查表

尾声

理解了这九个概念，你就能看懂 AI 圈里的各种新产品、新技术了。

无论是 Claude Code、Codex、Gemini CLI，还是各种 AI 应用，它们本质上都在这个框架下运作：

LLM 是核心引擎 → Token 是基本燃料 → Context 是工作台 → Prompt 是指令 → Tool 是外部手臂 → MCP 是接口标准 → Agent 是自主驾驶员 → Agent Skill 是驾驶手册

下次再看到这些名词，你不会再陌生了。