⚠️ 源单薄性声明 本页主要基于
2026-04-18落盘的 Claude Code 官方文档 + Boris 散点经验，仍然是 Anthropic 阵营内视角。 已讲清楚：context window 是什么、Claude Code 启动和工作阶段什么会占用上下文、compaction 怎么保留和丢弃内容。 还没讲清楚：不同厂模型的上下文管理差异、长 session 的真实成本、以及非 Claude 用户的恢复故事。
一句话
上下文 / context = AI 当前这一轮“看得见”的全部输入。
它不只是你刚打的那句话，还包括 system prompt、CLAUDE.md、历史对话、工具输出、读过的文件、被加载的 skill、MCP 工具说明等。
和相邻术语的边界
所以，本页讲的是对象本体和运行机制，不讲“怎么管得更好”。
为什么重要
上下文有上限，所以会带来两个直接后果：
后果 1：忘事
当 session 逼近上限，Claude Code 会自动 compaction，把前面的内容压成摘要。
摘要会尽量保住关键决策，但早期的细节、边界条件、长工具输出，可能被压掉。
后果 2：烧钱
上下文越大，每一轮调用要重带的输入越多。
长 session 里，真正贵的往往不是“你又问了一句”，而是“这句又把前面几十轮一起带上了”。
技术机制
1. context window 是容量，不是“记忆力”
它本质上是 token 容量，表示模型一次能处理的上下文总量。
这里要特别说明一个容易混淆的点：
本地 2026-04-18 文档并不是只写一个固定数字。model-config.md 同时出现了：
- 标准 200K context
- 特定模型/套餐可用的 1M context variant
所以，“上下文”这个概念本身是稳定的，但具体容量取决于模型和套餐，不应被简化成一个永远固定的数字。
2. Claude Code 启动时自动加载什么
来源：raw/2026-04-18/claude-code-docs/context-window.md
| 内容 | 大约 tokens | 说明 |
|---|---|---|
| System prompt | ~4,200 | Claude Code 本体行为规则 |
| Auto memory (MEMORY.md) | ~680 | 前 200 行或 25KB |
| Environment info | ~280 | cwd、平台、shell、git |
| MCP tools 名字 | ~120 | 只是名字，schema 懒加载 |
| User CLAUDE.md | 变 | ~/.claude/CLAUDE.md 全文 |
| Project CLAUDE.md | 变 | 当前 + 父目录的全部 CLAUDE.md |
| Skills registry | 变 | 每个 skill 的 name + description |
| Subagent registry | 变 | 每个 subagent 的 name + description |
| Git status | 变 | 分支、改动、最近 commit |
关键点：
CLAUDE.md是全文加载MEMORY.md只有前 200 行或 25KB- session 一开始就已经不是“空白状态”
3. Work 阶段什么会继续吃 context
来源：context-window.md + how-claude-code-works.md
- 用户 prompt：你每次新说的话
@filemention：整个文件内容；还会带上那个目录往上的CLAUDE.mdRead：读到的完整文件Grep/Glob：匹配到的行和路径Bash：命令输出，默认整段进入上下文- Skill 被触发：完整
SKILL.md被加载 - MCP 工具被调用：工具 schema + 返回结果进入上下文
- Subagent 返回：只回 summary；中间工作在独立 context 里
4. Compaction 机制
来源：context-window.md
达到自动压缩阈值后，Claude Code 会：
- 先清掉更早的工具输出
- 还不够，再总结对话
- 尽量保留用户请求和关键代码片段
- 从磁盘重新注入项目 root
CLAUDE.md
什么通常能活下来
- 项目 root
CLAUDE.md - 最近调过的 skills（有总预算）
- 用户 prompt 和 Claude 关键回答
- 当前正在运行的工具调用
什么更容易丢
- 早期 Bash 输出
- session 前半段的细节讨论
- 子目录里的嵌套
CLAUDE.md（下次再访问该目录时才重载）
最小可观测例子
例子 1：/context
输入：
/context你会看到一个彩色 grid，告诉你目前是谁在占上下文空间。
它不是优化手段本身，但它是观察上下文状态的最小入口。
例子 2：长 session 里 Bash 输出挤满上下文
一个 session 连续跑 4 小时，中间反复执行测试、打印日志、看 diff。
到后面 /context 里很可能会看到：Bash 输出占了大头。这说明不是模型“变笨了”，而是可用窗口被历史输出吃掉了。
例子 3：@file 读大文件的瞬时膨胀
你 @ 了一个 3000 行文件，Claude 不只会读这个文件，还可能一起加载该目录往上的 CLAUDE.md。
这类动作的风险不是“看不懂”，而是瞬间吃掉大量 token。
常见误解
误解 1：模型越大，记得越多
不对。
“上下文窗口大小”不是“模型能力大小”的同义词。模型强弱、effort、上下文容量，是三件不同的事。
误解 2：compact 一次就等于前面白聊了
不对。
compaction 是有损保留，不是完全清空。它的目标是保住关键结论，丢掉冗余中间过程。
误解 3：MEMORY.md 和 CLAUDE.md 一样
不对。
两者都会进上下文，但加载规则不同：MEMORY.md 有前 200 行/25KB 限制，CLAUDE.md 是全文加载。
误解 4：上下文就是聊天记录
不对。
聊天记录只是其中一层。system prompt、文件内容、工具输出、技能说明、MCP schema，都算上下文。
与其他术语的关系
[[上下文工程]]：管理本页这个“空间”的方法论。[[提示词工程]]：优化一条 prompt 的写法，不等于管理整个 session。[[subagent]]：上下文隔离器；它存在的重要原因之一就是减少主 session 膨胀。[[CLAUDE.md]]：长期稳定注入上下文的说明书层。[[skill]]：按需加载的能力包，被触发时会吃 context。[[MCP]]：工具注册和调用也会占上下文。
延伸阅读
[[上下文工程]][[Checkpointing 与 /rewind]][[subagent]]raw/2026-04-18/claude-code-docs/context-window.mdraw/2026-04-18/claude-code-docs/how-claude-code-works.md
needs_sources（明确待补）
- 非 Anthropic 视角的 context 管理经验
- 不同模型/套餐下 200K 与 1M 的体感差异
- 长 session 的真实账单与恢复案例
🎬 3 个场景（读者最可能用到的情境）
场景 1 · 长对话被 compact
HR 连续和 AI 盘点一个部门 3 小时，讨论了二十多个员工的细节。突然 AI 像”忘了”某个人的评分依据——不是模型变笨，是 session 逼近上限后触发了 compaction，早期细节被压成摘要。
场景 2 · CLAUDE.md 写太长吃 token
新人兴奋地把”团队介绍 + 架构设计 + 命名规范 + 踩坑记录”写成 8000 字 CLAUDE.md。结果每次开场光加载它就吃掉几千 token，真任务的预算被挤。
场景 3 · Bash 输出塞满窗口
散户让 AI 跑一整天量化回测，中间几十次 python backtest.py 每次都打印几百行日志。几小时后 AI 开始答非所问——/context 一看，Bash 输出占了 70%。
⚖️ 和最像的邻居比
| 术语 | 本质区别 | 适用边界 |
|---|---|---|
| 上下文 | AI 当前”看得见”的全部输入 | 谈容量、内容、机制时 |
| token 窗口 | 容量单位（几 K / 200K / 1M） | 谈”能塞多少”时 |
记忆（CLAUDE.md/MEMORY.md） | 跨 session 的持久化层 | 谈”下次还要记得”时 |
| RAM 类比 | AI 的”工作内存” | 给非技术读者打比方 |
🚫 反例（不该这么用）
反例 1 · 把上下文当”永久记忆”
“我上周已经告诉过它了，它应该记得。“结果新开一个 session，AI 一无所知。正确做法：想长期记住的，写进 CLAUDE.md 或项目文档；聊天窗口是短期工作内存，不是长期记忆。
反例 2 · 不关心 token 预算
连续 4 小时不开新 session、不 /clear、不看 /context。结果后半场每轮 API 调用都带着前几十轮历史，账单悄悄翻倍。正确做法：一件事一个 session，半小时瞄一次 /context。
❓ 常见误解
- 误解 1：“上下文窗口越大越好” → 实际：“Lost in the Middle” 等研究表明长上下文中间段容易被忽略，1M 不等于”真能用到 1M”；质量 > 容量。
- 误解 2：“上下文 = 聊天记录” → 实际：聊天只是其中一层，system prompt /
CLAUDE.md/ 文件内容 / 工具输出 / skill 正文 / MCP schema 全都算。 - 误解 3：“compact 一次就等于前面白聊了” → 实际：compaction 是有损保留——关键结论通常活下来，被压掉的是冗余中间过程。
🧬 历史坐标（最早谁提 · 本质 · 分型 · git）
最早谁提
2017 年 Vaswani 等在 “Attention Is All You Need” 里用位置编码给 Transformer 定了序列上限；2020 年 Brown 等的 GPT-3 论文（arxiv:2005.14165）把 2048 tokens 的 context window 作为一个工程指标写进公开叙事，“context window” 随之成为行业通用词。
本质（一句话 · 20 字内）
AI 一次能同时看到的 token 上限。
分型 / 演化（2-4 行主线）
- 2020 GPT-3：2K → 2023-03 GPT-4：8K/32K → 2023-11 Claude 2.1：200K → 2024 Gemini 1.5：1M+ → 2024-08 Claude Sonnet 4：1M
- 分叉一：堆容量派（Gemini / Claude 1M）— 把资料整坨塞进去
- 分叉二：检索派（RAG）— 保持小窗口 + 按需检索（2023 “Lost in the Middle” 指出超长上下文并非均匀使用）
- 分叉三：压缩派（Claude Code compaction / 显式摘要）— 在固定窗口内腾地方
代表 git / 文档
- Language Models are Few-Shot Learners (GPT-3) · Brown et al. 2020 · 把 2048 tokens 窗口写进主流叙事
- Lost in the Middle · Liu et al. 2023 · 长上下文里中间段容易被忽略的实证
- Claude 2.1 发布 · 200K 窗口 · Anthropic 2023-11 · 长上下文商用化分水岭