过去几个月里，Claude Code 悄然成为普通开发者能够接触到的、最受关注且应用最广泛的真实智能体系统之一。

作者：Kobe、Mengbing
发布于：2025-12-23
更新于：2026-03-30
原文：https://blog.lmcache.ai/en/2025/12/23/context-engineering-reuse-pattern-under-the-hood-of-claude-code/

完整的 Claude Code 智能体与工具调用轨迹图

过去几个月里，Claude Code 悄然成为普通开发者能够接触到的、最受关注且应用最广泛的真实智能体系统之一。

它既不同于 Perplexity、Devin 或 Manus 这类内部机制隐藏在 API 网关之后的纯云端智能体，也不同于 Mini SWE Agent 或 Terminus 2 这类可以拿到源码、在本地部署的完全开源智能体。Claude Code 采用的是一种部分在本地运行的形态：它在本机运行，并公开了客户端仓库。这给了我们一个难得的机会——可以截获它发出的流量，通过逆向分析看清每一次大模型调用、每一次中间的工具调用，以及智能体做出的每一个细微决策。

最近，我们用 Claude Code 做了一个很小的单次实验：从 SWE-bench_Verified 数据集中随机挑选一个任务，并把全部大模型输入与输出记录成一份原始日志文件：claude_code_trace.jsonl。把这份轨迹 导入可视化工具，就能查看完整的调用细节。

关键指标：

  • 共调用大模型 92 次（#1-#92）
  • 消耗约 200 万个输入 Token
  • 总耗时 13 分钟
  • 前缀复用率达到 92%

大模型智能体轨迹查看器：共 92 条轨迹，缓存命中率为 92%

我们的目标很简单：

只交给 Claude Code 一个小任务，幕后究竟会发生什么？

它会按什么顺序调用哪些大模型？

上下文在哪里得到了复用？提示词中有多少是稳定、已经出现过的前缀，又有多少是本轮新增的内容？

下面，我们就沿着这份调用轨迹逐步拆解。

1. Claude Code 执行一个简单任务时，究竟发生了什么

从产品体验来看，Claude Code 很直观：你在编辑器里输入需求，它帮你修改文件，或者执行几条 Bash 命令。但在底层，即使只是一个简单的单步请求，也会被拆解成一套结构远比想象中复杂的内部循环。

我们从 SWE-bench_Verified 数据集中随机选取了第 80 个任务。任务要求在 2e0f04507b17362239ba49830d26fec504d46978 这个提交版本的 django/django 仓库中修复一个问题。

问题描述：

“JSONField 在管理后台被设为只读时，无法正确显示。

具体来说，只读 JSONField 的值会显示成 Python 字典。例如，{"foo": "bar"} 会显示为 {'foo': 'bar'}，后者并不是合法的 JSON。

我认为可以在 django.contrib.admin.utils.display_for_field 中针对 JSONField 增加特殊处理，调用它的 prepare_value 方法（而不是直接调用 json.dumps，这样还能兼顾 InvalidJSONInput 的情况）。”

这段文字就是 Claude Code 实际收到的提示词。

Claude Code 收到的 Django JSONField 任务提示词

出人意料的是，在进行任何复杂推理之前，Claude Code 先执行了几步**“预热”操作**（轨迹编号 #2、#3、#4）。这些预热步骤不做实际工作，只是分别输入以下提示词：

  • 工具列表（#2）
  • Explore 子智能体（#3）
  • Plan 子智能体（#4）

预热的目的在于建立缓存。之后真正调用这些工具和子智能体时，就能命中缓存，从而缩短响应时间。总结智能体（#1）和新主题智能体（#5）则分别负责总结上下文和生成用于界面显示的新标题，作用类似 ChatGPT 的侧边栏标题。

主智能体（#6）带着一份体量庞大的系统提示词启动，其中包括 Git 历史、仓库状态和工具列表等信息。工具列表中共有 18 种工具：它不仅可以像往常一样调用 Bash、Grep、Read、WebFetch、AskUserQuestion 等工具，还能调用子智能体，并把特定任务委派给它们，例如：

  • Explore 子智能体（#7）
  • Plan 子智能体（#46）

这些子智能体还会继续调用各自工具列表中的工具。

主智能体（#6）启动后，立即调用了 Explore 子智能体（#7，也称文件搜索智能体），让它借助自己的工具探索代码库。Explore 使用的是另一套系统提示词，核心任务就是查找和理解代码：

你是 Claude Code，也就是 Anthropic 官方推出的 Claude 命令行工具。你是 Claude Code 的文件搜索专家，擅长深入浏览和探索代码库。

值得注意的是，Claude Code 并非只调用了一个 Explore 子智能体，而是并行启动了 3 个 Explore 子智能体，让它们各自围绕不同目标探索代码库：

  1. 探索 JSONField 的实现（存活区间：#7-#26）
  2. 探索管理后台的 display_for_field（存活区间：#8-#37）
  3. 探索只读字段的渲染逻辑（存活区间：#9-#45）

主智能体（#6）的上下文不会原封不动地传给这些子智能体。这样做反而有利于子智能体从一份干净的上下文出发。每个 Explore 子智能体可以并行调用 1 到 3 个工具；它所能使用的工具，是主智能体工具列表的一个子集（18 种工具中的 10 种）。

这里采用了 ReAct 机制：Explore 子智能体先调用工具，再观察工具返回的结果，并据此发起下一次工具调用。这个过程会不断循环，直至它判断代码库已经探索充分。

最终，最慢的那个 Explore 子智能体在第 #45 步完成探索。到了第 #46 步，主智能体把 3 个 Explore 子智能体的发现（摘要）追加进自己的上下文，然后调用 Plan 子智能体（#47）来制订修复方案。

Explore 子智能体的调用轨迹，以及向 Plan 智能体的切换

与 Explore 类似，Plan 智能体（#47）也有一套不同的系统提示词，核心任务是设计修复方案：

你是 Claude Code，也就是 Anthropic 官方推出的 Claude 命令行工具。你是 Claude Code 的软件架构师和规划专家，职责是探索代码库并设计实施方案。

Plan 智能体没有继承主智能体或 Explore 子智能体的全部上下文，这同样让它能够从一份干净的上下文开始工作。它拿到的只有 Explore 子智能体探索结果的摘要。它的工具箱也是主智能体工具列表的一个子集（18 种工具中的 10 种）。Plan 智能体需要设计一份满足以下要求的实施方案：

请设计一份实施方案，要求：

  1. 明确指出需要对 display_for_field 做哪些修改
  2. 判断是否需要基于模型字段实例化一个表单字段，还是存在更合适的做法
  3. 找出所有边界情况或潜在问题
  4. 结合 Django 的架构，推荐最佳方案

Plan 智能体的调用轨迹与不断累积的上下文

Plan 智能体同样遵循 ReAct 模式，从 #47 到 #72 不断循环调用工具。在此期间，上下文从 11,552 个 Token 增长到 38,819 个 Token。形成一份成熟的方案后（详情见 #72），Plan 智能体会在 #73 把方案交还给主智能体。

随后，主智能体会依次调用工具来：

  • 审查方案（#73）
  • 向用户询问需要澄清的问题（#74）
  • 把方案写入 Markdown 文件（#75）

最后，主智能体退出规划模式（#76）；在交互式地请用户批准方案后（#76-#77），进入执行模式（#77），开始落实方案。

执行阶段（#77-#91）依然遵循 ReAct 模式。主智能体会把方案 Markdown 文件当作待办清单：

  1. 在 utils.py 中引入 json
  2. 在 display_for_field() 中加入对 JSONField 的处理
  3. 在 test_admin_utils.py 中添加测试
  4. 运行测试，验证修复是否正确

每完成一轮文件读取或编辑等工具调用，它都会在方案 Markdown 文件中划掉相应的待办项。所有事项完成后，主智能体会在第 #92 步给出总结消息，结束任务。

这一阶段还调用了其他一些子智能体，例如提取 Bash 命令子智能体（#93）。它采用一次性提示词模板，专门负责提取 Bash 命令，以免系统意外执行 rm 一类危险命令而没有先征得用户确认。

下面就是这次 Claude Code 调用轨迹的完整示意图：

Claude Code 的规划与执行轨迹

2. 隐藏在背后的模式：Claude Code 是一台“前缀复用机器”

分析这份轨迹时，我们发现有一个现象始终如一，值得单独拿出来讨论：

Claude Code 的提示词极度依赖前缀。

所谓前缀复用，是指当前提示词的一部分前缀，已经在此前提示词的前缀中出现过。纵观所有阶段，提示词的总体复用率高达 92%；在基于 ReAct 的子智能体循环中，这个比例还要更高。如果分别分析各阶段的前缀长度，可以得到下表：

轨迹编号 Token 总数 共享前缀占比 说明
#1-#6 47,177 0.22% 预热与初始化阶段
#7-#45 546,104 92.06% Explore 子智能体阶段
#47-#72 528,286 93.23% Plan 子智能体阶段
#73-#92 827,411 97.83% 主智能体执行阶段

这意味着什么？Claude Code 的架构实际上已经天然适合 KV 缓存复用，即使它并未刻意针对这一点进行优化。

3. 什么是前缀缓存，为什么值得关注

大语言模型推理的核心机制之一是 KV 缓存（Key-Value Cache，键值缓存）：它会保存模型处理历史 Token 时产生的中间注意力计算结果。在自回归生成过程中，每生成一个新 Token，都需要关注此前的所有 Token，因此会涉及代价高昂的矩阵乘法。KV 缓存把早先 Token 已经算出的 Key 和 Value 矩阵保存下来，于是生成每个新 Token 时就不必重复计算。

前缀缓存在此基础上更进一步：当多个请求拥有相同的提示词前缀（例如相同的系统指令或文档上下文）时，它们对应的 KV 缓存计算结果也完全相同，因此可以在请求之间复用。

主流大模型服务商已经把这种机制转化成了可观的成本优势：

  • OpenAI 的 Prompt Caching 会自动处理前缀缓存：系统自动识别长度超过 1,024 个 Token 的公共前缀，并在后台透明地缓存。命中缓存的输入 Token 可享受 90% 的价格折扣（例如，GPT-5.2 每百万缓存 Token 的价格会从 1.75 美元降至 0.175 美元）。OpenAI Prompt Caching 价格
  • Anthropic 的缓存命中定价 则通过特殊的 cache_control 标记，让开发者能够显式控制哪些提示词区块需要缓存。写入缓存时价格会略高（5 分钟缓存为基础价格的 1.25 倍，1 小时缓存为 2 倍），但读取缓存同样可享受 90% 的折扣（以 Claude Sonnet 4.5 为例，缓存读取价格为每百万 Token 0.30 美元，而普通输入为 3.00 美元）。这种方式适合对复杂多轮对话或文档密集型工作流进行精细优化。Anthropic Prompt Caching 价格

结合 Claude Code 92% 的前缀复用率来看，效果会更加直观：本次实验共消耗 200 万个输入 Token。如果完全不使用缓存，费用将是 6.00 美元（200 万 × 3 美元/百万 Token）；而在使用前缀缓存后，成本会降至 1.152 美元（184 万个缓存命中 Token × 0.30 美元/百万 Token + 16 万个缓存写入 Token × 3.75 美元/百万 Token）。也就是说，仅一个简单任务就节省了 4.85 美元，降幅达到 81%。

开源推理引擎也已经广泛采用这一思路：

  • vLLM 的自动前缀缓存 借助 PagedAttention 机制，透明地缓存公共前缀
  • SGLang 的 RadixAttention 使用基数树数据结构，在请求之间高效匹配和复用最长公共前缀
  • LMCache 更进一步，在多个节点之间建立共享的分布式 KV 缓存池，尽可能提高大规模场景下的复用率

除了降低成本，命中前缀缓存还可以显著缩短 TTFT（Time to First Token，首 Token 延迟）。模型不必重新计算整个前缀，只需处理本次请求独有的后缀，因此共享上下文的后续请求可以把延迟降低到原来的五分之一乃至十分之一，让对话式智能体和基于文档的应用响应更快。

4. 从这份小型轨迹中，我们看到了什么

尽管任务本身很简单，这份轨迹仍然揭示了 Claude Code 作为一个完整系统的许多特征。

主系统提示词体量庞大

  • 其中包含完整的 Git 仓库状态与历史记录、主智能体全部 18 种工具的详细说明，以及最后才加入的执行阶段指令
  • 即使还没有任何对话历史，仅这份提示词就超过 20,000 个 Token

Claude Code 围绕专用子智能体构建

  • 子智能体只接收与自身职责相关的上下文，避免上下文膨胀
  • 通过隔离上下文，主智能体只需接收子智能体返回的摘要

并行执行提高了代码探索效率

  • 多个子智能体围绕不同的搜索目标并行启动，各自在自己的 ReAct 循环中工作
  • 这种隔离让每个子智能体都能拥有干净、聚焦的上下文，也能更均匀地分担上下文负载
  • 出于同样的考虑，工具调用也会并行执行

真正开始工作前，系统会通过“预热”调用准备缓存

  • 预热会把工具说明写入缓存，提前加载子智能体的系统提示词，并建立稳定的前缀基线
  • 后续调用子智能体时，预热可以显著加快响应速度

Claude 非常适合复用 KV 缓存

  • Claude 的总体前缀复用率最高可达 92%，非常适合做 KV 缓存复用优化
  • 即使只执行一个简单任务，也能节省 4.85 美元，成本降低 81%

交互式规划让过程更加透明

  • 用户可以掌控系统将要做出的修改
  • 在执行前形成一个自然的检查点，请用户批准方案
  • 用户的反馈还能帮助系统把方案进一步细化成可执行的待办清单，从而改善整个工作流

5. 除了前缀缓存，我们还能做得更好吗

最近，一些研究论文开始尝试提高非前缀缓存的效率。例如 CacheBlend 探索的就是如何优化非前缀内容，也就是子字符串的缓存复用。

CacheBlend 的非前缀 KV 缓存复用示意图

从这份轨迹可以看到，子智能体使用的工具列表是主智能体工具列表的子集。这意味着，子智能体实际上可以复用主智能体工具列表中的相关说明。这就是提高非前缀缓存复用效率的一个典型例子。

另一个场景是重复读取同一个文件。即使文件内容并不位于提示词前缀，只要被读取多次，仍然可以缓存并复用。文件越大、读取次数越多，这种能力带来的收益就越明显。