一个 Agent 小白的学习笔记（上）。这篇讲的是 Context Engineering 的核心框架：为什么它最重要、五大维度怎么理解、按什么优先级下手，以及长会话怎么靠压缩和按需加载扛过几十轮。
大家好，我是一个刚入门 Agent 开发的小白。最近啃了一批关于 Context Engineering（上下文工程） 的资料，越看越觉得这是 Agent 开发里最容易被忽略、却最决定成败的一个能力。
因为内容多，我拆成上下两篇。这一篇聚焦核心框架：讲清楚五大维度、优先级、以及长会话里的压缩与按需加载。下一篇讲落地工程：提示词、RAG、记忆、缓存。
为什么说 Context Engineering 是 Agent 开发最重要的能力？
先抛一个反直觉的结论：
模型都能用同一批，工具系统也大同小异。上下文管理的好坏，直接决定了你的 Agent 在第 50 轮之后还能不能作出准确的决策。
要知道，我们无法决定模型的能力，只能决定喂给模型的上下文长什么样子。 模型再聪明，如果上下文里塞满了垃圾、缺失关键信息、或者长到爆掉，它一样会给你离谱的答案。
所以对 Agent 开发者来说，真正能掌控、能优化的，就是「上下文」这个变量。
先避开两个新手坑
- Agent 不够聪明，就想自己训练一个模型？ —— 别。Fine-Tuning / Post-training 成本极高，而大多数时候你缺的根本不是模型能力。
- 等产品稳定了用强化学习优化 Agent 行为？ —— 别重建基础模型。
一句话：先做好 Context Engineering，再谈其他。
热身：上下文窗口像网吧的电脑
上下文窗口就像网吧的电脑。你在上机时可以下载软件、办公、干很多事情；一旦下机，系统就重置了，第二天再打开这台电脑，什么都没有。
这就是为什么 Agent 需要一个记忆系统，也是理解上下文管理一切难题的起点：窗口是临时的、昂贵的，而外部的文件系统、数据库是廉价的、永久的。
核心：Context Engineering 的五大维度
上下文工程无非是解决五类问题，对应五个维度。
| 维度 | 解决什么问题 | 手段 |
|---|---|---|
| Offload（卸载） | 上下文太挤 | 把信息搬到上下文之外（文件、数据库） |
| Reduce（压缩） | 上下文太长 | 把信息压缩成更短的格式（摘要、向量化） |
| Retrieve（检索） | 需要的信息不在上下文中 | 从外部源检索相关资料（RAG、读文件） |
| Isolate（隔离） | 一个上下文装不下所有事 | 拆成多个独立上下文（Multi-Agent） |
| Cache（缓存） | 重复计算 | 复用已有的计算结果（KV Cache、Prompt Cache） |
下面逐个展开。
1️⃣ Offload（卸载）：上下文很贵，文件系统很便宜
上下文窗口是昂贵的，但文件系统是廉价的。当上下文中堆满不必要的大段信息时，把它们卸载到文件或数据库里，只在需要时取回来。下一节的「JIT 按需加载」就是卸载思路的延伸。
2️⃣ Reduce（压缩）：把长的变短
压缩有两种手段，力度从小到大：
- Compaction（紧凑化）：不改变对话结构，把循环里已经用过的老工具结果替换成占位符（比如把一段 3000 token 的旧读文件结果替换成
[old tool result cleared]），或缩短工具参数。丢信息少，回收 token 也少。 - Summarization（摘要化）：直接破坏消息结构，用一段 LLM 生成的文字摘要替换整段历史。丢的信息更多，但回收的 token 也多。
核心策略：先紧凑化，实在不行再摘要化。
3️⃣ Retrieve（检索）：把信息从外面拉进来
当需要的信息不在上下文里，就主动去检索。最典型的是 RAG（检索增强生成）：把检索到的内容直接拼进上下文，或先对内容生成摘要再拼。下一篇会完整展开 RAG 管线。
4️⃣ Isolate（隔离）：一个装不下，就拆成多个
Multi-Agent 的本质，就是把庞大的上下文拆成多个独立的小上下文，让每个 Agent 只处理自己擅长的任务。两种隔离方式：
- By communicating（消息传递）：主 Agent 给子 Agent 发消息，子 Agent 处理完返回结果，主 Agent 再整合。主 Agent 上下文里多了的只是「发出去的消息 + 返回的结果」，不知道子 Agent 的内部状态。
- By sharing context（上下文共享）：子 Agent 直接复制主 Agent 当前的上下文，基于此继续处理，处理完返回结果。主 Agent 上下文里多的只有「返回的结果」，但子 Agent 的 token 消耗会更大（复制了一整份上下文）。
两句要记牢：「不知道内部」省 token 但主 Agent 信息弱；「全盘复制」子 Agent 更聪明但贵。
5️⃣ Cache（缓存）：别重复算同样的事
- KV Cache：模型推理层，一般不受我们管控。
- Prompt Cache：API 层，开发者可控制。把固定 system prompt 标成可缓存，相同前缀直接复用，大幅省钱。下一篇讲缓存时会给代码。
- Context Collapse（上下文折叠）：与其删掉老消息，不如把它们折叠——老消息存外部存储，上下文里只留一个折叠标记。
优先级：遇到问题先动哪个维度？
资料里给了明确优先级，很有参考价值：
先 Offload（卸载）→ Cache（缓存）→ Reduce（压缩，先紧凑化、不行再摘要化）→ Isolate（隔离）→ Retrieve（检索）
意思是：先把东西搬出去、把算过的复用、把长的压短，实在不行再拆分和检索。这避免了动不动就上 RAG——很多问题根本不用检索，优化卸载和缓存就行。
进阶一：信息什么时候进入上下文？全量填充 vs JIT
- 全量预填充：不管三七二十一，把循环中得到的所有信息全填进上下文。简单粗暴，但成本高、容易塞垃圾。
- JIT（Just-in-Time）按需加载：不提前塞，等 Agent 真正需要时再填充进上下文。RAG、Agentic Search（运行时工具搜索）、Context Offloading（主动卸载 + 按需恢复）都属于这一派。
实战：按成本递增排序工具调用
让 Agent 排查 bug 时，别直接塞一大堆内容，按「成本从便宜到贵」依次调用工具：
- Glob —— 按文件名模式搜索，只返回路径，不读内容（最便宜）
- Grep —— 按文件内容模式搜索，返回命中的行（中等）
- Read —— 最后才读有问题的那个文件（最贵）
先定位，再精准读取，避免把整个项目塞进上下文。
进阶二：上下文怎么扛过 50 轮？三层压缩机制
不管 prompt 管理做得再好，Agent 跑完 50 轮后大概率会变长到爆掉。采用三层递进压缩机制，先轻后重：
- Microcompact（微压缩）：不删消息、不改结构，只把老旧的工具结果缩小。第 3 轮读了文件得到 3000 token，到第 30 轮不用了，就替换成
[old tool result content cleared]，省下这 3000 token。 - Snip（截断）：直接砍掉老消息，从历史头部删除，被删的消息永久丢失。比摘要便宜，但会丢信息。
- Auto-Compact（自动摘要）：用 LLM 生成摘要，最重的手段。
什么时候触发压缩？
触发阈值大致是 有效上下文窗口 - 13k。快到上限就开始压，别等炸了再处理。
Auto-Compact 具体怎么压？
- 剥离图片：把上下文里的图片替换成
[image]标记。 - Fork 一个子 Agent 生成摘要（不占用主上下文）。
- 生成严格 9 段结构摘要：用户意图、技术概念、文件改动、错误修复、问题解决、用户消息、待办任务、当前工作、下一步。
- 恢复关键文件：压缩后附上最近读过的 5 个文件内容。
- 替换消息：旧消息替换为「压缩边界标记 + 摘要 + 恢复的文件 + 最近对话」。
这个 9 段结构摘要很值得抄作业——它保证了压缩后核心任务信息不丢失。
小结（上篇）
这一篇我们把框架建立起来了：
- Context Engineering = 决定 Agent 第 50 轮还能不能正确决策的能力。
- 用的是五大维度：卸载、压缩、检索、隔离、缓存。
- 下手顺序：Offload → Cache → Reduce → Isolate → Retrieve。
- 长会话靠 JIT 按需加载 + 三层压缩 扛住不爆。
下一篇（下篇）讲落地工程：怎么把 system prompt 模块化并缓存、RAG 管线怎么做、记忆系统选文件还是数据库、以及三层缓存如何省钱。欢迎关注继续看。
