上下文Context即一切：AI/Agent 时代「长上下文」设计与原理全景盘点
上下文即一切：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（上下文工程）。
这个判断不是情绪输出，而是三条产业事实的必然推论：
- 窗口已经"够用"了，但 Agent 依然在失忆。 截至 2026 年中，主流旗舰模型的上下文窗口已达 1M token 级别（Claude Opus/Sonnet 4.6 的百万 token 窗口于 2026 年 3 月全面 GA，GPT-5.x 系列同为 1M 级别，Gemini 系列更早进入 2M 区间）。窗口不再是瓶颈——上下文治理才是。
- "上下文工程"完成了从黑话到学科的跃迁。 2025 年 6 月 Andrej Karpathy 带火这个词；同年 9 月 Anthropic 发布工程长文《Effective context engineering for AI agents》；2026 年，它已经是字节、腾讯、阿里等大厂 Agent 岗位 JD 中的高频词。
- 成本结构逼着每个人懂上下文。 长上下文请求的 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 上同样成立。
成因（学界共识方向）：训练数据的位置偏置（重要内容常在文首/文末）、指令微调样本结构、以及注意力分布对位置的先验。
工程对策（可直接写进工作规范）：
- 关键约束、硬性规则放 system prompt（头部）；
- 最新任务指令、当前状态放消息序列尾部；
- RAG 检索结果按相关度排序时，把最相关的放最前或最后，别放中间；
- 对关键信息在头尾做策略性重复（repetition at boundaries）。
3.3 Context Rot：上下文会"腐烂"
2025 年 Chroma 发布的《Context Rot》报告对十余家主流模型做了系统测试，结论可以浓缩为一句话：
随着输入长度增长，模型性能持续退化——即使增加的内容与任务完全无关；而包含干扰、矛盾信息时，退化加速。
这就是"上下文腐烂"。它解释了所有 Agent 开发者都见过的灵异现象：任务跑到第 15 步，模型开始重复已做过的事、给出与第 3 步矛盾的结论。不是模型变笨了，是上下文被自己产生的废料淹没了。
三条腐烂机制：
- 注意力稀释：无关 token 分摊了有限的注意力预算；
- 干扰与矛盾：相互冲突的信息诱发"和稀泥"式输出甚至幻觉；
- 状态淹没：任务目标被几十屏工具输出埋在中间（恰好落在 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/进度/反思笔记（可编辑）│
│ ⑦ 当前用户输入 （最新） │
└──────────────────────────────────────────────┘
稳定性从上到下递减，变化频率从下到上递减
缓存策略：上段求命中，下段求隔离
两个被新手忽视的坑：
- 工具定义是隐形大户。 挂 30 个工具的 schema 动辄上万 token，且与任务多数无关。生产系统的标准做法是按意图动态加载工具子集。
- 工具输出是腐烂之源。 一个 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 再推进一步——生产系统要回答四个问题：
- 何时触发？ 双阈值（软阈值提示模型主动整理，硬阈值强制折叠）+ 任务边界触发（一个子目标完成时是最佳压缩点，信息已定型）；
- 保留什么？ 目标、约束、精确标识符（路径/ID/函数名）、未决事项。丢弃什么？工具原始输出、探索失败的过程、重复确认；
- 如何防漂移？ 锚点重注入 + 关键事实校验（压缩后抽样比对：数字、路径、约束一条不能少）；
- 要不要分层压缩？ 推荐两级：原始历史落盘（可回查）→ 摘要进窗口。永远保留回滚到原文的能力。
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 示例时，其内部状态发生的变化，近似于用这些示例做了几步参数更新。
推论：
- 上下文与微调不是两种技术，而是同一光谱的两端——快与慢的学习；
- 这解释了为什么上下文中信息的顺序、措辞、示例选择影响巨大：它们真的在"改变模型"（虽然是暂时的）；
- 也为 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 类）
- 维护好 AGENTS.md/CLAUDE.md（模板见 5.5），每季度清理过期条目——它既是 Agent 的记忆，也是团队的文档；
- 大任务先 plan 后干：让 Agent 先输出 plan 文件并让你确认，避免中途偏航烧光上下文；
- 上下文过半就主动整理：用内置 compact 指令，或手动要求"总结进度、列出未完成项"再继续；
- 一个会话只干一件事：跨任务开新会话 + 把结论写进文件，比在一个巨长会话里切换便宜且可靠；
- 拒绝让 Agent 读全量日志：先 grep/筛选，只喂相关片段——你替 Agent 做的每次注意力预算节省，都会变成它的准确率。
8.2 做 Agent 应用开发
- 上线前先做上下文审计：把生产流量抽样，打印每条请求的上下文构成，80% 的问题肉眼可见；
- 把 4.7 的 Checklist 纳入代码评审；
- 建自己的长上下文回归评测集（20–50 条真实业务长任务），每次换模型/改 prompt 跑一遍——这是 2026 年 Agent 团队的标准动作（对应 Anthropic 强调的 evals 文化）；
- 成本看板拆到上下文维度：cache 命中率、平均输入 token、compaction 触发率，三项指标足以定位 90% 的成本异常。
8.3 团队协作
- 上下文即文档：写给 Agent 的上下文文件，就是写给人的团队规范。推动 AGENTS.md 进代码仓库、进 PR 评审，是低成本高回报的团队升级；
- 经验沉淀闭环：每次 Agent 踩坑 → 一条规则写进记忆文件 → 全团队受益。这就是"程序性记忆"的团队版。
九、误区纠偏：9 条快问快答
- “窗口 1M，我就能塞 1M 的资料。” —— 不能。有效注意力远小于窗口，且成本随输入线性、延迟随输入平方（prefill）。
- “上下文越长，答案越全。” —— 无关内容反而降低准确率（Context Rot）。
- “RAG 过时了。” —— 语料超过窗口、更新频繁、需要审计溯源时，RAG 仍是唯一解；两者是互补。
- “摘要一下历史就行了。” —— 摘要是有损且误差复利的，没有锚点重注入的 compaction 是漂移的开始。
- “记忆系统 = 向量数据库。” —— 向量库只是语义记忆的一种载体；时序失效、图谱关系、技能文件都是记忆。
- “多 Agent 一定能解决上下文不够。” —— 半共享上下文的多 Agent 会制造互相矛盾的决策；要么全共享，要么彻底隔离。
- “Prompt Caching 是厂商的营销功能。” —— 它是量级级别的成本杠杆，也是上下文组装顺序的设计约束。
- “NIAH 100% 通过 = 长上下文很强。” —— NIAH 只测最简单的字面检索；看 RULER/MRCR，更要看自建评测。
- “上下文工程就是高级 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：核心参考资料
- Vaswani et al., Attention Is All You Need, 2017
- Liu et al., Lost in the Middle: How Language Models Use Long Contexts, 2023（arXiv:2307.03172）
- Hsieh et al., RULER: What’s the Real Context Size of Your Long-Context Language Models?, NVIDIA, 2024
- Packer et al., MemGPT: Towards LLMs as Operating Systems, 2023
- Anthropic Engineering, Effective context engineering for AI agents, 2025.09
- Anthropic Engineering, Introducing Contextual Retrieval, 2024.09
- LangChain, Context Engineering for Agents, 2025
- Chroma Research, Context Rot: How Increasing Input Tokens Impacts LLM Performance, 2025
- Google Research, TurboQuant, 2026.03
- Google DeepMind, Titans: Learning to Memorize at Test Time, 2025
- Kwon et al., Efficient Memory Management for LLM Serving with PagedAttention (vLLM), 2023
- DeepSeek 技术报告系列（MLA / DSA），2024–2025
本文信息截止 2026-08-17。模型窗口、价格与产品形态变化较快，引用具体数字时请以官方文档复核。欢迎转载，转载请注明出处。
汇聚全球AI编程工具，助力开发者即刻编程。
更多推荐
5
0- 0
已为社区贡献13条内容
所有评论(0)