上下文窗口与限制
物理约束有三种表现，应对策略有四类——理解了它们，就理解了为什么进阶 Agent 框架几乎都在做同一件事。
Core Curriculum
Level 1 · 概念理解
阅读时间 · 9 分钟
练习 · 建议必做
低波动
Last reviewed · 2026-04-22
你将学会什么
- 理解《上下文窗口与限制》在 agent harness / coding agent 学习路径里的核心作用。
- 能用本页给出的判断法区分“概念、机制、边界、代价”。
- 知道这页内容之后会在哪一章被复用到源码阅读或动手实践里。
学习前提
建议先读《Agent vs Workflow》；如果你是跳读，至少先看本章索引与本页 TL;DR。
这页在课程中的位置
课程理论地基，用来建立后续所有判断语言。
本页 1 句话结论
物理约束有三种表现，应对策略有四类——理解了它们，就理解了为什么进阶 Agent 框架几乎都在做同一件事。
带走的判断法
先问控制流、动作空间、终止时机，再谈 agent 能力。
Source Policy
课程主线：稳定概念 + 经典论文 + 官方机制。
TL;DR
- "Context window" 不是一个问题，是三种问题的合称：硬上限 token 预算、注意力衰减（lost-in-the-middle）、cost & latency 的（接近）平方级增长。
- 对照 RL：RL agent 的 state 是定长向量，没这个问题；LLM agent 的 state 是无界文本流，必然增长——所以"上下文管理"是 LLM Agent 独有的工程命题。
- 四类应对：裁剪（truncate）、摘要（summarize）、外置存储（offload to FS / vector DB）、多 agent 切分（subagent partition）。实践里几乎都是组合用。
- 这正是进阶 Agent 框架普遍引入 virtual file system + auto-summarization + subagent 的根本原因——不是炫技，是不得不。
1. 三种物理表现
| 表现 |
本质 |
触发症状 |
| ① Token 预算 |
模型有硬上限（4k / 32k / 128k / 1M…）。超出 = 直接报错或截断。 |
API 报 context_length_exceeded；或开头消息被默默丢弃。 |
| ② 注意力衰减 |
研究（Liu et al. 2023, Lost in the Middle）显示：长上下文中，开头和结尾的信息被注意得最好，中间部分被严重忽视。 |
Agent "忘了" 早期 user 目标；引用了开头的事实但忘了中段的关键约束。 |
| ③ Cost & Latency |
每次 forward pass 的成本与上下文长度线性，但因为 attention 是 O(n²)，长上下文延迟与显存几乎平方级；prefill 阶段尤其明显。 |
Loop 跑到第 20 轮，每一轮都比第 1 轮慢一倍 + 贵一倍。 |
"上下文窗口变大就解决了"是错觉
1M token 模型出现后，常有人说 "context 不再是问题"。事实是：硬上限（① ）确实变松了，但 ② 和 ③ 没有解决——长上下文里的注意力衰减和 cost/latency 仍然存在，且变得更隐蔽，因为 agent 不再因 OOM 直接挂掉，而是悄悄"开始忘事 / 变慢"。有上限时是显症；上限提高后变隐症。
2. 对照 RL：为什么 RL Agent 没这个问题
回到 01 章的 RL Agent 闭环图。RL Agent 的 state 通常是：
- 定长向量（位置、速度、像素帧的 latent…）；
- 由环境直接给出，不"累积历史"（如果需要历史，要么丢给 RNN/transformer 编码，要么走 frame stacking 但仍是定长）。
而 LLM Agent 的
