把 Claude Code 看成模型、工具、权限、状态不断往返的 runtime。
Claude Code Context & Interview
把上下文管理讲到面试官愿意继续追问
这是一页可交互的零基础长书：先把 Claude Code 看成受约束的执行循环， 再按压力来源拆开上下文窗口、工具结果、压缩边界、记忆、子 Agent 和面试答法。 重点不是背术语，而是讲清每一层到底保护什么状态。
Context workbench 200K window
system prompt CLAUDE.md user goals tool_use tool_result recent files
长任务不是“聊天越聊越长”这么简单，而是工具调用、文件内容、计划、记忆和子任务状态一起挤进同一张桌子。
本页回答一个问题：Claude Code 如何在长任务里保持“当前目标、工具证据、项目规则和恢复状态”不断线。 读完后，你应该能解释五层压缩各自的触发点、保留内容、损失边界和面试表达方式。
区分轻量裁剪、读时投影和 Auto-Compact 全量重写。
长期规则、当前摘要、附件恢复和子 agent 隔离不能混成一类。
不要只背机制名，要说触发条件、保留内容、失败恢复和取舍。
0. Mental Model
先把 Claude Code 看成一个“受约束的执行循环”
初学者容易把 Claude Code 理解成“会写代码的聊天框”。这个理解太浅。 聊天框只负责回答；Copilot 主要负责补全；Agent 则会在一个循环里反复 感知环境、决定下一步、调用工具、接收结果，再决定是否继续。
这就是为什么上下文管理会成为核心面试点：Agent 的每一次行动都会制造新的上下文。 它读过的文件、跑过的命令、失败过的测试、用户临时加的限制、后台子任务的进度， 都会影响下一步是否正确。
用户目标
组装上下文
模型返回 tool_use 或 end_turn
执行工具并写回结果
继续或结束
面试切入点：
Claude Code 的重点不是某一个神奇 prompt，而是把模型、工具、权限、记忆、
压缩、计划和子 agent 都放进同一个可审查的运行时。
1. Context Window
上下文窗口为什么会爆
大模型没有像人一样的持久记忆。每一次调用模型，本质都是把 system prompt、 历史消息、当前问题、工具定义、工具结果等内容重新塞进请求里。能塞进去的总量上限， 就是上下文窗口。
Agent 比普通聊天更容易爆窗口，因为它开局就有固定成本：system prompt、
工具描述、项目规则、记忆文件。真正开始工作后，每次工具调用又至少制造两类消息：
tool_use 和 tool_result。读一个大文件，真正占空间的是返回内容。
只靠长上下文也不够。窗口越长，成本和首 token 延迟越高；更麻烦的是 Lost in the Middle：模型通常更容易利用首尾信息，中间段容易被弱化。 所以上下文管理不是“省 token”，而是主动保护任务结构。
Token 预算模拟器
估算总量0 窗口占用0% 可能触发第 1 层
2. Naive Solutions
三种朴素方案为什么不够
| 方案 | 直觉 | Agent 场景里的失败点 |
|---|---|---|
| 滑动窗口 | 从最早消息开始砍 | 会误删初始目标、约束和关键工具结果 |
| 每 N 轮摘要 | 固定轮数或固定 token 做摘要 | 触发点机械，可能在关键转折处粗暴压缩 |
| 向量召回历史 | 把历史切片，按相似度召回 top-k | 忽略时序，可能拆散 tool_use 与 tool_result |
| Claude Code 分层压缩 | 先零成本瘦身，再读时投影，最后全量重写 | 把语义、状态、永久规则分通道管理 |
这里最容易被问到的是“为什么不能直接 RAG 化历史”。答案是：文档检索和 agent 历史不是一类问题。文档片段可以按相关性召回，agent 历史还必须尊重顺序、 因果、工具调用成对结构，以及用户中途改需求的全局约束。
3. Five-Layer Pyramid
Claude Code 的上下文管理是从轻到重的金字塔
第 1 层
大结果存磁盘
几乎无损 零 API 单个工具结果过大
完整结果不塞进消息，只写到本地文件；上下文里留下短预览和可回读路径。适合日志、长文件、大 grep 结果。
关键原则：
前三层尽量不调用模型；第四层不破坏原始历史；第五层才承认“旧消息链必须被重写”。
每一层都在为下一层减负。
4. Auto-Compact
最值得背的不是“摘要”，而是“全量重写 + 分通道恢复”
Auto-Compact 是兜底机制。它不按“每 10 轮”这种机械节奏触发，而是按 token 距离窗口上限的固定缓冲触发。更精确地说，要先从名义窗口里扣掉 摘要输出预留，再从有效窗口里扣掉自动压缩缓冲。文章和递归资料里反复出现的 13K token，指的是这层自动压缩缓冲。
触发后也不是简单保留最近 N 条。Claude Code 会把可压缩的历史整体重写成结构化摘要， 然后把最近文件、计划文件、活跃技能、异步任务状态等精确状态通过附件恢复。
这套取舍背后有一条清晰边界：语义信息适合摘要，运行状态不适合摘要； 永久规则不需要摘要，下一轮重新加载；system prompt 也不需要摘要，重新构建。
触发
先从名义窗口扣掉摘要输出预留，再用有效窗口减 13K 作为自动压缩触发点。手动 /compact 可在更小余量下运行。
5. Summary Prompt
好的 compact prompt 不是一句“请总结一下”
摘要器只有一个任务：保住下一轮继续干活必须依赖的信息。 所以 prompt 要先防呆：只输出文本，不调用 Read、Bash、Grep、Edit 等工具。 摘要阶段如果模型又去行动，就把“总结历史”变成了“继续做任务”，这会污染压缩结果。
结构上，它要把内容分成固定清单。最重要的两个清单是 所有用户消息 和 当前工作进度。 前者防止用户中途新增的约束丢失，后者保证下一轮不是重新探索，而是接着干。
<summary>
- Primary Request and Intent
- Key Technical Concepts
- Files and Code Sections
- Errors and fixes
- Problem Solving
- All user messages
- Pending Tasks
- Current Work
- Optional Next Step
</summary>
可迁移模板：
不要只要求“简短”。要要求摘要列出原始意图、关键文件、错误和修复、用户每次改口、
未完成事项、当前最细颗粒度进度，以及唯一下一步。
不能用满
保证 compact 自己有输出空间
真正参与触发计算
自动 compact 的触发线
用户主动压缩可更贴近上限
避免 prompt_too_long 类事故烧 API
6. Memory
记忆、摘要、上下文窗口是三套机制
上下文窗口是“这次 API 调用模型能看见什么”。摘要是“长会话快撑不住时，把当前历史改写成更小的状态”。 记忆则是“跨会话或跨项目长期存在的规则和偏好”。把三者混在一起，是很多 agent 项目的根本问题。
例如 CLAUDE.md 这种项目记忆不需要塞进摘要。压缩后可以清空用户上下文缓存，让下一轮重新加载它。 这叫分通道：永久规则走 memory 通道，当前工作走 summary 通道，最近文件走 attachment 通道。
记忆类型速查
企业/组织规则 IT 或 DevOps 管理
所有人都必须遵守的安全、合规、代码规范
项目记忆 CLAUDE.md 仓库根目录
团队共享的架构、命令、约束、常见坑
用户记忆 个人目录
个人偏好、常用工具、跨项目工作习惯
会话摘要 当前对话内
只服务这次长任务的压缩后接续状态
计划文件 / Skills 项目文件或技能包
把复杂任务的计划、验收、流程和专用规则落盘
7. Multi-Agent
多 Agent 不是“多叫几个模型”，而是上下文隔离策略
一个 agent 既调研、又实现、又评审，最先爆的通常不是智力，而是上下文和职责。 多 Agent 的价值是把任务切成干净的上下文，把权限切成合适的工具箱，把结果通过消息机制交回主线。
面试要讲清三件事：工具隔离、上下文隔离、消息通信。工具隔离避免子 agent 无限递归或抢用户对话权； 上下文隔离要逐字段判断克隆、禁写还是保留通路；消息通信要异步，父子之间不要互相同步阻塞。
常规 Subagent
主 agent 派一个专门角色去做子任务。子 agent 有独立上下文和工具池，完成后把结果交回主 agent。
Fork Subagent
让子 agent 复用父 agent 的缓存安全前缀，适合完整继承上下文、只分叉试一条轻量路线的场景。
Coordinator 模式
主 agent 只做拆分、派工、收结果和合成，worker 并行执行。关键是协调者必须理解结果，不能只转发。
8. Interview
面试回答要从“现象”讲到“工程边界”
30 秒版
Claude Code 不靠简单滑动窗口，而是分层管理上下文：能不压就不压， 先裁剪大结果和旧工具输出，再读时投影，最后用 Auto-Compact 全量重写历史， 并通过文件、技能、任务状态附件恢复关键运行状态。
2 分钟版
先讲上下文为什么爆，再讲三种朴素方案的问题，然后展开五层金字塔。 对 Auto-Compact 重点说触发阈值、全量重写、9 项摘要 prompt、附件恢复、 circuit breaker、递归守卫和续跑提示。
追问版
如果面试官追问多 Agent，就从工具权限、字段级上下文隔离、pending message、 XML-like notification、Fork 缓存复用和 Coordinator 合成责任继续展开。
Claude Code 的上下文窗口怎么管理？
先说观点：不是简单滑动窗口，也不是固定轮数摘要，而是五层从轻到重的压缩体系。大结果存磁盘、Snip、Micro-Compact、Context Collapse 先尽量零成本减压，最后才由 Auto-Compact 做全量重写和附件恢复。
Auto-Compact 什么时候触发？
核心公式是有效上下文窗口减去固定缓冲。文章中提到的缓冲是 13K token，目的不是按比例省空间，而是给摘要任务和后续输出留出可预测余量。
压缩时到底保什么？
语义信息进摘要，状态信息走附件，永久规则下一轮重新加载，系统 prompt 重新构建。最近文件、异步任务、计划和技能都不应该只靠摘要保留。
为什么向量召回不能直接替代上下文管理？
Agent 历史强依赖顺序和成对工具消息。向量召回只按相似度选片段，可能漏掉低相似但高约束的信息，也可能拆散 tool_use 和 tool_result。
多 Agent 的核心风险是什么？
隔离和通信。工具权限要按 agent 类型过滤；上下文状态要按字段决定克隆、禁写或保留通路；父子之间要走消息队列和通知，而不是同步函数调用。
为什么代码检索优先 Grep / Glob / Read？
代码检索常常需要精确名字、最新文件和可审计路径。Grep/Glob/Read 让模型一轮一轮决定搜什么、读哪里；RAG 更适合稳定语义知识库，不适合替代实时仓库里的精确代码定位。
Auto-Compact 的几个数字怎么讲？
先扣摘要输出预留，再计算自动触发线。常见讲法是 20K 给摘要输出上限，13K 给自动压缩缓冲，3K 是手动 compact 更紧的安全余量，连续失败还要熔断。
9. Visual Atlas
原链接图片不是装饰，而是面试答案的骨架
我重新抽取了可访问转载页的正文图片，排除了广告、作者头像、页脚二维码和推荐位缩略图。 可复核到的正文图包括：Claude Code 源码解析 19 张，多 Agent 实现机制 32 张。 这些图大多不是为了好看，而是在表达架构边界：循环、缓存、压缩、隔离、通信、并发。
网页里没有直接复制这些第三方图片，而是把图意重新整理成可交互组件、对照卡和流程板。 这样读者能记住“为什么这么设计”，而不是只看一张图的布局。
19 源码解析正文图
32 多 Agent 正文图
51 可复核正文图意
原图把 ChatBot、Copilot、Agent 和 Claude Code 主循环分开。网页已重画成“用户目标 → 组装上下文 → tool_use/end_turn → 工具结果回写”的循环。
图意是从 Thought-Action-Observation 转向更薄的工具循环，再用 EnterPlanMode / ExitPlanMode 把规划做成工具能力。
静态行为准则和动态环境信息用边界隔开，目标是让可缓存前缀尽量稳定，把项目规则、MCP、记忆放到可变区。
MEMORY.md 更像入口索引；独立记忆文件按需读入，避免把长期知识一次性全塞进当前窗口。
工具结果可重复获取就能裁剪；不可重放的子 agent 输出和任务状态必须保留。五层金字塔已把这个规则变成交互按钮。
父子型、平级协作型、主从协调型的差异已整理进常规 Subagent、Fork Subagent、Coordinator 三张卡。
子 agent 不应该继承所有能力。网页补充了准入门、只读探索、字段级克隆、禁写和任务注册通路。
父到子用 pending message，子到父用通知消息；超过前台等待线后自动后台化，避免父 agent 被同步阻塞。
缓存命中要求字节级前缀一致；Fork 复用父 agent 已渲染前缀，适合轻量分叉，不和 Coordinator 模式叠加。
协调者要派工、续命、停止、合成并亲自理解结果；worker 不拿协调工具，防止递归派人失控。
上下文压力 system memory tool results files compact
多 Agent 隔离 parent allowlist subagent pending message summary only
10. Recursive Audit
递归链接补全：只收和 Claude Code 上下文工程直接相关的内容
上下文窗口精确公式
递归复核后补入：名义窗口先扣摘要输出预留，自动压缩再扣 13K 缓冲；窗口管理是零和预算，不是越长越好。
Auto-Compact 失败恢复补入熔断、PTL 重试、先清空再恢复附件、SessionStart hooks 等面试可追问点。
Grep / Glob / Read vs RAG补入代码检索的精确性、实时性、可解释性、token 经济，以及超过 3 次查询时派 Explore 子 agent。
Skills 与项目记忆补入 planning-with-files、长期记忆、MCP Builder、UI/测试技能：它们都是把规则和流程从短窗口移到可复用载体。
能力边界与选型补入 Claude Code 适合终端闭环、跨文件重构、测试修复；轻量补全或强本土化场景不一定是最优解。
官方 Subagents复核 subagent 可配置 tools、disallowedTools、permissionMode、skills、memory、mcpServers、background、worktree isolation。
已补
把正文图按图意分成 10 组，新增读图重构章节，明确没有直接热链复制第三方图片。
已补
把内链里的 Grep/RAG、Skills、能力边界、短期记忆、自动压缩、官方 Subagents 补进递归资料矩阵。
已补
把 Auto-Compact 从“窗口减 13K”修正为“名义窗口先扣摘要输出预留，再扣 13K 缓冲”。
已补
把多 Agent 的图意补到工具隔离、上下文隔离、pending message、XML-like notification、Fork 缓存和 Coordinator 递归防护。
11. Source Map
资料覆盖地图
已读取微信正文 上下文窗口管理原文
覆盖 token、三类朴素方案、五层压缩、Auto-Compact、摘要 prompt、配图图意和面试答法。
微信受限，读取转载 Claude Code 源码解析读取正文图 19 张，补齐 Agent loop、Tool-Use Loop、Plan Mode、System Prompt、记忆系统和压缩全景。
微信受限，读取转载 多 Agent 实现机制读取正文图 32 张，补齐 Subagent、Fork、Coordinator、工具隔离、上下文隔离和消息通信。
内链补全 Grep / Glob / Read 递归链接补齐为什么代码上下文优先用确定性检索、按需读取和子 agent 探索，而不是默认 RAG。
内链补全 Skills 与长期项目流程补齐 planning-with-files、Claude Mem、MCP Builder 等把流程和记忆落盘的工程意义。
递归复核 短期记忆章节复核有效窗口、工具结果预算、prompt caching、熔断器和工作记忆设计。
递归复核 自动压缩章节复核 20K 输出预留、13K 自动压缩缓冲、3K 手动压缩线、PTL 重试和附件恢复。
公开能力校验 Anthropic 官方文档校验 subagents、独立上下文、工具权限、memory、MCP、slash commands 等公开能力。
本页覆盖原文、原文图片、内部同主题链接和递归复核资料的核心内容，并把原图的“模型工作台、
三种方案、五层金字塔、Auto-Compact 流程、信息半衰期、压缩接力、多 Agent 通信”等图意改写成可交互讲解。
微信原图未热链复制，避免把第三方图片资产直接发布到本站。