Claude Code 源码拆解:以道法体术观之,一个把提示词、认证、文件系统和终端熔成一体的 AI 代理

我最近重新看了一遍claude-code相关的公开材料，包括一个被广泛转发的源码镜像、几篇源码解析文章，以及当前仓库里留下来的重写痕迹。最初我只是想回答一个很朴素的问题：Claude Code 到底是一个“能在终端里问 AI 的命令行工具”，还是一套更完整的智能体系统？

看完之后，我的结论很明确：它不是一个聊天壳，也不是一个“把 API 包一层”的脚手架。它更像是一套把约束、状态、工具和交互熔在一起的终端智能体。你如果只从功能看，会觉得它支持问答、解释代码、重构、执行命令、读写文件；但如果从架构看，会发现它其实在做一件更大的事：

1. 用提示词定义“道”，也就是它为什么做、什么不能做、优先级如何；
2. 用模块边界定义“法”，也就是它如何被组织、如何分层、如何把风险关在外面；
3. 用运行状态定义“体”，也就是它在某个时刻到底是谁、手里有什么、能走到哪一步；
4. 用工具系统定义“术”，也就是它如何把判断变成可执行动作。

如果用道家的语言去读它，会比用普通软件目录图更准确。因为这套系统真正关心的，不是“能不能说话”，而是“说什么、什么时候说、说完以后能不能落地”。这也是我写这篇文章的原因：我想把它当成一个工程系统来读，而不是当成一个神秘的 AI 产品来崇拜。

这篇文章会分成两部分：

1. 先把claude-code的架构拆开，尽量从源码层面理解它的设计；
2. 再用“道法体术”的框架，把这些设计重新组织成一个更容易记住、也更容易复用的方法论。

需要说明的是：当前公开可访问的仓库里，原始泄露快照已经不在 tracked tree 里，仓库主体已经转成 Python porting workspace。本文主要参考的是公开的 deobfuscation 镜像、源码解析文章，以及当前仓库保留下来的说明性材料。对于无法直接逐行复原的部分，我会明确用“推断”而不是“事实”来写。

一、先把结论说前面：它不是“CLI + LLM”，而是“受控行动系统”

很多人第一次看到 Claude Code，会自然把它归到三类东西里：

1. 终端聊天工具；
2. 编程助手；
3. 自动化执行器。

这三种分类都对，但都不完整。因为它真正的核心不是“回答问题”，而是“在受控边界内把问题推进到结果”。这意味着它必须同时处理四件事：

1. 语言理解；
2. 决策和规划；
3. 认证和权限；
4. 文件、命令、终端和会话状态。

只要你接受这个前提，整个架构就会变得清晰：入口必须尽量薄，规则必须尽量厚，状态必须尽量稳，动作必须尽量可控。换句话说，它不是把 AI 塞进终端，而是把终端改造成 AI 的行动场。

这也是为什么src/cli.ts不承担太多业务逻辑。它做的事情相当克制：解析参数、注册命令、初始化认证、必要时初始化 AI、最后把请求交给对应命令处理。真正重的东西都被外置到了commands/、auth/、config/、ai/、fileops/、execution/、terminal/这些模块里。

这个判断很重要，因为它说明 Claude Code 的工程哲学不是“单点功能堆叠”，而是“能力分层”。如果你把它看成一个普通 CLI，你会错过它最关键的东西：它试图把模型的自由度关在一个可审计、可约束、可重试、可恢复的边界里。

二、为什么要用“道法体术”来读这套系统

我不太想用传统“分层架构”的方式来读它，因为那样太平。Claude Code 的设计其实很像一门武学：

1. “道”是它的价值取向和行为边界，决定什么可以做、什么应该先问、什么不能硬撞；
2. “法”是它的组织纪律，决定模块怎么切、职责怎么分、请求怎么流转；
3. “体”是它运行时的真实状态，决定它当下能不能继续、该不该刷新、有没有凭证、是不是在工作区内；
4. “术”是它面对具体问题时的动作形态，决定怎么读文件、怎么执行命令、怎么搜索代码、怎么跟用户交互。

这四层不是玄学。你把它翻回代码，几乎能一一对应：

1. ai/prompts.ts代表“道”，因为它直接定义了模型怎么想；
2. commands/index.ts和commands/register.ts代表“法”，因为它们定义了命令制度；
3. auth/index.ts、config/index.ts、tokens.ts代表“体”，因为它们处理身份、状态和持久化；
4. execution/index.ts、fileops/index.ts、fs/operations.ts、codebase/analyzer.ts、terminal/index.ts代表“术”，因为它们把行为真正落到系统里。

如果把这四层混在一起，系统就会变成一个谁都不敢改的巨石。Claude Code 没有这样做。它反而把每一层都切得很清楚，让“判断”“权限”“执行”分别走自己的通道。这样做的好处是，模型的能力可以很强，但危险动作不至于失控；终端的交互可以很灵活，但系统的边界不至于塌掉。

三、道：提示词、技能和工作流，不是附录，而是方向盘

从很多 AI 产品看，prompt 像是包装层；从 Claude Code 这类智能体看，prompt 更像是运行法则。ai/prompts.ts里最值得注意的，不是“它写了几段模板”，而是它把不同任务的心理姿态拆开了。

你可以把它理解成几种不同的内功心法：

1. 解释代码时，系统提示词强调分步骤、讲清逻辑、解释术语；
2. 生成代码时，系统提示词强调清晰、可维护、考虑边界情况；
3. 代码审查时，系统提示词强调缺陷、风险、可读性、维护成本；
4. Debug 时，系统提示词强调定位问题、对照错误信息、不要瞎猜。

这意味着 Claude Code 不是把“帮我写代码”当成一条泛化指令，而是把不同任务的认知姿势拆开处理。这个设计非常关键，因为它说明系统并不指望一个统一 prompt 就覆盖所有场景。相反，它承认不同任务需要不同的精神状态。

在道家的框架里，这叫“因势利导”。不是强行用同一种口诀去练所有功，而是看当前任务是什么，再把模型的注意力往正确方向引。PROMPT_TEMPLATES的存在本身就证明了一点：这个系统理解 prompt 不是一次性的文字，而是可复用的仪式结构。

更进一步看，Claude Code 还把技能、计划模式、工具描述这些东西塞进了同一个认知体系里。公开解析里提到，Claude Code 的工具说明不是短短一行简介，而更像操作手册。这个做法和很多传统 CLI 不一样。传统 CLI 倾向于把“怎么做”藏在程序逻辑里；Claude Code 更像把“怎么做”写成模型可读的规约，再让模型按规约行动。

这就是“道”的本质：不是把一个答案塞给模型，而是给模型一个稳定的方向。方向比答案更重要，因为答案会变，方向不会。

3.1 计划模式体现的不是功能，而是姿态

很多系统把“计划”和“执行”做成两个完全不同的 prompt 版本；Claude Code 的思路更有意思。公开解析里提到，它在某些模式切换时，不一定是换一整套系统，而是通过运行时注入提醒来改变行为。也就是说，同一个主体可以处在不同姿态里：有时先看后做，有时边看边做，有时只读不写。

这种设计看上去像“少做了”，其实是“让行为更可控”。因为提示词切换的粒度更细，模型不需要每次都重置上下文，也不需要重新装载完全不同的知识壳。对一个终端智能体来说，这很重要：你如果每切一次模式就换一套大 prompt，成本会很高；如果完全不切，行为又会漂。

Claude Code 的做法是保留统一的主体，再用系统提醒去改当前动作。这个思想很像修行中的“持本心而应万变”。

3.2 技能注入像是按需开门，不是提前把仓库搬进脑子

另一个值得注意的点是 skills。它不是一开始就把所有相关文档都塞进上下文，而是在符合条件时才注入。这样做的好处很直接：

1. 减少无关上下文；
2. 降低每轮推理的负担；
3. 把知识加载和任务触发绑定起来。

这其实是一种很朴素的工程智慧：不要为了“可能会用到”把所有东西都提前加载。该用时再开门，不该用时就让它沉睡。很多系统设计失败的原因就在这里，什么都想放在一开始，结果上下文越来越胖，模型越来越懒，最后谁都搞不清它究竟在看什么。

四、法：命令注册、配置合并、认证状态，构成它的制度层

如果说“道”负责方向，那“法”就负责秩序。Claude Code 的秩序感体现在三个最核心的地方：

1. 命令系统；
2. 配置系统；
3. 认证系统。

这三者不是平行摆放的功能模块，而是互相制衡的制度。用户能做什么，不仅取决于模型愿不愿意做，也取决于命令怎么注册、配置怎么加载、身份是否有效。

4.1commands/index.ts：命令不是 if/else，而是数据

我很喜欢它的命令注册思想。命令不是在 CLI 主文件里写一长串switch，而是抽象成CommandDef这样的结构：名字、描述、参数、别名、分类、是否需要认证、是否允许交互、隐藏与否，最后是 handler。

这种写法的好处很大：

1. 命令是可列举的，帮助页可以自动生成；
2. 命令是可分类的，界面可以按类别呈现；
3. 命令是可过滤的，隐藏命令不会污染帮助；
4. 命令是可验证的，注册时就能检查参数和描述。

本质上，它把“行为入口”从代码逻辑里抽出来，变成了元数据。这样做后，CLI 不再是一个死板的程序入口，而是一个可以扩展的命令市场。你新增一个 command，不必重写整个主流程，只要注册定义即可。

如果用更朴素的话说：这套系统不是在“写命令行”，而是在“搭命令体系”。

4.2commands/register.ts：真正的业务意图都落在这里

注册文件里有大约二十多个命令，从login、logout到ask、explain、refactor、fix、generate，再到run、search、edit、git、history、help、reset、clear一类的会话和系统命令。

这说明它的命令设计不是围着一个“聊天窗口”转，而是围着“开发者工作流”转。也就是说，Claude Code 不是想替代终端，它是想接管终端里的某一段工作流：

1. 你可以问它问题；
2. 你可以让它解释代码；
3. 你可以让它生成或者改写代码；
4. 你可以让它跑命令并把结果解释回来；
5. 你可以让它做会话管理和状态控制。

这已经不是“聊天机器人”了，这是一个围绕编程动作组织起来的工作台。

从实现上看，register.ts里的命令处理也很像工程现场的作业单：每个命令先检查输入，再决定是否要调用 AI、是否要读取文件、是否要做格式化输出，最后把结果直接送回终端。它没有把业务逻辑写得很花，反而很朴素。这种朴素很重要，因为它让每个命令都足够直接，方便审计，也方便后续更换实现。

4.3config/index.ts：配置不是一个文件，而是一个合成层

配置层的设计是另一个非常工程化的地方。loadConfig()不会只看一个配置文件，而是按顺序从默认值、文件、环境变量、命令行参数里逐层合并。

这代表它在哲学上承认一件事：配置永远不是单一来源。真正的应用配置一定是多层叠加的，最底层是默认值，中间是磁盘文件，上层是环境变量，最外层才是 CLI 传参。这样做的好处有两个：

1. 对普通用户友好，因为默认值已经够用；
2. 对高级用户也友好，因为你可以在任意层覆盖。

而validateConfig()则体现了“法”的另一面：它不是无限宽松的。比如 API base URL、模型名、认证信息这些关键项，不合法就直接报错。它允许你改，但不允许你乱来。

这也是道法体术里“法”的真正含义：不是规定所有细节，而是划出底线。

4.4auth/index.ts：身份不是一个字符串，而是一个状态机

认证层如果只是“读个 API key”，那就太低估它了。AuthManager的设计很明显是一个小状态机：

1. 初始化时尝试读取存储的 token；
2. 如果 token 有效，就进入已认证状态；
3. 如果 token 过期但支持刷新，就尝试刷新；
4. 如果走 API key，就把 key 包装成 token 结构；
5. 如果走 OAuth，就保留 refresh token，支持后续续期；
6. 退出时清理凭证。

这套设计的重点，不在于“支持两种登录方式”，而在于“身份可以持续演化”。这对终端智能体很重要，因为它意味着用户不必每次都重新登录，也不必把身份管理交给外部脚本。

更妙的是，认证不仅是功能状态，也是权限闸门。cli.ts在执行某些命令前会检查requiresAuth，没有身份就不让进入 AI 相关流程。这比“进到一半再报错”要好得多，因为它把失败前移到了入口。

4.5errors/formatter.ts：错误不是堆栈，而是可读的决策提示

很多系统的错误设计只有一个目标：把异常打印出来。Claude Code 这套代码显然更在意“让用户知道下一步怎么办”。createUserError()和formatErrorForDisplay()的思路是：

1. 把系统异常包装成更友好的用户错误；
2. 为错误附上类别；
3. 为错误附上解决建议；
4. 在调试模式下再补充详细堆栈。

这意味着错误不是终点，而是下一步动作的起点。这个思想很符合智能体工具的要求：模型和人类都需要知道“为什么失败、怎么修、是否可重试”。

如果一个智能体系统只会说“failed”，那它就很难真正做事。因为失败信息本身就是推理输入。Claude Code 在错误层做得比较像一个成熟的运维系统，而不是一个玩具 demo。

五、体：它把“当前状态”看得很重

“体”这一层，我理解成运行时的身体。身体并不是抽象名词，而是所有能被观察、能被持久化、能影响下一步动作的东西。Claude Code 里最明显的身体感来自四处：

1. AuthManager的 token 状态；
2. config的合成结果；
3. 工作区和文件系统边界；
4. 终端交互能力和背景进程状态。

5.1 为什么状态要在中间层，而不是散落在各个命令里

很多 CLI 项目写到后面会变得很乱，原因是状态散得太开：一个命令里管登录，一个命令里管目录，一个命令里管模型，一个命令里管输出，最后每个命令都偷偷保存自己的小宇宙。Claude Code 的做法相对克制，它尽量把状态收进可复用对象里。

比如认证交给AuthManager，配置交给loadConfig()，AI 客户端交给AIClient，终端交给Terminal，文件系统交给FileOperationsManager或fs/operations.ts的工具函数。这样每层状态都有自己的宿主。

这个设计的意义是，命令只负责“发起任务”，不负责“保管世界”。这对于 agent 来说尤其重要，因为 agent 的会话会变长、动作会变多、错误会变复杂。如果每个命令都自己持有一份状态，最后根本没人知道真正的真相在哪。

5.2 token、workspace、缓存，是这个系统的三类“气血”

如果按中医的比喻，token、workspace 和缓存就像气血经络。

1. token 决定它能不能进入 Claude API；
2. workspace 决定它能在什么范围内操作文件；
3. 缓存决定它会不会重复消耗算力和时间。

这三个东西看起来都很技术，但实际上它们都是身体问题。token 是身份之气，workspace 是行动之身，缓存是记忆之脉。少了任意一个，系统都容易出问题。

auth/index.ts里对 token 的持久化和刷新，就是在延续身份；fileops/index.ts里对 workspace path 的处理，就是在限定身体活动范围；execution/index.ts里对 shell 环境和背景进程的管理，就是在安排身体怎么发力。

5.3 终端交互状态也是身体的一部分

terminal/index.ts很容易被忽略，但它其实很关键。因为它不是只是“输出美化”，它在决定系统有没有互动感。

它会做几件看上去很小、但实际很重要的事：

1. 检测终端是否交互；
2. 判断颜色是否可用；
3. 支持 spinner；
4. 支持表格；
5. 支持可点击链接；
6. 提供 prompt 输入。

这些动作共同构成了一个事实：Claude Code 不只是一个 API 调用器，它还是一个“能和人持续配合”的终端体。交互性是身体的一部分，不是附属品。因为没有互动，智能体就只能一次性输出；有了互动，它才有机会在多轮任务里纠偏、确认、追问、回收。

六、术：真正干活的是这些工具层

到了“术”的层面，系统开始落地。这里是最接近现实世界的地方，也是最容易看出工程成熟度的地方。Claude Code 的“术”主要分成五类：

1. AI 客户端；
2. 文件操作；
3. 命令执行；
4. 代码库分析；
5. 终端适配。

6.1ai/client.ts：把模型调用做成一个可靠的远程过程

AIClient的核心作用不是“调用一次 API”，而是把调用 API 这件事变成一个可以重试、可以超时、可以流式、可以测试连接的远程过程。

它做了几件很典型的工程动作：

1. 统一请求头；
2. 统一模型默认值；
3. 支持普通 completion 和 stream completion；
4. 对请求包一层超时；
5. 对网络错误做重试；
6. 提供testConnection()做连通性验证。

这说明它并没有把“模型服务”当成一个随时都在线、永远不会坏的神灵，而是当成一个现实中的外部依赖。外部依赖就要有超时、重试、失败回退和可观测性。

另外，它的消息结构也很重要。Message不是一段大字符串，而是有 role 的数组。这意味着对话历史是结构化管理的。结构化消息是智能体系统里的基础，不然后续的 prompt caching、计划模式、工具调用、状态回放都会很难做。

6.2fileops/index.ts和fs/operations.ts：文件系统不是“能读就读”，而是“安全地读”

这两个模块非常能体现 Claude Code 的边界意识。它们不是简单把fs.readFile包一下，而是把文件操作变成了一套有防线的能力。

你会看到几个明显的设计点：

1. 路径校验；
2. 目录存在性检查；
3. 文件大小限制；
4. 读写分离；
5. 删除前确认目标存在；
6. 目录创建由显式选项控制；
7. 错误统一包装成用户可理解的格式。

尤其是路径处理，它会对输入路径做规范化，并尽量阻断目录穿越。这个细节很关键，因为一个 agent 如果能随便写到任意路径，那它就不再是助手，而是风险源。

所以这里的“术”不是炫技，而是束缚。它把“能做”压成“安全地做”。这在 agent 系统里比速度更重要。

6.3execution/index.ts：执行命令之前，先问自己是不是在拆房子

命令执行层是整个系统里最危险的地方，因为一旦让模型随便执行 shell，它就可以碰到真实世界。Claude Code 在这里做了两层缓冲：

1. 有危险命令模式的过滤；
2. 有前后台执行、超时、缓冲区、工作目录和环境变量控制。

这不是说它能把所有危险都挡住，不能。它能做的是把高风险动作尽可能拉回到可识别范围里。比如rm -rf /、对磁盘设备的写入、fork bomb 之类的命令会被显式标记为危险。这种做法的意义，在于把“明显会毁东西”的行为先挡掉。

然后是执行策略。它支持普通执行，也支持后台执行。普通执行用于短任务和需要结果回传的命令，后台执行用于长时间运行的流程。这样模型在做不同类型任务时就不用强行用一种执行方式。

这个模块的哲学其实很简单：命令不是“发出去就算”，命令是“在安全约束下送到 shell”。如果 shell 是现实世界的刀，那么这个层就是刀鞘。

6.4codebase/analyzer.ts：智能体要先知道它在什么森林里

代码库分析模块很容易被低估。很多人以为智能体就是“收到问题就回答”，但真正做开发的人知道，回答前得先知道项目结构、语言分布、依赖分布、文件数量、忽略模式。

analyzeCodebase()的设计说明 Claude Code 不是只会看单个文件，而是可以把整个目录树纳入分析。它会：

1. 递归扫描文件；
2. 忽略 node_modules、dist、build 等噪声；
3. 按语言统计；
4. 统计行数；
5. 对过大的文件做跳过；
6. 收集依赖关系。

这很像一个开山师傅先摸清山势。你不先知道哪条路是主路、哪些是支路、哪些是废道，就谈不上后续的重构、定位或者生成。

这个模块的重要性也在于，它把“读代码”从文件级提升到项目级。项目级理解是 agent 能不能像工程师的关键门槛。

6.5terminal/index.ts：终端不是输出器，而是人机协同界面

terminal/index.ts做的事情表面看都很常规：

1. 颜色输出；
2. 表格输出；
3. 链接输出；
4. prompt；
5. spinner；
6. 欢迎语；
7. 终端能力检测。

但它的意义不是“更好看”，而是“更可跟”。一个 agent 系统如果没有清晰的终端反馈，人类就很难知道它是在想、在做、在等还是挂了。

这点很现实。很多自动化程序失败之后用户只看到一堆日志，而 Claude Code 试图把交互做得更像一个配合良好的同事：它告诉你当前在做什么，哪里在等，哪里成功，哪里失败，接下来可以怎么继续。对人机协作来说，这种反馈不是装饰，是秩序。

七、把一次请求完整走一遍：从命令行到动作

如果把整个系统串起来，一次最普通的请求大概是这样的：

用户输入命令
  -> CLI 解析参数
  -> 注册命令 / 查找命令
  -> 校验认证状态
  -> 合并配置
  -> 初始化 AI 客户端
  -> 进入具体 handler
  -> handler 视任务调用 fileops / execution / codebase / terminal
  -> 返回结果并格式化输出

这个链路看起来不复杂，但它很讲究顺序。为什么先认证再初始化 AI？因为不该让未授权状态接触外部服务。为什么先合并配置再进入 handler？因为 handler 不该自己解析所有来源的配置。为什么 handler 里再调用 fileops 和 execution？因为命令只是入口，真正的动作应该集中在能力模块里。

这条链路最值得学习的地方，是它没有把“智能体”神化。它只是把一个复杂任务分解成几个清楚的阶段，每一阶段都能失败、都能报告、都能重试。真正强大的系统往往不是一步到位，而是把每一步都做得足够可控。

八、这套架构最值得抄的，不是功能，而是节制

如果只看功能列表，Claude Code 和很多 AI CLI 看起来差不多：问答、生成、解释、重构、执行、文件读写、日志、认证、配置。真正拉开差距的不是“它有没有某个按钮”，而是“它如何克制自己”。

我觉得这套系统最值得抄的地方有四个：

8.1 入口薄，边界厚

cli.ts极薄，但周边模块很厚。这样做的好处是未来可以换入口，甚至换界面，不需要重写整套智能体逻辑。今天是终端，明天可以是 Web、IDE、脚本或服务端代理。

8.2 能力拆分，而不是统一大杂烩

文件操作、命令执行、代码库分析、终端显示、认证、配置、AI 调用各自独立。这会显得“文件很多”，但这比一个巨型脚本稳定得多。

8.3 对风险有明确态度

危险命令、路径校验、文件大小限制、认证门槛、错误分级，这些都说明它默认把世界看成不完全可信的。这个态度是对的。因为 agent 一旦接入现实环境，默认就该保守。

8.4 工作流优先于模型崇拜

Claude Code 的强不是因为它会“说得更像人”，而是因为它把工作流写进了系统里。模型只是决策器的一部分，流程、状态、工具、边界才是真正让它能干活的东西。

九、它哪里还不够好：别把源码镜像当成神谕

如果只歌颂优点，就不算读源码，只算追星。Claude Code 这套设计也有很明显的局限。

9.1 prompt 权重太高，系统仍然依赖模型自律

从公开解析和代码结构看，它大量依赖 prompt、system reminder 和工具说明来约束模型。这样的系统优雅，但也脆弱。因为一旦模型偏离预期，系统层没有足够强的硬约束去纠正它。

9.2 命令执行虽然有危险过滤，但仍然不是沙箱

execution/index.ts的危险命令过滤只能挡住明显的风险，不能替代真正的隔离环境。只要 shell 还在，系统就还是暴露在现实环境里。也就是说，它是“受控”，不是“隔离”。

9.3 代码理解能力受限于文件扫描和上下文结构

代码库分析再强，也还是基于文件、目录、大小、忽略规则这种传统手段。它可以覆盖常见工程，但在超大仓库、非标准布局、动态生成文件或强依赖二进制资产的项目里，效果会明显打折。

9.4 交互体验强，但复杂协作仍有边界

终端交互做得再好，也只是终端交互。复杂多人协作、长链路审批、跨系统权限联动，这些问题不是一个 CLI 能完全解决的。Claude Code 把自己定位得很清楚：它是一个终端里的行动代理，不是整个组织的工作流引擎。

十、如果你想自己做一个 agent，我建议你先学这四个原则

10.1 先定义“道”，再写代码

不要先写一个ask()函数，再慢慢想系统应该做什么。先写清楚：

1. 你允许模型做什么；
2. 你禁止模型做什么；
3. 你遇到不确定时先问谁；
4. 你如何把行动变成可审计记录。

这是所有 agent 设计的起点。

10.2 把“法”做成元数据，不要只做成逻辑

命令、工具、模式、权限、分类，这些都应该尽量变成结构化数据。这样帮助页、调试、测试、文档和扩展才会自然长出来。只写 if/else，最后你会得到一团不可维护的胶水。

10.3 让“体”只保留必要状态

身份、配置、工作区、缓存、会话，保留这些就够了。不要让每个模块都自己存一份世界观。状态越分散，系统越难推理。

10.4 把“术”拆成可替换适配器

文件系统、命令执行、终端输出、代码分析、AI 调用，都应该是能替换的适配器。今天用 Anthropic 的 API，明天可以换别的模型；今天用 CLI，明天可以换 GUI 或服务端。只要适配器层清楚，外面一切都可以变。

十一、回到道家：为什么这套系统让我想到“守中”

最后我想把道家的比喻收一下。

“守中”不是啥都不做，而是不让系统偏到某一边去。Claude Code 的架构恰好就是在做这件事：

1. 它不让 prompt 独裁，所以有命令制度和错误层；
2. 它不让命令乱跑，所以有认证、配置和路径约束；
3. 它不让状态散掉，所以把身份、工作区和终端状态收拢；
4. 它不让工具失控，所以把文件、执行和分析拆开；
5. 它不让交互失真，所以把终端体验做得可见、可跟、可回收。

从这个角度看，Claude Code 的真正价值不是“会写代码”，而是它给出了一个很清晰的答案：智能体不是靠单一模型能力堆出来的，而是靠一套能把能力关进边界、再把边界转成动作的系统设计。

这也是我最想从这份源码里带走的东西。

它不是一个“更聪明的聊天框”。

它是一套把“想法”变成“动作”，把“动作”变成“可审计工程”的终端系统。

参考阅读

1. https://github.com/XingP14/claude-code
2. https://github.com/ghuntley/claude-code-source-code-deobfuscation
3. https://claudecoding.dev/posts/get-started/
4. https://dev.to/agenticloops-ai/disassembling-ai-agents-part-2-claude-code-28lb