Claude Code 泄露源码深度分析 - 512,000 行代码揭示的生产级 Agent 架构 / Claude Code Source Analysis and Production Agent Architecture

📅 创建时间：2026-05-08 🏷️ 标签：#ClaudeCode #源码泄露 #Agent架构 #PermissionModel #AntiDistillation 📚 前置知识：[[00-agent-overview]]

前言

2026 年 3 月 31 日，Anthropic 意外暴露了 Claude Code 的完整源码。一个缺失的 .npmignore 条目，Bun 打包器的默认行为，一个 59.8 MB 的 Source Map 文件。

512,000 行 TypeScript。1,906 个文件。

Anthropic 确认是"发布配置中的人为错误，不是安全漏洞"。没有客户数据泄露。但在补丁发布之前，开发者们已经将代码镜像到了 GitHub 的各个角落。一个叫 "claw-code" 的仓库在 24 小时内获得了 100,000 星——据报道是 GitHub 有史以来最快的增长纪录。

8,100+ 个 GitHub 仓库收到了 DMCA 删除通知，包括一些合法的 fork 和分析仓库。社区愤怒，Anthropic 撤回了大部分过于宽泛的通知。

这不是本文要讨论的故事。

本文要讨论的是：512,000 行代码揭示了什么工程现实。

第1部分：Claude Code 不是什么

1.1 错误的认知

大多数人对 Claude Code 的心理模型是：一个聊天界面，可以运行终端命令。

这是错的，而且错得重要。

Claude Code 是一个"Agentic Harness"——一个编排层，用工具包装语言模型，赋予它管理文件、执行 bash 命令、协调子 Agent、在长程多步会话中维护连贯状态的能力。

当你使用 Claude Code，你实际上在和大约 1,900 个 TypeScript 文件交互，这些文件专门负责管理模型能看到什么、允许做什么、以及出问题时的行为。

1.2 数字背后的真相

泄露源码揭示的一些数字应该重塑你的认知：

QueryEngine.ts → 46,000 行
基础工具定义 → 29,000 行
bashSecurity.ts → 2,592 行
内置工具总数 → 66 个

QueryEngine 是最大的单个模块
负责所有 LLM API 调用、流式处理、缓存、Token 计数
成本追踪、Prompt 缓存和重试逻辑

这不是代码膨胀。这是当每个组件都被认真对待时，生产级架构的实际样子。

到 2026 年初，Claude Code 的年化收入运行率估计达到 25 亿美元（来自 getpanto.ai 的报告）。这个运行率衡量的不是底层模型有多好——衡量的是 Harness 有多重要。

第2部分：架构概览——三层结构

2.1 三大核心组件

┌─────────────────────────────────────────────────────────────┐
│                    Claude Code 架构三层                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  编排循环（Orchestration Loop）                              │
│  ┌─────────────────────────────────────────────────────┐   │
│  │ while not done:                                       │   │
│  │   model.generate()                                   │   │
│  │   if tool_calls: execute_tools()                    │   │
│  │   results → model.generate()                        │   │
│  │ 复杂度不在循环设计，在保护它的东西：                   │   │
│  │ 上下文管理 + 权限门卫 + 重试逻辑 + 子 Agent 协调      │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  工具系统（Tool System）                                   │
│  ┌─────────────────────────────────────────────────────┐   │
│  │ ~40 个独立工具模块                                    │   │
│  │ BashTool, FileReadTool, GrepTool, WebFetchTool ...  │   │
│  │ 每个工具有自己的输入 schema、权限级别、执行逻辑        │   │
│  │ 工具之间没有共享可变状态                              │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  记忆架构（Memory Architecture）                            │
│  ┌─────────────────────────────────────────────────────┐   │
│  │ 三层设计                                              │   │
│  │ 短程：活跃上下文窗口                                 │   │
│  │ 中程：CLAUDE.md 文件                                 │   │
│  │ 长程：自动压缩 + 结构化摘要                           │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

2.2 工具设计哲学

Claude Code 的工具有一个核心设计规则：不要为通用目的创建工具，专用的更好。

Bash 工具的描述明确警告不要用它执行 find、grep、cat、head、tail、sed、awk、echo——不是因为这些命令危险，而是因为为每个操作提供专用工具能产生结构化、可审计的日志。

Grep 调用 → 带类型参数的调用 → 观测简单
bash -c "grep -rn 'pattern' ." → 需要解析

每个工具都有独立的权限级别和验证逻辑。Edit 工具要求之前必须有 Read——防止盲目覆盖。

第3部分：记忆架构——索引优于整体

3.1 单体记忆 vs 索引记忆

┌─────────────────────────────────────────────────────────────┐
│                    两种记忆模式对比                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  单体记忆（常见模式）：                                     │
│  • 把整个项目上下文加载到每次 prompt                       │
│  • 上下文窗口快速被过时信息填满                             │
│  • 不区分近期和历史数据                                    │
│  • Token 成本随项目规模线性增长                           │
│                                                             │
│  索引记忆（Claude Code 模式）：                             │
│  • MEMORY.md 索引始终加载，每条最多 150 字符               │
│  • 主题文件按需加载                                       │
│  • 对话记录只通过 grep 访问                                │
│  • Token 成本随任务相关性增长，不随项目大小                  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

3.2 三层详解

第一层：MEMORY.md（永久索引）

每个条目最多 150 字符，始终加载到每次对话。想象成书的目录——短引用告诉系统它知道什么，但不消耗太多上下文空间。

第二层：主题文件（按需加载）

覆盖特定主题的较长文档。只在当前任务需要时加载到上下文。当 Agent 在处理前端样式时，不会加载关于数据库迁移的信息。

第三层：对话记录（最严格限制）

之前的对话记录完全不加载到上下文。只能通过 grep 风格搜索访问，意味着 Agent 必须主动查找过去信息，而不是被动接收。

3.3 关键设计：记忆是提示，不是真理

Claude Code 最重要的设计决策：记忆是提示，不是真理。

在基于任何记忆条目行动之前，Claude Code 会验证它是否与代码库的实际当前状态相符。这个"验证后再行动"的模式防止了最常见的生产故障模式：基于过时或不正确信息做修改。

第4部分：上下文压缩——三档策略

4.1 三档压缩

Claude Code 使用三种不同的压缩策略，每种在会话生命周期的不同点触发：

┌─────────────────────────────────────────────────────────────┐
│                    Claude Code 三档压缩系统                     │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  MicroCompact（微压缩）                                      │
│  ┌─────────────────────────────────────────────────────┐   │
│  │ 零 API 调用的本地编辑                               │   │
│  │ 旧工具输出直接在对话状态中修剪                        │   │
│  │ 快速、便宜、对用户透明                               │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  AutoCompact（自动压缩）                                    │
│  ┌─────────────────────────────────────────────────────┐   │
│  │ 对话接近上下文窗口天花板时触发                        │   │
│  │ 保留 13,000 token 缓冲区                            │   │
│  │ 生成最多 20,000 token 的结构化摘要                   │   │
│  │ 内置熔断器：连续三次失败后停止重试                   │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  Full Compact（完全压缩）                                   │
│  ┌─────────────────────────────────────────────────────┐   │
│  │ 压缩整个对话                                          │   │
│  │ 重新注入最近访问文件（每文件最多 5,000 tokens）      │   │
│  │ 保留活跃计划 + 相关 skill schema                     │   │
│  │ 工作 token 预算重置为 50,000                        │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

4.2 背景故事：250,000 次 API 调用/天

在泄露的代码中，工程师们发现了一个 bug：autocompaction 系统的自动重试在失败时无限循环。它每天燃烧约 250,000 次 API 调用——全球每个用户。直到一个工程师用三行代码修复。

三行代码。修复了一个无限循环的自动压缩逻辑。

第5部分：权限系统——四层 + 23 项 bash 安全检查

5.1 四层权限模型

┌─────────────────────────────────────────────────────────────┐
│                    Claude Code 四层权限模型                    │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Plan（规划模式）                                          │
│  ┌─────────────────────────────────────────────────────┐   │
│  │ 只读分析                                             │   │
│  │ Agent 可以读文件、搜索代码、解释逻辑                   │   │
│  │ 禁止：任何写入、bash、网络请求                        │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  Standard（标准模式）                                      │
│  ┌─────────────────────────────────────────────────────┐   │
│  │ 高风险操作需要用户确认                               │   │
│  │ 允许：文件编辑、bash 执行、网络访问                   │   │
│  │ 危险操作前需要确认（如 rm、git push --force）        │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  Auto（自动模式）                                          │
│  ┌─────────────────────────────────────────────────────┐   │
│  │ 预批准的操作自动执行                                 │   │
│  │ Agent 自行判断风险等级                               │   │
│  │ 高风险仍需确认                                        │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  Bypass（旁路）                                           │
│  ┌─────────────────────────────────────────────────────┐   │
│  │ 内部系统调用，无任何检查                             │   │
│  │ 仅框架自身使用                                        │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

5.2 信任序列

权限在 Claude Code 中是正确性问题，不是 UX 问题。安全约束在工具描述中直接嵌入——就在模型在调用时看到的位置。

这是一个架构决策，不只是文档风格。模型在治理其行为的指令出现在它所控制的动作的上下文中，比藏在 10,000 tokens 之前的地方更可靠。

5.3 bashSecurity.ts——23 项安全检查

2,592 行，23 个编号的安全检查。每个检查背后都有一个真实事件。

特别值得注意的是 Zsh 特定的防御。Claude Code 在 macOS（Catalina 之后默认 Zsh）上运行，Anthropic 发现了 Zsh 扩展语义中独特的攻击向量。=cmd 扩展——=curl 被替换为 /usr/bin/curl——可以绕过 naive 命令黑名单。23 个检查。23 个事件。

第6部分：多 Agent 编排——提示，不是代码

6.1 发现：编排是 prompt，不是代码

泄露中最令人惊讶的发现之一：coordinatorMode.ts——处理多 Agent 协调的模块——完全作为系统提示指令实现。

不是代码级编排逻辑，不是单独的调度服务，不是消息总线。协调者收到一个 prompt，描述如何委托工作、从子 Agent 聚合什么、如何综合结果。

一个指令嵌入协调者的 prompt 中："Never write 'based on your findings'——这些短语把理解委托给 workers 而不是自己做。"这是文本文件中的质量门禁。这个指令阻止协调者成为被动继电器——不综合结果，只是 rubber-stamp 子 Agent 返回的任何东西。

6.2 为什么重要

因为它是 prompt 驱动的，Anthropic 可以在不重新部署的情况下更新编排行为。但代价是更难正式测试——但迭代速度是真实的。

第7部分：44 个功能标志——路线图泄漏

7.1 最重要的未发布功能

源码中有 44 个功能标志揭示了 Anthropic 的方向。

┌─────────────────────────────────────────────────────────────┐
│                    值得关注的未发布功能                        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  KAIROS（最重要的发现）                                     │
│  ┌─────────────────────────────────────────────────────┐   │
│  │ 一种自主守护进程模式                                   │   │
│  │ 将 Claude Code 从请求-响应工具                       │   │
│  │ 转变为持续后台进程                                   │   │
│  │                                                     │   │
│  │ • 维护仅追加的每日日志文件                           │   │
│  │ • 接收定期心跳 prompts，决定是否主动行动              │   │
│  │ • 强制 15 秒阻塞预算（动作不超过 15 秒）            │   │
│  │ • 监视 GitHub webhooks 获取新 issue 和 PR            │   │
│  │                                                     │   │
│  │ 代码中有 150+ 处引用。功能完全构建。                 │   │
│  │ 藏在功能标志后面。                                   │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  COORDINATOR（多 Agent 协调）                              │
│  ┌─────────────────────────────────────────────────────┐   │
│  │ 多 Agent 编排，明确质量门禁                           │   │
│  │ 内部 prompt："不要 rubber-stamp 弱工作"              │   │
│  │ 协调者 Agent 被设计为能拒绝子 Agent 的不合格输出     │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  ULTRAPLAN（云端深度规划）                                 │
│  ┌─────────────────────────────────────────────────────┐   │
│  │ 云端 Opus 4.6 模型，运行长达 30 分钟                │   │
│  │ 浏览器内成本批准流程                                │   │
│  │ 复杂多步任务的深度处理                               │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  BUDDY（最意外的功能）                                     │
│  ┌─────────────────────────────────────────────────────┐   │
│  │ Tamagotchi 风格的 ASCII 虚拟宠物                    │   │
│  │ 18 种可能的物种                                     │   │
│  │ 动态属性包括 "Debugging" 和 "Snack"                 │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

7.2 autoDream

作为 KAIROS 的配套，services/autoDream/ 目录中有一个 fork 子 Agent 伴侣。在空闲期间，它综合 Agent 在活跃会话期间观察到的东西，移除记忆中的矛盾，把原始观察转化为结构化的长期事实。

夜间记忆提炼——系统回顾自己的一天，在下一次会话开始前给自己写连贯的笔记。没有主要开源 Agent 框架发布了类似的东西。

第8部分：反蒸馏——保护模型的三个层次

8.1 泄露揭示的防御机制

Anthropic 构建了三层保护来防止竞争对手通过 API 交互提取 Claude 的能力：

┌─────────────────────────────────────────────────────────────┐
│                    三层反蒸馏保护                            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  第一层：假工具注入                                        │
│  ┌─────────────────────────────────────────────────────┐   │
│  │ anti_distillation: ['fake_tools']                  │   │
│  │ 在 API 响应中注入不存在的假工具定义                 │   │
│  │ 如果竞争对手抓取 Claude 输出训练自己的模型，           │   │
│  │ 假工具会成为训练数据的一部分                         │   │
│  │ → 训练出的模型尝试调用不存在的工具                  │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  第二层：连接文本                                         │
│  ┌─────────────────────────────────────────────────────┐   │
│  │ 在推理步骤之间插入加密签名的摘要                    │   │
│  │ 摘要看起来像自然语言，但包含嵌入签名                 │   │
│  │ 从 API 输出中提取 Claude 的决策过程变得更难         │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  第三层：原生客户端证明                                    │
│  ┌─────────────────────────────────────────────────────┐   │
│  │ Zig-based HTTP 栈作为 API 调用的 DRM              │   │
│  │ 验证请求来自真实的 Anthropic 客户端                   │   │
│  │ 而非自动化抓取工具                                   │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  安全研究者估计：所有三层都可以在大约一小时内绕过         │
│  → 这些是减速带，不是墙壁                                 │   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

第9部分：构建启示

9.1 从基础设施开始

Claude Code 泄露揭示的核心洞察：构建可靠的生产 Agent 需要什么。

这些不是理论观察，是经过大规模验证的工程模式：

启发1：索引优于整体
用轻量索引（MEMORY.md）始终加载，详细主题文件按需加载。
Token 成本随任务相关性增长，不随项目大小。

启发2：记忆是提示，不是真理
永远不要让 Agent 仅凭记忆行动。
在基于记忆条目做修改前，验证它与代码库的实际当前状态是否相符。
这个单一模式防止了 AI 编码工具中最常见的故障模式。

启发3：功能标志是标准实践
Anthropic 的 44 个功能标志表明即使是距发布还有数月的功能
也在代码库中完全实现和测试。
这将部署与发布解耦。

启发4：构建配置是安全表面
一个缺失的 .npmignore 行暴露了 512,000 行代码。
审计构建管道中意外的 source map 包含。
用与应用安全同等的严谨对待构建配置。

启发5：挫败感作为反思触发
当用户在 prompt 中骂人时，说明交互中出了根本问题。
用便宜的正则模式匹配检测挫败感，触发模式改变：
放慢、提问、避免假设。
几乎不花任何成本，但能捕获真实问题。

9.2 行动清单

立即行动：审计构建管道中的 source map 泄露
本季度：实现功能标志作为标准实践
本季度：评估 Agent 的记忆架构
中期：评估自有 API 的反蒸馏需求
持续：监控 KAIROS 开发

第10部分：地板刚刚变了

Claude Code 泄露之前，构建可靠的 Agent 需要数月的积累试错，而这些大厂没有分享。

那个限制不存在了。

泄露揭示的硬性部分是：构建生产 Agent 的难点从来不是模型。它一直是 Harness——上下文管理、权限架构、工具注册表、编排逻辑、在会出故障地方的断路器。

Anthropic 在这个 Harness 上花了数年和大量工程努力。蓝图现在是公开知识，被数千开发者在一个周末内分析。

在接下来 12 个月交付可靠 Agent 的团队不会是拥有更好模型的团队。他们是在模型质量成为商品之前认真对待架构的团队。

地板刚刚变了。大多数团队还没注意到。

Claude Code 泄露源码深度分析 - 512,000 行代码揭示的生产级 Agent 架构 / Claude Code Source Analysis and Production Agent Architecture ​

前言 ​

第1部分：Claude Code 不是什么 ​

1.1 错误的认知 ​

1.2 数字背后的真相 ​

第2部分：架构概览——三层结构 ​

2.1 三大核心组件 ​

2.2 工具设计哲学 ​

第3部分：记忆架构——索引优于整体 ​

3.1 单体记忆 vs 索引记忆 ​

3.2 三层详解 ​

3.3 关键设计：记忆是提示，不是真理 ​

第4部分：上下文压缩——三档策略 ​

4.1 三档压缩 ​

4.2 背景故事：250,000 次 API 调用/天 ​

第5部分：权限系统——四层 + 23 项 bash 安全检查 ​

5.1 四层权限模型 ​

5.2 信任序列 ​

5.3 bashSecurity.ts——23 项安全检查 ​

第6部分：多 Agent 编排——提示，不是代码 ​

6.1 发现：编排是 prompt，不是代码 ​

6.2 为什么重要 ​

第7部分：44 个功能标志——路线图泄漏 ​

7.1 最重要的未发布功能 ​

7.2 autoDream ​

第8部分：反蒸馏——保护模型的三个层次 ​

8.1 泄露揭示的防御机制 ​

第9部分：构建启示 ​

9.1 从基础设施开始 ​

9.2 行动清单 ​

第10部分：地板刚刚变了 ​

相关笔记 ​