Chapter 08–09 · Memory & Context Engineering
Memory、RAG、State、Context，看起来都在“给模型信息”，但它们不是一回事
这一份只解决一个核心问题：LLM 每次调用真正看到的 Context 到底从哪里来？ 只要把这个问题搞清楚，后面的长任务 Agent、Deep Research、Coding Agent 就会顺很多。
State现在做到哪
Current Runtime State
Memory过去发生什么
Persistent Experience
RAG外部知识有什么
External Retrieval
Context这次模型看到什么
Final Model Input
1. 四个概念先一次分清
📦
State
当前任务正在发生什么。
current steplatest error🧠
Memory
过去交互和经验中值得保留什么。
historyexperience📚
RAG
外部文档或知识库里有什么相关信息。
docsretrieval🧩
Context
这一次模型调用最终被拼进去的信息。
final inputattention budget
Memory + RAG + State + Tool Results + User Input → Context Builder → Final Context → LLM
2. Memory：不是“把聊天记录全塞进去”
真正的 Memory System 需要决定：什么值得记、怎么存、什么时候取、什么时候忘。
Memory = Write + Store + Retrieve + Update + Forget
常见 Memory 类型
📝
Working Memory
当前任务短期需要的信息，例如“现在在安装环境”。
📆
Episodic Memory
“发生过什么”，例如上次 CUDA 冲突是如何解决的。
📖
Semantic Memory
“知道什么”，例如某项目要求 Python 3.10。
常见错误：memory = all_chat_history。聊天记录只是原始材料，不等于高质量 Memory。
3. RAG：从外部知识库检索，再给模型
RAG 的本质不是“向量数据库”，而是先从外部知识里找到相关内容，再作为 Context 的一部分送给模型。
Retrieve → Augment Context → Generate
Memory vs RAG
一句话：Memory 回答“过去发生过什么”，RAG 回答“外部资料里有什么”。
4. Embedding 与相似度检索
这里只需要掌握直觉，不必深入向量数据库实现。
text → vector ∈ ℝᵈ
doc = "PyTorch requires CUDA 12.1"
query = "这个项目需要哪个 CUDA？"
doc_vec = embed(doc)
query_vec = embed(query)
similarity = cosine(query_vec, doc_vec)
cos(q, x) = (q · x) / (||q|| ||x||)
注意：Embedding 检索只是找“语义上像”的内容，不保证它一定正确、最新或足够完整。RAG 质量还取决于数据源、切分、重排、过滤和引用。
5. Context Engineering：真正决定模型这次看到什么
Prompt Engineering 关注“这句话怎么写”；Context Engineering 关注“这一次模型到底应该看到哪些信息”。
Prompt Engineering ⊂ Context Engineering
一个真实 Agent 的 Context 可能包含
系统信息
System Prompt、工具定义、规则、权限。
任务信息
User Query、Current State、Plan、最新 Observation。
外部信息
Memory、RAG Results、Tool Results、Notes。
最大误区：Context 不是越多越好。信息太多会降低信噪比、增加成本，并让模型更容易被无关内容干扰。
目标不是 More Context，而是 Right Context
6. GSSC：上下文工程的四步法
把 Context Engineering 记成四个动作即可：Gather → Select → Structure → Compress。
Gather
Conversation、Memory、RAG、Files、Tools、State。
Select
按相关性、新近性、重要性选真正需要的信息。
Structure
按 Goal / State / Evidence / Tool Result 等分区，而不是全部混成一坨。
Compress
把 500 行日志压缩成真正关键的错误、环境与影响。
一个好的结构化 Context
## Goal
复现论文 baseline
## Current State
环境已创建，当前阻塞在 flash-attn
## Relevant Memory
此前 torch 2.4 + CUDA 12.1 可正常工作
## Retrieved Evidence
README 要求 Python 3.10
## Latest Tool Result
ModuleNotFoundError: flash_attn
## Next Action
检查编译器与 CUDA 兼容性
7. Context Window ≠ Memory
Context Window
模型一次调用最多能看到多少 token。
Current Inference Capacity
Memory
系统长期保存并可以未来重新取回的信息。
Persistent Storage
正确思路：长期存很多，当前只检索少量。不要把“记得多”理解成“每次都塞进去”。
8. 映射到科研论文复现 Agent
这个案例可以把四个概念一次串起来。
State：当前已经完成环境创建，正在解决 flash-attn 编译失败。
Memory：之前某项目遇到类似 CUDA 冲突，最终通过切换 PyTorch 版本解决。
RAG：从 README、issue、论文实验部分检索 Python / CUDA / 依赖版本要求。
Context Builder：只挑本次问题相关的信息，结构化后交给 LLM。
LLM：据此决定下一步检查编译器、CUDA、torch 版本还是重装依赖。
9. 一页总结
State = 当前在做什么
Memory = 过去发生过什么
RAG = 外部知识里有什么
Context = 模型这一次看到什么
Context Engineering = 选择正确的信息给模型
Gather → Select → Structure → Compress
下一份：第 10 章——MCP / A2A / ANP。重点画清楚 `Agent ↔ Tool`、`Agent ↔ Agent`、`Agent ↔ Network` 三层协议关系，以及为什么 Tool Calling ≠ MCP。