夜雨聆风前面几篇分别拆了总览、agent loop、harness engineering、context engineering、prompt/context 结构、skill system 和 tool system。
把前面几篇文章连起来看，你会发现 Claude Code 真正值得研究的地方，是把大模型放进了一套能长期运行、能持续执行、能控制风险、也能不断重建上下文的工程系统里。
如果一定要把这个系列再压缩一次，那我更愿意把它概括成一句话：Claude Code 是一套围绕模型构建出来的 agent runtime。
系列回顾：
总判断
前面几篇看上去分别在讲入口、loop、harness、context、prompt、skill、tool，像是七个并列专题。
如果只把它们当成并列专题来读，还是容易失焦。它们其实都在解释同一套系统，只是落点不同。
Claude Code 的入口层和会话编排层，决定一次请求怎么启动；query.ts 决定系统如何在 tool_use 和 tool_result 之间持续循环；tool、skill、MCP 决定系统到底能做什么；prompt、attachments、skill surfacing、compact 决定模型到底能看到什么；而 harness、权限、状态和 transcript 则决定这套系统能不能在真实任务里稳定跑下去。
前面几篇文章拆开的，其实是一件事：Claude Code 如何把“模型推理”变成“可执行任务”。
一张图把主线重新串起来
这张图里最想强调的一点是：Claude Code 的很多模块不是并排摆在那里的。它们之所以重要，是因为都在服务同一个闭环。
这个闭环一旦成立，模型就不再只是“回答问题”，而是在一个被约束和增强过的运行时里持续推进任务。入口负责把它启动起来，上下文系统负责决定它看见什么，工具系统负责给它可执行能力，权限与编排负责控制动作边界，状态、transcript 与 compact 则负责让这个过程能跨越长任务继续运行。
第一个架构判断：它首先是一套 runtime
很多人第一次看 Claude Code，会本能地把重点放在 system prompt 上。这当然不奇怪，因为大模型系统最容易被看见的，往往就是 prompt。
但如果你顺着源码往下看，会发现 prompt 只是这套系统的一部分。Claude Code 值得学习的地方，也不只是“它怎么写 prompt”，更在于它怎么把 prompt 放进一套更大的工程结构里。前面几篇反复提到的 harness，本质上就是这层结构的名字。它对应的是把模型、工具、状态、权限和上下文托起来的一整套运行机制。prompt 在这里当然重要，但它已经属于运行时内部的一部分。
第二个架构判断：它靠闭环持续执行
理解 Claude Code，最关键的一步，是把注意力从“模型说了什么”转到“系统如何继续往前走”。
在普通聊天场景里，一次请求往往以一次回答为终点；但在 Claude Code 里，一次请求真正的终点往往落在若干轮 tool_use -> tool_result -> 再推理 之后的任务完成状态上，而不是第一段 assistant 文本。
因此 query.ts 会成为整套系统的心脏，tool system 不是外围插件，harness engineering 不是附加优化，权限系统也不是简单文案提醒。它们都直接参与了闭环本身：决定什么时候能执行、执行什么、结果如何回填、失败如何恢复、上下文如何继续保真。
如果不抓住这个闭环，Claude Code 就很容易被误读成“一个带很多能力的聊天程序”。抓住这一点之后，再回看前面的 tool、skill、权限、compact、transcript，位置就会清楚很多。
// src/QueryEngine.ts — transcript 持久化逻辑// 在进入 query loop 之前就先写入 transcript，// 这样即使模型还没有回复，进程就被 kill，// 也能通过 --resume 从上次用户消息处恢复。if (persistSession && messagesFromUserInput.length > 0) {const transcriptPromise = recordTranscript(messages)}整个 resume 的核心逻辑是：从磁盘重新加载 transcript，再把消息链 replay 进状态。recordTranscript() 会在 assistant 消息、compact、tool result 等关键节点之后被调用，保证磁盘上的 session log 始终是最新的，从而支撑 /resume 或 --resume 的可靠恢复。
如果按当前源码再补充一句，那么这里恢复的也已经不只是消息链本身。sessionRestore.ts 还会继续恢复 file history、todo 状态、context-collapse snapshot，必要时重新挂回 agent 设置和 worktree 上下文。Claude Code 要保住的，是整个 session runtime 的连续性。
第三个架构判断：它管理的是上下文系统和能力系统
Claude Code 的另一个关键点，在于它处理的从来都不只是“给模型一段字符串”。
它真正管理的，是一个不断变化的上下文系统：system prompt、user context、system context、messages、attachments、skills listing、tool descriptions、memory、system reminders、compact 结果，这些都会共同塑造模型输入。
与此同时，它还在管理能力系统。模型能看到哪些 tool，哪些 skill 可以被 surfacing，哪些 command 面向用户，哪些能力要通过 MCP 动态接入，哪些调用要经过权限链，哪些工具会被 ToolSearch 延后发现，以及哪些高层任务会被推给 AgentTool 或子 agent，这些都属于能力面的工程设计。
一张完整架构全景图
把前面三个判断合在一起，整套系统可以用一张图概括：
为什么要放在一起看
如果只看 agent loop，你会知道 Claude Code 会循环执行，但你不一定明白它为什么能稳定跑长任务。
如果只看 tool 和 skill，你会知道 Claude Code 有很强的能力系统，但你不一定明白这些能力是怎么进入 loop，又是怎么被权限系统和上下文系统约束的。
如果只看 prompt 和 context，你会知道 Claude Code 很会组织模型输入，但你不一定明白这些输入最后为什么会在 runtime 里产生真实动作。
这几个视角单独看都成立，但只有放在一起，Claude Code 的架构意图才会真正清楚：它要搭起来的，是一套把推理、动作、约束和状态统一起来的执行系统。
从这个角度回看，前面这组文章其实一直在回答同一个问题：Claude Code 为什么能从“会调用模型”走到“能持续执行任务”。
最后留下来的东西
如果把这个系列最后留下来的东西再往下压一层，我觉得有三点最重要。
第一，Claude Code 把任务执行建立在一个可持续推进的闭环上。模型不用一次把答案想完，它可以边做边推进。
第二，它把 tool 和 skill 分成了两个层次。前者更接近底层动作，后者更接近高层工作流，这种分层让能力扩展不至于混成一团。
第三，它把上下文、状态和恢复机制一起纳入了工程设计。上下文不是越多越好，能力也不是暴露得越全越好；两者都要服从预算、相关性和可恢复性。
这几件事合在一起，Claude Code 才成了一套能在真实任务里跑下去的系统。
结语
这个系列一路拆下来，最后真正变清楚的，是 Claude Code 的能力来自一整套彼此咬合的运行机制。只盯着某一段 prompt、某一个工具，或者某一个大文件，很难把这件事看完整。也正因为如此，“模型推理”才会变成“任务执行”。
把这一组文章读完之后，真正留下来的不该只是几个模块名，而应该是一个更稳定的判断：Claude Code 的核心，是它围绕大模型建立起来的可执行 runtime。
当你把 Claude Code 读透之后，就很难再把它简单地理解成“一个会调工具的大模型终端”。这个系列如果停在这里，停在这个判断上，也就足够了。
