▱

上下文窗口实验

入门8 分钟

看见 LLM 的上下文窗口如何被逐渐占满，并比较删除、摘要、RAG 与 Memory 四种策略分别解决什么问题、牺牲什么信息。

一句话理解

上下文窗口就是模型这一次生成时能看到的有限工作空间；System Prompt、对话历史、检索文档和工具结果都在争夺同一份预算。

上下文占用191,250 / 200,000 tokens

System 12% · 对话 42% · 文档 28% · 工具结果 12% · Memory 6%

选择一种策略

处理前191,250 / 200,000

风险：几乎没有空间留给新的对话和工具结果。

→

处理后112,430 / 200,000

压缩或移除 78,820 个 Token，剩余 87,570 个 Token 空间。容量释放更多，但摘要会牺牲细节。

上下文工程不是单纯把内容塞得更少，而是在有限预算里保留真正会影响下一次模型决策的信息，同时控制成本、延迟与信息损失。

关键结论

上下文是有限资源指令、历史、文档和工具结果都会竞争同一个工作预算。

摘要用细节换容量它能释放空间，但被压缩掉的细节之后可能变得重要。

RAG 把知识改成按需获取外部文档不必始终占据活动上下文，只在当前任务需要时检索进来。

Memory 不等于 ContextMemory 负责持久化；真正进入模型当前输入的内容才属于活动上下文。

动手想一想

明确哪些信息应该始终留在 Prompt，哪些可以摘要，哪些交给 RAG，哪些适合放进长期 Memory。不要只追求 Token 数最少，要说明丢失信息的风险。

概念说明

什么是 LLM 的上下文窗口？

上下文窗口是模型在一次生成过程中能够处理的有限输入空间。System 指令、用户与助手消息、检索片段、工具结果以及其他被拼进请求的内容，都会占用这份预算。它更像工作台，而不是无限容量的知识库。

应用必须决定哪些内容删除、哪些压缩、哪些以后再检索、哪些持久化到别处。关键不是“旧内容一律删掉”，而是判断哪些信息会影响模型接下来的决策。如果删掉的是任务约束或关键证据，即使 Token 使用量变漂亮，答案也可能变差。

RAG 通常在当前任务需要时检索相关外部信息；Memory 更强调跨轮次或跨会话保存事实、偏好或历史状态。两者都可以在某个时刻向模型提供内容，但都不等于上下文窗口本身。Context 是当前工作输入，RAG 和 Memory 是供给 Context 的不同机制。

好的上下文设计同时影响相关性、可靠性、Token 成本与响应延迟。更多上下文并不自动意味着更好的上下文；真正的工程问题，是让有限预算优先承载当前决策最需要的信息。

Context 和 Memory 是一回事吗？

不是。Context 是当前一次生成看到的工作输入；Memory 是一种持久化策略，它保存的信息以后可以再被取出并放进 Context。

RAG 能把模型的 Context Window 变大吗？

不能。RAG 只是帮助你从外部知识中选择更相关的内容，再把这些内容放进现有的上下文预算。

旧消息是不是都应该做摘要？

不是。摘要会用细节换空间。如果后来任务依赖某个被摘要掉的事实，过度压缩反而会降低可靠性。

这里的 200,000 Token 是某个模型的规格吗？

不是。这是为了教学而固定的模拟预算，用来稳定展示容量、信息保留和策略之间的权衡。

AhaFrame 学习说明 · 内容复核 2026-08-13. 实验使用固定的教学模拟 Token 预算，让容量与信息损失的权衡可以重复观察；它不是任何模型供应商的规格声明。

现在，你已经能判断上下文该留什么、舍什么。

下一步：看看 Agent 如何在一次任务里反复行动、观察并决定是否继续。