从 LLM 到 Agent Skill：一文搞懂 AI 圈核心概念

本文主要是理解「从 LLM 到 Agent Skill」，用最通俗的语言，把 AI 圈最核心的 8 个概念从底层到上层逐一拆解。

---

前言

AI 圈子里每天都在冒新名词：LLM、Token、Context、Prompt、Tool、MCP、Agent、Agent Skill……这些词你可能都听说过，但真的能准确说出每一个概念的确切含义吗？

今天我们从最底层的工程角度出发，一层一层往上搭，把这些概念拆开揉碎讲清楚。

---

一、LLM —— 大语言模型

LLM（Large Language Model），即大语言模型，简称大模型。

目前几乎所有大模型都基于 Transformer 架构训练，该架构由 Google 团队于 2017 年在论文《Attention is All You Need》中提出。有意思的是，虽然 Google 发明了火种，但真正点燃并引爆全世界的却是 OpenAI——2022 年底 GPT-3.5 横空出世，2023 年 3 月 GPT-4 将 AI 能力天花板拉到新高度。

如今 AI 已不再是 OpenAI 的独角戏，Claude、Gemini 等优秀后起之秀都在各自擅长的领域同台竞技。

大模型的工作原理

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

1. 用户输入一句话，如"抖音的视频怎么样"
2. 模型经过内部运算，预测下一个概率最高的词，如"特别"
3. 模型把"特别"追加到输入后面，再预测下一个词，如"得"
4. 重复此过程，直到输出特殊的结束标识符，回答结束

这就是为什么大模型要一个词一个词地输出答案——因为它就是这么运作的。

---

二、Token —— 大模型处理文本的基本单元

大模型本质上是一个庞大的数学函数，里面跑的全是矩阵运算，它接收的是数字，输出的也是数字，根本不认识人类文字。所以在人类和大模型之间，必须有一个"中间人"来做翻译——这就是 Tokenizer。

编码与解码

Tokenizer 负责两件事：

方向	名称	作用
文字 → 数字	编码	让模型能理解人类输入
数字 → 文字	解码	让人类能读懂模型输出

编码过程分两步：

1. 切分：把用户输入拆成最小的片段，这些片段就叫 Token
2. 映射：把每个 Token 对应到一个数字，即 Token ID

解码则反过来，把 Token ID 映射回文字。

Token ≠ 词

Token 和词并不是一对一的关系：

文本	切分结果	Token 数量
抖音的视频怎么样	抖音 / 的 / 视频 / 怎么样	4
抖音的技术工作坊	抖音 / 的 / 技术 / 工作 / 坊	5
程序员	程序 / 员	2
Helpful	Help / ful	2

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

• 1 Token ≈ 0.75 个英文单词
• 1 Token ≈ 1.5～2 个汉字

---

三、Context 与 Context Window

Context（上下文）

我们平时和大模型聊天，它好像能记住之前说的话。但大模型本质上只是一个数学函数，并没有真正的记忆。它是怎么做到的？

答案：每次发送消息时，背后的程序会自动把整段对话历史一起发过去。这样模型每次看到的就是完整的对话内容。

Context 就是大模型每次处理任务时所接收到的信息总和，包括：

• 用户问题
• 对话历史
• 模型正在输出的 Token
• 工具列表
• System Prompt 等

可以把 Context 看作是大模型的临时记忆体。

Context Window（上下文窗口）

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

模型	Context Window
GPT-4o	128K
Gemini Pro	1M
Claude Opus 4	200K

100 万 Token ≈ 150 万汉字，差不多能装下整部《哈利·波特》全集。

RAG 技术

如果有一个上千页的产品手册，不可能每次都把全部内容塞给大模型（成本太高，Context Window 也可能不够）。这时就需要 RAG（Retrieval-Augmented Generation，检索增强生成）——先从手册中检索出与用户问题最匹配的几个片段，只把这几个片段发给大模型，让它基于片段回答问题。

---

四、Prompt —— 提示词

Prompt 就是大模型接收的具体问题或指令，比如"帮我写一首诗"。

Prompt 怎么写，直接决定了大模型的输出质量。一个好的 Prompt 应该是清晰的、具体的、明确的。比如：

❌ 帮我写一首诗

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

这就是 Prompt Engineering（提示词工程）——研究怎么把话说清楚，让大模型更精准地理解你的意图。

User Prompt 与 System Prompt

有时候不仅要告诉大模型具体任务，还要告诉它人设和做事规则，这就引出了两种 Prompt：

类型	说明	谁设置的
User Prompt（用户提示词）	具体的任务指令	用户
System Prompt（系统提示词）	人设和做事规则	开发者（后台配置）

举个例子，做一个数学辅导机器人：

• System Prompt：“你是一个耐心的数学老师，当学生问你数学问题时，不要直接给出答案，而是要一步一步引导学生思考。”
• User Prompt：“三加五等于几？”

没有 System Prompt，大模型可能直接回答"8"；有了 System Prompt 约束，它会引导学生自己思考。

---

五、Tool —— 工具

大模型有一个致命弱点：无法感知外界环境。它只是文字接龙，没办法去查天气预报、读数据库、发邮件。

Tool（工具）本质上就是一个函数——给它输入，它给你输出。比如天气查询工具，输入城市和日期，输出天气信息。

工具调用流程

整个流程涉及四个角色：

1. 用户：提出问题
2. 平台：充当"传话筒"，负责上传下达（本质上是一段代码）
3. 大模型：分析问题，选择工具，生成调用参数，归纳总结结果
4. 工具：执行具体操作

┌──────┐      ┌──────┐      ┌──────┐
│  用户  │ ──→ │ 平台  │ ──→ │ 大模型 │
└──────┘      └──────┘      └──────┘
                                  │
                    ┌─────────────┤
                    ▼             ▼
              选择工具          生成调用指令
                    │             │
                    ▼             ▼
┌──────┐      ┌──────┐      ┌──────┐
│ 工具  │ ←── │ 平台  │ ←── │ 大模型 │
└──────┘      └──────┘      └──────┘
    │
    ▼
  返回结果 → 平台 → 大模型归纳总结 → 平台 → 用户看到答案

关键点：大模型自己不能调用工具，它只能输出一段文本告诉平台"我想调用哪个工具"，真正执行调用的是平台。

---

六、MCP —— 模型上下文协议

Tool 虽然好用，但有一个工程上的大问题：每个平台的工具接入规范都不一样。

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

同一个工具写三遍，太痛苦了。

MCP（Model Context Protocol，模型上下文协议）就是来解决这个问题的——它是一套统一的工具接入标准。有了 MCP，工具开发者只需按规范开发一次，就可以在所有支持 MCP 的平台上使用。

就像所有手机都用 Type-C 接口一样，统一标准，大家都方便。

---

七、Agent —— 智能体

有了 Tool 和 MCP，大模型已经能感知外部世界了。但如果遇到更复杂的问题呢？

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

要解决这个问题，需要多次调用工具，而且后一步依赖前一步的结果：

定位工具（获取经纬度）
        ↓
天气工具（查询天气：下雨）
        ↓
店铺工具（搜索雨伞店）

大模型需要一步步思考当前情况，并决定下一步该做什么。这种能够自主规划、自主调用工具、持续运作直至完成任务的系统，就叫做 Agent（智能体）。

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

---

八、Agent Skill —— Agent 技能

Agent 虽然强大，但在高频使用中会遇到一个新痛点：每次都要重复告诉它你的私人规则和格式要求。

比如你希望 Agent 成为出门小助手，每次出门前帮你扫一眼天气并提醒带东西，你的规则是：

• 下雨 → 带伞
• 光照强 → 带帽子
• 空气差 → 带口罩
• 风大 → 穿防风外套
• 手机必带
• 输出格式：先总结，再列物品清单（带原因）

如果每次都把这些贴到 Prompt 里，太反人类了。

Agent Skill 就是解决这个问题的——它本质上是一份提前写好、塞给 Agent 的 Markdown 说明文档，由两部分组成：

1. 元数据层（封面）

告诉 Agent 这个技能叫什么、负责做什么，至少包含：

• Name：技能名称，如 Go-out Checklist
• Description：技能描述

2. 指令层（正文）

格式不做具体要求，只要把事情说明白就行，通常包括：

• 目标：要完成什么
• 执行步骤：先做什么、后做什么
• 判断规则：什么条件下做什么决策
• 输出格式：按什么格式输出结果
• 示例：给出一个完整的输入输出示例

---

总结：概念全景图

从底层到上层，这 8 个概念构成了一个完整的体系：

┌─────────────────────────────────────────────┐
│            Agent Skill（技能文档）             │  ← 规定 Agent 的做事步骤和规则
├─────────────────────────────────────────────┤
│              Agent（智能体）                   │  ← 自主规划 + 调用工具，持续运作
├──────────────────┬──────────────────────────┤
│     Tool（工具）  │    MCP（统一接入协议）      │  ← 感知和影响外部环境
├──────────────────┴──────────────────────────┤
│     Prompt（User Prompt + System Prompt）     │  ← 给大模型下达指令
├─────────────────────────────────────────────┤
│  Context（上下文）│ Context Window（窗口大小）  │  ← 大模型的临时记忆体
├─────────────────────────────────────────────┤
│              Token（基本处理单元）              │  ← 文字与数字之间的桥梁
├─────────────────────────────────────────────┤
│              LLM（大语言模型）                  │  ← 一切的核心，文字接龙引擎
└─────────────────────────────────────────────┘

理解了这些概念，你就能看懂 AI 圈里的各种新产品和新技术了——无论是 Claude Code、Codex、Cline、Cursor 还是 OpenClaw，它们本质上都是在这个框架下运作的。

---