Context Window（上下文窗口）是模型在单次请求中能处理的最大 token 数，相当于 Agent 的”工作记忆”：系统提示、对话历史、工具返回、检索到的文档，一切推理依赖的信息都得装进这个窗口才能被模型”看见”。说它是最核心的约束，是因为它同时卡住三件事——信息装不下任务就断、token 超限成本线性上升、上下文太长模型反而记不住关键内容（Anthropic 称之为 context rot）。窗口管理做不好，Agent 会失忆、跑偏、烧钱。
一、Context Window 是什么
想象你读书时桌面上只能摊开固定数量的几页，超过上限，最早翻开的页会被推下桌面——这就是 Context Window。它用 token 计量，1 个 token 约等于 0.75 个英文单词，中文大致一个字到两个字一个 token。一个 20 万 token 的窗口能容纳约 15 万英文单词，足够装下一大块代码库，但对大型项目仍然远远不够。
窗口尺寸的演进很快：早期 GPT 只有 4K token，今天 Claude、Gemini 等前沿模型普遍到 200K+，部分模型宣称超过 100 万。但”更大”不等于”更好用”——研究反复显示，模型对超长上下文中间位置的信息召回能力显著下降，这就是著名的”lost in the middle”现象。
二、Agent 的窗口里装着什么
一次 Agent 推理，窗口被四类内容瓜分：
| 内容 | 占比（典型） | 特征 |
|---|---|---|
| 系统提示 | 小但常驻 | 每轮循环都要重发 |
| 对话历史 | 随轮次增长 | 多轮后迅速膨胀 |
| 工具定义与返回 | 中 | 一份工具 schema 动辄上千 token |
| 检索到的文档 | 按需注入 | RAG 拉进来，用完即弃 |
一个可运行的预算示意：
def token_budget_check(system_tokens, history_tokens,
tools_tokens, docs_tokens, max_window=200_000):
used = system_tokens + history_tokens + tools_tokens + docs_tokens
print(f"已占用 {used} / {max_window} token，剩余 {max_window - used}")
return max_window - used # 负数 = 超限，会触发截断或报错
token_budget_check(8_000, 120_000, 15_000, 60_000) # 203000，超限三、为什么它是”最核心”的约束
3.1 硬上限：装不下任务就断
窗口是模型架构决定的硬边界（与位置编码方案绑定），超限要么报错，要么被静默截断。Agent 运行在循环里，历史与工具结果每转一圈都在累积，累积速度远超单次对话，所以它比任何应用都先撞上墙。长任务里最常见的失败模式，就是 Agent 在任务中途耗尽上下文，草草宣布完成。
3.2 成本：每个 token 都要付钱
大模型按 token 计费，输入输出都算。一次 20 万 token 的请求是相当昂贵的调用；而 Agent 每轮循环都在重复消费整份上下文，成本随轮次翻倍叠加。这也是长上下文模型的”便利”和”账单”同时存在的根本原因。
3.3 上下文腐烂：越长越记不住
Anthropic 在一系列 benchmark 中发现：上下文 token 越多，模型从中准确召回信息的能力越差，且这个衰减在所有模型上都存在，只是程度不同。transformer 架构让每个 token 都能关注其他所有 token，n 个 token 产生 n² 组两两关系，上下文越长，注意力被摊得越薄；而模型的训练数据中短序列远比长序列常见，处理超长上下文的经验天然不足。
3.4 对比：工作记忆不等于长期记忆
| 维度 | Context Window | 长期记忆（向量库/文件） |
|---|---|---|
| 本质 | 推理时的易失工作区 | 持久存储 |
| 容量 | 固定 token 上限 | 近乎无限 |
| 生命周期 | 请求结束即失效 | 跨会话保留 |
| 检索方式 | 直接可见 | 需 RAG 检索拉入 |
| 类比 | CPU 缓存 / 桌面 | 文件柜 / 档案库 |
四、窗口快满时的四类工程手段
按时间尺度从短到长，业界把窗口管理分成四层，成熟 Agent 通常叠加使用：
- 压缩（compaction）：历史接近上限时，把冗长的原始对话摘要成关键决策、结果与待办，以摘要重新开局；最轻量的一档是”清空工具原始输出，只保留调用记录”；
- 检索（RAG）：把参考知识放外部存储，按需拉取相关片段进窗口，而不是一股脑全塞进去；
- 持久记忆：用户偏好、完成状态等跨会话事实落库，下次运行再读回；
- 子代理架构：把窄任务拆给上下文干净的专职子代理执行，主代理只接收 1～2 千 token 的浓缩结论，避免被原始数据淹没。
Anthropic 的实践建议还有一个反直觉的结论：让 Agent 保持窗口精简、检索收窄、压缩积极，比给它一个巨大窗口塞满内容，准确率反而更高——”更多上下文”不等于”更好上下文”，精挑高信号 token 比扩容更重要。
五、窗口管理的两条反直觉经验
第一条，精简比扩容更有效。Gravity AI 在构建参考 Agent 时观察到，从”把一切塞给大窗口”改成”窗口保持精简、压缩积极、检索收窄”之后，准确率反而提升——模型在小而相关的上下文上推理，比在大而杂的上下文上更可靠。
第二条，信息位置比信息量更关键。长上下文中，位于首尾的信息召回率明显高于中间，因此关键指令和约束应放在窗口首尾，而不是埋在中间。对 Agent 工程而言，这意味着不仅是”塞什么进窗口”，还要控制”关键内容落在窗口的哪个位置”。
常见问题（FAQ）
Q1：窗口越大越好吗？
不是。更大带来成本与延迟，且中间信息召回率下降，需配合压缩与检索。
Q2：Agent 忘记早期指令怎么办？
多半是窗口溢出或上下文腐烂，用摘要压缩与持久记忆兜底。
Q3：Context Window 和记忆是一回事吗？
不是。窗口是易失工作区，记忆是可持久化存储，二者靠检索衔接。
