Appearance
Q23 · Token 和上下文窗口是什么？它们在工程上意味着什么？
一个订单客服助手已经和用户聊了几十轮。最早，用户说“只讨论订单 A123”；后来助手查了退款政策，工具返回一大段网页内容。用户现在问：“A123 能退款吗？”如果应用把所有历史消息和完整网页一股脑交给模型，这次请求可能装不下；若为塞进去而随意丢掉最早的订单约束，回答又可能串到别的订单。
这里的容量通常按 token 计算。token 是模型处理内容时使用的计数单位：一段文字会被模型所用的分词器切成若干片段。上下文窗口则是一次模型调用中，模型能同时处理的内容容量。它包含这次调用实际送入的内容，也要为模型接下来生成的内容留空间。一次会话能在数据库里保存很多轮，不代表模型在每次调用时都能看到全部历史。OpenAI 的基本概念、对话状态说明
术语与符号
| 词或符号 | 含义 | 订单例子中的对应物 |
|---|---|---|
| token | 模型计量输入和输出的单位；由特定模型的分词规则决定 | “订单 A123”被切分后得到的若干 token |
| 分词器（tokenizer） | 把文字等内容映射为 token 的规则或工具 | 计算这次请求到底占多少容量 |
| 上下文窗口（context window） | 单次调用可容纳的上下文与生成内容的总容量约束 | 这一次问“A123 能退款吗？”时可用的空间 |
| 输入 token | 本次送入模型的消息和其他可见内容占用的 token | 规则、当前问题、选入的历史、退款政策片段 |
| 输出 token | 模型在本次调用中生成内容占用的 token | 最终答复；某些模型还包括用户看不到的推理等内容 |
| 工具结果 | 程序调用搜索、数据库等工具后得到的数据，再提供给模型 | 查到的退款政策网页片段 |
| 截断 | 为满足限制，丢弃一部分输入，或生成到上限时停止 | 旧消息被裁掉，或答复写到一半结束 |
| 摘要 | 把较长历史压缩为保留关键事实的短记录 | “当前仅处理 A123，已核对用户提供的购买信息” |
| 检索 | 按本轮问题从外部资料里挑相关片段 | 只取与 A123 退款条件有关的政策段落 |
W、I、O | 下文分别表示窗口容量、本轮实际输入、为生成预留的容量，单位都是该模型的 token | 三者帮助应用判断是否还能装下资料 |
**token 不是“汉字数”，也不是“单词数”。**中文、英文、空格、标点、代码、JSON 字段名的切分都取决于模型和分词器；同样的句子换模型，token 数也可能变。图片、音频等非纯文本输入还可能按各自规则折算。不要用“一个汉字等于一个 token”估算账单或边界，应使用目标 API 的计数方法，并核对请求完成后的用量字段。OpenAI token 计数文档、Google Gemini token 说明
一次调用究竟装了什么
图里的纸条代表具体内容，不代表每条消息固定占一格。第一次调用时，模型也许只看到用户的问题和工具定义，随后请求调用“查退款政策”工具。工具运行完后，应用发起后续模型调用，把工具结果作为新的输入交给模型；这时退款政策会占用该次调用的输入容量。工具返回越长，不一定越有帮助，还可能挤掉真正重要的聊天事实或回答空间。
工程上可以先用一个预算关系检查：I + O ≤ W。这里 I 是这次实际送入的 token，O 是希望为输出保留的 token，W 是所用模型的上下文容量。这个关系只是装箱直觉：真实 API 还可能分别限制最大输入、最大输出、单条工具内容或多模态内容；某些推理模型生成的内部推理 token 也占用输出或上下文预算。开发时要以当前模型和接口文档、实际计数结果为准，不能只套一个通用公式。OpenAI 对话状态说明、OpenAI 推理模型说明
假设我们已经用目标模型的计数工具得到一组纯教学数字：窗口容量 W = 1,000 token；规则 100、近期对话 300、退款政策结果 450、当前问题 50，合计输入 I = 900。如果希望留 O = 200 给答复，需求就是 1,100 token，超过 1,000。这里的数字是假设的 token 计数，不是说这些中文材料分别有多少字，也不代表任何真实模型规格。
应用可以先从 450 token 的政策结果里，挑出与 A123 问题相关且能标明来源的 250 token。于是输入变成 700，预留 200 后合计 900；剩余空间可应对格式等额外开销。若政策片段不足以判定，助手应明确缺少什么信息，继续查证或请用户提供，而不是凭短片段推断退款资格。压缩要保留决定结论的条件和来源，不是机械截取网页前几百字。
窗口满了时会怎样
超限行为取决于具体接口和配置。有的请求会直接报错，要求应用缩短输入；有的对话接口允许自动去掉较早消息；也可能因为输出预算耗尽，生成以未完成状态结束。应用不能假设服务端总会“聪明地留下重要内容”，应明确选择保留什么、丢弃什么，并检查响应状态。OpenAI 对话状态说明、OpenAI Realtime 截断说明
回到订单例子。假设应用按时间从旧到新删消息，最早的“只讨论 A123”可能先消失；后面的政策段落却还在。模型此时不是“忘性差”，而是这次输入里已经没有关键约束。如果上一轮还出现 B456 订单，它可能把 B456 的信息混进回答。正确处理是把“当前订单 A123”作为结构化会话状态保留，在每次相关请求里明确送入；对退款结论还要核对订单号与政策条件。
另一种失败是输入正好勉强装下，却几乎没给回答留空间。模型可能只写出“根据政策，A123 可……”就到上限；对支持内部推理的模型，预算还可能先消耗在不可见的推理内容上。程序要查看输出是否完整以及用量信息，必要时缩短输入、增加合适的输出限额或把任务分步完成，不能把半句当成完整结论。OpenAI 推理模型说明、OpenAI token 计数文档
它为什么影响费用、速度和质量
多数按量计费的模型接口按输入、输出等用量收费，但各模型的费率、缓存折扣和特殊 token 口径不同。重复把几十轮历史及整页工具结果送入，通常会增加输入用量；长输入也可能增加处理时间，长输出会增加生成时间。缓存某段重复输入若被接口支持，可能降低其费用或延迟，但缓存不等于释放上下文空间，不能用缓存来替代内容选择。Google Gemini token 计数说明、OpenAI 提示词缓存说明
更大的窗口可以减少装不下的情况，却不能保证模型准确找到长文里的关键条件。订单政策如果有“未拆封”和“签收后规定期限内”两项条件，扔进十页资料也不能代替对两项条件逐一核对。长上下文的使用应通过实际任务评测，检查答案是否引用了相关段落、是否忽略了冲突信息。Google Gemini 长上下文说明
长对话怎样管理预算
- **明确每轮必须带入的事实。**应用规则、当前订单号、已经确认的资格事实应放在可靠的会话状态里；旧的闲聊不必逐字重放。会话状态要标注来源和更新时间，避免摘要把“用户声称已签收”写成“系统确认已签收”。
- **保留近期原话，压缩较早历史。**最近几轮通常包含本轮指代；更早内容可形成短摘要。摘要应记录结论所需条件和未解决的问题，必要时能回查原始记录。摘要本身也会占用 token，且可能遗漏细节。
- **只检索相关资料。**对“A123 能退款吗”，挑政策中退款期限、商品状态等有关段落，并附来源标识；限制每次检索返回的片段数和长度。若多个来源矛盾，不能靠截短材料掩盖矛盾，应先核实。
- **发送前计数并预留输出。**用目标模型或 API 的计数接口核算整个请求，包括消息、工具定义和准备加入的资料；按任务预计的答复长度留空间。发送后读取实际用量、截断或未完成标记，把失败作为可重试或降级的状态处理。OpenAI token 计数文档、Google
countTokens接口 - **按质量而非只按 token 最小化。**删掉 200 token 的退款例外条款，也许省了成本，却会造成错误答复。预算紧张时，先删重复、无关和过时内容；关键事实与判定条件要保留。
即使 API 支持服务端保存对话或引用上一响应，也要确认这次实际交给模型的是哪些内容。服务端有历史记录并不表示每轮历史免费，或能无限装进单次窗口。OpenAI 的对话状态文档也说明，关联先前响应的方式仍会对链中的输入 token 计费；具体实现仍须查看所用接口。OpenAI 对话状态说明
面试时可以这样回答
Token 是模型计量内容的单位，由模型的分词规则决定，不能直接按汉字数换算。上下文窗口是一次模型调用能够同时处理的容量。应用送入的规则、聊天历史、当前问题、检索片段和工具结果都要占输入预算，还要给回答预留空间；有些推理模型的不可见推理也会影响输出预算。工程上我会用目标模型的计数接口预估请求，保留关键事实和近期对话，较早历史做可回查的摘要，只取相关资料，并检查调用后的实际用量和完成状态。超限时不能随意删掉规则，否则会产生看似正常但依据已丢失的回答。
如果追问“窗口很大，为什么还要做摘要和检索”，可以回答：长输入仍有费用、延迟和定位关键信息的质量问题；摘要和检索是为了让本轮所需的证据与约束更可靠地进入窗口，不只是为了塞进容量。若追问“一个汉字占几个 token”，应回答“没有跨模型固定值”，并展示所用模型的计数结果，而不是背一个换算常数。