上下文窗口规划
把上下文窗口分配给提示词、工具、历史和回复。
这里只填大小,不填文字本身。没有任何内容会被上传。
把请求排成能命中缓存的顺序
关于 上下文窗口规划
窗口要由你发送的一切和回复所需的空间共同分享,而后半句正是预算最容易忘掉的。加起来刚好压在上限之下的请求其实装不下,因为回复无处可去。这里把一切摊开:系统提示词、工具定义、文档、到目前为止的对话和这一轮,再加上为回复预留的部分,一起对照模型真实的窗口。它会说明装不装得下、差多少,并点出占用最多的那一块——那几乎总是历史,也几乎总是最该先动的地方。
功能特性
- 请求的每一部分都对照真实窗口计量
- 为回复预留空间——预算之所以诚实,就在这里
- 预留超过模型单次能生成的量时发出警告
- 历史占据窗口时发出警告
- 一条堆叠条,显示窗口究竟去了哪里
- 剩余容量或超出量以数字给出
- 带核对日期的模型窗口
- 所有字段都可编辑,贴合你自己的请求
如何使用 上下文窗口规划
- 选择目标模型
- 填入请求各部分的大小
- 为回复留出足够的 token
- 看它装不装得下,以及什么在占地方
示例
输入
32,100 sent + 4,000 reserved
输出
Fits, with 963.9K to spare
预留是"必须装下"的一部分,不是事后才想起的东西。
常见错误与故障排除
- 我的数字在上限之下,它却说装不下。 — 回复也得装下。已占用的数字是你发送的部分加上预留的部分。
- 我不知道各部分有多大。 — 用 token 计数器去量具体的文本。这个工具关心的是预算的形状,而不是精确测量。
- 预留被标为过大。 — 每个模型对单次回复能生成多少都有上限,这与窗口是两回事。上限就显示在输入框下方。
- 历史占据了窗口。 — 这条警告值得动手。压缩、编辑上下文或概括较早的轮次,效果都比其他任何改动更明显。
常见问题
- 为什么要为回复预留 token?
- 因为回复是在同一个窗口里生成的。如果输入把它填满,就没有地方作答了,结果是被截断的回复或一个报错,而不是一条关于预算的清晰提示。
- 窗口和输出上限有什么区别?
- 窗口是模型一次能容纳的量。输出上限是它在单次回复中生成的量,要小得多。两者这里都会检查,因为任何一个超了都会失败。
- 这些数字准确吗?
- 窗口大小是公布值,并附有核对日期。你为各部分填入的是你自己的估计,所以请把结果当作预算的形状,而不是保证。
- 装不下时该怎么办?
- 看哪一块最大,几乎总是历史或检索到的文档。少检索一些、概括更早的轮次,比修剪系统提示词管用得多。
- 换更大的窗口能解决吗?
- 它买来的是空间,不是效率。窗口里的一切在每次请求里都要付费,所以一段填满大窗口的对话,花费也会相应地高——这正是成本类工具存在的意义。
相关工具
- 提示缓存规划 — 重排请求的各块,让可缓存前缀尽可能长。
- 代理循环成本估算 — 逐轮估算成本,计入重发的历史与缓存。
- 文本切分 — 把文档切成有重叠的片段,只在真正的边界处断开。
- Token 计数器 — 为 GPT、Claude 和 Gemini 计数 token,在你键入时实时更新。
- 项目说明构建器 — 写一份对得起每次请求开销的 CLAUDE.md。
- 对话记录转换 — 把消息数组转成可读记录,也能转回去。
更多AI 与智能体工具
查看全部AI 与智能体工具 · 全部工具