Claude Code 上下文和令牌效率

Claude Code 的开销是结构性的，而非偶然。其系统提示（system prompt）依赖于模型——发送给 Sonnet 的为 27,787 个字符，而发送给 Fable 的为 10,526 个字符——并且它捆绑了大型工具模式（tool schemas，已从 99,778 个字符缩减至 82,283 个字符），这些因素共同导致首次交互的基线达到约 32,800 个令牌，远高于 OpenCode 的约 6,900 个 ^[1]。添加 MCP 服务器和 CLAUDE.md 文件后，提示前的负载上升至约 75,000 个令牌，相当于在任何代码加载前就消耗了 200k 窗口的六分之一 ^[4]。更隐蔽的代价在于缓存机制：与 OpenCode 重用字节相同的缓存前缀不同，Claude Code 每轮都推进其缓存断点，并在会话中途重写数万个缓存令牌。在一项相同的文件摘要任务中，其缓存写入量高达 OpenCode 的 54 倍（53,839 对比 1,003）^[1]。

提示前的膨胀缩小了可用预算；上下文腐化则进一步损害了你对预算的使用效率，两者叠加作用。Jake Minns 将其区分为两种类型：内在腐化（intrinsic rot）——由于模型的注意力预算固定，随着令牌堆积，信噪比下降；以及内容腐化（content rot）——来自工具调用和失败尝试中积累的过时或矛盾信息 ^[2]。这种质量下降是渐进的，并且早期就开始，而非在某个临界点突然发生：当关键信息位于上下文窗口中间时，检索准确率下降超过 30% ^[2]。实践者生动地描述了这些症状——输出质量在达到名义上限之前就已急剧下降，代理重复处理已解决的问题或重试失败的方法——社区逐渐将这种现象称为“上下文腐化”，以解释为何更大的上下文窗口并不保证更好的结果。

社区主流观点认为，这是纪律问题而非模型问题——这体现在广泛传播的“别怪 Claude，你的代理层才是问题”一文中，该文指出仅靠上下文纪律就能大致将令牌使用量减半。但最受欢迎的解决方案——使用子代理——却引发分歧。评论者 a_c 警告称，每个子代理都会重新发送相同的约 3 万个令牌的系统提示，在使用七种子代理时，可能轻易消耗 5 小时窗口的 30%，而实际工作尚未开始 ^[5]；mips_avatar 反驳称这些共享提示属于缓存读取，成本约为完整预填充的十分之一 ^[5]；wongarsu 则指出，缓慢的子代理可能将主协调器的上下文逐出缓存，导致必须以全价重新支付 ^[5]。专用上下文层展示了其真实潜力：Insforge Skills + CLI 设置将某项工作负载的令牌数从 1040 万减少到 370 万，错误从 10 个降至 0 ^[3]；社区中关于 MCP 虚拟化层的演示也声称实现了类似节省，尽管在独立复现之前，此类结果仍需保持合理怀疑。