上下文即一切：AI/Agent 时代「长上下文」设计与原理全景盘点（2017–2026）

副标题：从 Attention 的平方复杂度，到 Agent 的记忆战争——一篇讲透「上下文」这个 LLM 时代最核心、也最被误解的概念。

发布日期：2026-08-17 ｜ 信息截止：2026-08-17
适合读者：从刚入行的工程师到资深架构师（文中提供分级阅读路线）
关键词：长上下文 / Context Engineering / KV Cache / Agent Memory / RAG / Prompt Caching / Compaction

---

〇、写在前面：为什么是现在

2026 年，如果你只允许一个 AI 工程师保留一个技能，那不再是 Prompt Engineering，而是 Context Engineering（上下文工程）。

这个判断不是情绪输出，而是三条产业事实的必然推论：

1. 窗口已经"够用"了，但 Agent 依然在失忆。 截至 2026 年中，主流旗舰模型的上下文窗口已达 1M token 级别（Claude Opus/Sonnet 4.6 的百万 token 窗口于 2026 年 3 月全面 GA，GPT-5.x 系列同为 1M 级别，Gemini 系列更早进入 2M 区间）。窗口不再是瓶颈——上下文治理才是。
2. "上下文工程"完成了从黑话到学科的跃迁。 2025 年 6 月 Andrej Karpathy 带火这个词；同年 9 月 Anthropic 发布工程长文《Effective context engineering for AI agents》；2026 年，它已经是字节、腾讯、阿里等大厂 Agent 岗位 JD 中的高频词。
3. 成本结构逼着每个人懂上下文。 长上下文请求的 TTFT（首 token 延迟）与按 token 计价模式，让"塞满窗口"从 demo 技巧变成了生产事故。一个日均十万次调用的系统，上下文策略的差异能带来数十倍的成本差。

本文的目标只有一个：读完之后，你脑子里的"上下文"不再是一个聊天框的长度参数，而是一套完整的、跨层的技术体系——它向下连着 GPU 显存与注意力数学，向上连着 Agent 的记忆架构与团队工程规范。

分级阅读路线

你是谁	建议路径	预计时间
零基础 / 学生	第一、三、七章 + 附录 A	30 min
应用开发者（1–3 年）	第四章 → 第五章 → 第八章	60 min
算法 / 推理工程师	第二章 → 第六章 → 第七章面试题	90 min
求职者（任何方向）	全文速读 + 第七章 + 第九章	120 min

全文核心论点（先记住这一句）：
LLM 没有记忆，只有上下文。一切长上下文技术——无论模型层、应用层还是 Agent 层——本质都是对同一个稀缺资源"注意力预算"的分配学。 这门分配学由三个子问题构成：装不下（存储问题）、看不完（算法问题）、用不起（系统问题）。后文所有技术，都是这三个问题的答案。

---

一、第一性原理：上下文到底是什么

1.1 LLM 的无状态本质：它永远"活在当下"

剥掉所有产品包装，大语言模型在数学上是一个无状态函数：

y = f(x)

其中 x 是这一次请求送进去的全部 token 序列，y 是模型生成的 token。两次调用之间，模型权重不会因你的上一句话发生任何改变。你以为它"记得"你，真相是：客户端把整个对话历史重新拼进 x，重新算了一遍。

一句话定义：上下文（Context）= 某次推理时，模型能看到的全部输入 token 序列。它是模型在这一刻拥有的全部世界。

这个定义有两个残酷推论：

• 不在上下文里的信息，对模型而言不存在。 你的数据库里有一亿条记录，但只要没检索进上下文，模型就等于"不知道"。
• 上下文里的每一条信息都在花钱、抢注意力。 上下文不是越大越好的仓库，而是一块寸土寸金、有容量上限、有注意力衰减的黄金地段。

1.2 上下文的三层定义

工程实践中，"上下文"其实是个复合体，至少分三层：

┌─────────────────────────────────────────────┐
│  ③ 逻辑上下文：这次任务"应该知道"的一切        │
│     （需求、代码库、历史决策、用户偏好…）        │
│  ┌─────────────────────────────────────┐    │
│  │ ② 工程上下文：你"组装出来"送进模型的    │    │
│  │   System Prompt + 工具定义 + 检索结果  │    │
│  │   + 对话历史 + 状态文件                │    │
│  │  ┌─────────────────────────────┐    │    │
│  │  │ ① 物理上下文：上下文窗口      │    │    │
│  │  │   Context Window（token 上限）│   │    │
│  │  └─────────────────────────────┘    │    │
│  └─────────────────────────────────────┘    │
└─────────────────────────────────────────────┘

• 物理上下文是硬约束（如 200K token）；
• 工程上下文是你的设计作品——Context Engineering 的全部工作都在这里；
• 逻辑上下文是理想态，永远大于前两者，所以必须做取舍。

认知跃迁点 #1：所谓"上下文工程"，本质是信息架构设计：在有限窗口内，让最高价值的信息离决策点最近。它是数据库、操作系统、信息检索三门经典学科在 LLM 时代的合流。

1.3 关于上下文的三大错觉

在深入技术之前，先拆掉三个最常见的错误心智模型——它们正是无数线上事故的根源：

错觉	真相
“窗口 1M = 能用 1M”	标称窗口 ≠ 有效上下文。基准测试显示多数模型在 32K 之后能力开始衰减（第三章详述）
“塞得越多答得越好”	无关信息（distractor）会稀释注意力，甚至让准确率低于不给这些信息时——这叫 Context Rot
“上下文是记忆”	上下文是计算的工作区，不是存储。关掉会话，一切归零。"记忆"必须由工程系统外挂（第五章）

1.4 三十年尺度下的窗口进化史（速览）

时间	模型/事件	上下文窗口	备注
2017	Transformer 原论文	512	平方复杂度初现
2018–2020	GPT-2 / GPT-3	1K → 2K	Few-shot 学习诞生
2023.03	GPT-4	8K / 32K
2023.07	Claude 2	100K	首次把"读整本书"变成卖点
2024.02	Gemini 1.5 Pro	1M → 2M	百万 token 时代开启
2024	GPT-4 Turbo / Claude 3	128K / 200K	主流档位确立
2025	Claude 4 系 / GPT-5 系	200K–1M	Agent 化，上下文治理问题爆发
2026.03	Claude Opus/Sonnet 4.6	1M（GA，无溢价）	可整库读入代码
2026	Gemini 3.x Pro	1M（>200K 阶梯计价）	长上下文进入成本精细化阶段

注意一个产业信号：2026 年的竞争焦点已从"窗口多大"转向"长上下文的单位成本与有效利用率"（例如 Gemini 对超过 200K 的请求阶梯加价）。窗口长度的军备竞赛降温了，上下文经济学登场。

---

二、模型层：长上下文的物理学

本章回答：为什么上下文不能无限长？把窗口拉长 100 倍，工程师到底要对抗什么？
不懂这一章，你对上下文的认知永远停留在"调参数"。

2.1 注意力机制：O(n²) 的原罪

Transformer 的核心是自注意力：每个 token 都要和序列中所有 token 计算相关度。设序列长度为 n、维度为 d：

• 计算量：O(n²·d) —— 长度翻 10 倍，prefill 计算量翻 100 倍；
• KV 显存：O(n) —— 线性增长，但常数极大（见下）。

这就是"长上下文难"的数学根源。过去八年所有的长上下文研究，都是在绕过或驯服这个 n²。

2.2 KV Cache：被严重低估的"记忆成本"

自回归生成时，每生成一个新 token，都要对全部历史做注意力。如果每次都重算历史，成本不可接受。于是工程上把每一层每个历史 token 的 Key/Value 向量缓存下来——这就是 KV Cache。

它有多大？动手算一笔（面试高频题）：

每 token 的 KV 大小 = 2(K和V) × 层数 × KV头数 × 头维度 × 字节数

以 Llama-3-70B 级模型为例（80 层，GQA 8 个 KV 头，头维 128，FP16）：
2 × 80 × 8 × 128 × 2 bytes = 327,680 B ≈ 320 KB / token

128K 上下文 → 128,000 × 320KB ≈ 40 GB 显存（仅 KV，不含权重）

结论：长上下文的真正瓶颈往往不是算力，而是显存墙。 一个 70B 模型 + 128K 上下文的单请求 KV Cache，就能吃掉一张 80GB 卡的半条命。这也解释了为什么"多轮对话越长越慢越贵"——每一轮你都在为全部历史重复支付 KV 存储与读取。

2.3 Prefill 与 Decode：两个世界，两种瓶颈

阶段	做什么	瓶颈	上下文长度的影响
Prefill（预填充）	一次性算完所有输入 token 的注意力	算力（compute-bound）	n² 增长，决定 TTFT
Decode（解码）	逐 token 生成，每步读全部 KV	显存带宽（memory-bound）	n 线性增长，决定每 token 延迟

工程直觉：1M token 的请求，TTFT 轻松十几秒——这不是网络问题，是物理问题。所以生产系统的长上下文体验优化，第一刀永远砍向 prefill（见 2.7/2.8 的缓存复用）。

2.4 位置编码的外推战争：从 RoPE 到 YaRN

Transformer 本身不知道 token 的顺序，位置信息靠位置编码注入。主流是 RoPE（旋转位置编码）：把"位置"编码为对 Q/K 向量的旋转角度，天然表达相对位置。

问题在于：模型只在训练长度内见过这些角度。 训练时见过 8K，推理时塞 128K，等于让模型读一本"页码超出字典"的书——注意力分布直接崩坏。于是出现了外推/内插技术谱系：

技术	核心思想	一句话点评
PI（Position Interpolation）	把长位置线性压回训练区间	简单有效，高分辨率受损
NTK-aware Scaling	在频域非线性缩放，高频细节少损失	免微调外推的里程碑
YaRN	NTK + 注意力温度补偿 + 分区插值	2023–2025 开源模型的事实标准
LongRoPE / 渐进式扩展	搜索最优缩放因子 + 分阶段训练	把开源窗口推到 2M 区间
RandYaRN 等（2026）	随机化窗口训练提升长度泛化	前沿方向：让"长度本身"不再敏感

配合长上下文继续预训练（long-context post-training）——用几十万到百万 token 的真实长文档/代码/对话语料再训一阶段——才造就了今天的百万级窗口。

认知跃迁点 #2：窗口长度不是"配置出来的"，是训出来的 + 外推出来的。看到一个模型宣称 1M 窗口，内行会先问：长文本训练占比多少？外推方案是什么？——这几乎是必考的追问。

2.5 稀疏注意力与线性注意力：给 n² 动手术

既然全量注意力太贵，那就不看全部：

• 滑动窗口注意力（Sliding Window）：每个 token 只看邻近 W 个位置（如 Mistral 7B 的 4096 窗口），层间堆叠间接获得全局感受野。代价：超长程直接依赖被削弱。
• 全局 token + 局部窗口：Longformer 式混合，关键位置（如 [CLS]、段首）保持全局可见。
• 动态稀疏（NSA / MoBA 等，2025–2026）：运行时为 query 动态挑选最重要的 KV 块（token selection + 块级路由），把稀疏做到"硬件友好 + 可训练"。DeepSeek 2025 年公布的 DSA（DeepSeek Sparse Attention）即此路线：在保持长文理解的同时大幅压低推理成本。
• 线性注意力 / 状态空间模型（SSM）：Mamba、RWKV、RetNet 一系，把"注意力"替换为 O(n) 的循环状态压缩。2024–2026 年主流玩法是混合架构（如 Jamba、Nemotron-H 等：大部分层用 SSM，少量层保留全注意力），用极小的全注意力比例保住"精确检索"能力。

一句话总结这一节：长上下文架构史的暗线，是"精确但昂贵的全注意力"与"便宜但有损的压缩"之间持续的讨价还价。

2.6 MLA：把 KV Cache 压到极限的代表作

DeepSeek-V2/V3 系列的 **MLA（Multi-head Latent Attention）**值得单独讲，因为它直接改写了成本曲线：

• 常规 MHA/GQA：缓存每层每头的完整 K、V；
• MLA：把 K、V 先低秩压缩进一个隐向量，KV Cache 只存这个压缩后的隐向量，注意力时再解压。

效果：KV Cache 缩小一个数量级以上，配合推理框架的落地，使 DeepSeek 系能以极低价格提供长上下文服务。2026 年 MLA 及其变体已成为国产与开源长上下文模型的主流选择之一。

2.7 推理系统层：PagedAttention 与 KV 压缩

模型结构之外，服务系统是长上下文的第二战场：

• PagedAttention（vLLM，2023）：借鉴操作系统虚拟内存分页，把 KV Cache 切成固定大小的 block 按需分配，显存碎片浪费从 60–80% 降到接近 0，并发吞吐提升数倍——如今是所有主流推理引擎的地基。
• KV Cache 量化与选择性驱逐：对不重要的 KV 用更低比特存储，或按注意力分数丢弃（H2O、SnapKV 一系）。
• TurboQuant（Google，2026.03）：将 KV Cache 显存占用压缩至少 6 倍、推理提速最高 8 倍且几乎零精度损失——2026 年 KV 压缩工程化的标志性工作。
• 前缀共享 / Cache-aware Routing：同一段 system prompt 的 KV 只算一次，请求按前缀哈希路由到持有该 KV 的实例。

2.8 Prompt Caching：每个应用工程师都该懂的省钱机制

**Prompt Caching（前缀缓存）**是 2024–2026 年对应用侧影响最大的基础设施能力：

• 原理：推理方把你请求的前缀部分的 KV Cache 存下来；后续请求若前缀逐字节一致，直接复用，跳过 prefill。
• 商务面：Anthropic 式显式缓存对缓存命中部分读取约 1 折计费（写入约 1.25 倍），TTL 分钟级到小时级；OpenAI 系自动缓存约 5 折。
• 工程铁律：上下文组装顺序必须是"稳定在前、易变在后"——System Prompt → 工具定义 → 长期知识 → 会话历史 → 当前输入。任何在前段插入一个空格的行为都会击穿缓存。

认知跃迁点 #3：上下文工程天然包含一个"排序学"——同一段内容，放在 prompt 前部还是后部，价格、延迟、命中率、注意力权重全都不同。这是把"上下文"当资源管理的起点。

---

三、能力层：长上下文真的"好用"吗

本章回答：厂商宣称的窗口 ≠ 你能用的能力。这一层是 demo 与生产之间的分水岭，也是面试区分度最高的区域。

3.1 评测进化史：从大海捞针到真枪实弹

基准	时间	测什么	关键结论
Needle In A Haystack（NIAH）	2023.11	在长文本中插入一句无关事实，看能否找回	开创性但太简单：字面匹配即可命中
NIAH 变体（多针/多值/多跳）	2023–2024	多个事实、需聚合推理	Claude 2.1 时代首次揭示"多值聚合"崩溃
LongBench / v2	2023.08 / 2024.12	中英双语真实任务（摘要、代码、QA）	任务真实了，分数立刻腰斩
RULER（NVIDIA）	2024.04	13 类任务：检索 + 变量追踪 + 聚合 + QA	多数模型"有效上下文"远低于宣称值；聚合与变量追踪任务最先崩
MRCR（Google DeepMind）	2024.10	多轮共指消解：长对话中的指代链推理	揭示"检索得到 ≠ 推理得出"，长上下文需要的是推理而非查找
NoLiMa	2025	去掉字面线索的"无针"联想任务	模型失去字面锚点后性能大幅下滑——真实场景几乎没有"针"

认知跃迁点 #4：NIAH 时代我们以为长上下文是"检索问题"；RULER/MRCR/NoLiMa 时代才看清它是检索 + 聚合 + 多跳推理的复合问题，而后两者恰恰最先崩坏。向面试官说出这句话，足以领先 90% 的竞争者。

3.2 Lost in the Middle：那条著名的 U 型曲线

斯坦福等团队 2023 年的经典论文《Lost in the Middle: How Language Models Use Long Contexts》发现：

• 关键信息放在上下文开头或结尾时，模型表现最好；
• 放在中间时，性能显著下降，呈 U 型曲线；
• 在闭源模型与多文档 QA 上同样成立。

成因（学界共识方向）：训练数据的位置偏置（重要内容常在文首/文末）、指令微调样本结构、以及注意力分布对位置的先验。

工程对策（可直接写进工作规范）：

1. 关键约束、硬性规则放 system prompt（头部）；
2. 最新任务指令、当前状态放消息序列尾部；
3. RAG 检索结果按相关度排序时，把最相关的放最前或最后，别放中间；
4. 对关键信息在头尾做策略性重复（repetition at boundaries）。

3.3 Context Rot：上下文会"腐烂"

2025 年 Chroma 发布的《Context Rot》报告对十余家主流模型做了系统测试，结论可以浓缩为一句话：

随着输入长度增长，模型性能持续退化——即使增加的内容与任务完全无关；而包含干扰、矛盾信息时，退化加速。

这就是"上下文腐烂"。它解释了所有 Agent 开发者都见过的灵异现象：任务跑到第 15 步，模型开始重复已做过的事、给出与第 3 步矛盾的结论。不是模型变笨了，是上下文被自己产生的废料淹没了。

三条腐烂机制：

1. 注意力稀释：无关 token 分摊了有限的注意力预算；
2. 干扰与矛盾：相互冲突的信息诱发"和稀泥"式输出甚至幻觉；
3. 状态淹没：任务目标被几十屏工具输出埋在中间（恰好落在 Lost in the Middle 区）。

认知跃迁点 #5：上下文是消耗品，不是容器。它有新鲜度、有信噪比、有保质期。成熟系统监控上下文质量，就像监控系统内存一样理所当然。

3.4 注意力预算：一个统一的心智模型

把 3.2–3.3 抽象成一句话，就是 Anthropic 在那篇著名工程文章中的核心命题：

“Context is a critical but finite resource.” —— 上下文是关键但有限的资源。

我称之为注意力预算模型：

模型单次推理的"有效注意力" ≈ 常数 B（远小于窗口长度）

你的全部工作 = 让 Σ(信息价值_i × 注意力权重_i) 最大化
其中 Σ注意力权重 ≤ B，且权重受位置、信噪比、表述方式影响

由此推出上下文工程的四大动作（下一章展开）：写入（Write）、选择（Select）、压缩（Compress）、隔离（Isolate）——它们分别对应"造预算、花预算、省预算、分预算"。

3.5 长上下文三难困境（The Long-Context Trilemma）

这是全文的总纲图，请记住它：

              【装得下】
             （存储问题）
               /      \
     压缩/检索/记忆      稀疏/线性注意力
             /            \
    【看得完】 ———————————— 【用得起】
   （算法问题）   KV缓存/前缀缓存   （系统问题）
                  量化/批处理

• 装不下 → RAG、记忆系统、上下文压缩（第四、五章）
• 看不完 → 位置编码外推、稀疏/线性注意力、长文训练（第二章）
• 用不起 → KV Cache 优化、Prompt Caching、量化与调度（第二章）

任何一个上下文技术方案，都可以用这个三角来定位它解决了哪一角、牺牲了哪一角。 这是分析框架，也是面试时的万能拆解器。

---

四、应用层：上下文工程完整图谱

本章回答：作为应用/Agent 工程师，我每天到底该怎么做？这是全文与工作直接对接的部分。

4.1 范式迁移：三代功夫

代际	核心问题	时间	代表技能
第一代：Prompt Engineering	“怎么问”	2022–2024	措辞、Few-shot、CoT 措辞
第二代：Context Engineering	“给什么看”	2024–至今	信息组装、检索、预算分配
第三代：Memory / Context OS	“让它成为谁”	2025–萌芽	持久记忆、跨会话状态、技能沉淀

Karpathy 2025 年中的表述最精准：context engineering 是"在有限窗口内，用恰当的信息恰当地填充上下文"的艺术。注意——它没有取代 Prompt Engineering，而是把它收编为子集：prompt 只是上下文中你亲手写的那一小段。

4.2 上下文的解剖学：一个 Agent 请求里到底有什么

┌──────────────────────────────────────────────┐
│ ① System Prompt        人格/规则/边界（最稳定） │
│ ② Tool Definitions     工具 schema（较稳定）    │
│ ③ 长期注入知识          用户画像/项目规范（半稳定）│
│ ④ 会话历史              多轮对话+工具调用记录（增长）│
│ ⑤ 检索结果              RAG/搜索结果（按轮注入）   │
│ ⑥ 运行时状态            TODO/进度/反思笔记（可编辑）│
│ ⑦ 当前用户输入           （最新）                │
└──────────────────────────────────────────────┘
      稳定性从上到下递减，变化频率从下到上递减
      缓存策略：上段求命中，下段求隔离

两个被新手忽视的坑：

1. 工具定义是隐形大户。 挂 30 个工具的 schema 动辄上万 token，且与任务多数无关。生产系统的标准做法是按意图动态加载工具子集。
2. 工具输出是腐烂之源。 一个 grep 能返回 5000 行日志。必须对工具结果做截断、摘要或落盘引用（见 4.5）。

4.3 四个动词：Write / Select / Compress / Isolate

这是 LangChain 官方对上下文工程策略的经典归纳，可作为团队设计评审的 checklist：

策略	含义	典型实现
Write（写入）	让模型把信息写到窗口外，留待以后取用	Scratchpad、todo.md、把中间结论写入文件
Select（选择）	按需取回最相关的信息	RAG、工具查询、agentic search（模型自主决定搜什么）
Compress（压缩）	在不丢决策关键信息的前提下缩短历史	会话摘要（compaction）、工具输出裁剪
Isolate（隔离）	用多个独立窗口分担预算	子 Agent、多 Agent 编排、路由到小模型

4.4 Anthropic 的三件套：Compaction、结构化笔记、子 Agent

Anthropic《Effective context engineering for AI agents》（2025.09）给出的长任务三板斧，至今仍是业界事实标准：

① Compaction（压缩/折叠）
当上下文接近阈值（如窗口的 80–92%），让模型自己总结历史、重开一段新对话。核心是总结 prompt 必须强制保留：

请总结当前任务状态，必须包含：
1. 原始目标与所有硬性约束（逐条保留，不得意译）
2. 已完成的操作及其结果（含文件路径、函数名等精确标识符）
3. 尚未完成的事项与当前卡点
4. 关键决策及其理由
禁止泛化表述（如"修改了若干文件"），必须保留可执行的精确信息。

血泪教训：摘要是有损压缩，且误差会复利累积。多次 compaction 后模型会"温和地漂移"出原始需求。所以高可靠系统会在每次 compaction 后重新注入不可压缩的锚点（原始任务书 + 硬约束清单）。

② Structured Note-taking（结构化笔记）
让 Agent 把状态写到窗口之外的文件里：plan.md、progress.md、findings.md。本质是把"工作记忆"外化为"文件系统中的显式状态"，每轮只读回与当前步骤相关的部分。Claude Code 的 todo 机制与大量编码 Agent 的 plan 文件都是这个思想。

③ Sub-agent Architecture（子 Agent 架构）
主 Agent 只做规划与集成；把高 token 消耗的子任务（调研、测试、日志分析）派给拥有独立干净上下文的子 Agent，子 Agent 回传压缩后的结论。这是"隔离"策略的极致形态——2026 年初 Claude Code 的多 Agent 协作系统（主 Agent 派活、子 Agent 并行、汇总结论）即此架构的产品化。

反面提醒：Cognition（Devin 团队）在《Don’t Build Multi-Agents》中给出对立警告——若子 Agent 之间不共享完整上下文轨迹，会做出互相冲突的隐式决策。两派共识其实是同一条：上下文要么完整共享，要么彻底隔离；最忌讳的是半共享。

4.5 Just-in-time 检索 vs 预加载

长上下文时代最大的路线之争：要不要把一切都塞进窗口？

	预加载（stuff it all in）	Just-in-time（用时再取）
做法	开局把相关文档/代码全部读入	给模型"获取信息的工具"，需要时再读
优点	实现简单，无检索误差	预算省、信噪比高、可处理无限语料
缺点	Context Rot 重灾区，贵，慢	依赖模型主动检索能力，多一轮延迟
适用	短任务、语料极小	长任务、大代码库、生产系统

Anthropic 的原话级结论：人类不会把整个图书馆背进考场，而是带着借书证进考场。 对代码 Agent 而言，grep/glob/read 这类"文件系统工具"就是最好的 just-in-time 检索——它比向量检索更精确、更便宜、模型也更擅长。

认知跃迁点 #6：在足够强的模型面前，“检索系统"正在从"预构建索引"退化为"给模型一把趁手的查询工具”。RAG 没死，但它的默认形态正在迁移。

4.6 RAG 已死？不，它在进化

每逢窗口变大，就有人宣布 RAG 已死。截至 2026 年的产业答案是：RAG 与长上下文是互补而非替代，分工如下：

场景	首选	原因
单一文档深度分析（< 窗口）	长上下文直读	无检索误差，保留全文细节
海量语料（TB 级知识库）	RAG	窗口装不下，也付不起
高频更新的事实	RAG / 工具查询	重读窗口不如重查一次
需要精确字面匹配（法条、代码符号）	关键词/混合检索 + 长上下文	向量检索会漏精确匹配
多跳推理	长上下文 + 迭代检索	RULER 证明聚合是长上下文的软肋

RAG 自身的进化（面试加分项）：

• Contextual Retrieval（Anthropic，2024.09）：入库前让 LLM 给每个 chunk 生成"它在全文中的语境说明"，检索失败率下降近半——本质是把 Lost in the Middle 问题在入库侧就解决掉；
• Late Chunking、父子分块（parent-child）：小块检索、大块回传，兼顾命中精度与上下文完整；
• Agentic RAG：检索本身变成 Agent 循环——查询、评估、改查、再查，直到证据充分。

4.7 生产级上下文工程 Checklist（可直接贴进团队 wiki）

• 预算先行：为 system/tools/history/retrieval 设定 token 配额，超限有明确降级策略；
• 顺序即金钱：稳定内容前置，最大化 prompt cache 命中；每轮把"当前指令"放末尾；
• 关键信息放头尾，中间只放可牺牲的；
• 工具输出必治理：截断 + 摘要 + 落盘引用三选一，禁止原始大输出直灌；
• 阈值化 compaction：80% 预警、92% 强制折叠，锚点（目标+硬约束）每次重注；
• 矛盾检测：注入多条政策/文档时，显式要求模型标注冲突并说明取舍；
• 可观测：记录每轮上下文组成（各段 token 数、命中率、是否触发折叠），像监控 P99 一样监控它；
• 评测闭环：用自己的真实长任务建回归集（NIAH 不能代表你的业务）。

---

五、Agent 层：记忆架构的战争

本章回答：会话结束后，上下文去哪了？如何让 Agent 跨会话、跨周期地"记住"？这是 2025–2026 年 Agent 领域最激烈的战场。

5.1 为什么 Agent 是上下文问题的重灾区

普通聊天：上下文增长慢，用户随时纠偏。
Agent：上下文被自己的工具调用以指数级污染——一次 ls -R、一次完整测试输出、一次爬虫结果，就能吃掉半扇窗口；且任务越长，错误越复利。

Agent 的失败模式可以总结为一句话：它不是死于窗口不够，而是死于窗口里的垃圾太多。

5.2 MemGPT：把操作系统搬进上下文（开山之作）

MemGPT（2023.10，加州伯克利，后发展为 Letta 公司）的洞见至今仍是最优雅的：

上下文窗口 = 内存（RAM），外部存储 = 磁盘。LLM 缺的不是记忆，而是虚拟内存管理机制。

它的架构：

┌─ Main Context（内存，即窗口）────────────┐
│  · System Instructions（只读区）        │
│  · Working Context（人格/用户画像，可自编辑）│
│  · FIFO Message Queue（近期消息，可换出）  │
└──────────────┬─────────────────────────┘
        page in / page out（由模型自主调用函数完成）
┌──────────────▼─────────────────────────┐
│ External Context（磁盘）                 │
│  · Recall Storage（完整对话史，可检索）    │
│  · Archival Storage（任意资料，向量检索）  │
└────────────────────────────────────────┘

精髓在于自主性：换页不是工程师写死的规则，而是模型通过函数调用自己决定"这段对话换出磁盘"“把那条记忆调回窗口”。这是"让模型管理自己上下文"的起点，2026 年各家 Agent 的自治记忆多多少少都是它的后代。

5.3 记忆的认知科学分类（面试框架题必备）

成熟的 Agent 记忆系统普遍采用认知心理学四分法：

记忆类型	人类类比	Agent 中的载体	例子
工作记忆	当下思考的内容	当前上下文窗口	本轮对话 + 工具结果
情景记忆	亲身经历的事件	会话日志/事件流	“上周二用户让我把部署切到蓝绿发布”
语义记忆	事实与概念	向量库/知识图谱	“该客户的生产库是 PG 15”
程序性记忆	技能与习惯	技能文件/工作流模板	“代码审查检查清单 v3”

2026 年北京大学《Meta Context Engineering via Agentic Skill Evolution》等研究进一步指出：静态的技能/提示架构是 Agent 能力的天花板，让 Agent 在任务中自主进化自己的技能文件（程序性记忆的自更新），是记忆系统的下一个前沿。

5.4 主流记忆系统全景（截至 2026 年中）

系统	核心范式	一句话点评
MemGPT / Letta	OS 式虚拟内存分页	架构开山，学术优雅，有状态 Agent 服务化
Mem0	抽取-更新两阶段（ADD/UPDATE/DELETE/NOOP）	个人记忆层事实标准，轻量、易接入，带图谱变体
Zep / Graphiti	双时序知识图谱	企业级首选；能处理"事实过期"（旧事实被标记失效而非覆盖）
A-MEM	Zettelkasten 卡片盒式笔记网络	记忆自动建立链接，涌现式组织
MemoryBank	艾宾浩斯遗忘曲线衰减	让记忆"自然遗忘"，早期代表
HippoRAG	海马体启发的图检索	用 PageRank 在知识图上做多跳联想检索
MemOS（2025–）	“记忆张量”+记忆操作系统	把记忆当一等公民资源统一调度，体系化野心最大
Claude Code / OpenClaw 系	文件即真相（files as truth）	不造新数据库，就用 markdown 文件 + 文件系统工具

行业观察：2026 年出现明显分流——个人/单 Agent 记忆（Mem0 路线）、团队级共享记忆（经验跨 Agent 流通，如腾讯 TencentDB Agent Memory 方向）、以及反框架的文件流（Claude Code 的 CLAUDE.md/AGENTS.md）。没有银弹，选型问三件事：记忆的读者是谁（单 Agent/多 Agent/人）、事实会不会过期、要不要可审计。

5.5 文件即真相：CLAUDE.md 与 AGENTS.md 的崛起

2025 年下半年起，一个朴素到反直觉的范式赢了：最好的长期记忆就是版本库里的 markdown 文件。

• CLAUDE.md / AGENTS.md：放在仓库根目录的项目级上下文文件——构建命令、代码规范、踩坑记录、架构决策。Agent 每次启动自动读取，等于给每次会话注入"团队共识"；
• 优势：人类可读可审、Git 可追溯、PR 可评审、零额外基础设施；
• 2026 年大厂现状：AGENTS.md 已成跨工具事实标准（OpenAI Codex、Cursor、Claude Code 等均识别）。会写、会维护 AGENTS.md，已是 Agent 时代工程师的基本功——它本质就是"团队级的 system prompt"。

写好 AGENTS.md 的要点（浓缩版）：

# AGENTS.md 骨架
1. 项目一句话说明 + 技术栈          ← 定向
2. 构建/测试/lint 的精确命令        ← 最高价值：Agent 最容易在这里翻车
3. 代码风格硬约束（≤10 条）         ← 只写"违反会被打回"的规则
4. 目录导航（哪里放什么）            ← 替代盲目 grep
5. 已知坑与禁令（踩过的坑，带日期）   ← 团队经验沉淀

反模式警告：把 AGENTS.md 写成 3000 行的小作文——它自己就成了 Context Rot 的源头。规则文件也要做注意力预算管理。

5.6 Compaction 的工程细节（进阶）

把 4.4 的 compaction 再推进一步——生产系统要回答四个问题：

1. 何时触发？ 双阈值（软阈值提示模型主动整理，硬阈值强制折叠）+ 任务边界触发（一个子目标完成时是最佳压缩点，信息已定型）；
2. 保留什么？ 目标、约束、精确标识符（路径/ID/函数名）、未决事项。丢弃什么？工具原始输出、探索失败的过程、重复确认；
3. 如何防漂移？ 锚点重注入 + 关键事实校验（压缩后抽样比对：数字、路径、约束一条不能少）；
4. 要不要分层压缩？ 推荐两级：原始历史落盘（可回查）→ 摘要进窗口。永远保留回滚到原文的能力。

5.7 多 Agent 的上下文交接（Handoff）

多 Agent 系统的上下文设计只有两条干净的路：

• 共享轨迹派：交接时传递完整 trace，代价是预算，收益是决策一致（Cognition 主张）；
• 压缩回传派：子 Agent 独立工作，只回传结构化结论（Anthropic 研究系统实践：orchestrator-worker 模式，实测在调研类任务上效率显著优于单 Agent）；

交接协议的最小可用格式（可直接抄）：

handoff_note:
  task: 原始目标（原文）
  constraints: [硬性约束清单]
  done: [已完成事项 + 产物位置]
  open: [未决事项]
  key_decisions: [{决策, 理由}]
  artifacts: [文件路径/链接]   # 细节不进上下文，进文件系统

---

六、深水区：前沿方向与范式之问

本章面向资深读者，也是面试"谈谈你对未来的判断"类问题的弹药库。

6.1 无限上下文？循环记忆与"测试时学习"

全注意力的 n² 决定了"暴力加长"终有尽头。2024–2026 年的激进路线是把记忆从"数据"变成"参数"：

• Infini-attention（Google，2024）：在注意力里挂一块压缩记忆矩阵，流式处理无界输入；
• Titans（Google，2025）：“Learning to Memorize at Test Time”——模型在推理时把 surprising（高意外度）的信息写入短期记忆参数，遗忘由"意外度门控"决定。记忆与遗忘第一次成为可学习的对象；
• 嵌套学习（Nested Learning，2025）：把上下文视为"最内层的快速学习回路"，与慢速权重更新构成多层时间尺度的记忆谱系；
• SSM 混合架构的工程化：用近乎 O(1) 的状态承载超长历史，全注意力层只保留给需要精确检索的时刻。

判断：未来 2–3 年不会是"无限窗口"，而是分层记忆的自动编排——窗口、KV 压缩、循环状态、外部存储由系统按信息价值自动调度。上下文的边界将不再由架构写死，而由"注意力预算调度器"动态划定。

6.2 上下文即"临时权重"：ICL 的本质

一个深刻的理论视角：in-context learning（在上下文里学习）可以被理解为隐式的梯度下降——模型读你的 few-shot 示例时，其内部状态发生的变化，近似于用这些示例做了几步参数更新。

推论：

1. 上下文与微调不是两种技术，而是同一光谱的两端——快与慢的学习；
2. 这解释了为什么上下文中信息的顺序、措辞、示例选择影响巨大：它们真的在"改变模型"（虽然是暂时的）；
3. 也为 6.1 的测试时学习提供了理论连续性。

6.3 Context OS：终局猜想

把全文收拢成一个图景——上下文正在演化为一种操作系统：

应用（Agent 任务）
   ↓ 申请 / 归还
上下文调度器（预算分配、压缩时机、缓存命中）
   ↓
记忆层级：寄存器=当前 token｜缓存=KV Cache｜
内存=上下文窗口｜磁盘=文件/向量库/图谱
   ↓
硬件：GPU 显存、带宽、n² 物理定律

操作系统用虚拟内存骗进程"你拥有无限内存"；Context OS 的终极承诺是骗 Agent"你拥有无限记忆"——而实现它的每一块拼图（分页、换入换出、缓存、压缩、隔离），我们已经在第二、四、五章全部见过了。这不是预言，这是正在发生的工程事实。

---

七、求职篇：15 道高频面试题与答题骨架

以下问题覆盖 2025–2026 年大厂 Agent/LLM 岗位的真实高频考点。每题给"答题骨架"而非全文——面试拼的是结构。

Q1：什么是上下文窗口？为什么不能无限长？
骨架：n² 注意力计算 + KV Cache 线性显存（现场算 70B 模型 128K 的 40GB 例子）+ 位置编码外推失效 + 注意力预算衰减。四角齐全即满分。

Q2：KV Cache 是什么？为什么需要？怎么省？
骨架：避免 decode 阶段重复计算历史 K/V；省法：GQA/MQA → MLA 低秩压缩 → 量化（TurboQuant 类）→ 驱逐策略（H2O/SnapKV）→ PagedAttention 防碎片。

Q3：长上下文 vs RAG，怎么选？
骨架：用 4.6 的表格回答；补一句"两者正交，生产系统几乎都是混合"；举一个你自己的决策案例。

Q4：Lost in the Middle 是什么？工程上怎么缓解？
骨架：U 型曲线 + 训练位置偏置成因 + 四条对策（3.2）。进阶：提到 PAM-QA 类"位置无关训练"研究。

Q5：什么是 Context Rot？你的系统如何治理？
骨架：无关/矛盾信息导致性能退化（Chroma 报告）→ 治理：工具输出截断、阈值化 compaction、子 Agent 隔离、可观测上下文构成。有踩坑故事最佳。

Q6：RoPE 如何外推到更长上下文？
骨架：RoPE 的相对位置旋转 → 超出训练长度角度失真 → PI/NTK/YaRN 思路递进 → 必须配合长文继续预训练与评测验证。

Q7：滑动窗口注意力与全局注意力如何取舍？
骨架：成本 O(n·W) vs O(n²)；长程依赖靠层间堆叠间接传递；混合方案（少量全局层/token）；举例 Mistral、Longformer。

Q8：MLA 的原理与收益？
骨架：KV 低秩压缩进隐向量、推理时解压；KV Cache 降一个量级；代价是训练/解压复杂度；对长上下文服务成本的意义。

Q9：Prompt Caching 的原理与使用约束？
骨架：前缀 KV 复用 → 前缀必须逐字节一致 → "稳定前置"组装顺序 → 商务折扣量级 → TTL 与命中率监控。

Q10：NIAH 和 RULER 的区别？你信哪个？
骨架：单针字面检索 vs 13 类复合任务（含聚合/变量追踪）；RULER 揭示有效长度缩水；再补 MRCR/NoLiMa 说明"检索≠推理"。答"都不如业务自建评测集"是点睛之笔。

Q11：MemGPT 的核心思想？
骨架：窗口=RAM、外存=磁盘、模型自主 page in/out；main context 三分区；意义：第一个让模型自己管理上下文的系统。

Q12：设计题——为一个客服 Agent 设计记忆系统。
骨架：按四分法拆（工作/情景/语义/程序）→ 存储选型（向量库+图谱+文件）→ 写入时机（会话结束抽取、更新冲突用时序失效而非覆盖）→ 召回（按意图检索注入）→ 评估与合规（可审计、可删除）。有结构比有名词重要十倍。

Q13：Agent 跑 20 轮后变笨，如何排查？
骨架：先拉上下文构成快照（各段 token 占比）→ 查工具输出是否灌水 → 查关键指令是否落入中段 → 查是否发生矛盾注入 → 依次用截断/重注入/compaction/隔离验证。这是考察真实经验的题。

Q14：何时做 compaction？摘要丢了关键信息怎么办？
骨架：双阈值+任务边界触发；强制保留清单（见 4.4 模板）；锚点重注入+抽样校验；两级压缩保留原文可回滚。

Q15：谈谈你对"上下文工程未来"的看法。（开放题）
骨架：从预算分配（今天）→ 自动化调度（Context OS）→ 测试时学习（记忆进参数）；引用 Titans/MemOS 方向；落回"信息价值 × 注意力权重"这个不变量。观点可以大胆，逻辑必须闭环。

---

八、大厂日常篇：今天就用得上的实践清单

8.1 用好编码 Agent（Claude Code / Cursor / Codex 类）

1. 维护好 AGENTS.md/CLAUDE.md（模板见 5.5），每季度清理过期条目——它既是 Agent 的记忆，也是团队的文档；
2. 大任务先 plan 后干：让 Agent 先输出 plan 文件并让你确认，避免中途偏航烧光上下文；
3. 上下文过半就主动整理：用内置 compact 指令，或手动要求"总结进度、列出未完成项"再继续；
4. 一个会话只干一件事：跨任务开新会话 + 把结论写进文件，比在一个巨长会话里切换便宜且可靠；
5. 拒绝让 Agent 读全量日志：先 grep/筛选，只喂相关片段——你替 Agent 做的每次注意力预算节省，都会变成它的准确率。

8.2 做 Agent 应用开发

1. 上线前先做上下文审计：把生产流量抽样，打印每条请求的上下文构成，80% 的问题肉眼可见；
2. 把 4.7 的 Checklist 纳入代码评审；
3. 建自己的长上下文回归评测集（20–50 条真实业务长任务），每次换模型/改 prompt 跑一遍——这是 2026 年 Agent 团队的标准动作（对应 Anthropic 强调的 evals 文化）；
4. 成本看板拆到上下文维度：cache 命中率、平均输入 token、compaction 触发率，三项指标足以定位 90% 的成本异常。

8.3 团队协作

• 上下文即文档：写给 Agent 的上下文文件，就是写给人的团队规范。推动 AGENTS.md 进代码仓库、进 PR 评审，是低成本高回报的团队升级；
• 经验沉淀闭环：每次 Agent 踩坑 → 一条规则写进记忆文件 → 全团队受益。这就是"程序性记忆"的团队版。

---

九、误区纠偏：9 条快问快答

1. “窗口 1M，我就能塞 1M 的资料。” —— 不能。有效注意力远小于窗口，且成本随输入线性、延迟随输入平方（prefill）。
2. “上下文越长，答案越全。” —— 无关内容反而降低准确率（Context Rot）。
3. “RAG 过时了。” —— 语料超过窗口、更新频繁、需要审计溯源时，RAG 仍是唯一解；两者是互补。
4. “摘要一下历史就行了。” —— 摘要是有损且误差复利的，没有锚点重注入的 compaction 是漂移的开始。
5. “记忆系统 = 向量数据库。” —— 向量库只是语义记忆的一种载体；时序失效、图谱关系、技能文件都是记忆。
6. “多 Agent 一定能解决上下文不够。” —— 半共享上下文的多 Agent 会制造互相矛盾的决策；要么全共享，要么彻底隔离。
7. “Prompt Caching 是厂商的营销功能。” —— 它是量级级别的成本杠杆，也是上下文组装顺序的设计约束。
8. “NIAH 100% 通过 = 长上下文很强。” —— NIAH 只测最简单的字面检索；看 RULER/MRCR，更要看自建评测。
9. “上下文工程就是高级 Prompt。” —— Prompt 是上下文的子集；上下文工程是信息架构 + 资源调度 + 系统可观测的综合学科。

---

十、结语：一次认知跃迁的完成

回头看全文那条主线——

上下文不是聊天框的长度，而是 LLM 的全部世界、最稀缺的资源、以及正在成形的操作系统。

• 在物理层，它是 KV Cache 的显存、n² 的算力、位置编码的角度；
• 在能力层，它是一条 U 型曲线、一份会腐烂的预算、一组永远偏紧的评测；
• 在应用层，它是 Write/Select/Compress/Isolate 四个动词，是头尾黄金位与缓存命中率的排序学；
• 在Agent 层，它是 MemGPT 的虚拟内存、AGENTS.md 的团队契约、compaction 的有损压缩艺术；
• 在未来，它是 Titans 式的测试时学习，是 Context OS 对"无限记忆"的温柔欺骗。

当别人还在争论"哪个模型窗口更长"时，你已经知道：窗口只是预算的上限，如何使用预算才是分水岭。 这个认知，足以让你在任何一场面试、任何一次架构评审、任何一个 Agent 事故复盘中，领先一个身位。

上下文即一切。而你现在，真正看见了它。

---

附录 A：长上下文技术时间线（2017–2026）

年份	里程碑
2017	Transformer 发布（512 token）
2020	GPT-3（2K），few-shot 学习
2023.03–07	GPT-4 32K / Claude 2 100K；Lost in the Middle 论文；RoPE 外推（PI/NTK/YaRN）密集涌现
2023.10–11	MemGPT 发布；NIAH 评测走红
2024.02–04	Gemini 1.5 Pro 1M–2M；RULER 发布；LongBench 普及
2024.08–09	Prompt Caching（Anthropic）；Contextual Retrieval；PagedAttention 生态成熟
2024.10	MRCR：长上下文评测进入"推理"时代
2025	稀疏注意力工程化（NSA/DSA/MoBA）；Karpathy 提出 Context Engineering；Anthropic《Effective context engineering for AI agents》；Mem0/Zep(Graphiti)/LangMem 混战；AGENTS.md 约定形成；NoLiMa 揭示无针场景退化
2026	Claude Opus/Sonnet 4.6 百万 token GA；GPT-5.x / Gemini 3.x 长上下文阶梯计价；TurboQuant（KV 压缩 6 倍+）；DeepSeek V4；上下文工程成为岗位核心技能，记忆系统向团队级共享与技能自进化演进

附录 B：术语表（Glossary）

术语	定义
Context Window	模型单次推理可接受的最大 token 数
KV Cache	缓存历史 token 的 Key/Value 向量，避免重复计算
Prefill / Decode	输入批处理阶段（算力瓶颈）/ 逐 token 生成阶段（带宽瓶颈）
TTFT	Time To First Token，首 token 延迟
Prompt Caching	复用相同前缀的 KV Cache 以省时省钱
RoPE / YaRN	旋转位置编码 / 其长度外推方案
GQA / MLA	分组共享 KV / 隐向量低秩压缩 KV
稀疏注意力	只计算部分 token 对的注意力（滑窗/动态选择）
NIAH / RULER / MRCR	长上下文三代代表性评测
Lost in the Middle	中段信息利用率低的 U 型现象
Context Rot	无关/矛盾上下文导致的性能退化
Context Engineering	在有限窗口内组织、注入、压缩、隔离信息的工程学科
Compaction	对会话历史的摘要折叠
Just-in-time Retrieval	用时再取的按需检索（对应预加载）
Agentic Memory	Agent 的跨会话持久记忆系统（工作/情景/语义/程序四类）

附录 C：核心参考资料

1. Vaswani et al., Attention Is All You Need, 2017
2. Liu et al., Lost in the Middle: How Language Models Use Long Contexts, 2023（arXiv:2307.03172）
3. Hsieh et al., RULER: What’s the Real Context Size of Your Long-Context Language Models?, NVIDIA, 2024
4. Packer et al., MemGPT: Towards LLMs as Operating Systems, 2023
5. Anthropic Engineering, Effective context engineering for AI agents, 2025.09
6. Anthropic Engineering, Introducing Contextual Retrieval, 2024.09
7. LangChain, Context Engineering for Agents, 2025
8. Chroma Research, Context Rot: How Increasing Input Tokens Impacts LLM Performance, 2025
9. Google Research, TurboQuant, 2026.03
10. Google DeepMind, Titans: Learning to Memorize at Test Time, 2025
11. Kwon et al., Efficient Memory Management for LLM Serving with PagedAttention (vLLM), 2023
12. DeepSeek 技术报告系列（MLA / DSA），2024–2025

---

本文信息截止 2026-08-17。模型窗口、价格与产品形态变化较快，引用具体数字时请以官方文档复核。欢迎转载，转载请注明出处。

---