上下文是有限资源
指令、历史、文档和工具结果都会竞争同一个工作预算。
上下文工程·入门·8 分钟
上下文窗口实验
看见 LLM 的上下文窗口如何被逐渐占满，并比较删除、摘要、RAG 与 Memory 四种策略分别解决什么问题、牺牲什么信息。
01
体验
先处理问题，再阅读解释。
学习路径
01
填充
加入指令与历史
02
观察
查看 Token 占用
03
管理
选择处理策略
04
比较
观察信息与容量权衡
正在加载确定性实验运行时…
02
反思
把结果整理成可以复用的判断。
关键结论
摘要用细节换容量
它能释放空间，但被压缩掉的细节之后可能变得重要。
RAG 把知识改成按需获取
外部文档不必始终占据活动上下文，只在当前任务需要时检索进来。
Memory 不等于 Context
Memory 负责持久化；真正进入模型当前输入的内容才属于活动上下文。
03
深入理解
把这次体验连接到概念、参考与迁移。
概念说明
什么是 LLM 的上下文窗口？
上下文窗口是模型在一次生成过程中能够处理的有限输入空间。System 指令、用户与助手消息、检索片段、工具结果以及其他被拼进请求的内容，都会占用这份预算。它更像工作台，而不是无限容量的知识库。
上下文太大时会发生什么？
应用必须决定哪些内容删除、哪些压缩、哪些以后再检索、哪些持久化到别处。关键不是“旧内容一律删掉”，而是判断哪些信息会影响模型接下来的决策。如果删掉的是任务约束或关键证据，即使 Token 使用量变漂亮，答案也可能变差。
RAG 和 Memory 有什么不同？
RAG 通常在当前任务需要时检索相关外部信息；Memory 更强调跨轮次或跨会话保存事实、偏好或历史状态。两者都可以在某个时刻向模型提供内容，但都不等于上下文窗口本身。Context 是当前工作输入，RAG 和 Memory 是供给 Context 的不同机制。
为什么上下文工程重要？
好的上下文设计同时影响相关性、可靠性、Token 成本与响应延迟。更多上下文并不自动意味着更好的上下文；真正的工程问题，是让有限预算优先承载当前决策最需要的信息。
常见问题
Context 和 Memory 是一回事吗？
不是。Context 是当前一次生成看到的工作输入；Memory 是一种持久化策略，它保存的信息以后可以再被取出并放进 Context。
RAG 能把模型的 Context Window 变大吗？
不能。RAG 只是帮助你从外部知识中选择更相关的内容，再把这些内容放进现有的上下文预算。
旧消息是不是都应该做摘要？
不是。摘要会用细节换空间。如果后来任务依赖某个被摘要掉的事实，过度压缩反而会降低可靠性。
这里的 200,000 Token 是某个模型的规格吗？
不是。这是为了教学而固定的模拟预算，用来稳定展示容量、信息保留和策略之间的权衡。
实验使用固定的教学模拟 Token 预算，让容量与信息损失的权衡可以重复观察；它不是任何模型供应商的规格声明。
LEARNING CONTEXT
学习连接
Context Window 变大，并不会消除信息选择策略；每个 Token 仍然在争夺注意力与预算。
未看过
Mental Model
- S02-M01有限的 Context Budget
建议补充前置
进入这起事故前，没有必须完成的已发布前置内容。
迁移这个模型
一个客服长对话超过 Working Context 预算。哪些证据应该保留、压缩、重新检索或丢弃？
04
下一步
把这个判断带到另一个问题或构建中。
动手想一想
为客服 Agent 设计上下文策略
明确哪些信息应该始终留在 Prompt，哪些可以摘要，哪些交给 RAG，哪些适合放进长期 Memory。不要只追求 Token 数最少，要说明丢失信息的风险。