Claude Code源码泄露揭示Agent“延迟曝光”机制的核心价值

2026年4月，一个看似偶然的工程事故在开发者社区引发了广泛讨论。Claude Code的npm包意外携带了source map文件，导致数十万行TypeScript源码被完整还原。这一“意外开源”让业界首次有机会深入审视这款全球顶级编码Agent的内部实现机制。开发者们迅速展开了深度挖掘，很快将焦点聚集在一个此前并未引起足够重视的设计模式上——延迟曝光（Delayed Exposure）。

前缀缓存：Agent性能的核心约束

源码分析揭示了一个关键细节：Claude Code并未在初始阶段将所有工具一次性暴露给模型。工具被分为两类：一类是立即可见的，另一类则是延迟的。延迟工具不会在初始prompt中展开完整schema，而是先以“线索层“的形式存在——告知模型存在哪些工具及其来源，但不会给出完整参数定义。这种设计的精妙之处在于，它将工具的变化与前缀（prefix）稳定性的边界紧密绑定，从结构层面保障了缓存复用效率。

为何延迟曝光成为必然选择

理解延迟曝光的价值，首先需要理解前缀缓存的工作机制。Transformer架构的推理过程本质上是对token序列的逐层处理，每一层都会产生KV cache供后续token复用。DeepSeek在2024年推出的上下文硬盘缓存机制，首次将这一优化工程化：命中缓存的部分成本可降至原来的0.1倍。但其有一个严格条件——只有从第0个token开始完全一致的前缀才会命中缓存，中间有任何差异都会导致缓存失效。

Claude Code与Codex的殊途同归

在Agent场景中，前缀缓存的影响被显著放大。Agent每一轮都会将历史对话与新输入一起发送给模型，上下文单调递增，本是理想的缓存结构。但当工具列表在运行时发生变化时，前缀的一致性被破坏，缓存命中率急剧下降。更关键的是，现代Agent的工具形态已经发生根本变化：工具数量从原先的2-5个扩展到数十甚至数百个，来源涵盖本地工具、MCP工具、子agent工具等多种形态，部分工具集甚至是运行时动态生成的。

工程实践的启示

Claude Code采用分层承载的设计思路，通过delta attachment机制将工具变化整理为增量附加信息，而非每轮重写前缀。OpenAI的Codex CLI则走了另一条路径：通过tool_search将工具发现变成正式的会话事件，搜索结果写入会话历史而非前缀。从表面看两者的实现方式不同，但本质目标完全一致——将变化往后缀移动，而不是改写前缀。

如有侵权，请联系删除。