目录

• 1. 从“工作记忆”说起
• 2. Context Window 不是“记忆”，只是“瞬时可见集”
• 3. 为什么这是一场“资源博弈”
  • 3.1 Token 是有限的预算
  • 3.2 注意力是稀缺资源
  • 3.3 成本、延迟与可靠性的三角约束
• 4. Context Window 约束下的典型工程困境
  • 4.1 多轮对话中的“历史膨胀”
  • 4.2 工具定义与系统提示词抢占空间
  • 4.3 检索增强（RAG）的“上下文污染”
  • 4.4 长任务中的“中间状态丢失”
• 5. 主流应对策略：把窗口当成“稀缺资源”来治理
  • 5.1 分层记忆架构
  • 5.2 历史压缩与滚动摘要
  • 5.3 上下文预算管理
  • 5.4 检索后的重排序与压缩
  • 5.5 工具与提示词的“按需加载”
• 6. Context Window 的“更大”真的能解决一切吗？
  • 6.1 有效利用长度 < 理论窗口长度
  • 6.2 长窗口放大了成本与非确定性
  • 6.3 窗口大小不能替代结构化
• 7. 设计启示：把 Context Window 当作第一公民
• 8. 总结

1. 从“工作记忆”说起

在认知科学里，人类的工作记忆（Working Memory）容量非常有限。1956 年，乔治·米勒提出著名的“神奇数字 7±2”：普通人大约只能同时记住 5～9 个信息块。尽管后来研究者认为实际容量可能更接近 3～5 个块，但核心结论始终成立——人类能同时“握在手里”的信息非常稀缺。

AI Agent 也有一个与工作记忆高度同构的东西：Context Window（上下文窗口）。

它决定了一个 Agent 在单次推理中最多能“看见”多少 Token。无论模型本身多么强大，无论外部工具、检索系统、代码解释器多丰富，最终真正进入模型注意力范围的，只有被塞进这扇窗口里的那一小段内容。

因此，当我们从 Agent 工程的角度去审视这个问题时，Context Window 就不再只是一个模型参数，而是整个系统设计中最核心、也最容易被低估的工程约束。

它本质上是一场持续发生的资源博弈：你要在有限 Token 预算里，同时装下系统提示词、工具定义、历史对话、检索结果、中间推理、代码片段与最终答案。

谁能更高效地分配这扇窗口，谁就拥有更强的 Agent。

---

2. Context Window 不是“记忆”，只是“瞬时可见集”

很多讨论会把 Context Window 类比成 Agent 的“记忆”。这个说法有一定道理，但容易产生一个危险误解：以为窗口越大，Agent 记得越牢。

实际上更准确的说法是：

Context Window 只是模型在当前推理时刻能够直接访问的临时工作区。它不等于长期记忆，也不等于知识库。一旦推理结束，窗口内的内容并不会自动沉淀为可复用的经验。

用一个工程化类比：

• Context Window：CPU 的寄存器 + L1/L2 缓存，容量小、速度快、推理时直接可用；
• 向量数据库 / 外部知识库：内存或磁盘，容量大、访问慢、需要检索才能进入工作区；
• 持久化记忆 / 摘要：已经过压缩与提炼的长期状态，成本低，但信息有损。

一个成熟的 Agent 系统，必须在这些层次之间不断做信息的“换入换出”。而 Context Window 就是那个最狭窄的瓶颈：所有最终用于生成的信息，都必须经过它。

---

3. 为什么这是一场“资源博弈”

3.1 Token 是有限的预算

无论上下文窗口是 4K、128K 还是 1M，它都是一个有限预算。Agent 在运行过程中，要把这个预算分配给多个互相竞争的消耗方：

总 Context Window
├── 系统提示词（System Prompt）
├── 工具定义与 JSON Schema
├── 历史对话与历史工具调用结果
├── 检索出来的文档片段
├── 代码执行结果 / 错误堆栈
├── 规划与中间推理（CoT / ReAct）
└── 最终要输出的答案

其中任何一项失控，都会挤压其它项的生存空间。

3.2 注意力是稀缺资源

大量研究显示，模型在长上下文中的表现并不均匀。即使窗口支持 128K Token，“有效注意力”也往往集中在开头、结尾和少数高相关位置，中间大量内容容易被“忽略”。

这意味着：

• 单纯把更多内容塞进窗口，不等于模型就能有效利用；
• 无关信息不仅浪费 Token，还会增加混淆风险；
• “最小必要上下文”往往比“最大可能上下文”效果更好。

3.3 成本、延迟与可靠性的三角约束

更长的上下文同时意味着：

• 更高的计算与 API 成本：输入 Token 通常是计费大头；
• 更长的首 Token 延迟：尤其是处理超长历史时；
• 更复杂的缓存失效问题：一旦前缀变化，缓存命中率会下降；
• 更大的失败面：超长输出、超时、内容截断、JSON 解析失败等风险都会上升。

因此，Context Window 的分配问题，本质上是成本、延迟、质量、可靠性之间的多目标优化。

---

4. Context Window 约束下的典型工程困境

4.1 多轮对话中的“历史膨胀”

Agent 通常需要保留对话历史以维持上下文一致性。但历史是单调增长的。如果不加处理，一个长任务跑上几十上百步后，历史 Token 就会吃掉整扇窗口。

常见结果包括：

• 早期重要信息被截断；
• 模型开始遗忘任务目标；
• 重复提问、循环调用工具；
• 输出质量随对话变长而下降。

4.2 工具定义与系统提示词抢占空间

当 Agent 拥有大量工具时，每个工具的 JSON Schema、参数说明、使用示例都会进入上下文。工具数量越多，留给任务本身的空间越少。

这带来一个反直觉结论：

加入更多工具，并不总是让 Agent 更强。超过一定阈值后，工具描述反而会挤占推理空间，导致调用准确率下降。

4.3 检索增强（RAG）的“上下文污染”

RAG 是解决长文档问答的主流方案，但检索回来的片段质量参差不齐。如果直接把所有候选片段都塞进窗口：

• 无关片段浪费预算；
• 矛盾片段干扰判断；
• 片段顺序影响模型对证据权重的判断。

因此，RAG 的核心挑战已经从“能不能检索到”逐步转向“检索回来后，如何筛选、排序、压缩，再送入有限的窗口”。

4.4 长任务中的“中间状态丢失”

一个复杂 Agent 可能执行数十次工具调用。每次调用后的中间结果、错误信息、临时判断，如果全部保留，Token 消耗惊人；如果全部丢弃，又可能导致后续步骤失去判断依据。

这要求系统对“中间状态”做分层处理：哪些必须原样保留、哪些可以压缩、哪些用完即弃？

---

5. 主流应对策略：把窗口当成“稀缺资源”来治理

5.1 分层记忆架构

不要把 Context Window 当作唯一的记忆载体。典型方案是把记忆分为：

• 工作记忆：当前 Context Window，只放本轮真正需要的内容；
• 短期记忆：本次会话的原始记录，放在外部存储；
• 长期记忆：跨会话的用户偏好、事实、经验，经抽取与检索后按需进入窗口。

这样，窗口只是信息流动的“前台”，而不是全部记忆的容器。

5.2 历史压缩与滚动摘要

对多轮对话历史，可以采用：

• 滑动窗口：只保留最近 N 轮完整内容；
• 滚动摘要：把较早内容逐轮压缩成结构化摘要；
• 关键事件提取：把工具调用结果、错误、决策点抽取为“事实卡”。

例如，在每一轮结束时执行一次轻量压缩：

def summarize_distant_history(messages, keep_recent: int = 6):
    """把较早的历史压缩成摘要，只保留最近若干轮完整内容。"""
    if len(messages) <= keep_recent:
        return messages

    distant = messages[:-keep_recent]
    recent = messages[-keep_recent:]

    # 实际场景中，这里调用 LLM 生成结构化摘要
    summary = (
        "历史关键信息："
        + "；".join(m.tool_result_summary for m in distant if m.tool_result_summary)
    )
    return [{"role": "system", "content": summary}] + recent

这样既保留了长期语义粘性，又避免历史无限膨胀。

5.3 上下文预算管理

把 Context Window 的容量显式建模为“预算”，并为不同类型内容设定上限比例：

预算分配示例（假设窗口 16K Token）
├── 系统提示词：≤ 1K
├── 工具定义：≤ 4K
├── 历史与摘要：≤ 6K
├── 检索证据：≤ 3K
└── 生成缓冲区：≥ 2K

一旦某类内容超限，就触发压缩、裁剪或降低检索数量。

5.4 检索后的重排序与压缩

对 RAG 场景，不要直接把所有召回片段送进窗口，而是：

1. 召回 Top-K 候选；
2. 使用轻量重排序（Rerank）挑选最有价值的片段；
3. 对长片段做句子级或段落级压缩；
4. 只把精炼后的证据送入窗口。

这样能在有限预算下最大化信息密度。

5.5 工具与提示词的“按需加载”

对于工具数量很多的 Agent，可以采用：

• 动态工具绑定：根据当前任务与规划结果，只加载少数相关工具；
• 工具描述精简：用短名 + 必要参数说明代替冗长文档；
• 系统提示词分层：基础指令常驻，任务相关指令按阶段注入。

其目标都是一致的：让每一寸窗口都被高价值信息占据。

---

6. Context Window 的“更大”真的能解决一切吗？

近年来，模型上下文窗口经历了从 4K、8K、32K、128K 到 1M 甚至更大的快速扩张。这当然大幅缓解了很多“历史截断”问题，但工程约束并未消失，只是发生了转移。

6.1 有效利用长度 < 理论窗口长度

上下文越长，模型在中间区域的信息召回能力通常越弱。研究中的“Lost in the Middle”现象表明，关键信息放在文档中间时，模型更可能遗漏。

因此，即使有 1M 窗口，把全部文档一把塞进去也不是最优方案。“塞得下”不等于“用得好”。

6.2 长窗口放大了成本与非确定性

当单次输入达到数万甚至数十万 Token 时：

• 单次调用成本显著上升；
• 推理时间变长，用户体验下降；
• 上下文中的任何无关噪声都可能被模型过度联想；
• 缓存策略、重试策略、限额策略都需要重新设计。

这要求我们仍然坚持“克制”的上下文使用哲学：能压缩就压缩，能检索就检索，能按需注入就按需注入。

6.3 窗口大小不能替代结构化

很多工程问题，本质上是状态管理问题。窗口再大，如果没有好的状态抽象，Agent 仍会迷失在大量非结构化文本中。

因此，更聪明的做法经常是：

• 用结构化状态对象替换自然语言历史；
• 用显式的工作流步骤替换自由发挥；
• 用受控的工具输出替换冗长的原始返回。

这比单纯追求更大的窗口更可靠。

---

7. 设计启示：把 Context Window 当作第一公民

综合来看，一个优秀 Agent 系统在设计之初，就应当把 Context Window 视为“第一公民”，而不是事后优化项。

几条可落地的设计原则：

1. 最小必要上下文：每个 Token 都要有进入窗口的理由；
2. 分层记忆：窗口只承载当前工作集，长期信息放在外部并按需检索；
3. 显式预算管理：为系统、工具、历史、证据分配可量化的上限；
4. 信息压缩优先：在长度与保真之间做主动权衡，而不是被动截断；
5. 按需注入：工具、提示词、知识都采用动态加载，而非全量常驻；
6. 可观测与可回退：记录 Token 占用、截断点与压缩决策，便于定位质量问题。

---

8. 总结

AI Agent 的 Context Window，表面上只是一个模型参数，实际上却是整个 Agent 系统中信息流动的咽喉。

它同时约束着：

• 模型能“看到”多少信息；
• 工具与记忆能“表达”多少信息；
• 系统要付出多少成本与延迟；
• 最终决策的稳定性与可解释性。

从这个意义上说，Agent 开发的核心矛盾，已经从“模型会不会答”逐渐转向“在有限窗口里，让模型看到最该看到的东西”。

那些把 Context Window 当作资源认真规划、持续压缩与治理的团队，与那些不断把内容塞进去直到截断的团队，长期来看会走向完全不同的工程效果。

这场从“工作记忆容量”出发、最终落脚于“Token 资源博弈”的设计竞赛，才刚刚开始。