1.1 窗口即预算：容量与注意力的直觉
1.1 窗口即预算：容量与注意力的直觉
本节摘要：本节建立全书第一个定量直觉：token 窗口是预算约束，不是装填目标。先给 token 量级的尺子——从一页文档到一个代码库各是什么量级，让你能口算"装不装得下"；再讲"每一轮全价重付"：模型无状态，上下文每轮整包重发，既是容量问题也是成本问题。然后是本节的核心警告"塞满不等于用好"：Anthropic 把注意力比作预算——token 越多，单个 token 分到的注意力越薄（官方）；实证侧，lost in the middle 一族研究反复观察到无关文档增多时准确率下降（实测）。由此立起预算恒等式：窗口 = 指令 + 工具 + 记忆 + 素材 + 输出预留，其中输出预留最常被忘掉——塞满的第一个症状是模型回复变短。最后拆三个常见误区。
学习目标
阅读完本节，你应当能够：
- 口算常见内容的 token 量级，判断一类任务是否装得下。
- 解释"每轮全价重付"对容量与成本的双重含义。
- 说出"塞满不等于用好"的两个证据，并写出预算恒等式。
- 识别三个常见误区并给出反驳。
一、先领一把尺子：token 量级直觉
上下文窗口以 token 计。不要求精确，但必须有量级直觉（换算为工程估算，示意）：
| 对象 | 量级（示意） | 说明 |
|---|---|---|
| 一句指令 | 50~200 token | "你是客服，请按 JSON 输出……" |
| 一页 A4 中文文档 | 500~1,000 token | 中文约 1 字 ≈ 1 token（粗估） |
| 一个中型工具 schema | 100~500 token | 名称 + 描述 + 参数说明 |
| 一段 RAG 检索片段 | 200~500 token | 典型 chunk 512 token 上下 |
| 40 轮客服会话历史 | 8k~30k token | 随轮数线性累积 |
| 一部中篇文档全文 | 50k~200k token | 一份 80 页 PDF 的正文 |
| 一个中型代码库 | 500k~5M+ token | 远超任何窗口 |
主流模型窗口在 128k~1M 量级（官方，2026-09 时点）。对照表格读两个结论：其一，单轮短任务根本花不完窗口——这也是"窗口焦虑"长期不被重视的原因；其二，Agent 场景必超——历史线性累积、工具结果动辄上千、检索片段成批进入，40 轮会话加十几个工具就能吃掉大半窗口。
💡 窗口规格是"上限"不是"目标"：128k 窗口像 128k 的预算——上限高只说明你不会立刻爆仓，不说明每一分都花得对。
二、每一轮全价重付
模型无状态：它不记得上一轮读过什么，是你（应用层）每轮把整个上下文重新发给它。两个推论：
- 容量推论：历史不会"沉淀"在模型里，只会在你的 messages 数组里越长越长——第 N 轮的窗口 = 前 N-1 轮的全部内容 + 本轮新增。增长是线性的，而且永不自动收缩。
- 成本推论：多数 API 按输入 token 计费，且长输入的单价随长度上台阶（官方，各家阶梯定价不同）。一份 50k 的静态文档每轮都重发，等于每个 token 收入乘以轮数——上下文是复利成本，不是一次性投入。
这一条把上下文工程同时变成质量工程与成本工程：省下的每一个重复 token 都是纯利。
三、塞满不等于用好：注意力稀释
容量之外还有第二重约束：注意力。Anthropic 的比喻最好记——把注意力也当成预算：窗口里的 token 越多，单个 token 分到的注意力越薄，与任务无关的内容不是中性的，它在稀释与任务相关的内容（官方）。
实证侧的旁证同样清楚：把无关文档不断加进窗口，即使正确答案始终在窗口里，模型准确率也会随文档数上升而下降（实测，Liu et al. 2023 的多文档曲线，2.2 节详述）。这被社区称为"长上下文幻觉"的近亲——窗口支持长文本，不等于能有效利用长文本。
直觉模型（示意）： 相关 token： ●●●●●●●●●● 10 个信号 无关 token： ○○○○○○○○○○○○○○○○○○○○ +20 个噪声 ──→ 每个信号的"被读到概率"被摊薄
两条约束合起来，得到本节的座右铭：**窗口是预算，不是仓库。**预算的正确用法是"恰好够用"，不是"尽量装满"。
四、预算恒等式
把窗口当作一笔预算，它的科目固定为五项：
窗口 = 指令 + 工具 + 记忆 + 素材 + 输出预留 指令 系统提示、任务要求、输出契约（第 3.1 节） 工具 全部工具的 schema（第 3.2 节） 记忆 对话历史与跨会话记忆（第 4 章，后半） 素材 检索片段、文件内容、工具结果（第 5 章，后半） 输出预留 模型本轮生成结果的空间
三条读法：
- 恒等式每轮成立：不是设计期算一次就完，是每一轮组装窗口时都要过一遍的审计。
- 输出预留最容易被忘：四项都往里塞，塞到只剩 200 token 给模型说话——症状是回复变短、JSON 被截断、总结"偷懒"。工程经验值：预留 15%~25%（示意），长输出任务取上限。
- 前四项是第 1.2 节的四成分：恒等式先立总额，四成分表再给科目详情——两件工具在下一节合体。
⚠️ 一个高频事故：把一份 60k 的产品手册全文塞进 128k 窗口，再挂上 20 个工具（5k）与 30 轮历史（20k），只给模型留 43k 看似宽裕——但手册里与本次问题相关的只有两页。真正该装的是那两页（检索），不是整本手册（堆料）。
五、三个常见误区
| 误区 | 反驳 |
|---|---|
| "窗口大了（1M），上下文工程可以退休" | 稀释与位置效应不随窗口消失（实测），成本更随窗口线性上升；窗口越大，越需要预算表 |
| "信息多多益善，模型自己会挑" | 无关信息是负资产：它稀释注意力（第三节），实证上降低准确率 |
| "上下文工程就是高级提示词工程" | 0.1 节已分界：前者管运行时的动态供给系统，管的对象远不止一段指令 |
本节要点回顾
- 量级尺子：一页 1k、一段检索 0.5k、40 轮会话 1 万级、一个代码库百万级；Agent 场景必超预算。
- 每轮全价重付：容量线性累积 + 输入按轮计费，上下文是复利成本。
- 塞满不等于用好：注意力稀释（官方）+ 无关文档负贡献（实测）。
- 预算恒等式：窗口 = 指令 + 工具 + 记忆 + 素材 + 输出预留；每轮审计，输出预留留 15%~25%（示意）。
- 座右铭：窗口是预算不是仓库，正确姿势是"恰好够用"。
预算的总额与科目立好了。下一节给科目表：窗口里的一切内容，按"谁产生、多久有效、谁负责裁剪"三问，恰好分成四种成分——那张表是全书之纲。