Token（词元）是什么

原创于 2026-08-14 16:53:16 发布 · 289 阅读

5 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

收录于

AI Agent

Token（词元）是什么？

Token（词元）是大语言模型处理文本时使用的最小文本单位之一。

你可以简单理解成：

Token ≈ AI 眼中的“文字积木”

我们平时看到的是：

我喜欢学习Java开发

但是 LLM 并不是直接按照“一个字”或者“一个单词”来处理，而是先把文本切分成 Token。

1. Token 是怎么切分的？

例如：

我喜欢Java

可能被切分成类似：

我
喜欢
Java

也可能是：

我
喜欢
Ja
va

具体怎么切，取决于模型使用的 Tokenizer。

所以：

Token ≠ 字符 ≠ 汉字 ≠ 单词

2. 中文 Token

中文通常比较容易理解。

例如：

人工智能

可能切成：

人
工
智
能

4 个 Token。

但具体模型可能存在不同的切分方式，所以不能简单认为：

一个汉字 = 一个 Token

只能作为粗略估算。

3. 英文 Token

英文通常不是严格按照单词切。

例如：

Artificial Intelligence

可能被拆成类似：

Artificial
Intelligence

也可能进一步拆成子词。

比如：

unbelievable

可能类似：

un
believ
able

因此：

1 个英文单词
≠
1 Token

4. Token 为什么这么重要？

因为 LLM 的输入和输出，核心都是按照 Token 计算的。

例如：

用户 Prompt
       ↓
Tokenizer
       ↓
Token
       ↓
LLM
       ↓
Token
       ↓
Tokenizer
       ↓
最终文本

所以 Token 直接影响：

① 上下文长度

例如模型支持：

128K Tokens

表示一次能够处理的上下文规模大约是 12.8 万 Token。

上下文通常包括：

System Prompt
+
User Prompt
+
历史对话
+
RAG内容
+
Tool结果
+
Agent中间上下文

全部都会占 Token。

② API 成本

很多模型 API 都按照 Token 计费。

例如：

输入 Token
+
输出 Token
=
总 Token

所以：

Prompt 很长
+
RAG 返回很多文档
+
历史聊天很多
+
Tool 返回大量数据

就会导致 Token 快速增长。

5. Token 和 AI Agent 的关系

这个对你理解 Agent 很重要。

一个 Agent 请求可能是：

System Prompt
      ↓
“你是一名 MySQL 专家……”
      ↓
User Prompt
      ↓
“帮我分析这个 SQL……”
      ↓
Memory
      ↓
过去20轮对话
      ↓
RAG
      ↓
公司数据库规范
      ↓
Tool
      ↓
MySQL 查询结果
      ↓
LLM

这些内容都会进入上下文，占用 Token。

所以 Agent 经常遇到一个问题：

上下文越来越长 → Token 越来越多 → 成本增加 → 甚至超过模型上下文限制。

6. 举一个完整例子

用户：

帮我分析一下这个 SQL 为什么慢：
SELECT * FROM person_info WHERE person_id = '10001';

假设 Tokenizer 切分后：

System Prompt       500 Token
+
User Prompt         50 Token
+
Memory              1000 Token
+
RAG                 3000 Token
+
Tool Result         2000 Token
+
LLM Output          500 Token
--------------------------------
总计                7050 Token

这就是一次 Agent 调用可能消耗的 Token。

7. Token、字符、字节的区别

这三个概念非常容易混。

字符 Character
      ↓
计算机看到的文字字符

字节 Byte
      ↓
计算机存储数据的基本单位

Token
      ↓
LLM 处理文本的单位

例如：

Java开发

它有：

4个字符

但：

Token 数量

需要通过具体模型的 Tokenizer 才能确定。

所以不能简单计算：

字符数 = Token数

8. Token 是怎么进入模型的？

完整过程：

          原始文本
              │
              ▼
        ┌────────────┐
        │ Tokenizer  │
        └─────┬──────┘
              │
              ▼
       Token ID 数字序列
              │
              ▼
        Embedding
              │
              ▼
         Transformer
              │
              ▼
        预测下一个Token
              │
              ▼
       Token ID 数字序列
              │
              ▼
        ┌────────────┐
        │ Tokenizer  │
        └─────┬──────┘
              │
              ▼
           文本结果

注意：

LLM 最终是在预测“下一个 Token”。

例如：

今天的天气很

模型可能预测：

好

然后继续：

今天的天气很好

再预测下一个 Token。

不断循环，最终生成完整回答。

9. 为什么 Token 越少越好？

不是绝对的。

目标应该是：

在保证模型理解能力的前提下，减少无意义 Token。

例如 Agent Prompt：

❌ 不推荐：

重复几十遍：
你必须遵守规则……
你一定要……
你必须……

更好的方式：

# 角色
你是 MySQL 专家。

# 任务
分析 SQL 性能。

# 规则
1. 优先检查索引。
2. 必要时调用 EXPLAIN。
3. 不修改生产数据。

更加简洁，也更容易维护。

10. Token 在 RAG 中尤其重要

RAG 很容易出现：

用户问题
 ↓
向量检索
 ↓
找到 20 个文档
 ↓
全部塞给 LLM

可能导致：

RAG文档 = 50,000 Token

这样非常浪费。

所以一般会：

用户问题
 ↓
Vector Search
 ↓
Top K
 ↓
Rerank
 ↓
Top 3～5
 ↓
截取相关内容
 ↓
LLM

这样可以明显减少 Token。

11. Agent 中 Token 的主要消耗来源

一般重点关注：

Token消耗
   │
   ├── System Prompt
   │
   ├── 历史对话 Memory
   │
   ├── RAG上下文
   │
   ├── Tool返回结果
   │
   ├── Agent中间推理/状态
   │
   └── LLM最终输出

尤其是：

RAG + Memory + Tool Result

很容易把上下文搞得非常大。

最后记住这几个关系

Prompt
  ↓
由 Tokenizer 切成 Token
  ↓
Token ID
  ↓
Embedding
  ↓
LLM
  ↓
预测下一个 Token
  ↓
不断生成
  ↓
最终文本

以及：

Token 是 LLM 处理文本的基本单位；Token 数量决定了上下文能装多少内容，也直接影响模型调用成本和 Agent 的性能。

对于你现在学习 AI Agent，下一步建议重点理解 Context Window（上下文窗口）、Embedding（向量） 和 Token 三者的关系：

上下文窗口 (Context Window)：这是模型一次性能处理的 Token 总数上限（如 128K）。它像一个“工作台”，决定了你的 System Prompt、用户输入、历史对话、RAG 文档、工具结果等所有内容能否一次性放进去。Token 是衡量这个“工作台”容量的尺子。
Embedding (向量)：这是 Token 进入模型前的“身份证”。Tokenizer 将文本切成 Token 后，每个 Token 会被转换成一个高维数字向量（Embedding），模型正是基于这些向量进行理解和计算。Token 是 Embedding 处理的基本单元。
Token：如本文所述，它是信息的基本载体和计费单位。

三者的核心关系链是：
文本 → 被 Tokenizer 切分成 Token → Token 被转换为 Embedding 向量 → 向量序列输入模型，并受 上下文窗口 的 Token 数量限制 → 模型输出 Token 序列 → 最终还原为文本。

实践建议：