05Context ManagementClaude Code 如何决定这一轮看什么上一篇讲 Memory System重点是哪些经验值得跨会话留下下一次还能被 Claude Code 召回。但记忆被保存下来只解决了一半问题。真正到某一轮模型调用时还要继续追问这些记忆、项目规则、工具结果、文件片段、历史消息到底哪些会进入上下文按什么顺序进入太多时怎么处理这篇就看 Context Management。这里说的上下文范围比“聊天记录”大得多。它包括系统提示、工具描述、项目规则、memory、用户当前任务、历史消息、搜索结果、文件片段、命令输出、diff、todo、summary。Claude Code 每一轮都要把这些材料重新组织成模型能看的工作现场。这篇的主线很简单哪些东西属于上下文。这些东西大概按什么顺序进入。上下文太多时先压哪里再压哪里。平时使用 Claude Code 时要不要主动处理上下文。这篇文章要拆的主线上下文到底是什么很多时候一说上下文管理脑子里先冒出来的是/compact。好像上下文管理就是窗口快满时做一次总结。从几篇 Claude Code 源码分析资料看compact 只是最后一层处理。更靠前的位置还有很多细小但重要的动作工具结果先裁剪大文件只读必要片段搜索结果先保留候选路径稳定规则放在前面动态事实放到后面大范围探索交给隔离上下文[1][2][3]。所以这篇先把问题收窄上下文管理就是决定这一轮模型应该看见哪些材料以及这些材料以什么形态出现。这里的关键词是“这一轮”。Claude Code 看起来像一直在连续思考实际每次模型调用都要重新组织输入。系统提示、工具描述、项目规则、memory、历史消息和最新工具结果会一起组成这一轮模型看到的现场。上一轮读过的文件、跑过的命令、得到的错误也只有以某种形式进入这一轮上下文才会影响下一步判断。这就解释了上下文管理为什么重要。工具系统负责把事实拿回来记忆系统负责把经验留下来上下文管理负责决定这些东西什么时候给模型看给多少放在哪里太多时怎么压。哪些东西属于上下文聊天记录之外还有很多材料Claude Code 的上下文可以先分成几类。它们的来源、稳定性和用途都不一样。上下文材料提供什么信息稳定程度基础行为规则Claude Code 的身份、协作方式、基础约束高工具描述有哪些工具、参数怎么写、结果怎么理解高项目规则项目命令、目录约定、代码风格、团队要求中高memory用户偏好、项目经验、调试经验、长期交接中高当前任务用户这一轮真正要完成什么中历史消息任务如何演变、用户补充过什么限制中工具结果搜索命中、文件片段、命令输出、测试结果低代码变更edit/write 后的 diff、已改文件、风险点低summarycompact、局部摘要、subagent 返回摘要中外部状态todo、notes、临时报告、任务状态文件中这张表里最容易被低估的是工具描述和工具结果。工具描述本身会进入模型输入。模型能否正确调用工具和工具描述、参数 schema、风险说明、输出格式有关。第 02 篇讲工具系统时已经说过工具描述会把工具从函数列表变成模型和真实项目之间的行动协议。工具结果也会快速吃掉上下文。一次搜索可能返回几十个命中一次测试可能输出几千行日志一次构建失败可能带出一串堆栈。它们都有价值但价值集中在少数位置路径、行号、错误类型、失败用例、关键堆栈、复现命令。Memory 也在这里变成“上下文来源”。第 04 篇讲的是记忆如何写入和召回这一篇只关心它进入模型时的形态它可能是一个短索引也可能是被按需读取的 topic file还可能是 compact 后重新注入的项目规则。记忆保存得再好进入上下文时仍然要接受预算和顺序管理。这些内容按什么顺序进入稳定的在前动态的在后上下文的顺序有工程含义。大致可以理解成这样基础行为规则 - 工具描述 - 项目规则 / memory 索引 - 当前任务 - 历史消息 - 工具结果 / 最新观察 - summary / compact 后的任务状态前面的内容负责稳定行为后面的内容负责当前事实。基础行为规则和工具描述通常更稳定。它们告诉模型自己在什么模式下工作、能用哪些工具、工具应该怎样调用。项目规则和 memory 也偏稳定但会随着目录、任务和会话状态变化。用户当前任务、历史消息、工具结果、命令输出、diff 则更动态通常出现在后面。这和几篇资料里提到的 stable / dynamic boundary 对得上。稳定前缀越少变化prompt caching 越容易发挥作用动态尾部越干净新增成本越可控[2][3]。这里先把 prompt caching 放在上下文结构里看。对写 agent 的人来说它传递出的设计原则更重要稳定内容尽量稳定动态事实尽量追加高噪声材料先整理再进入。如果项目规则、工具描述、系统行为每一轮都大幅变化模型看到的行为边界也会飘。反过来如果把大日志、大文件、大搜索结果都直接放到尾部模型虽然“看见”了很多东西却更难抓住下一步最有用的证据。所以上下文顺序有点像给模型分层前面告诉它“按什么规则行动”后面告诉它“这一步发生了什么”。每一轮怎样选择上下文先看目标再补证据Claude Code 做代码任务时上下文通常不会一开始就塞满整个仓库。更合理的过程是按任务逐步展开。一轮任务可以这样看先看用户目标。这一轮到底是修 bug、改文章、重构、查原因还是只做计划。再看已有约束。包括项目规则、用户刚刚强调的限制、前文已经确定的改造方向。用低成本方式缩小范围。先用目录、文件名、搜索命中、已有 todo 找候选位置。读取少量关键片段。先读相关文件、相关函数、相关段落再按需要展开更大的项目范围。工具执行后整理证据。把搜索结果、命令输出、diff、测试结果变成下一轮能用的事实。这个顺序的好处是模型每一步都有依据。在大仓库里这个选择更重要。更小的启动目录、局部规则、按需读取、生成文件排除都在减少无关材料进入主上下文。资料里提到 Claude Code 会围绕 live repo context、专用 Grep/Glob/LSP、延迟工具加载等机制做上下文治理[2][3]。正文不展开这些实现细节只取它背后的工程思路先确定边界再展开细节。工具结果进入上下文前要先变成证据工具结果是上下文膨胀最快的来源。第 02 篇讲过工具系统让 agent 能读文件、搜代码、跑命令、改文件。到了上下文管理这里要继续问这些工具结果要原样给模型看吗多数时候更好的做法是先把结果变成证据。工具结果适合进入主上下文的形态搜索结果候选路径、行号、匹配片段、命中数量文件读取有范围的片段、关键符号、必要上下文命令输出退出码、关键错误、关键 stdout/stderr、完整日志位置测试结果失败测试、断言信息、报错文件、复现命令diff修改文件、变更意图、风险点、是否触及无关内容长日志和大文件尤其适合这样处理。比如测试输出有 3000 行主上下文里真正需要的可能只有哪个测试失败。失败断言是什么。报错文件和行号。复现命令是什么。完整日志存在哪里。这样模型下一轮能继续判断也不会被无关输出淹没。Kubesimplify 的分析里提到 large tool result persistence 这类思路大结果可以持久化模型只拿 preview 或摘要[2]。这点很适合放到自己写 agent 时借鉴。这也是“先压工具结果再压会话历史”的原因。工具结果在进入主上下文前先整理好后面 compact 的压力会小很多。上下文太多时怎么办先压工具结果再压会话历史这是 Context Management 最核心的一节。上下文太多时处理顺序最好从轻到重。几篇源码分析资料里提到snip、microcompact、context collapse、autocompact等压缩策略[1][3][5]。这些术语作为资料锚点即可正文可以翻译成四层动作1. 工具压缩先把入口变窄这是最便宜的一层。搜索结果只留候选路径和片段长文件只读必要范围测试日志只留失败点命令输出只保留退出码、关键错误和完整日志位置diff 只保留变更摘要和风险。这层压缩越早做主上下文越干净。2. 外部化把长状态放到上下文外有些信息后面还要用但每轮都放进模型很浪费。比如阶段结论、长日志、临时调研报告、todo、任务状态可以放到外部文件或结构化状态里。主上下文只保留索引和下一步。需要时再重新读取。这和第 04 篇 memory 的边界也有关长期有效的经验可以沉淀为 memory当前任务交接更适合放在 todo、notes 或 compact summary 里下一篇 Planning Task State 会继续讲显式任务状态。3. 隔离把高噪声探索留在主线外大范围搜索、长文档阅读、日志分析常常是“大量输入 少量结论”的任务。这类任务适合放到子上下文或 subagent 里。主线只接收短摘要、证据路径、风险和建议下一步。第 11 篇会专门讲 subagent这里只强调它在上下文管理里的价值隔离噪声。一个好的子任务返回结果应该像这样结论是什么。证据在哪些文件或日志里。哪些方向已经排除。有什么风险。主线下一步该读哪里或改哪里。只有结论、没有证据路径的摘要会让主线很难继续验证。4. 会话压缩把聊天历史压成任务状态最后才是会话级 compact。它适合发生在两个时机上下文接近上限或者任务完成一个阶段准备进入下一阶段。compact 的目标是把原来的执行轨迹压成可继续工作的任务状态。好的 compact summary 至少要保留这些字段摘要字段为什么要保留当前目标防止任务方向漂移硬约束保留用户明确要求和禁止事项关键文件后续可以重读当前事实已修改内容知道代码或文章已经变到哪里验证结果继续判断是否完成已排除方向减少重复试错风险和未验证事项给下一轮留提醒下一步让任务能接着走Sabrina 的分析提醒了 compact 的一个风险压缩会把来源边界变模糊原来分别来自用户、工具、模型推断、文件内容的信息被压进同一段摘要后后续模型可能难以区分[4]。所以 compact 后最好做一次校准重读关键文件看当前 diff必要时重跑关键命令。摘要是交接文档文件系统和命令结果才是当前事实。平时要不要处理上下文看任务长度和噪声程度日常用 Claude Code 时不需要每个小任务都手动管理上下文。短任务通常顺其自然。比如改一个小 bug、调整一段文案、查一个函数调用Claude Code 按轮次追加工具结果就够了。过早清理反而会打断连续性。长任务就要主动一点。尤其出现这些信号时可以考虑整理上下文上下文占用很高。任务跑了很多轮读了大量文件测试和搜索输出堆了很多。模型开始重复问已经说明过的事。这说明关键约束可能被历史噪声冲淡了。模型引用旧状态。文件已经改过但它还在按旧内容推理。任务阶段发生变化。探索结束准备实现或者实现结束准备验证这时适合总结一次。用户目标变过多次。早期要求和最新要求混在一起容易让模型拿错优先级。大输出进入太多。日志、搜索结果、长文件片段已经占据大量上下文。处理方式也分轻重。轻一点的做法是重申当前目标和硬约束要求 Claude Code 用几句话总结当前状态。再重一点可以让它整理 todo、列出已改文件和未验证事项。到了阶段切换或上下文压力很高时再做 compact。这背后的原则很朴素平时按需打扫一旦任务变长、噪声变多、目标变过几次就把工作台重新收拾一下。对我写 Agent 的启发如果自己写一个 coding agent上下文管理应该是独立模块而不是藏在 prompt 拼接函数里。我会先定义一个 context budget区域放什么控制方式base context基础行为规则、工具说明尽量短稳定加载project context项目规则、memory 索引启动加载按需补细节task context当前目标、硬约束、todo每轮更新保留最新版本evidence context文件片段、搜索结果、命令输出、diff工具返回时先裁剪summary contextcompact summary、阶段结论阶段切换或上下文压力高时生成external statenotes、日志文件、任务状态可重读、可审计、可跨压缩延续然后要设计 context router。每条信息进入上下文前都问几个问题它来自哪里是用户、工具、文件、模型总结还是 memory它是否仍然新鲜下一步是否真的需要它应该放在稳定前缀还是动态尾部能否用摘要替代完整内容在哪里能重新读取更重要的是压缩设计。压缩要超出“让模型总结一下”。它应该有明确接口、触发条件和摘要结构。工具压缩应该发生在入口处search返回候选路径、行号、匹配片段和命中数量。read_file默认支持范围读取完整文件按需打开。run_command返回退出码、关键错误、关键输出和完整日志位置。edit返回修改文件、变更摘要、风险点和是否触及无关内容。会话压缩应该有固定 schema当前目标 硬约束 关键文件 已修改内容 验证结果 已排除方向 风险和未验证事项 下一步触发条件也要工程化token 压力升高。阶段切换。连续大量工具输出。同类搜索重复出现。用户目标发生明显变化。准备把任务交给子任务或恢复旧任务。压缩后还要校准重读关键文件检查当前 diff重跑关键命令。这样摘要负责交接当前事实负责纠偏。最后我会保留一个很小但很重要的原则上下文管理的目标是让 agent 每一轮都看见下一步真正需要的东西。参考资料Claude Code 源码与架构分析[1] 《驾驭工程从 Claude Code 源码到 AI 编码最佳实践》本文主要参考它关于自动压缩、snip、microcompact、collapse、autocompact等分层压缩的分析。[2] Kubesimplify - What Claude Code’s Leaked Source Teaches About AI Agents本文主要参考它关于 prompt cache break detection、large tool result persistence、工具结果持久化和上下文成本的分析。[3] Engineer’s Codex - Diving into Claude Code’s Source Code Leak本文主要参考它关于 live repo context loading、stable/dynamic prompt boundary、专用搜索工具和 context compaction 的分析。[4] Sabrina.dev - Comprehensive Analysis of Claude Code Source Leak本文主要参考它关于上下文压缩、strip 逻辑和 compact 后来源边界风险的分析。[5] Ken Huang - Claude Code Pattern 6: Context Management at Scale本文主要参考它对 context collapse、snip compaction、micro-compaction、autocompact 的分类。[6] Zane Chen - Learn From Claude Code: Context Compaction本文主要参考它关于 compact 后如何保留继续工作信息的分析。下一篇继续追的问题这一篇讲的是Claude Code 每一轮给模型看什么。但模型看见上下文以后还要把目标、计划、todo、阻塞点和完成条件组织起来。否则信息很多推进过程仍然可能乱。所以第 06 篇继续追Claude Code 如何把上下文里的信息整理成可执行、可追踪的任务状态