（Claude code 的上下文窗口内容分布）
故事的开始，要从这个图来说起，这可能是 Claude 最近分享中，非常核心的核心了，实在没忍住，就写一些吧。
这张图背后的信息量极大，背后对应着一条 AI 工程化时的主线命题：高效使用上下文窗口（当然也可以看出 Claude code 的主要核心架构）。
先从问题开始：为什么上下文空间高效利用如此重要，主流模型不是都在扩大上下文窗口吗？从64k
到128k再到最近 Claude 的 1M ，我选择最大的窗口不就好了。
为什么：要高效利用上下文窗口
如果纯依赖模型窗口去做架构设计，大概率遇到现实和 AI 的两道坎：
- 现实 Context 永远都是超出上下文窗口的：要想获得好的输出，就要提供更好更多的 context 。欲望总是无限的，无数人都想把自己全部的 context “喂”给模型。
- 大模型的“伪上下文“窗口：1M 的窗口大小，是真的吗？我想用 AI 的过程中，可能都遇到过： 明明前面我都说过了，为什么模型又忘了！ 明明前面 AI 自己都做对过，怎么到这里就错了！
在不做任何的上下文压缩的前提下，为什么 AI 看起来没那么聪明？
答案是： 注意力机制 。
上下文窗口的利用，是有损的，中间很多跟最近任务相关性低的内容，都会被模型“丢失”。
研究指出：当上下文窗口的使用超过50%以上，注意力就开始直线下降，远比我们看到的上下文窗口小的多，这是相对好解释的原理。
还有一层：上下文焦虑。
目前只看到 Claude 发表了相关研究，当模型感觉自己快要接近上下文窗口限制的时候，会更急于完成任务，而不是选择最优的方案（不确定这是否跟采用的目标奖励函数训练有关）。
高效利用上下文窗口，还有成本的考量，跟提示缓存有关系。
目前的主流模型都提供了提示缓存的机制，来避免每次请求都重新计费。
如果架构设计不合理，可能造成缓存失效，意味着每个 token 都要重新计费。
Manus 提到过一个 case：很多时候我们需要让模型获取到当前时间，比如搜索新闻、研究等领域。这个时间在上下文的位置不同，可能带来10倍以上的成本差异。
比如下面这个示例：时间是写在 system prompt 的开头
你是一个 AI 助手，当前时间是{time},你的任务是…
因为时间大多以秒级传入，那么每次请求这个 {time}大概率都会变化 ，也就是从这个变化的位置开始，后面的所有 token 都要重新计费，想象下你这段内容后，还会跟着上万 token 的对话历史（有矿的请绕道）
所以综上，上下文窗口其实非常的宝贵！要善待！
怎么用：上下文窗口
他山石：从 Claude code 最近的更新，学利用上下文窗口思路
再次点赞 Claude 的开源贡献，包含 2.1.88 的非官方“开源”
配合近期 Claude 的 Blog 以及 Claude Code 的功能更新，你会发现很多都是在围绕着上下文窗口做功课。下面举几个例子来看看：
- Skills ：可能技能可视化或者文档概念的简化，大家都理解了，对技能有了很好的认识。 但技能产生的背后逻辑，其实也是上下文窗口“逼”出来的，叫：渐进式披露（划重点，这个设计哲学值得单独开篇来讲）。
再来个问题：Skills 是怎么被 AI 阅读并使用的呢？是 SKILL.md 整个给到了 AI 吗？
其实不是，而是通过SKILL.md 中开头的一小段 YMAL 内容（大概不超过100个 token），只暴露 Skills 的名称和描述（今天 CLI 还附带了一些命令工具的路径），默认注入到上下文窗口。
在模型需要使用时，通过名称和描述，才知道有这个 Skill，然后再去 read 整个 的 SkILL.md，根据这份主指南的内容，再按需取读取 scripts 、reference 等文件的内容（这些内容也就是 Claude context window 图中的 files read）。这种渐进式披露，很好的避免了内容直接“撑爆”上下文窗口。 - 停下来想想
：现在再回头看你的 Skill 结构，是不是存在 SKILL.md 文档过长的情况，如果是，那么大概率也会浪费这宝贵的上下文空间。
- insight 功能：可能很少人用这个，但我觉着这是近期非常重要的一个功能。原理是通过分析过往的对话历史记录，给出一份洞察建议，告诉你在使用 Claude code 的过程中，哪些应该是写入 CLAUDE.md的，哪些应该是个 SKills，哪些适合变成 hooks 的触发（你不好复盘，CC 可以帮你），这也就能减少很多重复内容在上下文的存在了。
- 题外话：功能太多用不过来，Claude 估计也发现了，所以这个功能的部分能力，已经集成到了 init 的命令中，这个命令原本只是创建 CLAUDE.md 的，相比 insight 更高频，会顺带问你要不要更新 skills + hooks（瞧瞧，如何用好用户的注意力限制，在 AI 领域，仍然是个命题）
- 再题外话：这个分析洞察能力，可以被扩展到非常多场景的非结构化内容的分析，尤其是随着 AI 的介入，打破了原本结构化的数据，很多内容不再是按照预先的设计产生。（值得划重点）
- subagent：很多任务的执行，其实是可以独立的，比如在项目开始前，你需要先研究一下，那么这个研究只要输出结论，过程不是最重要的。就可以有个 explore 的 Agent 帮你做，只把最终的输出返回给主 Agent。或者每个功能之间是独立的，可以启用2-3个 subagent 分别去做。
- tool search：模型能使用工具，但工具并不是越多越好，这个问题在早期并不明显。原来的工具都是注入在上下文窗口的，随着工具的增加，占着很多的上下文窗口。很多时候，一个任务并不是全部工具都要用，也就是说有很多工具是“闲置”的（换下来的二手怎么处理）。而且工具越来越多，还干扰了模型的注意力。所以，Claude 提供了一个机制：工具搜索，当工具的 token 占用上下文超过10%的时候，就把全部工具移出上下文窗口，改为提供一个搜索工具的工具。需要使用工具的时候，由模型去搜索调用。
- 进一步：Claude 并没有满足缩减数量，还考虑了工具的内容：每个工具的调用和返回信息，标准差异很大。有时候一次调用还不行，多乱调用后，这些低质量的返回信息，如果记录到上下文窗口，也是浪费。那有什么更好的办法吗？AI 是很擅长写代码的，所以提供了一个写代码的方式来调用工具，AI 可以决定在一个执行代码文件中，单次或者多次调用1或多个工具。高效且高质量的内容才被返回给上下文，执行过程和报错等信息，都在代码执行的环境中，精彩的设计！
写到这里，我的大脑上下文空间也快满了，出现了注意力丢失和焦虑的情况，我想大概对：为什么、怎么用，把我想到的讲了出来。
以上很多拆解属于抛砖引玉，业界还有非常多精彩的架构设计。
今天的认知，也只是 opus 4.6 时代的认知，也许明天，也许后天，这些认知都会被清零。
了解 AI ，最好的时候是昨天，再次就是现在，与 AI 斗，其乐无穷呀
要我帮你把上面的内容重新整理一下，改成一版更适合其他同学阅读的文档吗？
不要！谢谢！我写的这些也不一定对
Stay hungry Stay foolish！
4
2
