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
信息来源	过去交互、任务经验	外部文档、知识库
典型内容	用户偏好、失败经验、历史状态	论文、README、代码库、企业文档
是否动态形成	通常是	通常来自已有知识源
是否可检索	通常可以	通常需要

一句话：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。