Token 与上下文窗口：长度预算不是可靠记忆

Token 是模型处理文本等输入时使用的单位，上下文窗口则限制一次请求可处理的内容范围。它们不等于中文字符数，也不等于产品能永久记住多少对话。

一个汉字不是固定多少 Token

文本会由具体模型的 tokenizer 分成片段；词、标点、空格、语言和编码方式都会影响结果。不能用“一个 Token 固定等于 0.75 个汉字”估算所有模型，也不能看到 8K 就断言每个提供方都指完全相同的数量。

需要准确预算时，应以目标模型和接口的计数方式为准。OpenAI 的输入计数文档还说明，消息包装、工具及复杂输入会影响计数，不能只数用户可见文字。Token counting

输入不仅有本次问题，还可能包括系统指令、历史对话、检索资料和工具结果。输出也占用预算；适用的模型还可能涉及推理 Token。最大输出长度是另一个约束，不能从总窗口大小直接推出答案可以有多长。上下文管理说明

用一个假设容量说明预算关系，不对应任何产品规格：

如果又追加 2,000 Token 的工具返回，就要减少其他输入或调整输出预算。实际接口是否报错、截断或由应用主动压缩，取决于具体实现，不能一概说模型“自动忘掉最前面的内容”。

可容纳更多文本，只解决装不装得下的一部分问题。材料中的冲突、噪声、引用位置和任务要求仍影响答案；把整本资料塞进去并不能保证逐段正确检索和引用。

可采取的办法包括：先挑与问题相关的片段、给来源编号、保存关键约束、按主题压缩历史，以及在需要时重新检索原文。摘要应保留否定条件、版本和出处，不能只保留结论而丢掉限制。

应用可以保存历史，在下次请求时重新提供；也可以用检索系统找回外部资料。这些属于应用管理状态的方式，不是模型参数在每次对话后自动更新。

同理，Token 数也不直接等于费用。输入、输出、缓存或其他服务项目的计费方式由提供方与所选模型决定，应查看实际账单口径，不能用统一单价套所有服务。