一、一个被很多人忽略的问题：Agent 的成本，很多时候不是模型能力，而是“前缀”

事情的起点，其实有点戏剧性。

原本只是一个再普通不过的工作日，但开发者圈突然被一件事刷屏——
Claude Code 的源码，被“意外公开”了。

不是官方开源，也不是技术发布，而是一个很典型的工程事故：
npm 包里误带了 source map 文件。

这种文件本来只是用来调试的，但一旦放出来，就等于把压缩后的代码“反编译”回了原始实现。于是短短时间内，几十万行 TypeScript 代码被完整还原，整个工程细节几乎被摊在桌面上。

一时间TorchV的办公室里，同事们奔走相告，coding-agent和数字员工们被指派进行了深度的源码挖掘。大家纷纷对自己Focusing的方面开始了探索

说回来，这件事为什么会炸？ 因为大家第一次有机会，看到公认的全球Top级“顶级 Agent”到底是怎么做的。 很快，讨论就集中在几个非常熟悉的话题上：

• 它到底有多少工具？（答案：很多，而且很复杂）
• Agent loop 是怎么跑的？
• 多 agent 协同是怎么做的？
• 有没有什么“隐藏能力”（比如后台常驻、自动执行等）

这些都很正常，也确实很有意思。

但如果我们把这些代码多翻一会儿，会慢慢注意到一个不那么起眼、甚至一开始很容易忽略的点：

👉 工具并不是一开始就全部给模型的。

而且不仅如此，它们：

• 有一部分是“延迟”的
• 有一部分只以“线索”形式存在
• 有一部分甚至被刻意放在不同的上下文结构里

这件事初看很像是某种 prompt 技巧，甚至有点“工程细节味太重”。

但再往深一点想，就会意识到：

这很可能不是技巧，而是一个被精心设计过的结构。

更有意思的是，当我们把视角从 Claude Code 稍微拉开一点，会发现：

这并不是它一家在这么做。

同样是顶级的编码智能体Codex，在开源代码中也能找到相同的做法，被称之为： delayed exposure

这时候，一个问题就变得值得认真对待了： **为什么这些系统都在做同一件事？

原因其实不在“能力”，而在一个很多人一开始不会注意到的地方：

多轮Agent的成本和速度，很大程度由 Context 的结构决定的。

更具体一点说，是由——

👉 前缀（prefix）是否稳定决定的。

而 Claude Code 这次“意外开源”，恰好让我给大家带来一段颇有意思的分享：

延迟曝光机制，和前缀缓存(prefix cache)有什么关系？

二、prefix cache 是什么，以及它为什么会成为 Agent 的核心约束

很多人真正开始关注 prefix cache，其实是从 2024 年的一次“价格变化”开始的。 当时 DeepSeek 在 API 里上线了一个能力：上下文硬盘缓存。

官方给出的描述很直接：

• 很多请求，其实有大量重复前缀
• 这些前缀可以缓存下来
• 下次再用，不需要重新计算

更关键的是价格：

👉 命中缓存的部分，成本可以降到原来的 0.1 倍

这事之所以重要，不仅因为“便宜了”，而是因为它首次将cache的复用做到了工程化中，让这个相对隐性的知识被知晓：

模型推理，并不是每次都必须从头计算。

prefix cache，本质上在复用“已经算过的前缀”

要理解这件事，需要稍微回到一点点模型原理。

以 Transformer 为例（现在几乎所有大模型都是这个架构），推理过程大致是这样的：

• 输入被拆成一串 token
• 模型一层一层处理这些 token
• 每一层都会产生一组中间结果（KV cache）
• 后续 token 会不断依赖前面所有 token 的计算结果

换句话说：

模型在处理第 N 个 token 时，前面 N-1 个 token 的计算结果是已经存在的。

于是就有一个很自然的优化：

如果下一次请求的前缀完全一样，那这些中间结果（KV cache）其实可以直接复用。

也就是说：

• 不需要重新跑 attention
• 不需要重新算 embedding
• 直接从缓存继续往后生成

DeepSeek 做的事情，本质上就是把这套机制“工程化”了：

• 把前缀的计算结果缓存到磁盘（而不是只存在内存）
• 在分布式系统中复用这些缓存
• 自动识别请求前缀是否一致

而且它还有一个非常严格的条件：

只有从第 0 个 token 开始完全一致的前缀，才会命中缓存。

中间哪怕有一点不同：

👉 都不会命中

这件事为什么会对 Agent 产生巨大影响

在普通单轮问答里，这个机制已经很有价值了：

• 长 prompt（system prompt / few-shot）
• 重复调用
• 数据分析类任务

都可以明显降成本。 但在 Agent 里，这件事的影响是被放大的。 因为 Agent 的调用方式是这样的：

• 每一轮都会把“历史对话 + 新输入”一起发给模型
• 上下文单调递增，这是一个非常适合缓存的结构

如果一切都按理想情况发展，每一轮只是往后 append，前面的内容完全不变 那么：

👉 prefix cache 命中率会非常高
👉 推理成本接近“增量计算”

但现实情况下，模型提供商在收到消息后会这样格式化输入：

┌───────────────────────────────┐
│         System / Instructions │  ← 稳定前缀（基本不变）
├───────────────────────────────┤
│         Tool List / Schema    │  ← 稳定前缀（最容易被破坏）
├───────────────────────────────┤
│   Environment / Context Info  │  ← 通常稳定（但可能变化）
├───────────────────────────────┤
│                               │
│   ┌───────────────────────┐   │
│   │ User Message (turn 1) │   │
│   ├───────────────────────┤   │
│   │ Assistant (reasoning) │   │
│   ├───────────────────────┤   │
│   │ Tool Call + Output    │   │
│   ├───────────────────────┤   │
│   │ User Message (turn 2) │   │
│   ├───────────────────────┤   │
│   │ Assistant ...         │   │
│   └───────────────────────┘   │
│                               │
│        (持续 append)           │  ← 可增长后缀
└───────────────────────────────┘

很多系统，会在不知不觉中破坏这一点。 最典型的，就是前面提到的：

👉 前缀被改写了。

而改写前缀的“重灾区”，往往就是工具列表，这会带来一个非常实际的结果：

同一个 Agent，随着对话轮次增加，成本和延迟不断“重算”。

也正是因为这个原因，prefix cache 在 Agent 里，从一个“可选项”，变成了一个必做项：

• 你可以让上下文变长
• 但尽量不要让“前面的结构”发生变化

换句话说： DeepSeek 把这件事“显性化”了——用价格告诉你缓存有多重要；
而 Agent 系统，则必须把这件事“结构化”——从一开始就围绕缓存去设计上下文。

接下来，我们就可以回到最开始那个问题：

如果工具本身是动态的，那该怎么让它“不破坏前缀”？

答案就是——延迟曝光。

三、Claude Code 意外“开源”，让一个原本模糊的机制变清晰了

如果只停留在表层，Claude Code 做的事情其实并不新鲜：

• 有工具
• 支持 Tool Search
• 模型可以按需调用

但源码一旦被还原出来，有一件事会变得非常明显——它的重点根本不在“工具调用”，而在另一件更底层的事情：

工具是如何进入上下文的。

Claude Code 从一开始就把工具可见性，当成一个和缓存边界绑定的问题来处理。

它的基本思路可以用一句话概括：

工具不是一次性给模型，而是分阶段、分位置、分承载方式进入上下文。

首先，它在系统层面就把工具分成两类：

一类是立即可见的，模型从第一轮就可以直接调用；另一类则是延迟的，这部分工具不会在初始 prompt 里展开完整 schema。

这一步本身不复杂，但关键在于后面的处理方式。

对于这些延迟工具，Claude Code 并不是“什么都不给”，而是先给模型一个“线索层”：

• 告诉模型有哪些工具存在
• 告诉它们来自哪个来源（比如 MCP）
• 但不会给出完整参数定义

这样，模型在第一轮看到的上下文，是一个轻量且稳定的前缀，而不是一整套庞大的工具 schema。

接下来，当模型真正需要某类能力时，它才会通过 Tool Search 去拿完整定义。

这一点和很多系统类似，但 Claude Code 的关键区别在于：

👉 “拿到定义”这件事之后，这些信息会以什么形式进入上下文。

如果只是简单实现，很容易走到一种直觉方案： 将搜索到的工具重新加入工具列表

这种方式简单直接，但有一个致命问题：
前缀变了，cache 直接失效。

Claude Code 的处理方式明显更“克制”。

它没有依赖单一表达，而是根据不同路径，把“延迟工具的存在”放在不同的承载层里。

有时候，它确实会用类似上面的提示块，让模型知道有哪些工具；但在另一条路径下，这些信息会变成一种 system-reminder 风格的消息，不再是直接拼在 prompt 前部的文本。

再往后，你会看到更进一步的做法：它会把这些变化整理成一种增量结构，比如：

• 普通提示块示例：

  <available-deferred-tools>
  Read
  Edit
  Grep
  </available-deferred-tools>
  

• 系统提醒类信息示例：

  Deferred tools appear by name in <system-reminder> messages.
  

• 更稳定的增量附加信息示例：

  deferred_tools_delta:
    - tool: Read
    - tool: Edit
    - tool: Grep
  

这种形式的本质，不再是“每轮重写一段文本”，而更像是：

👉 把工具池的变化，当作一次可追加的状态更新。

进一步看源码里的开关逻辑，这件事就更清晰了。

是否使用 <available-deferred-tools> 这种前置块，并不是固定的，而是取决于类似 isDeferredToolsDeltaEnabled() 这样的路径判断：

• 如果没有启用更稳定的机制，就退回到“前置提示块”
• 如果启用了 delta attachment，就不再每轮 prepend
• 而是把变化整理成附加信息，进入会话历史

再往深一层看，还有一个更容易被忽略的点：

它在 cache 判断上，是有明确取舍的。

延迟工具的变化，本质上是“系统能力的变化”，但 Claude Code 的策略是：

👉 **这种变化不应该直接影响 prefix cache **

换句话说，它在做两件事：

• 让模型“看到工具”
• 但尽量不让“工具变化”成为 cache 的扰动源

把这些拼在一起，就可以得到一个非常清晰的结构：

它不是在解决“模型如何选工具”，而是在解决“工具系统如何不破坏前缀”。

四、再看 Codex：另一种实现，但在解决同一个问题

如果只看 Claude Code，或许以为这是 Anthropic 的一套“特殊技巧”。

但当你再去看 OpenAI Codex CLI 的实现，会发现一个很有意思的现象：

它走的是相对不同的路径，但目标几乎一样。

Codex 的切入点不是“工具怎么放”，而是：

把“工具发现”这件事，变成一次正式的会话事件。

它的做法可以简单理解成三步：

第一步，初始阶段不暴露全部工具
模型一开始只看到：

• 少量基础工具
• 一个叫 tool_search 的入口

其他工具，并不在顶层完整出现。

第二步，需要时让模型自己去搜
当模型判断需要某类能力时，它不会直接调用工具，而是：

👉 先调用 tool_search

这个动作的意义在于：

• 明确当前有哪些工具
• 拿到完整 schema
• 确认命名空间和调用方式

第三步，也是最关键的一步：

👉 搜索结果会写入会话历史

也就是说，这不是一段临时提示，而是一个正式存在的历史项：

• 有 call
• 有 output
• 有配对关系

从这一刻开始，这些工具就“存在于对话里”了。

这一步的工程价值非常大，但很容易被忽略。

因为它带来一个直接结果：

工具定义不需要反复出现在前缀里了。

后续轮次发生的事情是：

• 模型直接基于历史里的工具定义调用
• 系统通过“命名空间 + 短名”解析回真实工具
• 整个顶层工具集合保持稳定

也就是说，Codex 做了一件和 Claude Code 本质类似的事情：

👉 把变化往“后面”移动，而不是改前面

如果你把两者放在一起看，会发现一个非常清晰的共识：

路径不同，但答案是一致的：

不要让“工具全集”成为一个每轮都会变化的 prompt 前缀。

而这，也正是“延迟曝光机制”真正要解决的问题。

五、为什么“延迟曝光”会在 Agent 中变成一个几乎必选的结构

如果只看 Claude Code 或 Codex，很容易把延迟曝光理解成一种“高级优化”。

但一旦你把视角从“某个实现”切换到“Agent 系统整体演进”，就会发现：

这其实不是优化，而是规模上来之后的必然结果。

先看一个趋势变化。

早期的 Agent，工具通常是这样的：

• 数量很少（2~5 个）
• 来源固定（本地 + 少量 API）
• 生命周期稳定（基本不会变）

在这种情况下，把所有工具一次性塞进 prompt，完全没问题，甚至更简单

但现在的 Agent，工具形态已经完全变了：

• 工具数量：几十甚至上百
• 工具来源：
• 本地工具
• 平台内置工具
• MCP 工具
• 子agent工具
• 工具可见性：可能在运行过程中动态变化

尤其是 MCP 这一类能力，本质上是：

工具集合是“运行时生成”的，而不是静态配置的。

这时候，如果你还用“全量工具直接暴露”的方式，会发生什么？

第一层问题，是成本问题：

• prompt 变得很重
• 每一轮都要重新发送完整 schema
• token 消耗显著上升

但更致命的是第二层问题：

👉 prefix cache 开始频繁失效

这时候，延迟曝光就不再是“优化”，而是一个结构性解法：

• 工具不再一次性暴露
• 可见性分层（基础工具 / 延迟工具）
• 能力通过搜索或线索按需获取
• 工具定义尽量只出现一次（进入历史或稳定层）

这样做的直接结果是：

• 首轮更轻，按需加载
• 中间轮次更稳定
• prefix 更容易保持一致
• cache 命中率显著提高

换句话说：

当工具系统开始“动态化 + 大规模化”，延迟曝光几乎是唯一不会把系统拖垮的方案。

好，这一章我帮你做一次压缩 + 强化 TorchV 部分 + 收尾更有力，去掉重复表达，让节奏更干净。

六、延迟曝光真正保护的不是“工具数量”，而是“前缀不被改写”

如果把前面的分析收敛成一句话，其实就是：

延迟曝光真正保护的，不是“工具少一点”，而是“前缀稳定不被改写”。

可以把一次模型请求简单拆成两部分：

• 前缀（prefix）：instructions、工具定义、环境信息
• 后缀（suffix）：用户输入、工具调用结果、对话历史

prefix cache 的规则非常简单，也非常严格：

👉 只有前缀完全一致，缓存才会命中。

延迟曝光本质上做了一件事：

把原本会进入前缀的变化，转移到后缀或更稳定的附加层。

这其实就是把“只追加、不修改”的设计，从对话内容，扩展到了工具系统本身——也就是一种更完整的 Append-Only Prompt 模式。

这个问题在真实系统里并不抽象。

在 TorchV 的 Agent 实践中，我们遇到过一个很典型的场景：有状态的沙箱工具。

• agent 先发起连接
• 连接成功后，系统才返回一组新的可操作工具

如果直接把这些工具“刷新进前缀”，很容易出现：

• 每轮工具列表都在变化
• prefix 不再稳定
• cache 命中率迅速下降

我们的调整方式其实和前面两家的思路是收敛的：

• 初始只暴露稳定能力
• 动态工具通过“事件 / 附加信息”进入上下文
• 严格避免回写或重排前缀
• 所有变化尽量表现为 append，而不是 rewrite

这件事在 RAG 和企业知识库场景里尤为关键。

因为：

• prompt 本身很长（知识上下文 + system 约束）
• Agent 运行链路更长（检索 → 推理 → 调用 → 再检索）
• 工具来源更多且更动态

如果前缀不稳定：

👉 每一步几乎都在“重新算一遍”

而一旦前缀稳定：

👉 系统会明显进入“增量执行”的状态（速度和成本都会下来）

也正因此，在我们新的 Agent 产品线 Workstation 里，这一点被明确提炼成一个设计原则：

能力可以动态变化，但前缀必须尽量静态。

回头看 Claude Code 和 Codex，其实路径不同，但本质完全一致：

• Claude Code：通过承载层设计，隔离工具变化
• Codex：通过 tool_search，把工具展开变成历史追加
• TorchV：在动态工具与长上下文之间，强制“只追加不回写”

当 Agent 还很简单时，这件事不明显；
但当工具变多、链路变长、上下文变重时，

👉 谁能控制“变化发生在哪里”，
👉 谁的系统才能真正跑得稳、跑得久、跑得起。