先说结论：别从”聊天 + 几个工具”开始想
很多人研究 Claude Code 源码之后，第一反应是：”我是不是也能自己做一个类似的系统？”可以，但前提是你要先放弃一个误区：不要把它理解成”模型 + function calling + terminal UI”。从源码看，一个像样的 Claude Code，至少需要一整套运行时模块。
模块 1：入口与交互层
你至少需要一个明确的运行宿主：命令行、TUI、IDE 插件、Web UI。Claude Code 选的是终端 + React Ink。这不是唯一选择，但你必须先有一个稳定的交互外壳。
模块 2：会话主循环
这一层对应 Claude Code 的 QueryEngine.ts。没有它，你就只有零散 API 调用，无法形成真正任务闭环。主循环至少要负责：消息历史、模型调用、工具调用、结果回流、中断与预算、会话状态延续。
模块 3：统一工具协议
这层对应 Tool.ts。如果没有统一工具协议，系统很快会出现：每个工具输入格式不一致、权限难统一、UI 渲染难统一、扩展能力难接。所以工具协议几乎是底层地基。
模块 4：上下文装配系统
这是很多人最容易忽略的部分。你不仅要有模型，还要决定模型在每轮开始前看见什么：Git 状态、项目规则、memory 文件、当前日期、当前模式。Claude Code 的”懂项目”，很大程度就来自这层。
模块 5：权限与审批系统
一旦工具开始执行真实动作，权限系统就必须上线。否则它根本不适合进入工程现场。流程：工具调用请求 → 权限判断 → 允许/拒绝 → 用户审批。
模块 6：文件与 Shell 基础设施
如果你想做的是”工程助手”，这两类工具几乎不可缺：文件读写编辑、Shell/命令执行。因为没有它们，系统就很难完成真正闭环。
模块 7：状态与任务系统
只要你支持多轮会话、长命令、后台任务、多 Agent、远程会话，你就一定需要统一状态中心。这正是很多 demo 产品在往真实产品过渡时最容易垮掉的地方。
模块 8：扩展系统
当基础能力稳定后，你还会自然想要：插件、MCP、LSP、Skills、自定义 Agent。这就是平台化起点。
一个更现实的分阶段路线
- 先做单会话主循环
- 再做文件和 Shell 工具
- 再补上下文和权限
- 再补任务状态系统
- 最后才考虑 MCP、远程、多 Agent
小结
如果你想自己做一个 Claude Code，最该先学到的不是某个神奇 prompt，而是这套模块化思路：先有运行时，再有工具；先有上下文与权限，再谈自动化上限；先把单线程跑稳，再扩到平台化能力。这也是 Claude Code 源码真正值得借鉴的地方。