上下文、token 与成本的直觉

01token：AI 的计量单位THE UNIT

模型不按"字"读写，按 token——大致是词的碎片。一个英文单词、一个汉字，通常都在一到两个 token 的量级。精确换算不重要，重要的是记住：token 是 AI 世界的度量衡，输入按它计费，输出按它计费，模型一次能处理多少内容（上下文窗口）也按它计量。

还有一条不对称：输出通常比输入贵数倍。读是扫一遍，写是一个 token 一个 token 逐个生成——这也是为什么答案越长越慢：生成是逐字吐的，不是整段掏出来的。

最反直觉的一条：模型没有记忆。你和它的"对话"是个幻觉——每次你发新消息，系统把整段历史对话从头到尾重新发给模型，模型重新读一遍，然后接着写。它不是"记得"你说过什么，是每次都"重读"你说过的一切。

这一条解释了一大片现象：为什么换个新对话它就"忘了"（因为历史没被重发）；为什么产品要做"记忆功能"（把要点存下来、下次开头塞进去）；为什么 F-001 里说 Agent 循环每转一圈开销都在涨（每圈都要重读全部状态）。

变贵：第 50 轮对话时，你为前 49 轮的全部内容再付一次输入费。对话长度线性涨，累计成本近似平方涨——长对话的账单曲线比直觉陡得多。

变慢：重读的内容越多，开始回答前的等待越长。

变笨：上下文窗口是有限的，塞得越满，模型对中间部分的注意力越稀。关键信息淹没在几万 token 的闲聊里，效果就是"它怎么把前面说好的忘了"——不是忘了，是没注意到。

所以老手的习惯是：一个任务一个对话，长任务定期"换血"——把结论摘要出来，开个新对话从摘要继续。这不是洁癖，是在管理一份按 token 计价的注意力预算。

既然每轮都重发同样的开头（系统提示、资料、历史），服务商就提供了提示缓存：同样的前缀短时间内再次出现，不用全价重算，缓存部分常常有数倍到十倍的折扣。

直觉模型：把对话开头想成"已经翻好放在桌上的书"。你几分钟内回来接着聊，书还摊在那里，翻书钱免了大半；你隔了太久或者改了开头的字，书被收走了，重新全价摊开。

这条直觉的工程推论：稳定的内容放前面，多变的内容放后面。系统提示、参考资料这些不变的部分放在最前，缓存才有效；把动态内容（比如当前时间）插到开头，等于每轮都亲手把书合上。

把上下文窗口当成越大越好。窗口大是能力上限，不是免费午餐——塞满一个大窗口既贵又稀释注意力。窗口的正确用法是"够用就好"，不是"装到满"。

把"它忘了"当成模型缺陷。多数时候是使用方式问题：对话太长、关键信息没有被重申、或者新对话没带上必要背景。先检查自己给了它什么，再怀疑它记不住什么。

成本只算 API 单价。真实成本 = 单价 × 重读次数 × 上下文长度。Agent 循环转三十圈，每圈重读全部历史——单价便宜的模型跑出昂贵的账单，就是这么来的。评估 Agent 项目成本，先问循环圈数和每圈上下文，再问单价。

成本结构如何倒逼产品形态（额度制、预览/精修分层），见 N-009 长任务系统的工程边界——读完本页你会明白它说的"成本是第一天的设计输入"在物理层面意味着什么。Agent 循环的开销缰绳（步数上限、成本上限），见 F-001 第 02 节。