Sebastian Raschka对Claude Code 源码的分析：

姚姚林先

Sebastian Raschka对Claude Code 源码的分析：

------------------------
Claude Code 真正的核心优势（很可能）不在模型本身

今天似乎曝出了 Claude Code 的源码。我在 GitHub 上看到了几份 TypeScript 代码库的快照。出于法律原因，我不想在这里放链接，但里面确实有一些值得学习的细节。

当然，大家大概都知道，Claude Code 在编程任务上比 Claude 网页聊天更强，原因并不是“给聊天界面外面套了一层 shell”，而是它本质上更像一个经过精心设计的工具系统，并且在提示词和上下文处理上做了不少优化。

我也得说明，很多定性的编程能力当然还是来自模型本身；但我认为，Claude Code 之所以这么强，更关键的是这套软件层的“支撑框架（software harness）”。也就是说，如果把其他模型——比如 DeepSeek、MiniMax 或 Kimi——接进来，再针对这些模型做一些优化，同样也可能得到非常强的编程表现。

下面这些点，主要是出于学习目的，帮助理解代码代理（coding agent）是怎么工作的。

1. Claude Code 会构建实时仓库上下文

这点可能最直观：当你开始输入提示时，Claude 会加载主分支、当前分支、最近的提交记录等信息，还会把 CLAUDE.md 一并纳入上下文。

2. 激进地复用 Prompt 缓存

里面似乎有一种“边界标记”机制，用来区分静态内容和动态内容。也就是说，那些静态部分会被全局缓存起来，以保证稳定性，也避免每次都重新构建和重新处理那些开销很大的内容。

3. 它的工具链，比“上传文件后聊天”强得多

从提示内容看，系统会引导模型优先使用专门的 Grep 工具，而不是通过 Bash 去调用 grep 或 rg。原因大概是，这种专用工具在权限控制上更好，而且结果收集机制也可能更完善。

另外，它还有专门的 Glob 工具用于文件发现；还有一个 LSP（Language Server Protocol，语言服务器协议）工具，用来做调用层级分析、查找引用等。这相较于普通聊天界面是很大的增强——因为聊天界面里，代码更像是“静态文本”，而不是可被语义化理解和导航的程序结构。

4. 尽量减少上下文膨胀

处理代码仓库时，最大的一个问题当然是上下文窗口有限。尤其当你和代理来回多轮交互、反复读取文件、加入日志文件、长 shell 输出时，这个问题会更明显。

Claude Code 里有不少底层机制专门用来压缩这部分负担。比如，它会做文件读取去重：如果文件没有变化，就不再重复处理。

另外，如果某些工具输出太大，它会把结果写到磁盘里，而在上下文中只保留预览内容和文件引用。

当然，和现代 LLM 界面类似，它也会自动截断过长上下文，并在必要时触发自动压缩/摘要。

5. 结构化的会话记忆

Claude Code 会为当前对话维护一个结构化的 Markdown 文件，其中包含类似这样的分区：
会话标题
当前状态
任务说明
文件与函数
工作流
错误与修正
代码库与系统文档
学到的内容
关键结果
工作日志

这其实很像人类写代码时的习惯：会记笔记、做摘要、保留阶段性结论。

6. 它会使用 Fork 和子代理

这点应该不算意外：Claude Code 会通过子代理并行处理任务。很长一段时间里，这几乎就是它相对 Codex 的卖点之一（直到 Codex 最近也开始支持子代理）。

在这里，fork 出来的代理会复用父代理的缓存，同时又能感知或处理可变状态。这样系统就可以把摘要、记忆提取、后台分析之类的旁路工作分出去做，而不会污染主代理循环的上下文。

为什么它用起来、效果上都比网页 UI 里的编程体验更好

总的来说，Claude Code 之所以比纯网页 UI 更好用，不是因为提示词工程更强，也不只是因为模型更强，而是因为上面这些零碎但关键的性能优化和上下文管理机制共同叠加出来的效果。

当然，易用性本身也是一部分原因：所有内容都在本机上，组织得更清晰，而不是把文件上传到一个聊天界面里去处理。

#How I AI#