claude-reviews-claude：一份由 Claude 自己写的 Claude Code 架构分析
Claude reads its own source code — 17-chapter architectural deep-dive into Claude Code v2.1.88. EN/ZH bilingual.
秒懂
- 它是什么？
- 这个仓库不是代码，而是一套 17 章的工程分析文档，宣称由 Claude 阅读 Claude Code v2.1.88 的 TypeScript 源码后撰写。它的价值在阅读材料本身，不在可运行的软件。
- 适合谁用？
- 如果你在写 agent harness，或者需要理解一个生产级 CLI agent 的分层方式，这份 17 章文档值得按章节顺序读一遍，尤其是查询引擎、权限流水线和压缩系统三部分。如果你需要的是能跑的代码、可复现的基准或对 Claude Code 当前版本的描述，不要采用它：仓库里没有软件，分析对象固定在 v2.1.88。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 167 天前。
- 用什么语言写的？
- GitHub 没有给出这个仓库的主要语言。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的问题不是代码问题，而是理解问题
Claude Code 是一个闭源分发的产品，但它的源码结构通过 source map 等途径在社区中流传。README 明确列出两个还原仓库：instructkr/claw-code 和 ChinaSiro/claude-code-sourcemap。问题在于，还原出来的东西是 1,902 个文件、477,439 行 TypeScript，直接打开几乎读不下去。claude-reviews-claude 的定位就是在这堆文件之上加一层导读。
目标读者也很清楚。README 的章节表里反复出现的是查询循环、工具注册、权限流水线、上下文装配、压缩策略这类词，这些是写 agent 框架的人才会关心的东西。它不面向想学怎么用 Claude Code 的终端用户，也不面向想改 Claude Code 行为的人。作者在开头就把它定义成一份结构化的工程分析，包含架构图、代码走读和设计模式，而不是源码归档。
这里有一个需要读者自己判断的地方：文档自称由 Claude 撰写。仓库没有给出可核验的生成流程或人工审校记录，所以这个说法本身只能当作项目叙事来读。真正决定它有没有用的是内容是否具体，而不是谁写的。
17 章按子系统切分，而不是按文件目录切分
README 给出了一张完整的章节表，从第 0 章架构总纲到第 17 章遥测、隐私与运营控制。每一章都标注了主题、能学到什么，以及被分析代码的规模。比如第 1 章查询引擎标注核心引擎 1296 行，第 4 章插件系统标注 1.88 万行，第 6 章 Bash 执行引擎标注 1.15 万行，第 13 章桥接系统标注 1.17 万行。
这些行数标注是这份文档最实用的部分之一。它让你在打开某一章之前就知道自己面对的是多大的一个子系统，也让你能判断哪几章值得细读。插件系统 1.88 万行和压缩系统 3.9 千行显然不是同一个阅读量级。
章节的切分方式也透露了作者的取舍。它没有按 src/ 下的目录结构逐层展开，而是按运行时职责重组：工具系统、钩子系统、权限流水线、上下文装配、压缩系统。这种切法对想借鉴设计的读者更友好，代价是它和真实文件路径之间的对应关系需要读者自己去还原。文档没有承诺提供这种映射。
第 17 章的内容值得单独提一句。README 描述它覆盖双通道遥测、模型代号、卧底模式、远程紧急开关和未来路线图。这类运营层面的设计在常规架构文档里很少见，也是这份分析里信息密度可能最高的一章。
核心机制被概括成一个循环加六大支柱
README 用一张 ASCII 图给出了整体结构，把 Claude Code 拆成 System Prompt、工具系统、查询循环、上下文管理、权限与安全、多 Agent 集群、Skill 与 Plugin 六个部分。其中查询循环被单独画成流程图：用户输入进入 QueryEngine.query()，调用 Claude API 流式接口，如果 stop_reason 是 end_turn 就输出结果，如果是 tool_use 就经过权限检查、执行工具、把结果注回循环。
作者对这个设计的判断写在图下面：智能存在于 LLM 中，脚手架只是个循环。42+ 工具、7 层安全、4 层压缩、多 Agent 协调，全部是围绕这个循环的生产级 harness。这个判断是整份文档的论点，也是它区别于普通源码走读的地方。它不是在描述代码做了什么，而是在解释为什么这些代码长成这样。
需要留意的是，README 里同时出现了几个互相不完全一致的数字描述。六大支柱那张图写的是 4 层压缩，章节表第 11 章写的是三层压缩架构。工具数量在正文里写 42+，在架构概览里写 42+ 工具且每个 30+ 方法。这些差异可能来自不同章节的不同统计口径，但从 README 本身无法确认。读的时候以具体章节为准，不要把概览图里的数字当作定论。
怎么读：在线站点是主路径，GitHub 是备用
README 明确推荐在线阅读，站点部署在 GitHub Pages：https://openedclaude.github.io/claude-reviews-claude/zh-CN/。作者给出的理由是站点支持全文搜索、暗色模式和章节导航，阅读体验优于 GitHub 原生 Markdown 渲染。对一份 17 章、跨多个子系统的长文档来说，全文搜索不是锦上添花，而是能不能用起来的差别。
仓库本身是双语结构，根目录 README 为中文，README_EN.md 为英文，站点也在路径上区分语言。章节链接的格式是 https://openedclaude.github.io/claude-reviews-claude/zh-CN/chapters/01-query-engine 这样的形式，第 0 章总纲则挂在 /zh-CN/overview 下。
如果你打算在本地读，需要知道这个仓库里没有构建脚本、没有依赖清单、也没有可执行的分析工具。它是一份文档仓库，克隆下来得到的是一组 Markdown 文件，本地阅读会失去站点提供的搜索和导航。README 里也没有提到任何 CLI、npm 包或安装命令，所以不存在“把它跑起来”这一步。
这也是评估这个项目时最容易搞错的地方：它不是软件，没有运行时，没有配置项需要填写。你能做的只有读。
它的边界：版本冻结、无验证、无更新承诺
第一个限制写在标题里：分析对象是 Claude Code v2.1.88。这是一个快照，不是一个持续跟踪的项目。Claude Code 的迭代速度在 README 的叙述里被反复强调，这意味着文档描述的实现细节会随着上游版本推进而失效，而且失效速度不会慢。仓库最后一次推送时间是 2026 年 4 月 1 日，没有发布任何 release，所以也没有版本化的文档快照可供对照。
第二个限制是内容无法独立验证。文档描述的是源码行为，但源码本身来自社区还原仓库，不是官方发布。还原过程是否完整、是否与 v2.1.88 官方构建一致，README 没有说明。你在文档里读到的任何机制，如果要用于实际决策，都需要回到源码自己确认一遍。
第三个限制是它不能替代 API 文档或使用文档。17 章里没有任何一章讲怎么调用 Claude Code、怎么写 CLAUDE.md、怎么配权限规则给最终用户看。第 7 章讲权限流水线的七层纵深防御，讲的是实现，不是配置方法。
最后一个需要直说的问题：README 的写作风格偏营销，用了追剧、Season 1 完结、点 Star 当订阅这类表述，正文里还夹着 emoji 和徽章。这不影响内容本身，但会影响你对它的第一印象。把它当成一份写得比较随意的技术长文，比当成正式技术报告更贴近实际。
和直接读源码相比，差别在取舍
最直接的替代方案就是 README 自己列出的那两个还原仓库：instructkr/claw-code 和 ChinaSiro/claude-code-sourcemap。它们的区别不是质量高低，而是你拿到的东西完全不同。
还原仓库给你的是 1,902 个文件、477,439 行 TypeScript 的完整代码。你能看到真实的类型定义、真实的错误处理分支、真实的边界条件。代价是你得自己决定从哪读起，而面对一个 1296 行的 QueryEngine 和 1.88 万行的插件系统，这个决定并不容易做。
claude-reviews-claude 给你的是别人已经做完的取舍：哪些子系统重要、它们之间怎么连接、哪些设计值得迁移。代价是你看到的是经过一层概括和判断的版本，细节被省略，而且这层概括的质量你无法逐条核对。
一个实际的做法是两者对照着用。先读某一章建立整体印象，再回到对应的源码文件确认你真正关心的那个分支。文档第 6 章标注 Bash 引擎 1.15 万行，第 13 章标注桥接系统 1.17 万行，这些数字能帮你判断该在哪一章停下来去翻源码。
需要注意的是，这份文档没有提供章节到文件路径的映射表，所以对照过程需要你自己找入口。
维护成本、许可与采用建议
维护成本这一项几乎不需要讨论，因为这不是一个需要维护的依赖。它没有运行时，不会引入漏洞，不会破坏你的构建。你唯一需要承担的成本是阅读时间，以及文档随上游版本过期后重新判断可信度的成本。
许可方面，仓库采用 MIT。对一份文档来说，这个许可意味着你可以复制、修改、再分发内容，包括用于内部培训材料，条件通常是保留版权声明和许可文本。README 没有对文档内容单独声明额外限制，也没有提到对还原源码仓库的任何授权关系，那两个仓库的许可需要各自查看。以上只是对 MIT 条款的一般性说明，具体使用场景请自行确认或咨询法务。
采用建议按读者类型分开。写 agent 框架或做工具编排的工程师，可以从第 1 章查询引擎、第 2 章工具系统、第 7 章权限流水线、第 11 章压缩系统这四章入手，它们对应的是 harness 设计里最难自己摸索的部分。做 agent 产品但不写底层的人，第 0 章总纲加第 3 章协调器、第 8 章 Swarm 可能更有用。只想了解 Claude Code 怎么工作的人，读总纲就够了，17 章全读的投入产出比不高。
不该采用的情况也要说清楚。需要当前版本行为描述的人不该用它，因为文档冻结在 v2.1.88。需要可运行参考实现的人不该用它，因为仓库里没有代码。需要权威规格说明的人也不该用它，因为内容未经独立验证。
动手前的具体检查项有三个：在线阅读站点是否可访问，你的目标子系统是否在 README 列出的 17 章范围内，以及你能否接受所有实现细节都需要回到还原源码二次确认。
编辑结论
如果你在写 agent harness，或者需要理解一个生产级 CLI agent 的分层方式，这份 17 章文档值得按章节顺序读一遍，尤其是查询引擎、权限流水线和压缩系统三部分。如果你需要的是能跑的代码、可复现的基准或对 Claude Code 当前版本的描述，不要采用它：仓库里没有软件，分析对象固定在 v2.1.88。动手之前先确认两件事：在线阅读站点是否可访问，以及你关心的子系统是否落在 README 列出的 17 章范围内。
社区笔记