READ · UNDERSTAND · TRANSFER
阅读理解，按需巩固
先沿着原理、问答和迁移案例阅读。需要检查理解时，再切换巩固练习或展开个人记录。
核心知识 · Token 计量、上下文容量与生成余量
先理解核心原理
先备概念：请求与响应生命周期、模型接口的结果类型
窗口决定一次请求可以容纳多少信息，生成上限决定本次最多生成多少，二者都不证明信息被正确使用。预算需要按完整请求和目标接口计数；下一轮新增结果会占用新的输入，不能用上一轮余量直接保证后续请求。
从缓冲区容量理解模型窗口
一个文件能装进内存，不代表程序已经解析出正确字段。同样，请求被模型接受，只说明满足容量规则；找出相互制约的条款、使用某个数字并引用其依据仍是任务能力。长窗口位置敏感性的原始论文在其受测模型与任务上说明这种差异，不能据此给所有新模型套用固定退化比例。
“预留输出”是一项策略
输出上限是允许生成的最大值，模型可能提前结束，也可能因预算不足停止。若接口把推理计入生成用量，最终文字很短也可能耗尽 G。预留大小应依据代表任务的实际用量分布、允许成本和交付长度调整，检查上限触发比例；这不是要求全部任务都留同一数量。
下一轮需要重新核算
本题假设中，第一轮还可增加 2000 token，但一次工具结果有 4000，下一请求就需要调整。不要用首轮的窗口合法性证明整个 Agent 任务合法。可先让工具返回摘要与引用，必要时读取相关段落；如果材料的完整措辞决定结论，就应分步取原文或换具备足够容量的模型，而不是压掉关键条件。本题只讨论模型请求容量与信息取舍；长任务事实账本、授权约束和连续摘要漂移见“上下文预算与压缩”单元。
回到问题：怎样回答？
Token 是模型处理与计量的单位，不能按汉字数固定换算。完整输入包括指令、工具定义、历史和证据；上下文窗口与最大输出是两个限制，部分推理模型还把不可见推理计入生成预算。先按目标接口统计输入并预留生成与安全余量，工具结果加入后重新计算。超出窗口要减少或分段输入，输出截断要检查生成上限和实际用量；更长窗口只增加可容纳信息，不保证模型正确找到并使用证据。
实现与取舍
先分清计量与容量
Token 是模型编码和处理内容的单位，不等于一个汉字或英文单词。相同文字在不同编码下的数量可能不同，单纯数正文也会漏掉角色边界、工具 Schema 和消息结构。开发时选目标模型的计数方式，尽可能对完整请求计数，再用接口返回的实际 usage 对照。token 计价、上下文容量与请求限流也是不同约束，价格便宜不代表窗口更大。
输入与输出共享哪些限制
完整输入记为 I，计划允许生成的总预算记为 G，模型上下文容量记为 C。对于采用输入与生成共同占用上下文的接口，先检查 I＋G 不超过 C，再检查 G 不超过该模型独立的最大输出上限；具体计数和预留规则以部署接口为准。若推理用量计入生成预算，G 还要容纳推理和可见回答，不能只按最终文章字数设置。保留安全余量 S 是工程选择，用于输入估算误差或预期增量，不是供应商自动赠送的空间。
一个给定假设的预算算例
以下全部数字是教学假设，不代表任何当前模型：C＝32000，独立最大输出＝8000，当前完整输入 I＝23000，计划 G＝6000，安全余量 S＝1000。采用 I＋G＋S≤C 的本地规则，目前还能增加 2000 token 输入。若下一轮把 4000 token 工具结果加入，输入变成 27000，同样生成预算会要求 34000，总额超出 2000。此时应筛掉无关输入、分步读取，或在交付允许时减少生成范围；只把输出参数调大反而更挤。
分别处理不同失败
输入过大可能被接口拒绝，也可能触发显式配置的裁剪，不能默认自动裁剪仍保留关键材料。生成触及上限时查看完成状态与原因，部分 JSON 不作为可执行参数。网络流中断与 token 预算耗尽不是同一问题，需要按真实状态诊断。纯文本可分章节生成并逐段验收，依赖完整参数的工具调用则先取得合法完整对象。压缩、检索和增大窗口各有取舍：摘要有损、检索可能漏召回、长输入有成本且不保证证据利用，选择后还要检查答案与引用是否支持。
工程推演
- 场景
- 教学场景：输入为 23000 token，工具下一轮追加 4000，假设窗口 32000、生成预算 6000、安全余量 1000。
- 设计决策
- 在追加前核算下一请求，发现需求为 34000，选择移除至少 2000 无关 token 或按问题分步读取；关键依据保留原文与版本。
- 验证目标
- 算术可检查：初始可增加量为 2000，追加后的缺口为 2000。验收目标是预算合法、必要证据仍覆盖且输出完整；没有调用真实模型。
- 适用边界
- 计数与窗口共享规则是给定假设；安全余量不能证明语义完整，分段或摘要后仍可能漏掉条件。
连续追问与解答
沿着问题的前提和约束继续向下读。先理解参考解答，再尝试收起答案，用自己的话解释因果和取舍。
第 1 层为什么不能根据“9000 个汉字”直接判断输入能否放进窗口？
容量判断先要确定计量对象，字数只能提供粗略线索。
参考解答
因为编码、语言和内容结构不同，同样字数会得到不同 token 数；9000 汉字也只覆盖正文，没有计算指令、历史、工具定义和结构开销。使用目标模型对应的计数工具或完整输入计数接口，说明多模态计数规则；若只能估算，留余量并比较实际 usage，不能将粗估包装成精确值。
第 1 层输入没有超限，为什么输出仍可能被截断？
同一请求存在输入与生成两类容量约束，不能相互替代。
参考解答
输入合法只通过了输入相关检查。独立输出上限太小，或生成占用剩余上下文，都可能使结果不完整。查看接口状态和 incomplete 原因，区分达到生成上限、内容过滤与流传输中断；不要只凭文本长度诊断，也不要把部分结构化结果当完整。
沿着这个回答继续深入
第 2 层只看见 1000 token 回答，却耗尽 6000 的生成预算，可能发生了什么？
父问解释输出不足，子问加入可见文字与总生成用量不相等的条件。
参考解答
若该接口把推理与可见输出共同计入生成预算，剩余用量可能消耗在推理；检查 usage 的分类和完成原因。也要排查其他响应内容，不能直接断定供应商计费错误。这个数字仅为教学假设，实际分项和参数语义随接口不同。
沿着这个回答继续深入
第 3 层把生成预算从 6000 加到 8000，是否一定能避免再次截断？
增加生成预算与输入争用容量，修复局部限制可能触发整体限制。
参考解答
不一定。先同时检查独立输出上限和上下文余量；本题初始输入 23000 加 8000 再加 1000 正好为 32000，但加入工具结果后的 27000 已不适合该设置。即便容量合法，模型仍可能需要更多生成或提前结束。可减输入、分章或调整任务，完整性最终按状态和产物验收。
第 1 层上下文窗口扩大四倍，是否就可以不用检索和筛选证据？
从容量扩展迁移到效果判断，避免把容纳信息等同使用信息。
参考解答
不能自动这样判断。更大窗口减少容量不足，却不能证明相关材料被找到、冲突被解释或引用正确。保留必要证据，排除明显无关内容，再用固定任务对比答案正确、来源支持、漏点与费用。检索也会漏召回，是否减少检索应由代表样本验证，不是由窗口规格推导。
举一反三：条件变了，怎样推导？
先找出改变的条件，再判断原方案中哪些前提仍成立。下面的案例是教学推演，便于将原理迁移到新问题。
完整合同条款决定例外
改变的条件：普通摘要任务变为依赖定义、否定词和例外的精确解释。
延伸问题：预算不足时可以把条款全部摘要后解释吗？
推导与参考解答
摘要可定位相关章节，但关键结论前读取适用版本的完整定义、条款与例外，并保留引用。若组合仍超窗，按问题拆成可验收子任务，保存中间主张及依据后综合；无法保留必要上下文时缩小结论范围。更省 token 不能抵消丢条件造成的错误。
保持不变的原理：容量调整必须保留决定结论的证据，语义充分性独立验收。
固定格式报告输出很长
改变的条件：输入很短，但要求一次交付许多章节且容易达到输出上限。
延伸问题：换更大输入窗口是首选吗？
推导与参考解答
先检查独立输出上限与实际生成用量，输入空间大不代表允许更长输出。按稳定目录分章节生成、逐段保存和验证，再检查整体引用与重复遗漏；若必须一次返回完整对象，缩小交付范围或选择足够输出能力的接口。不要在截断 JSON 末尾拼接猜测字段。
保持不变的原理：输入容量和输出能力分别约束交付，完整结果来自明确验收。
易错点
- 把英文粗略换算比例套到中文、代码或多模态完整请求。
- 认为设置 max_output_tokens 就会生成指定长度，或该参数只计算可见文本。
- 输入填满窗口后才考虑回答和下一轮工具结果。
- 把增大窗口当作检索质量、引用支持和事实正确的保证。
- 凭被截断的 JSON 补几个括号后执行外部写操作。
参考资料
依据官方接口文档及原始论文设计；预算数字为明确教学假设，未运行真实模型，不代表某公司原题或当前产品额度。 新增问答与迁移案例用于原理讲解，来源核查与案例运行验证分别记录。
检查自己理解到哪一步
读完后可以对照这些标准解释原理、边界和取舍。掌握程度由你自评；需要进一步验证时，再完成下方小任务。
- 基础达标
- 说清 token 不是字数，区分完整输入、上下文容量和最大输出。
- 中高级信号
- 正确计算给定预算算例，知道推理可能占生成预算，分开诊断超窗与截断。
- 资深信号
- 为下一轮增量设置容量规则，权衡分段、检索与摘要，并验证必要证据使用而非仅验证请求被接受。
巩固练习 按需完成 · 建议 20 分钟
采用本题教学假设：窗口 32000、独立最大输出 8000、完整输入 23000、生成预算 6000、安全余量 1000。先算可新增输入量，再加入 4000 token 工具结果，给出两种合法调整方案，并说明每种方案如何检查必要证据与完整输出。
展开验收要求与检查点
- 算出初始可新增输入为 2000、追加后总需求为 34000、缺口为 2000。
- 至少给出保留生成预算时减少输入，以及任务允许时收缩生成范围两种选择，不把调大输出当万能修复。
- 说明数字是教学假设，真实请求要按目标接口计数。
- 输出状态不完整时不执行参数；增删证据后逐条核查必要依据。
重点检查
- 能区分 token、完整输入、上下文窗口、最大输出和费用预算。
- 会用给定假设计算输入与生成余量，说明下一轮追加工具结果的影响。
- 能区分输入过大、生成预算耗尽和网络中断，不执行不完整参数。
- 知道长窗口容量与证据使用效果需要分别验证。