token、上下文窗口，以及模型为什么会"忘掉中间"

token 不等于字

模型看到的不是字符，是 token。英文大致按子词切分，中文取决于分词器 —— 有的按字，有的按常见双字组合。所以不能拿字数直接估 token 数，差得远的时候会让你误判预算。

要准确数字只能实测：用对应模型的 tokenizer 跑一遍，或者调用官方的 count tokens 接口。

上下文窗口到底是什么

它约束的是单次请求里输入 + 输出加起来的 token 上限。几个常见误解：

• 不是"记忆容量"。会话历史是每次请求重新发过去的，模型本身不保存任何东西。
• 不是"发满就更聪明"。长上下文里信息密度被稀释，反而更容易漏掉细节。
• 超出上限不是只有"报错"这一种表现，有些接口会静默截断，把最早的内容丢掉 —— 表现就是"它怎么忘了开头说的"。

长文档中间的信息容易被忽略

这一点有实证研究支撑（Liu 等人 2023 年关于长上下文检索位置的实验）：把同一条关键信息放在文档开头或结尾，模型的召回率明显高于放在中间。这个现象被称作 "lost in the middle"。

对实践的直接影响：

一种省 token 的工程习惯

与其把所有历史都堆进上下文，不如维护一份结构化摘要：当前目标、已确认的事实、待办事项。每次请求只发这份摘要 + 最近几轮对话。这样既控住了长度，也不会因为早期对话被截断而丢掉关键前提。