2.1　模型在做什么：从 token 预测到指令跟随

一句话结论：模型做的全部事情，是「给定前文，预测接下来的内容」。它能干活的唯一原因是：指令跟随被训练进了这个预测过程里。理解这一点，你就知道它的能力边界在哪，也知道为什么按 Token 计费。

读这篇之前

需要先读 1.3（模型只能看见上下文）。这一篇是第 2 章的地基，也是全系列最基础的一篇——Token 不懂，后面全是玄学。

一、先从最小度量单位说起

如果你问我学 AI 最先该搞懂什么，答案只有一个：Token。

这是整个大模型世界的最小度量单位，就像物理学里的原子、编程里的字节。你不理解 Token，就无法理解模型的定价、上下文窗口、速度限制，甚至连写提示词的优化方向都是错的。[原文 704]

Token 是大语言模型处理文本的基本单位。 但它不等于"一个字"，也不等于"一个词"——它介于两者之间，由分词器（Tokenizer）按 BPE（Byte Pair Encoding） 算法自动切分。切分规则取决于模型的词表，不同模型的词表不同，粒度也不同。[原文 704]

同一句「我爱学习人工智能」，不同模型可能切成 6 个 Token，也可能切成 4 个。这就是为什么同样长的文本在不同模型上费用不同——计费按 Token 数，不按字符数。

中英文为什么差这么多

一个让很多开发者困惑的现象：同样 1000 字，中文比英文贵不少。

原因在词表。主流模型的词表以英文为核心构建，所以：

一个英文单词通常对应 1~1.3 个 Token
一个中文字符大约对应 1.5~2 个 Token

这意味着中文内容的 Token 密度更高，成本也更高。[原文 704]

原文给出的对照数据（用来说明量级，不必记具体数字）：

文本内容	字符数	Token 数	每字符 Token 比
Hello World	11	2	0.18
The quick brown fox jumps	25	5	0.20
你好世界	4	4-6	1.0-1.5
我爱学习人工智能	8	8-12	1.0-1.5
人工智能是未来（含标点）	9	10-14	1.1-1.6

这张表有两个实用推论：

同样的内容，中文的成本约是英文的 5 倍（按字符比算）。做多语言产品时这是真实的成本差异。
当你做上下文压缩（第 5 章）时，压缩中文带来的收益比压缩英文更明显。

注意：上表的 Token 数是特定模型的实测值，不同模型会不同。不要记数字，记比例关系。

二、模型到底在算什么

现在进入核心问题：模型在做什么？

答案朴素到让人失望：它在预测下一个 Token。

给定一段前文，模型输出一个概率分布——每个候选 Token 有多大概率是接下来的那个。选一个放上去，再预测下一个，如此循环。[原文 704]

"今天天气很" → 模型 → {"好": 0.62, "热": 0.21, "冷": 0.08, ...} → 选"好"
"今天天气很好" → 模型 → {"，": 0.55, "啊": 0.12, ...}       → 选"，"

这个机制解释了很多现象：

现象	为什么
为什么模型"不知道"自己不知道	它只是在算概率，没有"我不知道"这个状态
为什么同样的输入有时答案不同	采样有随机性（2.3 详述）
为什么它会被提示词影响	前文变了，下一步的概率分布就变了
为什么它不会执行代码	它只输出 Token，执行是外面的事（1.5）

但是，它为什么能"听话"

如果模型只是预测下一个 Token，那它应该只会续写，不会执行指令。为什么你说"帮我总结这段"它就真的总结？

因为指令跟随是训练出来的。

现代模型的训练分两大阶段：[原文 4567]

预训练（Pre-training）：在互联网规模的海量文本上做下一 Token 预测。这个阶段让模型学会语言与世界知识——但此时它只会"续写"，不懂得"执行指令"。
后训练（Post-training）：用监督微调、强化学习等手段，把"按指令做事"这个行为模式固化进模型。这个阶段让模型从"文本续写器"变成"助手"。

用原文的表述：

LLM 的能力来自两部分：预训练所积累的世界知识与语言能力，以及后训练所固化的决策策略。[原文 4567]

这个区分极其重要，因为它意味着：

"聪明"来自预训练（知识量、语言能力）
"听话"来自后训练（遵循指令、按格式输出、拒绝有害请求）

所以当你发现"模型明明知道答案却不肯按我要的格式输出"时，问题通常不在知识，而在指令的表达方式——这是第 3 章的内容。

三、由此得到的三个能力边界

理解"预测下一个 Token + 指令跟随"这个本质，能直接推出三条边界：

边界一：模型没有"事实感"，只有"像不像"

模型优化的是"下一个 Token 像不像训练数据里该出现的样子"，而不是"这个陈述是否为真"。

所以在训练数据稀疏的领域，它会生成看起来非常合理但完全错误的内容——这就是幻觉（2.3 详述）。

边界二：模型没有"状态"，每次都是全新的

模型不记得上一次调用发生了什么。它没有内部状态，每次调用都是"读一遍你给的消息列表，然后输出"。

Agent 的"记忆"全在上下文里（第 5、6 章），不在模型里。

边界三：模型没有"手"，只有"嘴"

模型能输出一切能被 Token 表示的东西——包括一段 JSON、一段代码、一个工具调用请求。但它不会真的执行。

真正执行的是你的框架代码（1.5 已详述）。

四、一个实用的心智模型

把上面所有内容压成一个类比：

模型像一个读遍了人类文本、但从未出过门的人。

他能把任何话题讲得头头是道（预训练的知识）

他愿意按你说的方式回答（后训练的指令跟随）

但他没看过今天的天气，也没法替你去取快递（没有手，没有实时信息）

他有时会把记忆里的两件事混在一起，说得斩钉截铁（幻觉）

这个类比能解释 Agent 设计里几乎所有的取舍：它能"说"的部分靠模型，能"做"的部分靠工程。

五、怎么估算 Token：三个能直接用的办法

理论懂了，动手时你还是要回答「我这段提示词大概多少 Token」。三个办法，精度从粗到细：

办法	怎么用	精度	适用
粗估法	英文 ≈ 字符数 ÷ 5；中文 ≈ 字符数 × 1.2~1.5	±30%	快速判断可行性
分词器工具	用对应模型官方提供的 tokenizer 计算	精确	成本核算、卡边界
实测法	发一次请求，读返回的 usage 字段	最准	上线前验证

为什么粗估法要分中英文？ 因为一个英文单词常被切成 1 个 Token，而 4 个字母左右才凑成 1 个 Token；中文单字通常就占 1 个 Token 甚至更多（取决于是否为常见组合词）。所以英文按「字符数 ÷ 4~5」，中文按「字符数 × 1~1.5」，量级才对。[原文 704]

一个容易踩的坑：很多人以为计费只看输入。实际上输入和输出都算 Token，而且输出通常更贵。写 Agent 时要特别留意——工具返回的长结果、模型的长篇推理，都在持续计费。

六、上下文窗口：这个"有限"到底是多少

有了 Token，就可以定义模型最硬的那条约束了。

上下文窗口（context window） 表示模型一次能"看到"的最大 Token 数量，包括输入和输出。如果总 Token 数超过窗口，多出来的部分会被截断，或者需要特殊处理。[原文 704]

三个要点：

它是"输入 + 输出"的总和，不是只算输入。留 20% 余量给输出是常见做法。
它是硬限制，不是"性能下降的阈值"。超了就是超了。
它直接决定 Agent 能处理多复杂的任务——窗口太小，多轮对话和长文档处理就受限。[原文 704]

具体各家模型的窗口数值迭代极快，本文不写具体数字（必然过时）。查当前值请以官方文档为准：各厂商的模型文档页会明确列出 context window。

窗口为什么是 Agent 的真瓶颈

回到 1.3 的结论：模型只能看见上下文，而上下文要靠工具去补。那么「窗口有多大」就直接决定了「一个任务能走多远」：

每一轮的工具结果都要进上下文
轮数越多，累积的上下文越长
一旦触到上限，就必须开始丢弃或压缩——而丢弃什么，决定了 Agent 会不会「忘掉关键信息」

这就是为什么第 5 章要用一整章讲上下文工程：它不是优化技巧，而是让 Agent 能处理长任务的必要条件。

七、把这一篇的结论整理成一张图

flowchart TD
    A["文本"] --> B["分词器 Tokenizer<br/>BPE 切分"]
    B --> C["Token 序列<br/>计费与窗口的度量单位"]
    C --> D["模型：预测下一个 Token<br/>循环生成"]
    D --> E["预训练：知识与语言能力"]
    D --> F["后训练：指令跟随与决策策略"]
    E --> G["能力：懂很多"]
    F --> H["行为：听话、按格式输出"]
    G --> I["边界：没有事实感 → 幻觉"]
    H --> J["边界：没有状态 → 每次全新"]
    C --> K["上下文窗口<br/>输入+输出的 Token 上限"]
    K --> L["Agent 的真瓶颈<br/>→ 第5章 上下文工程"]

这张图把第 2.1 篇的全部内容串起来了：Token 是度量单位 → 模型预测 Token → 预训练给能力、后训练给行为 → 于是有了能力与边界 → 而窗口是这一切的硬约束。

八、动手：算清你的 Token 成本

理论懂了，最重要的实操是算清账。

一个完整的成本模型

月成本 = 日调用量 × 单次 Token × 单价 × 30

单次 Token = 系统提示 + 工具定义 + 上下文 + 历史 + 输出

五个加数里，最容易被低估的是"工具定义"和"历史"。

组成	典型值	是否常被忽略
系统提示	500-3000	有时
工具定义	100-300 × 数量	严重被忽略
上下文（检索/文件）	2000-20000	有时
历史累积	随轮数增长	严重被忽略
输出	100-1000	较少

一个真实算例

假设：

系统提示 1500 Token
工具 10 个 × 200 = 2000 Token
每轮检索片段 3000 Token
平均 6 轮，历史累积平均 4000 Token
输出 400 Token

单次任务 ≈ 1500 + 2000 + 3000×6 + 4000 + 400×6
        ≈ 1500 + 2000 + 18000 + 4000 + 2400
        = 27,900 Token

其中 18,000 是"每轮重复的检索片段" —— 占 65%。

这说明：优化重点不是系统提示，而是别每轮都重复塞同样的材料（用引用传递，12.3）。

三个立竿见影的省钱动作

动作	省多少	代价
工具按阶段加载（4.5）	工具定义减半	切换时缓存失效
检索结果只放一次，后续引用	省掉重复	要能回读
前缀稳定（5.3）	单价降 60-90%	要重构上下文顺序

第二条最容易被忽略：很多人每轮重新检索、重新塞材料，而实际上第一轮的检索结果还在上下文里。

九、中英文混用的实际影响

2.1 讲了中文 Token 密度高。实践中还有一个细节：代码块与中文混排会显著增加 Token。

内容	特点
纯中文叙述	~1.2 Token/字
纯英文代码	~0.25 Token/字符
中文 + 代码块混排	边界处切分效率低，实际更高

实践含义：如果你的提示词里嵌了大量中文注释的代码，Token 会比预期高。

一个可取的做法：把长代码放在工具返回或资源里，而不是塞进系统提示。

十、常见误区

误区一：Token 就是字数。
不是。英文约 1 字符 ≈ 0.2 Token，中文约 1 字符 ≈ 1-1.5 Token。同一段内容，中文消耗的 Token 远多于英文。

误区二：模型变强了就不会幻觉。
模型变强主要提升的是"复杂推理"和"指令遵循"，而幻觉的根源是"没有事实核查机制"，不是"不够聪明"。

误区三：模型有记忆，只是被清空了。
不是清空，是根本没有。每次调用都是无状态的函数调用。

误区四：预训练和后训练只是技术细节。
它们的分工决定了你调优的方向：知识不够 → 补上下文或检索；不听话 → 改提示词或换模型。

误区五：换个更大的模型就能解决一切。
更大的模型在知识与推理上有优势，但如果问题出在"缺上下文"或"流程设计"，换模型没有帮助（1.3 已论证）。

十一、下一篇

Token 与上下文窗口是模型最硬的约束。既然模型只能"看见"有限的内容，那么这个"有限"到底是多少？超出之后会发生什么？

下一篇专门讲上下文窗口——它是 Agent 真正的瓶颈，也是后面第 5 章「上下文工程」存在的原因。

2.1 模型在做什么：从 token 预测到指令跟随