架构总览
如果你想自己做一个 Claude Code，需要哪些模块
先说结论：别从“聊天 + 几个工具”开始想
很多人研究 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
这就是平台化起点。
一个更现实的分阶段路线
如果你真想自己做，别试图一步复刻 Claude Code。
更现实的路线是：
- 先做单会话主循环
- 再做文件和 Shell 工具
- 再补上下文和权限
- 再补任务状态系统
- 最后才考虑 MCP、远程、多 Agent
小结
如果你想自己做一个 Claude Code，最该先学到的不是某个神奇 prompt，而是这套模块化思路：
先有运行时，再有工具；先有上下文与权限，再谈自动化上限；先把单线程跑稳，再扩到平台化能力。
这也是 Claude Code 源码真正值得借鉴的地方。