Claude Code底层架构解析：ReAct Loop、上下文窗口与CLAUDE.md机制详解

很多人每天都在用 Claude Code 写代码，但你有没有想过，当你敲下回车之后，它底层到底在干什么？今天我们不聊怎么用，聊聊 Claude Code 的底层架构是怎么跑的。B站UP主 Data老B 用三张架构图，把 Claude Code 的运行机制讲得非常清晰，本文在此基础上做进一步梳理和分析。

完整闭环：从输入到执行的全链路

当你在终端输入一句话，Claude Code 背后发生了什么？

首先，它会把你的输入、.claude/CLAUDE.md 文件内容、当前目录结构等信息全部打包成一个巨大的 Prompt，通过 API 发给 Claude 模型。

模型返回的不是普通文本，而是一个结构化的 JSON，里面包含"我要调用哪个工具"以及"参数是什么"。这种结构化输出基于 Anthropic 的 Tool Use（也称 Function Calling）协议——一种已成为行业标准的大模型与外部系统交互范式。其核心思想是将"决策"与"执行"彻底解耦：模型只负责推理和规划，输出符合预定义 Schema 的 JSON 对象来声明需要调用的工具名称和参数；而实际的文件读写、命令执行等操作则由本地运行时完成。相比让模型直接生成 bash 脚本再执行，Tool Use 协议提供了更强的类型安全和权限控制，Claude Code 可以在执行前对工具调用进行校验和权限拦截，避免危险操作。

Claude Code 拿到这个 JSON 后，在你的本地环境执行对应操作——读文件、写文件、跑命令——然后把执行结果再拼回 Prompt，再次发给模型。

这就是一次完整的闭环。整个过程可以概括为：

1. 用户输入 → 打包上下文 → 发送 API 请求
2. 模型响应 → 返回结构化工具调用指令（JSON）
3. 本地执行 → 执行工具操作 → 结果回传
4. 循环往复 → 直到任务完成

这个架构并不复杂，但理解它对于高效使用 Claude Code 至关重要。值得注意的是，这种 Agent Loop 架构与传统 IDE 中的 AI 代码补全插件（如 GitHub Copilot 的 Inline Suggestion 模式）有本质区别。传统代码补全是单轮交互：将当前代码上下文发送给模型，模型返回补全建议，交互结束。而 Claude Code 的 Agent Loop 是多轮自主交互：模型可以自主决定读取哪些文件、执行哪些命令、搜索哪些内容，并根据每一步的结果动态调整后续行为。这使得 Claude Code 能够处理"在整个项目中重构某个接口"这类需要跨文件理解和多步操作的复杂任务，而不仅仅是补全当前行的代码。这种架构本质上是将大模型从"工具"升级为"智能体"（Agent），代价则是更高的 Token 消耗和更长的执行时间。

ReAct Loop：Think → Act → Observe

上述循环机制有一个专业名称，叫做 ReAct Loop（Reasoning + Acting），核心就是三步不断重复：Think、Act、Observe。

ReAct 框架最早由 Yao 等人在 2022 年的论文《ReAct: Synergizing Reasoning and Acting in Language Models》中提出。在此之前，大模型的推理（Chain-of-Thought）和行动（Action Generation）通常是分开研究的两个方向。ReAct 的核心贡献在于证明了将推理轨迹和工具调用交替进行，能显著提升模型在复杂任务上的表现。这种模式已成为当前几乎所有 AI Agent 框架（如 LangChain、AutoGPT、OpenAI Assistants API）的底层范式，Claude Code 是这一范式在编程场景中最成熟的工程实现之一。

具体到 Claude Code 中，三个阶段的运作方式如下：

• Think（思考）：模型先输出思考过程，这段内容你在终端里是能看到的
• Act（行动）：模型输出一个 Tool Use 指令，指定要调用的工具，比如 Read File、Bash、Search 等
• Observe（观察）：Claude Code 在本地沙箱里执行这个工具调用，拿到结果后作为 Tool Result 拼进下一轮 Prompt

关键点在于：每一轮都是完整的 API 调用。 整个对话历史越来越长，Token 消耗也越来越大。这就是为什么复杂任务烧 Token 特别快——模型每一步都要重新读一遍所有历史记录。

这也解释了一个常见困惑：为什么有时候一个看似简单的任务，Claude Code 却消耗了大量 Token？因为每次工具调用的输入和输出都会累积在对话历史中，随着交互轮次增加，单次 API 调用的 Token 量呈线性增长。举个具体的例子：假设每轮工具调用平均产生 2K Token 的输入输出，到第 20 轮时，仅工具调用的历史记录就已经累积了约 40K Token，再加上 System Prompt、CLAUDE.md 和用户对话，单次 API 请求可能轻松超过 60K Token。

上下文窗口：内存与硬盘的比喻

Claude Code 没有数据库，没有向量检索，没有长期记忆。它的全部"记忆"就是当前的上下文窗口——大约 200K Token。

这里有必要解释一下 200K Token 的技术含义。Token 是大模型处理文本的基本单位，对于英文文本大约 1 个 Token 对应 4 个字符，中文则大约 1-2 个字符对应 1 个 Token。200K Token 大约相当于 15 万个英文单词或一本 500 页的书。相比之下，GPT-4o 的标准上下文窗口为 128K Token。更大的上下文窗口意味着模型能"看到"更多的历史信息，但也带来了计算成本的显著增长——Transformer 架构中自注意力机制的计算复杂度为 O(n²)，虽然各家厂商通过稀疏注意力、滑动窗口注意力等技术进行了优化，但长上下文的推理成本仍然远高于短上下文。这也是 Claude Code 长任务烧 Token 的根本技术原因。

这个窗口里塞了什么？

• System Prompt + CLAUDE.md 中的项目约定
• 所有对话轮次
• 每次工具调用的输入和输出

窗口满了怎么办？早期的对话会被逐步丢弃，不断淘汰最旧的内容。但有一个例外——CLAUDE.md 永远在窗口最前面，不会被丢掉。

Claude Code 采用的这种滑动窗口淘汰策略，本质上是一种 FIFO（先进先出）的上下文管理方案。当对话历史超过窗口容量时，最早的对话轮次会被截断丢弃，这与操作系统中的页面置换算法有异曲同工之处。而 CLAUDE.md 被设计为"钉在窗口头部"的固定内容，类似于操作系统中被标记为"不可换出"的内核页面。这种设计在工程上非常巧妙：它不需要额外的向量数据库或 RAG（检索增强生成）管道，仅通过 Prompt 拼接的优先级策略就实现了"持久记忆"的效果。

Data老B 给了一个非常精妙的比喻：

CLAUDE.md 是硬盘，对话历史是内存。内存满了会淘汰，但硬盘一直在。

这个比喻完美解释了为什么 CLAUDE.md 写得好，Claude Code 的效率能翻倍。它是 Claude Code 唯一的"持久化锚点"，你在里面定义的项目约定、代码规范、架构说明，会在每一轮对话中持续生效。而对话中临时讨论的内容，随着上下文窗口滑动，终将被遗忘。

对于用户而言，这意味着 CLAUDE.md 的每一个字节都极其珍贵——它占用的是永远不会被释放的上下文空间，因此应该只放最核心、最稳定的项目信息，避免冗余内容挤占宝贵的窗口容量。

Claude Code架构总结与实践启示

把以上三层拆解合在一起，Claude Code 的本质就是：

层级	组件	作用
执行引擎	本地 Agent Loop	循环执行 Think → Act → Observe
记忆机制	200K 滑动窗口	承载所有上下文，满了就淘汰旧内容
持久锚点	CLAUDE.md	永不被丢弃的"硬盘"配置

没有魔法，架构非常清晰。 理解了这三层，很多使用中的困惑就迎刃而解了：

为什么Claude Code有时候会"忘事"？

因为上下文窗口是滑动的，早期对话被淘汰后，模型就失去了那部分信息。如果你在第 5 轮告诉它一个重要约定，到第 50 轮时这条信息可能已经被丢掉了。

为什么CLAUDE.md写好了效率翻倍？

因为它是唯一不会被淘汰的内容。把项目的关键信息、编码规范、架构决策写进 CLAUDE.md，等于给 Claude Code 装了一块永久硬盘。

为什么长任务特别烧Token？

因为每一轮 API 调用都要携带完整的对话历史。任务越长，历史越多，每次调用的 Token 数越大。这是 ReAct Loop 架构的固有代价。

基于架构理解的优化建议

理解了 Claude Code 的底层架构后，以下几条实用建议能帮你显著提升使用效率：

1. 精心维护 CLAUDE.md：把最重要的项目信息放在这里，它是你与 Claude Code 之间最可靠的沟通渠道。但也要注意精简——CLAUDE.md 占用的是永不释放的上下文空间，冗余信息会持续挤占可用窗口容量
2. 拆分复杂任务：与其让一个超长会话完成所有事情，不如拆成多个短会话，减少 Token 消耗。每个新会话都会从一个干净的上下文窗口开始（仅包含 System Prompt 和 CLAUDE.md），这不仅节省成本，还能避免长对话中累积的噪声信息干扰模型判断
3. 关键信息及时重申：如果某个约定很重要但不适合放在 CLAUDE.md 中，在长对话中适时重复提醒。这本质上是在手动对抗滑动窗口的淘汰机制
4. 理解 Token 成本结构：工具调用的输入输出都会计入上下文，尽量让每次工具调用精准高效。例如，使用精确的文件路径而非让模型搜索整个目录树，使用具体的行号范围而非读取整个大文件，都能有效减少每轮循环的 Token 开销

理解工具的底层原理，才能真正用好它。Claude Code 的架构虽然简洁，但这种"简洁"正是它强大的原因——一个 Agent Loop、一个滑动窗口、一个持久锚点，三者配合就能完成复杂的编程任务。

核心要点