Claude Code 的最小内核：Loop、Tools 与 Context

前两章我们做了两件事：

• 先把“Claude Code 为什么时灵时不灵”这个问题摊开
• 再把 Agent / Prompt / Harness 的边界讲清楚

从这一章开始，我们正式往下走一层：

Claude Code 这个系统，最底层到底是怎么动起来的？

如果你是开发者，我强烈建议你一定要把这一层搞明白。

因为只要这一层没搞清楚，后面很多“高级技巧”看起来就都像玄学：

• 为什么它能自己连续调用工具？
• 为什么它会自己停下来？
• 为什么它有时候会越做越偏？
• 为什么一个小小的 hook、skill、rule、verify flow，能对系统效果产生这么大影响？

这些问题，其实都能追溯到 Claude Code 的最小内核。

而这个内核，并没有想象中那么复杂。

你甚至可以把它压缩成三个词：

• Loop
• Tools
• Context

就这么简单。

如果再说得更极端一点：

Claude Code 的底层，不像“一个神秘 Agent 系统”，更像“一个会反复喂模型、接工具、回填结果的循环外壳”。

听上去一下子没那么浪漫了，对吧？

但也正因为它没那么浪漫，你才能真的理解它、调它、改它、搭它。

这一章我们就把这个最小内核拆开。

---

一、先看最小形态：一条循环为什么能撑起整个系统

如果你把 Claude Code 外面那层 UI、插件、配置、MCP、commands、hooks 全部拿掉，只剩核心机制，它大致会长这样：

while True:
    response = model(messages, tools)

    if response wants tools:
        result = execute_tools(response)
        messages.append(result)
    else:
        return response

如果你第一次认真看这种结构，可能会觉得有点失望：

“就这？”

是的，就这。

但问题恰恰在于：就这已经够了。

为什么？

因为这个循环已经具备了 Agent 的最小闭环：

1. 看见当前世界 通过 messages 和 tools 看见当前任务和自己能做什么

2. 做出决策 模型决定下一步是直接回答，还是调用某个工具

3. 行动 宿主进程真的执行工具

4. 感知行动结果 工具输出再回到上下文

5. 继续推理 模型基于新结果再做下一步判断

这件事一旦跑起来，你就已经从：

• “一个回答问题的模型”

跨到了：

• “一个能感知、行动、再感知的系统”

这就是 Claude Code 最底层真正让人震撼的地方。

不是它会说。
而是它可以：

说一句，做一步，再根据现实结果继续说下一句。

从工程视角看，这其实就是最小 Agent loop。

---

二、Claude Code 真正的“魔法感”，其实来自这个闭环

很多人第一次用 Claude Code 的惊艳感，几乎都来自同一种体验：

你给它一个任务，它不是直接答你一段话，而是开始：

• 读文件
• 搜目录
• 跑命令
• 查错误
• 再改代码
• 再跑测试
• 最后再告诉你结果

这让它看起来特别像一个人在工作。

但如果你把这个过程拆开，就会发现所谓“魔法感”其实主要来自这个闭环：

模型决定下一步
-> 工具真的执行
-> 结果回到模型
-> 模型继续决策

也就是说，Claude Code 之所以不像普通聊天机器人，不是因为它突然获得了神秘意志，而是因为：

它不再只在语言层闭环，而开始在“语言 + 环境反馈”层闭环。

这是个非常本质的区别。

普通聊天模型的工作方式更像：

你说一句
我回一句
结束

Claude Code 的工作方式更像：

你给一个任务
我先决定要看什么
然后看
看完再决定要改什么
改完再决定要测什么
测完再决定要不要继续

一旦你这样看，很多现象就解释通了。

比如为什么 Claude Code 会：

• 连续调用多个工具
• 自己决定中间步骤
• 在信息不够时先查，而不是先答

这不是因为它“有了人格”，而是因为：

loop 允许它把推理、行动和反馈串起来。

---

三、Loop 到底在干什么：不是死循环，而是“条件驱动的行动循环”

这里有一个经常被忽略的点。

很多人说到 agent loop，会简单概括成 while true。

这当然没错，但不够准确。

因为真正有用的不是“循环”本身，而是：

循环何时继续，何时停止，是由模型当前的判断驱动的。

这和传统脚本很不一样。

传统脚本往往是：

• 先写死步骤
• 再按步骤执行

而 Claude Code 这种 loop 则是：

• 每一轮重新判断现在要做什么
• 决策依据是当前上下文
• 上下文会因为工具结果持续变化

这意味着：

1. 它不是静态流程

不会因为你一开始说“修这个 bug”就固定好 10 个步骤。

它可能先：

• 读错误日志

如果日志不够，再：

• 查调用链

如果调用链不够，再：

• 搜相关配置

也就是说，它是边走边判断。

2. 它不是无限乱跑

理论上是 while True，但真正的刹车其实非常明确：

当模型判断“不再需要工具”时，loop 就停。

这也是 Claude Code 能“像一个人在工作完之后收工”的原因。

3. 它的质量高度依赖当前上下文

因为每一轮判断都靠上下文，所以：

• 如果上下文清楚，它会很稳
• 如果上下文噪声多，它就会飘
• 如果上下文缺关键状态，它会重复探索
• 如果上下文里混进旧任务，它会被带偏

这也是为什么我们后面一定要讲：

• planning
• compact
• memory
• session summary

因为 loop 的决策质量，不是天生的，而是：

被上下文质量直接决定的。

---

四、Tools 不只是“功能列表”，而是模型的行动边界

接下来讲第二个核心词：Tools。

很多人第一次理解 Claude Code tools，会把它想成：

“给模型开放了哪些功能。”

这当然对，但还是太轻了。

从系统角度看，tools 更准确的含义是：

模型能以什么粒度、什么方式对外部世界动手。

这句话很重要。

因为 tools 决定的不是“功能多少”，而是：

• 模型的行动边界
• 模型的思考粒度
• 模型和环境交互的接口稳定性

举个例子。

如果你只给它一个特别抽象的大工具：

• execute_workflow

听上去很强，但其实非常糟。

为什么？

因为模型根本不知道：

• 什么时候该用
• 这个工具到底能干什么
• 失败后怎么定位问题
• 结果该怎么用于下一轮推理

相反，如果你给它这些更原子的工具：

• read_file
• write_file
• edit_file
• bash
• grep
• glob

它的动作边界就会非常清楚。

这会直接带来两个好处：

1. 模型更容易选对动作

它知道：

• 想看文件，就 read_file
• 想改某段内容，就 edit_file
• 想验证命令，就 bash

2. 结果更容易回到推理链里

因为每个工具结果的语义更稳定。

这也是为什么很多成熟的 harness，都特别强调：

工具要原子化、职责清晰、可组合。

如果 tools 设计得太大、太黑盒、太泛化，Claude Code 不会“变聪明”，只会变得更像在雾里打拳。

---

五、Context 才是决定 Claude Code 稳不稳定的真正战场

前面我们讲了：

• loop 负责让系统动起来
• tools 负责让系统能动手

那接下来最关键的就是第三个词：

Context

很多人会把 context 理解成：

“聊天记录”

这其实是最容易低估它的一种方式。

更准确地说：

Context 是 Claude Code 当前全部判断的工作内存。

模型每一轮都在问自己：

• 当前任务是什么
• 之前已经做了什么
• 现在哪些结果已经拿到了
• 下一步还缺什么信息
• 哪个动作最有可能推进任务

而所有这些判断，都是基于当前上下文做的。

所以：

• loop 决定系统能不能持续工作
• tools 决定系统能不能行动
• context 决定系统会不会做出正确判断

这也是为什么我会说：

Claude Code 稳不稳定，真正的战场其实在 context。

你可以想象一个开发者在下面这两种状态里的差别。

状态 A：上下文干净

• 任务清晰
• 已知信息明确
• 最近结论还在
• 当前只做一件事

这时候 Claude Code 往往会非常稳。

状态 B：上下文拥挤

• 上一轮调研还没清
• 旧 bug 的日志还在
• 新需求说明塞进来了
• 一堆工具结果没整理
• 还有两个没完成的方向混在一起

这时候 Claude Code 就会开始出现：

• 决策漂移
• 过度探索
• 反复确认
• 方向切换

所以如果你以后只记住一句关于 Claude Code 的话，我建议记这一句：

Claude Code 不是越聊越强，很多时候是越聊越危险。

因为 context 是累积的，而不是天然会自我整理的。

这也是为什么后面那一整套：

• planning
• rules / skills / commands 分层
• compact
• session summary
• memory

本质上都是在服务同一件事：

让 context 继续可用。

---

六、为什么这三样东西一旦连起来，就会出现“像人在工作”的错觉

现在把这三层重新放到一起看：

1. Loop

让系统可以持续“看 -> 想 -> 做 -> 再看”

2. Tools

让系统真的能动手

3. Context

让系统能基于过去和当前状态继续判断

三者一旦组成闭环，就会出现一种非常强的人类错觉：

“它在自己工作。”

这个错觉不是假的，但也不是全部真相。

它“像在自己工作”，是因为：

• 有推理
• 有行动
• 有反馈
• 有连续性

但它又和真正的人类工作很不一样，因为：

• 它没有天然长期记忆
• 它没有天然任务边界
• 它没有天然验证意识
• 它没有天然协作习惯

也就是说：

Claude Code 最底层已经具备了行动闭环，但距离“稳定工作系统”还差很多层。

这一章的意义就在这里。

我们先把“它是怎么动起来的”讲清楚，后面你才会真正理解：

• 为什么要前置 planning
• 为什么要有 rules
• 为什么要有 hooks
• 为什么要有 session summary
• 为什么 worktree 那么重要

因为这些都不是凭空加上的花样。

它们全都是在给 loop + tools + context 这个最小内核补结构。

---

七、本章交付：Claude Code 最小内核图

这一章的交付物，是一张最小内核图。

以后你只要怀疑自己是不是又把 Claude Code 想复杂了，就回到这张图。

User Request
   ↓
Context (messages / state / loaded knowledge)
   ↓
Model
   ↓
Decide:
  - respond
  - or use tool
   ↓
Tool execution in environment
   ↓
Result returns to context
   ↓
Next decision

你会发现，后面我们要搭的所有东西，其实都只是在增强这个图里的某一层：

• CLAUDE.md 和 rules：增强上下文的稳定性
• skills 和 commands：增强知识与流程入口
• hooks：增强工具前后和生命周期治理
• memory：增强状态延续
• worktree：增强执行边界
• verify：增强结束条件的可信度

这张图足够简单，但它是后面整本书最底层的参照物。

---

八、本章小结

这一章我们没有谈任何高级能力。

我们只做了一件很关键的事：

把 Claude Code 的最小内核拆成了 Loop、Tools、Context 三层。

最后得到的结论其实很重要：

1. Claude Code 的底层并不神秘，它首先是一个行动闭环
2. Tools 决定模型能做什么动作
3. Context 决定模型能不能持续做对判断

也就是说，Claude Code 的强，不只是因为模型强，而是因为：

模型被放进了一个能“看、做、再看”的闭环里。

但我们也已经看到一个更重要的事实：

只有 loop + tools + context，还不够把它变成一个稳定的工作系统。

因为：

• 它还没有任务边界
• 还没有长期规则
• 还没有验证闭环
• 还没有自动化治理
• 还没有长期记忆

所以从下一章开始，我们就不再只讨论“它怎么动起来”，而是往前走一步：

从工具到系统：Claude Code 工作系统全景图。

因为真正的实战，不是理解 loop，而是知道：

在 loop 外面，哪些层是必须补的。