在AI辅助编程的领域里Context就是一切。它是模型思考的养料，也是限制模型发挥的枷锁。每一个使用过Claude IDE或类似工具的开发者，大概dou经历过那种令人抓狂的时刻：对话稍微长一点，模型就开始“遗忘”刚才的代码，或者直接报错“Prompt Too Long”。

但你是否想过在那些kan似流畅的交互背后系统是如何在有限的“大脑容量”里塞进成千上万行代码、文档历史以及即时指令的？2026年1月的那次核心源码泄露，让我们有机会一窥Anthropic自研Agent的Context管理核心逻辑。这不仅仅是一段代码，geng是一场关于空间、记忆与效率的精密博弈。

今天我们就抛开那些枯燥的官方文档，直接潜入源码深处，kankanClaude Code是如何像一位经验丰富的管家，打理那个总是塞满杂物的“背包”的。

一、 背包的容量：不仅仅是200k那么简单

我们要打破一个误区：你以为模型有20万Token的窗口，你就Neng全用上吗？错。

在源码中，Context窗口的计算逻辑非常现实。它就像是你去坐飞机，虽然飞机Neng装200吨货，但你必须给机组人员、燃油和应急设备预留位置。Claude Code也是一样，它必须为“压缩工具”本身预留空间。

让我们kan一段核心的计算逻辑：

// 默认上下文窗口设为 200k
export const MODEL_CONTEXT_WINDOW_DEFAULT = 200_000
// 针对  或特性开启的模型使用百万级上下文
// Ru果模型名字里带 ，背包容量直接升级到 100万 Tokens
export function has1mContext: boolean {
  return /\/i.test
}
// 必须预留的 “应急空间”
// 系统要从背包里提前划走 2万 Tokens 的 “应急空间”，
// 专门留给 “Summary API”。
const MAX_OUTPUT_TOKENS_FOR_SUMMARY = 20_000
// 你实际Neng用多少空间？
// 计算有效可用窗口：总窗口 - 为 Summary 预留的 token
export function getEffectiveContextWindowSize: number {
   // 先算预留多少：取“模型Zui大输出”和“2万”里的较小值
  const reservedTokensForSummary = Math.min(
    getMaxOutputTokensForModel,
    MAX_OUTPUT_TOKENS_FOR_SUMMARY,
  )
  // 再拿背包总容量
  let contextWindow = getContextWindowForModel
  // 支持环境变量硬覆盖
  const autoCompactWindow = process.env.CLAUDE_CODE_AUTO_COMPACT_WINDOW
  // Zui终可用空间 = 总容量 - 预留空间
  return contextWindow - reservedTokensForSummary
}

这段代码揭示了一个残酷的真相：你的实际可用空间 = 总容量 - 预留空间。系统必须死死守住这2万个Token的“应急空间”。为什么？因为当背包真的满了你需要把旧东西打包压缩时Ru果连打包工具dou伸不进去手，那整个会话就彻底死锁了。这就像你想整理一个塞满杂物的房间，结果连转身的地方dou没有，Zui后只Neng崩溃。

二、 自动整理：未雨绸缪的智慧

既然空间有限，那什么时候开始“断舍离”？hen多简单的Zuo法是等到溢出报错再处理，但Claude Code显然geng有远见。它采用了一种“未雨绸缪”的策略。

源码中的 `autoCompactIfNeeded` 函数展示了这一机制。它不会等到背包爆裂才行动，而是设定了一个缓冲界限。这就好比你在内存条还剩10%的时候就开始清理垃圾，而不是等到蓝屏。

export async function autoCompactIfNeeded(
  messages: Message,
  toolUseContext: ToolUseContext,
  cacheSafeParams: CacheSafeParams,
  querySource?: QuerySource,
  tracking?: AutoCompactTrackingState,
  snipTokensFreed?: number,
): Promise<{ wasCompacted: boolean; compactionResult?: CompactionResult }> {
    // 第一步：先查 “保险丝”
    // 熔断器：Ru果连续压缩失败 3 次直接 “拉闸断电”—— 不再尝试压缩。
    // 为什么？因为遇到了 “不可恢复的问题”，
    // 再试也是浪费 API 额度。
    if (tracking?.consecutiveFailures !== undefined &&
      tracking.consecutiveFailures>= MAX_CONSECUTIVE_AUTOCOMPACT_FAILURES) {
    return { wasCompacted: false }
  }
  const model = toolUseContext.options.mainLoopModel
  // 第二步：判断 “要不要整理”
  // 不是等背包全满了才整理，而是 提前 N 个 Token 就触发。
  // 比如背包总容量 20万 Token，用到 18万时就开始整理
  // 留足 “伸手整理” 的空间，避免真的溢出。
  const shouldCompact = await shouldAutoCompact
  if  {
    return { wasCompacted: false }
  }
  // 第三步：尝试整理，成功 / 失败分开处理
  try {
      // 尝试压缩对话
    const compactionResult = await compactConversation(
      messages,
      toolUseContext,
      cacheSafeParams,
      true, // isAutoCompact
    )
    return { wasCompacted: true, compactionResult, consecutiveFailures: 0 }
  } catch  {
      // 失败：增加失败计数
    const nextFailures =  + 1
    return { wasCompacted: false, consecutiveFailures: nextFailures }
  }
}

这里有个非常人性化的设计：熔断机制。Ru果系统尝试压缩了三次dou失败，它就会放弃。这听起来hen消极，但其实非常聪明。这就像你试图把一个巨大的沙发搬进小房间，试了三次dou卡在门口，这时候明智的Zuo法是停下来而不是继续把门框撞坏。系统判定遇到了“不可压缩”的硬骨头，再试也是烧钱，不如直接报错让用户处理。

三、 状态重启点补偿：别把“正在用的东西”扔了

这是整个Context管理中Zui精彩、也Zui考验工程细节的部分。

想象一下你在整理书桌。你把旧文件扔进了碎纸机，但Ru果不小心把你正在写的那份报告的手稿也扔进去了那工作就彻底断了。Claude Code面临的风险也是一样：在压缩历史对话时如何保证“当前正在使用的文件、工具和计划”不被误伤或丢失？

源码通过一套“先精简脱水，再精准补回”的组合拳解决了这个问题。我们称之为状态重启点补偿。

// ===== 保存状态重组补偿区 =====
// 1. 补回正在kan的文件：把刚才通过 FileReadTool 查kan、还没丢缓存的文件重新加回来。
const fileAttachments = createPostCompactFileAttachments
// 2. 补回正在Zuo的计划 / 技Neng：把之前进行中的 Plan、Skill重新加回来。
const planAttachment = createPlanAttachmentIfNeeded
const skillAttachment = createSkillAttachmentIfNeeded
// 3. 把被删掉的 Deferred Delta 工具协议重新发给模型。
for ) {
  postCompactFileAttachments.push)
}

这段代码的逻辑非常清晰：压缩完成后系统会立即检查“当前状态”。它会把刚才Agent正在阅读的文件内容、正在执行的Plan以及激活的Skill重新注入到新的上下文中。

这就像是给Agent装了一个“短期记忆外挂”。虽然它的长期记忆被压缩成了摘要，但它的“工作记忆”被完整保留了下来。Zui终，压缩后的上下文结构变成了这样：

+ + + + 。

这种设计保证了Agent在“断片”后醒来第一眼kan到的还是刚才没干完的活，而不是一脸茫然。

四、 PTL防御：剥洋葱式的Zui后防线

Ru果前面的“脱水”和“整理”dou失败了比如遇到了一个超级巨大的文件，或者模型突然抽风，导致Summary API报错“Prompt Too Long”，这时候该怎么办？

Claude Code准备了一根救命稻草：PTL防御。这是一种简单粗暴但极其有效的“剥洋葱”策略。

// 像 “剥洋葱” 一样，一次剥掉 10% 的Zui旧内容，重试
// 类比：工作台实在太满，连 “脱水” 后dou放不下 —— 就先把Zui旧的一摞文件移走。
// 特点：虽然 “有损”，但Neng把 “被锁死的会话” 救回来 —— 总比完全用不了强。
const truncated = ptlAttempts <= MAX_PTL_RETRIES
  ? truncateHeadForPTLRetry
  : null

当常规压缩失败时系统会启动 `truncateHeadForPTLRetry`。它的逻辑hen简单：既然塞不下那就把Zui旧的内容剥掉一部分，比如10%，然后再试一次。

这当然是有损的。你可Neng会丢失一些Zui早的对话细节。但在“彻底崩溃”和“丢失一点旧记忆”之间，系统毫不犹豫地选择了后者。这是一种务实的工程哲学：活着，比完美geng重要。

五、 成本控制：Prompt Cache的“借鸡生蛋”

除了空间管理，Claude Code在成本控制上也Zuo到了极致。我们dou知道，API调用是按Token计费的，尤其是System Prompt这种每次dou要发送的长文本，简直是吞金兽。

源码中有一个非常巧妙的设计：Forked Agent借用主对话的Prompt Cache。

// Forked Agent 借用主对话上下文的 Prompt Cache。省了大量 “贴标签” 的时间。
// 测试证明这个借用机制Neng省掉每次压缩所需的极大头部填充 Token 开销
const promptCacheSharingEnabled = getFeatureValue_CACHED_MAY_BE_STALE(
  'tengu_compact_cache_prefix',
  true,
)

压缩工作通常是在一个“分支Agent”里进行的，它和主对话并不是同一个实例。按照常规逻辑，这个分支Agent需要重新加载一遍System Prompt，这又是一笔不菲的开销。

但Anthropic的工程师们想了个办法：让分支Agent直接“借用”主对话Yi经建立好的Prompt Cache。这就好比你复印文件时直接用了上一份文件的首页模板，不用重新排版。测试数据表明，这个机制Neng省掉每次压缩时极大的头部Token开销。对于高频使用的IDE工具来说这省下的可不仅仅是几块钱，而是用户体验的流畅度。

六、 与启示

通过对Claude Code源码的剖析，我们不难发现，所谓的“智Neng”背后其实是无数个“Ru果……就……”的工程判断。

Claude Code的Context管理并非简单的“满了就删”，而是一套包含预测、保护、补偿、降级和优化的完整体系。

对于我们开发者而言，理解这些机制不仅Neng让我们geng惊叹于Anthropic的工程实力，gengNeng指导我们日常的使用习惯：

不要迷信无限窗口： 即使是100万Token的窗口，也要预留“应急空间”，系统需要呼吸的余地。

善用“工作台”概念： 在构建自己的Agent时务必区分“长期记忆”和“当前工作状态”，压缩时一定要把“当前状态”捞回来。

接受有损压缩： 在极端情况下剥掉Zui外层的洋葱是救活会话的唯一办法，不要试图保留所有细节。

在这个代码与逻辑交织的世界里Claude Code教会了我们Zui重要的一课：如何在有限的资源下Zuo出Zui聪明的取舍。

---