令牌：真正的基本单元。

语言模型既不读字符，也不读单词。它读的是令牌（token）——子词单元，英文中通常为 2 到 6 个字符，由分词器（tokenizer）选取，以平衡词汇量和序列长度。内化这一点是一切认知的基础，因为 LLM 工程中半数的 bug 和意外，都源于对"什么算一个令牌"的误解。

首先要看到的

对几个字符串运行分词器，看看会发生什么。以下是 Anthropic 的 Claude 分词器的结果（OpenAI 的 tiktoken 对英文的处理类似）：

"Hello"           → 1 token
"Hello world"     → 2 tokens  (Hello | world)
"ChatGPT"         → 1 token   (one canonical chunk)
"Anthropic"       → 1 token
"unhappiness"     → 3 tokens  (un | happiness ... or un | happi | ness)
"supercalifragilisticexpialidocious" → 8 tokens

"Czesław Miłosz"  → 7 tokens  (C | z | es | ł | a | w |  Mił | osz ...)
"日本語"          → 3 tokens  (one per character)
"🦀"             → 2 tokens  (the emoji decomposes into bytes)

"{\"name\":\"alex\"}"           → 7 tokens
"{ \"name\" : \"alex\" }"       → 10 tokens (extra spaces cost real tokens)

这个列表中有四点值得特别关注。

"ChatGPT"是一个令牌。训练语料库中频繁出现的字符串会获得专属令牌，因为这样更高效。"Anthropic"也是如此。"OpenAI"大概是一两个令牌。常见的产品名、API 名、编程关键字——都是一个令牌，因为它们出现得足够频繁，分词器训练过程将它们合并了。这也是为什么 Python 中的 def function_name(): 所用令牌数，少于对同一事物的英文描述。

波兰语、日语和 emoji 消耗的令牌多得多。"Czesław"——一个普通的波兰人名——需要六七个令牌，因为分词器主要在英文语料上训练，对波兰语变音符号并未优化。同一个名字的英文转写（"Czeslaw"）只需 2-3 个令牌。这不是 bug，而是训练分布的直接结果。实际影响：为非英语用户服务的聊天机器人，每轮对话的成本（cost）比服务英语用户高出 2-4 倍，且有效上下文窗口更小，因为每条用户消息消耗的令牌更多。

空白符和格式化也是真实的令牌。两个 JSON 示例仅在空白符上有区别，但这个区别是有意义的。制表符、换行符、多余的空格——都消耗令牌。"紧凑型"提示词格式比"可读性强"的格式实际上更省钱。在生产环境中，你为每个令牌付费，乘以每次请求，这一点尤为重要。

分词是确定性的，但并不直观。分词器是一段代码，将字符串转换为整数序列（令牌 ID）。相同输入，每次输出相同。但分词边界由算法决定，该算法在语料库上训练而来，而非基于语言学规则。你无法通过目测预测分词结果；必须实际运行分词器才能知道。

对提示词成本的影响

在生产中你会切实感受到的三个具体结果：

你的提示词成本不是字符数、单词数，也不是任何可以目测的量。它是分词器输出的计数，唯一知道它的方式就是去测量。服务商的计费面板会在事后显示真实数字；如果想提前知道，就在本地对输入运行分词器。

# Pre-flight token counting (Anthropic)
from anthropic import Anthropic
client = Anthropic()

count = client.messages.count_tokens(
    model="claude-sonnet-4-5",
    messages=[{"role": "user", "content": prompt}],
)
print(f"input tokens: {count.input_tokens}")

# Or locally with tiktoken for OpenAI
import tiktoken
enc = tiktoken.encoding_for_model("gpt-5.5")
print(f"input tokens: {len(enc.encode(prompt))}")

对故障的影响

三种可追溯到令牌的故障模式，在你检查之前，它们看起来都像别的问题：

JSON 输出中名称被截断。模型正在生成一个包含名称字段的 JSON 对象。max_tokens 设为 200。模型输出了 {"name": "Czesł 就停了，因为完成这个波兰人名加上剩余 JSON 所需的令牌超出了预算。JSON 格式损坏，下游代码崩溃。如果在设置 max_tokens 之前测量过令牌数，你会给它 250。

结构化输出中的子词溢出。你要求模型输出三个类别之一："critical"、"warning"、"info"。结果你得到了"criti"或"warning_"或"infos"。模型开始输出正确的令牌，但在子词边界处采样偏移了。严格模式和 JSON schema 约束生成可以防止这种情况；它们的存在本身就说明了令牌为何重要。

边缘情况下的行为不一致。你的提示词在 ASCII 输入的示例上运行正常，但在使用弯引号（"智能"引号）的相同示例上却失败了。原因在于：" 和 " 的分词结果不同。模型在训练中见过 ASCII 版本一百万次，而见过弯引号版本可能只有一万次。对人类看起来相同的输入，行为却出现了差异。

上下文窗口是有限且对位置敏感的资源。

你听到"200K 上下文窗口"，直觉上以为"200,000 个令牌的空闲空间"。这种直觉的两半在生产环境中都是错的。这些空间需要真实的费用，而且窗口内并非所有位置都平等——位于长上下文中间的内容，性能可测量地差于位于开头或结尾的相同内容。将上下文窗口视为均匀的平坦内存，是产生微妙质量 bug 的根源，而这些 bug 在开发环境中不会暴露。

上下文成本随使用量而非容量增长

那个显眼的数字——Claude Sonnet 4.5 的 200K 上下文窗口——是上限，不是价格档位。你为实际使用的令牌付费，而且每轮对话都要付费。一个积累了 80K 令牌历史记录的多轮智能体（agent）对话，在每次后续模型调用时都要为 80K 输入令牌付费，而不是只付一次。在 20 轮对话中，同样的积累历史要付费 160 万个输入令牌。提示词缓存（第 2.2 章）在上下文稳定时能显著降低这一成本，但基本规律是"上下文成本随对话长度复利增长"。

推论：上下文是智能体消耗的最昂贵资源。不是模型调用，不是工具调用（tool calling），而是积累的上下文令牌。优化智能体携带多少上下文向前推进（摘要、截断、如第 1.3 章所述的子智能体隔离）通常是可用的最高杠杆成本优化。

"迷失在中间"效应

更难以直觉把握的是：在上下文窗口内的位置，影响模型能够可靠使用其中内容的程度。2023-2025 年的多项研究记录了一种被称为"迷失在中间（lost in the middle）"的规律：当你将 30 个文档放入上下文并要求模型使用其中一个时，模型更有可能使用位于上下文开头或结尾的文档，而不是中间的文档。

该效应的形态：

该效应有充分的实证支撑，随模型和任务的不同而在量级上有所差异，并随新模型的推出而有所减弱（但并未消失）。2026 年的前沿（frontier）模型处理长上下文比 2023 年的模型好得多，但中间位置的性能损失仍然可测量。请在设计时考虑这一点。

如何应对

对你在提示词中排布信息的方式，有三个实际影响：

将最重要的内容放在开头和结尾。如果你的系统提示词有关键规则（"绝不透露 API 密钥"），就把它们放在最顶部或最底部——不要埋在 2000 个令牌的系统提示词中间。如果你检索的上下文有 10 个按相关性排序的片段，就把排名最高的片段放在边界处，而不是中间。

在用户实际问题附近重申关键指令。如果系统提示词写着"仅以 JSON 格式回复"，然后跟着 5 万个令牌的对话历史，模型在生成回复时可能已经忘记了 JSON 约束。解决方法：在用户消息末尾加上简短的重申（"请以 JSON 格式回复，如系统提示词所指定"）。这种冗余看起来丑陋，但值得这样做。

不要因为可以就把上下文填满。在检索增强（retrieval-augmented）生成中增加更多文档，在某个点之后往往会损害质量，不是因为模型读不了，而是因为相关文档现在被埋在中间，模型无法聚焦在它上面。大多数生产 RAG 系统最终采用 top-5 或 top-10 的片段，不是因为模型只能处理这么多，而是因为这是"迷失在中间"开始抵消边际上下文收益之前的甜点区域。

思维模型：注意力作为预算

"迷失在中间"背后的机制：上下文中每个令牌在生成下一个令牌时都必须被关注。注意力机制从根本上就是对所有输入令牌进行加权——而当有 100,000 个令牌作为输入时，每个令牌默认只分到一小片注意力。开头的令牌在处理早期就被"锚定"（某种意义上模型的表征从左到右构建）；结尾的令牌在序列中最新，获得强烈的位置权重。中间的令牌既未被锚定，也不是最新的。

理解这个数学不是必须的，使用这个直觉就够了：把注意力看作模型分配给输入令牌的有限预算，其中开头和结尾有结构性优势。你希望模型真正使用的信息，应该放在预算最充裕的地方。

长上下文与 RAG：比看起来更深刻的问题

"直接把所有内容倒进上下文，窗口够大"是检索增强生成的一个诱人替代方案。有时这是正确答案，有时不是，其权衡有三个维度：

• 成本（Cost）。每轮输入 20 万个令牌是昂贵的——按 2026 年的定价，在 Sonnet 上大约每轮 $0.60。使用 5 个检索片段的 RAG 每轮约 $0.015。差距会复利增长。
• 延迟（Latency）。即使使用了优化推理，处理 20 万个令牌也需要可观的时间——通常是 3-10 秒才输出第一个令牌。上下文较小的 RAG 在不到一秒内就能输出第一个令牌。
• 质量（Quality）。有时长上下文胜出（当正确答案需要跨多个文档综合时）。有时 RAG 胜出（当正确文档需要处于上下文的开头/结尾以规避"迷失在中间"时）。在你的评估（eval）集上测量。

实话实说：长上下文是一种工具，不是检索的替代品。当你需要对已知语料库进行跨文档推理时使用它。当语料库太大无法放入，或成本和延迟重要，或大多数查询只需要几个片段时，使用 RAG。

采样：模型是一个概率分布，而非一个函数。

思维模型中最有用的单一转变：模型不会为给定输入选择单一输出。对于每个下一个令牌，它生成整个词汇表上的概率分布，然后由独立的采样步骤从中选取一个令牌。不同的采样设置，不同的输出——相同的输入，相同的模型。内化这一点，能消解一类困惑（"为什么这次得到了不同的答案？"），并为生产智能体提供一个控制面。

模型实际输出的是什么

在每一步生成中，模型输出一个 logit 向量——每个词汇条目一个数值，通常是 100,000-200,000 个数。对它们做 softmax，就得到了下一个令牌可能是什么的概率分布：

Prompt: "The capital of France is"
Model's distribution over next token:
  " Paris"   →  0.847
  " the"     →  0.043
  " a"       →  0.022
  " located" →  0.018
  " known"   →  0.011
  " Lyon"    →  0.008
  ... 200,000 more tokens, mostly near zero ...

Sampling picks one of these. Then the process repeats for the next token,
conditioned on the new sequence.

模型的输出不是" Paris"——而是整个分布。采样是将分布缩减为单一令牌的操作。不同的采样选择，沿着概率树走出不同的路径。

用白话说温度（temperature）

温度是一个单一数值——通常在 0 到 2 之间——控制分布在最高概率令牌上的集中程度。

在温度 0：每次都取概率最高的单一令牌。分布在采样前被折叠为独热向量（one-hot vector）。有时称为"贪婪解码（greedy decoding）"。这是模型行为最接近确定性的状态。

在温度 1：按实际分布采样。模型的自然可变性。

在温度 2：平坦化分布。高概率令牌被采样的频率降低，低概率令牌被采样的频率升高。输出变得更加多样，也更缺乏连贯性。

温度 0 仍然不是确定性的

对于从传统软件转来的人，采样中最令人意外的事情是：即使在温度 0 下，相同的提示词也可能产生不同的输出。不是总是，但频率足以在生产中造成影响。

为什么？"总是取概率最高的令牌"这条确定性路径，依赖于概率向量在各次运行中完全相同。实际上，概率向量可能因以下原因在各次运行之间有所不同：

• 批处理推理中的浮点非确定性。现代推理服务器将请求批量处理以提高 GPU 效率。你的请求落入的具体批次影响矩阵乘法中加法的顺序，这（由于浮点加法不满足结合律）可能使 logit 值产生微小偏移。通常无关紧要。但偶尔足以使 top-1 从一个令牌翻转到另一个。
• 模型快照更新。服务商部署了新的小版本。API 调用中相同的模型名称，权重略有不同，分布略有不同。你"确定性"的运行出现了分歧。
• 服务端处理变化。缓存、路由、故障转移机制——即使你指定了 temperature=0，所有这些都可能引入微小扰动。

实际影响：将 temperature=0 视为"低方差"，而非"零方差"。如果你需要真正的可重现性（用于测试或评估重运行），你需要将 temperature=0 与显式种子（seed）结合使用（在服务商支持的情况下），最好还要固定模型快照——即便如此，也要预期偶发的漂移。

何时使用哪个温度

这个决策由任务驱动，而非个人偏好驱动。粗略指南：

top_p（核采样）：另一个旋钮

top_p 是约束采样的另一种方式。温度对整个分布进行变形，而 top_p 对其截断：只从累积概率超过 top_p 的最小令牌集合中采样。在 top_p = 0.9 时，你从合计占 90% 概率质量的顶部令牌中采样——在 20 万个令牌中通常只有几十个。

直觉：top_p 限制了令牌有多不可能仍能被采样。它保证你不会意外选到概率极低的令牌，同时仍允许"足够可能"的令牌之间的多样性。

大多数生产智能体将 top_p 保持在默认值（1.0，即不截断），只依赖温度。偶尔同时使用两者是有用的：温度 0.7 加 top_p 0.9 给你"多样但不狂野"。除非你有特定的故障模式需要缓解，否则很少值得调整。

种子与可重现性的局限

Anthropic 和 OpenAI 都支持 seed 参数。承诺是：相同的种子 + 相同的提示词 + 相同的模型 + 相同的参数 → 相同的输出。现实更接近于"极有可能是相同的输出，但不能保证"——服务商明确将种子记录为尽力而为（best-effort），而非合同保证。早先提到的非确定性来源（批处理、快照漂移）在边缘情况下仍然适用。

种子确实能给你的：在短时间窗口内的测试中有意义的可重现性。如果你在早上 9 点用固定种子运行评估套件（eval suite），然后在 10 点再次运行，结果几乎肯定相同。但如果一个月后再运行，在模型快照更新之后，结果可能不同。

种子的实际用途：在测试和 CI 运行中设置种子，以防单个示例上的噪声污染你的评估信号。不要在生产中设置它——生产受益于多样性，而且确定性本来也无法保证。

幻觉是可预测的故障模式，而非随机错误。

"幻觉"这个词被过度使用了。人们用它指代从轻微的事实错误，到自信捏造的引用，再到彻头彻尾的编造，涵盖万象。将其视为单一现象意味着你无法调试它；将其视为三四种不同的机制，意味着你可以命名当前面对的那种，并选择正确的修复方法。

以下是四种机制，它们解释了生产智能体中被称为"幻觉"的大多数情况。每一种都是模型工作方式的可预测结果，每一种都有独特的修复方法。

机制一：延续偏差（Continuation bias）

模型从根本上是一个下一令牌预测器。给定一个部分写好的回复，它生成最能延续该模式的令牌。当模式良好时，这是一个特性。当模型已经提交到一个听起来自信但没有事实支撑的开头时，它就成了故障模式。

具体来说：问模型"《威斯特伐利亚和约》哪年结束的？"，它可能开始说"《威斯特伐利亚和约》结束于"——此时下一令牌分布强烈倾向于一个具体年份。如果模型经过足够多的来源训练，知道是 1648 年，你就得到了正确答案。如果模型不确定，分布仍然倾向于某个年份（因为还有什么能完成这个句子呢？），然后它就采样了一个。错误的年份听起来和正确的年份一样自信，因为句法形态是相同的。

机制：一旦模型提交到某个句子形态，即使必须编造内容来完成它，它也会这样做。在默认情况下，下一令牌计算中没有"等等，我其实不知道这个"的分支。

修复方法：明确授权不确定性的提示词。"如果你不知道答案，就说'我不知道'"的效果比你预期的好——它给了模型一个被允许的延续，而不是"编造一个自信的答案"。结合接地（grounding）效果更好："仅根据提供的来源作答。如果答案不在来源中，就说明这一点。"这能大幅减少延续偏差导致的幻觉。

机制二：训练分布缺口（Training-distribution gaps）

模型知道它在训练期间见过的内容。对于没有出现在训练中（或很少出现）的话题、人物、产品或事件，模型是在没有可靠信号的情况下运作的。合理令牌上的分布趋于平坦，采样变得更加可变，输出在事实上变得不可靠，程度与该话题在训练中的代表性成反比。

症状：在冷门话题上自信地错误，在常见话题上准确，而用户没有任何明确的信号来区分哪种情况。询问重要历史人物的用户得到正确答案；同一用户询问次要地方人物时得到自信的虚构。模型在这两种情况下都不暴露自己的不确定性。

机制：模型从稀疏的训练数据中进行合理插值，而"合理"从外部看与"事实"完全相同。

修复方法：检索增强生成（第 1.2 章）。不要问模型它知道什么；给它相关文档，让它从这些文档中作答。模型在"从提供的文本中综合"方面，比"从训练中回忆"好得多。接地将工作负载从记忆（不可靠）转移到阅读（可靠）。

机制三：指令冲突（Instruction conflict）

模型被训练为遵循用户指令并给出有帮助的答案。当这两者冲突时——当遵循指令会产生听起来不够有帮助的答案，或反之——模型会协调这个冲突，有时落在错误的一边。

具体例子：用户要求"按字母顺序列出 API 端点"并提供了 20 个端点的列表。模型正确排序了大多数端点，但在过程中悄悄修正了一个端点名称中的拼写错误。用户说的是"列出它们"——不是"列出它们并悄悄纠正拼写"——但模型的帮助性训练推动它朝着产生"明显更正"版本的方向走。用户可能没有注意到这一点；模型可能对哪个拼写是正确的判断有误；无论如何，用户得到了一个以他们未曾要求的方式与输入不同的输出。

机制：模型在生成过程中平衡多个目标，当它们相互拉扯时，协调结果可能引入用户未要求的内容。

修复方法：明确指出哪个维度重要。"精确保留输入；不要纠正或规范化。""简洁；除非被问到，不要添加解释。"这些指令关闭了帮助性训练原本会推动的路径。

机制四：压力下的虚构（Confabulation under pressure）

第四种也是最棘手的机制：模型产生的文本听起来像是记忆或事实，但实际上是当场生成的，背后没有任何检索或计算支撑。这是人们说"幻觉"时通常所指的令人担忧的情况——捏造的引用、编造的函数签名、虚构的引语。

这种情况最常发生在模型被要求提供特定结构化事实声明时——引用、函数签名、日期、电话号码——而它实际上并不知道这些。因为答案的句法形态定义明确（引用用"作者（年份）"，代码用"function_name(arg1, arg2)"），模型可以产生完全符合形态的内容，而无需拥有其中的实质内容。

机制：模型生成符合所要求格式的输出，即使它没有内容来填充它们，因为格式符合性正是其训练所奖励的。

修复方法是多层次的。接地（机制二的修复方法）在提供了来源材料的情况下有帮助。验证（第 1.2 章的接地检查模式）在生成后可以对照来源验证声明时有帮助。明确的提示词有边际帮助："仅引用提供的上下文中存在的来源；如果你没有真实引用，就说明这一点。"对于高风险输出——医疗、法律、代码执行——三者结合使用，并将任何未经验证的声明视为可疑。

推理模型与对话模型：新的维度

从 2024 年起，服务商推出了一类独特的"推理"模型——带有扩展思考的 Claude、OpenAI 的 o 系列和 GPT-5 推理模式、DeepSeek-R1 及类似模型。这些模型在产生可见回复之前，会在内部生成"思考"令牌。思考对用户隐藏，但消耗真实的令牌和真实的算力。

关于推理何时有帮助的直觉：

• 有帮助：多步骤逻辑问题、数学、代码审查、复杂规划，以及任何模型受益于"先推导出答案再提交"的场景。思考令牌本质上是模型与自身对话，探索分支，发现自身错误。
• 没有帮助（且成本更高）：简单的事实查询、分类、提取、对话式回复。没有什么需要"推理"的——模型要么知道答案，要么不知道，额外的思考令牌是浪费的算力。
• 适得其反（反直觉地）：模型立即知道答案但扩展思考引入过度思考或自我质疑的任务。某些经过良好校准的、训练有素的行为，当你让模型先"多思考"时会变得更加嘈杂。

对智能体设计的实际影响：在智能体中将模型与任务匹配。在规划步骤（决定下一步做什么）使用推理模型，在综合步骤（写最终答案）使用更快的非推理模型，在分类步骤（决定调用哪个工具）使用能胜任的最便宜模型。第 2.2 章的成本梯度就是建立在这一洞察之上的。

诚实的注意事项：这个建议是 2026 年初的实践现状，"推理"模型与"对话"模型之间的边界正在模糊。Sonnet 4.5 和 GPT-5.5 都有混合模式，可以在需要时思考，不需要时不思考，由单一参数控制。趋势是走向"一个模型，可调节的思考预算"，而非"两个模型系列"。但底层思维模型——扩展思考对难题有帮助，对简单问题有害——仍然适用。

总结：30 秒内的幻觉分类诊断

当你在生产中看到幻觉时，依次过一遍四种机制：

生产智能体中几乎每一个幻觉都是这四种之一，或它们的组合。命名机制是修复的一半——它将你引向具体的干预手段，而不是模糊的"把提示词改好一点"的猜测。