token 与上下文窗口¶
模型眼里没有"字"和"词"，只有 token——理解计费、窗口和一切上下文问题的起点。 🟢 稳定 ｜ 对位 W1（W4 上下文工程再回看）｜ 最后核实：2026-09-08
为什么要懂¶
你之后遇到的每一个工程约束——API 按什么收费、为什么长对话变慢变贵、为什么 log 文件塞不进去、为什么模型"忘了"开头说过的话——都追溯到这个概念。这是 agent 开发的「计量单位」。
核心解释¶
token 是模型处理文字的最小单位，但它不是字也不是词，而是 tokenizer（分词器）从海量文本里统计出来的「常见碎片」：
- 常见英文单词 ≈ 1 个 token（
the、data） - 不常见的会被拆开：
SDTM可能是 1–2 个 token，unblinding可能拆成un+blind+ing - 中文：现代分词器下常见字/词 1 个 token，生僻字会更多；经验法则：中文 1 个汉字 ≈ 1–2 token，英文 1 个单词 ≈ 0.75–1.3 token
- 代码：缩进、括号、变量名各自占 token——所以 SAS/Python 代码比同样行数的散文更"贵"
上下文窗口（context window）= 模型一次能看到的 token 总量上限，包括：系统提示词 + 工具定义 + 历史对话 + 你的新问题 + 它要生成的回答。全部加起来不能超过窗口。
类比：上下文窗口是审评员的桌面。桌子就那么大——摊开的资料（上下文）他能直接看到，没摊开的（档案室里的文件）等于不存在。2026 年桌面已经很大了（主流 128K–1M token，约等于几百页文档），但桌面大不等于每份文件都被仔细看——这是 W4 上下文工程要解决的问题。
动手试试¶
- 打开 OpenAI tokenizer 工具，粘贴一段你写的 SAS 代码（比如一段
%macro），观察：哪些词被拆开了？缩进占了多少 token？ - 再粘贴同一段内容的英文注释和中文注释，比较 token 数——你会直观理解为什么中文 prompts 有时更"省"。
- 查一下你用的 DeepSeek 模型的窗口大小和单价（platform.deepseek.com 文档），算一笔账：一份 3000 行的 SAS log 大约多少 token？塞进去一次多少钱？
常见误解¶
- ❌「1 token = 1 个字」→ 不确定，取决于分词器和内容，算成本时用 API 返回的 usage 字段，不要自己估
- ❌「窗口 1M，那我什么都扔进去」→ 能扔 ≠ 该扔。窗口是上限不是目标，信噪比才是关键（见上下文工程）
- ❌「历史对话不收费」→ 每轮请求都会把全部历史重新发给 API 重新计费——长对话的成本是滚雪球的，这是 W3 nano-agent 要管历史的原因之一
现状与深挖¶
- 主流模型窗口（2026-09）：128K 是起步线，头部模型普遍 256K–1M。窗口竞赛已趋缓，竞争转向「长窗口里能不能真的用得好」（有效上下文）。
- 深挖：tokenizer 加餐视频（Karpathy《Let's build the GPT Tokenizer》前 30 分钟）见 resources.md 每周原理资源包 W1 行。