Token 与上下文窗口是什么？为什么长对话会变贵
Token 不是一个汉字
模型通常把文本切成 Token 后处理。一个 Token 可能对应词、词的一部分、标点或其他编码片段，具体由分词器决定。不同模型对同一段中文的切分可能不同，因此不能用固定的“一个汉字等于一个 Token”计算容量与费用。
需要准确预算时，应使用目标模型对应的分词或计数接口。图片、音频和工具定义也可能占用输入额度，计量方式应以所用服务的文档为准。
上下文窗口装了什么
上下文通常包括系统指令、历史消息、当前问题、工具定义、工具结果和检索资料。模型支持的窗口大小限制了可处理的信息规模，最大输出长度又可能有独立限制；不同服务对输入、输出与内部推理的预算口径不同，不能只看一个窗口数字。
聊天应用常会把部分历史重新发送，后端并不是天然记住所有旧消息。会话存储与模型当前可见上下文是两回事，调试时要查看实际发送了哪些信息。
长对话为什么成本增长
历史越长，每轮输入通常越多。如果每次都发送完整历史，即使用户只问一句短问题，也可能付出较大的输入成本。输出长度、工具多次调用与重试还会增加总开销。应分开记录每次调用的输入、输出和工具成本，再按任务汇总。
部分服务提供提示缓存，但缓存命中、保留方式和计费规则不同。不能把可能命中的缓存当成固定折扣，更不能为了缓存而忽视用户隔离与敏感信息处理。
大窗口不等于一定理解得好
模型能接收更多内容，不代表会准确利用每个细节。重复、冲突和过时信息可能稀释重点；关键约束藏在冗长历史中也可能被忽略。设计上下文时，应优先保留当前任务目标、必要事实和可追溯证据。
常见办法是按相关性检索历史、压缩已完成步骤，或用结构化状态记录关键事实。但摘要也可能遗漏信息，涉及数字、权限和操作结果时，应保留可核对的原始记录。
如何做一次容量验证
准备含中文、代码、工具返回和长资料的代表性请求，记录真实计数，再逐步增加长度。验证超限时应用是否给出明确提示，或者按既定策略裁剪，而不是静默丢掉当前问题。还要比较缩短上下文后答案是否失去关键依据。
本文没有对具体模型做计费或容量测试。面试时可按“如何计量、哪些内容占窗口、怎么控制任务成本、超限如何处理”回答，避免用统一换算率或最大窗口代替工程方案。