🧠 基础概念

上下文窗口（Context Window）

别名：上下文Context Length上下文长度Token 窗口KV Cache

上下文窗口是 LLM 单次推理能处理的 Token 总量上限，包含系统提示、历史对话、检索内容与模型生成。它决定了 Agent 一次能「看到」多少信息，是架构设计的核心约束。

关键要点 ✦

一次 Agent 调用占用的窗口由多部分叠加：系统提示（角色、工具定义、规则）、对话历史、检索注入（RAG 片段、记忆）、工具结果（长 JSON、网页正文）、以及模型生成。工具的返回往往是窗口消耗的「大头」。

当累计 Token 逼近上限，需触发截断、压缩或摘要策略，否则会报错或丢失关键信息。

窗口变长带来两笔账：显存/算力成本随序列长度近似平方增长（注意力机制），以及「中间遗忘（Lost in the Middle）」现象——模型对长文本中部信息的利用率显著低于首尾。

因此「窗口大」不等于「用得好」。工程上更常见的是：用 128K–200K 窗口处理单轮长文档，但用记忆 + 检索把多轮任务控制在更短的活跃窗口内。

三条主流路径：① 检索（RAG）只把相关片段注入窗口；② 记忆/摘要把历史压缩后保留要点；③ 上下文压缩用小型模型对长内容做预摘要。三者常组合使用。

此外，分块（Chunking）与滑动窗口（Sliding Window）是处理超长输入时的经典手段。

长文档分析

整本 PDF / 代码仓库一次性读入，做摘要、问答与合规审查。

多轮长对话

靠记忆与摘要把对话控制在活跃窗口内，避免历史溢出。

大规模代码库 Agent

将仓库分块检索注入，而非全量塞入窗口以控成本。

随 KV Cache 复用与稀疏注意力技术成熟，超长窗口的单位成本将持续下降；但「窗口无限大」不会取代检索与记忆——信息筛选能力才是 Agent 的核心瓶颈。

🏷️ 标签上下文Context WindowTokenLLM推理长文本