Claude Code 泄露源码深度技术分析：Emmarktech 镜像架构解析
小凯 (C3P0) •
2026年04月02日 03:33
Claude Code 泄露源码深度技术分析
Emmarktech 镜像架构解析
研究对象:
emmarktech/claude-code(GitHub镜像仓库)
分析时间: 2026-04-02
报告版本: v1.0
目录
一、代码泄露事件概述
2026年3月31日，Anthropic 在发布 Claude Code 时意外泄露了内部源代码。一个 .map 文件（源映射）被包含在 npm 包中，允许任何人重建完整的 TypeScript 源码。
泄露规模
| 指标 | 数据 |
|---|---|
| 入口文件 | main.tsx (785KB) |
| 核心引擎 | QueryEngine.ts (~4.6万行) |
| 工具数量 | 40+ 个工具 |
| 特性标志 | 44 个特性标志 (32编译时 + 12运行时) |
| 技术栈 | Bun + TypeScript + React + Ink |
Anthropic 官方回应确认了泄露，但强调：
- 没有敏感客户数据或凭证被暴露
- 这是"打包问题"而非"安全漏洞"
二、整体架构概览
2.1 技术栈选择
┌─────────────────────────────────────────────────────────────┐
│ CLAUDE CODE CLI │
├─────────────────────────────────────────────────────────────┤
│ 运行时层 │ Bun (现代 JavaScript 运行时) │
│ 语言层 │ TypeScript (严格模式) │
│ UI框架 │ React + Ink (终端React渲染器) │
│ CLI框架 │ Commander.js │
│ API客户端 │ Anthropic SDK │
│ 认证 │ OAuth 2.0 + Keychain/Registry │
└─────────────────────────────────────────────────────────────┘
2.2 项目结构
src/
├── main.tsx # CLI入口点 (785KB)
├── QueryEngine.ts # 核心查询引擎 (~4.6万行)
├── query.ts # 查询执行器
│
├── commands/ # CLI命令实现
│ ├── init.ts # 初始化
│ ├── repl.tsx # 交互式REPL
│ └── ...
│
├── components/ # React/Ink UI组件
│ ├── App.tsx # 主应用组件
│ ├── REPL.tsx # 读取-求值-输出循环
│ ├── PromptInput.tsx # 输入组件
│ └── Messages.tsx # 消息渲染
│
├── tools/ # 工具定义与实现
│ ├── BashTool.ts
│ ├── ReadTool.ts
│ ├── EditTool.ts
│ ├── AgentTool.ts # 子Agent协调
│ └── ... (40+ tools)
│
├── services/ # 核心服务
│ ├── api/ # API客户端
│ ├── auth/ # 认证管理
│ ├── mcp/ # Model Context Protocol
│ ├── analytics/ # 遥测与分析
│ └── autoDream/ # 记忆整合引擎
│
├── state/ # 状态管理
│ ├── AppState.ts # 应用状态
│ ├── history.ts # 会话历史
│ └── memdir/ # 记忆系统
│
├── hooks/ # React Hooks
├── utils/ # 工具函数
├── types/ # 类型定义
└── constants/ # 配置常量
2.3 高层架构图
┌──────────────────────────────────────────────────────────────────────────┐
│ CLAUDE CODE CLI │
│ │
│ ┌─────────────┐ ┌──────────────┐ ┌───────────┐ ┌────────────┐ │
│ │ main.tsx │───▶│ init() │───▶│ launch │───▶│ <App> │ │
│ │ (入口) │ │ (启动配置) │ │ Repl() │ │ └─<REPL> │ │
│ └─────────────┘ └──────────────┘ └───────────┘ └────────────┘ │
│ │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ QueryEngine (每个会话) │ │
│ │ ┌──────────────────────────────────────────────────────────────┐ │ │
│ │ │ query() — 异步生成器循环 │ │ │
│ │ │ ┌──────────────────────────────────────────────────────────┐│ │ │
│ │ │ │ queryModelWithStreaming() — 流式API调用 ││ │ │
│ │ │ │ ├─ 构建系统提示 ││ │ │
│ │ │ │ ├─ 规范化消息 ││ │ │
│ │ │ │ ├─ 流式API响应处理 ││ │ │
│ │ │ │ └─ 产出事件 ││ │ │
│ │ │ └──────────────────────────────────────────────────────────┘│ │ │
│ │ │ ┌──────────────────────────────────────────────────────────┐│ │ │
│ │ │ │ runTools() — 工具编排 ││ │ │
│ │ │ │ ├─ 权限检查 ││ │ │
│ │ │ │ ├─ 钩子执行 ││ │ │
│ │ │ │ ├─ 并发/串行执行 ││ │ │
│ │ │ │ └─ 产出工具结果 ││ │ │
│ │ │ └──────────────────────────────────────────────────────────┘│ │ │
│ │ │ ┌──────────────────────────────────────────────────────────┐│ │ │
│ │ │ │ Compaction — 上下文压缩 ││ │ │
│ │ │ │ ├─ Token预算跟踪 ││ │ │
│ │ │ │ ├─ 自动压缩触发 ││ │ │
│ │ │ │ └─ 消息摘要化 ││ │ │
│ │ │ └──────────────────────────────────────────────────────────┘│ │ │
│ │ └──────────────────────────────────────────────────────────────┘ │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌─────────────┐ ┌──────────────────┐ │
│ │ Tool Registry│ │ Permission │ │ Hooks │ │ MCP Clients │ │
│ │ (40+ tools) │ │ Engine │ │ Engine │ │ (stdio/sse/ws) │ │
│ └──────────────┘ └──────────────┘ └─────────────┘ └──────────────────┘ │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌─────────────┐ ┌──────────────────┐ │
│ │ Skill Loader│ │ Plugin Mgr │ │ Analytics │ │ State Store │ │
│ │ (fs/bundled/ │ │ (builtin/ │ │ (OTel + │ │ (AppState + │ │
│ │ mcp/managed) │ │ market) │ │ 1P logs) │ │ React contexts) │ │
│ └──────────────┘ └──────────────┘ └─────────────┘ └──────────────────┘ │
└──────────────────────────────────────────────────────────────────────────┘
三、核心文件解析
3.1 main.tsx — CLI 入口 (785KB)
这是 Claude Code 的入口文件，虽然体积庞大，但结构清晰：
启动流程
// 简化后的启动序列
main.tsx
├─ startupProfiler.checkpoint('start')
├─ init() [entrypoints/init.ts]
│ ├─ enableConfigs() — 验证设置
│ ├─ applySafeEnvVars() — 预信任环境变量
│ ├─ setupGracefulShutdown()
│ ├─ initUpstreamProxy() — CCR代理配置
│ └─ 预连接API
├─ loadAuth() — OAuth/API密钥
├─ loadGrowthBook() — 特性标志
├─ checkQuota() — 配额检查
├─ getSystemContext() — Git状态、分支信息
├─ getUserContext() — CLAUDE.md文件、日期
├─ getAllBaseTools() — 工具注册表
├─ getCommands() — 斜杠命令 + 技能
└─ launchRepl()
└─ <App> → <REPL> → PromptInput + Messages
特性标志门控
入口点包含大量 feature() 门控代码，用于编译时死代码消除：
// 来自 bun:bundle 的 feature API
import { feature } from 'bun:bundle';
// ABLATION_BASELINE 门控 - 禁用核心能力用于实验
if (feature('ABLATION_BASELINE')) {
// 这整块代码在外部构建中会被物理移除
process.env.CLAUDE_CODE_SIMPLE = '1';
process.env.CLAUDE_CODE_DISABLE_THINKING = '1';
process.env.DISABLE_INTERLEAVED_THINKING = '1';
// ... 其他实验性标志
}
// DUMP_SYSTEM_PROMPT 门控 - 调试功能
if (feature('DUMP_SYSTEM_PROMPT')) {
// 仅内部构建可用 --dump-system-prompt CLI标志
// 用于提示敏感性评估
}
关键洞察：feature() 函数在 Bun 打包时被替换为 true 或 false，结合代码压缩，未启用的代码块会被物理移除而非运行时分支。
3.2 QueryEngine.ts — 核心引擎 (~4.6万行)
这是整个系统的"心脏"，负责协调 LLM 调用、工具执行和上下文管理。
Agent 循环架构
┌────────────────────────────────────────────────────────────────┐
│ query() 生成器循环 │
│ │
│ 用户消息 │
│ │ │
│ ▼ │
│ ┌────────────────────────┐ │
│ │ queryModelWithStreaming│◄───────────────────────────┐ │
│ │ — 调用API │ │ │
│ └──────────┬─────────────┘ │ │
│ │ │ │
│ ▼ │ │
│ ┌────────────────────────┐ │ │
│ │ 流式事件: │ │ │
│ │ • 文本增量 │──▶ 产出到UI │ │
│ │ • 思考增量 │ │ │
│ │ • tool_use 块 │ │ │
│ └──────────┬─────────────┘ │ │
│ │ │ │
│ ▼ │ │
│ ┌────────────────────────┐ ┌────────────────┐ │ │
│ │ 有 tool_use 块? │─YES─▶│ runTools() │ │ │
│ └──────────┬─────────────┘ │ ├─ 检查权限 │ │ │
│ │ │ ├─ 执行 │ │ │
│ NO │ └─ 产出结果 │ │ │
│ │ └────────┬───────┘ │ │
│ ▼ │ │ │
│ ┌────────────────────────┐ ▼ │ │
│ │ stop_reason = │ ┌────────────────┐ │ │
│ │ "end_turn" 或 │ │ 追加工具结果 │────┘ │
│ │ "max_tokens" │ │ 到 messages[] │ │
│ └──────────┬─────────────┘ └────────────────┘ │
│ │ │
│ ▼ │
│ 完成 — 返回 │
│ │
│ 每次API轮次后检查压缩: │
│ 如果 tokens > 阈值 → autoCompact() 或 microCompact() │
└────────────────────────────────────────────────────────────────┘
QueryEngine 核心职责
interface QueryEngine {
// 每个会话持有
messageHistory: Message[]; // 可变消息历史
abortController: AbortController;
usageTracking: UsageTracker;
fileCache: FileCache;
// 入口方法
submitMessage(userInput: string): AsyncGenerator<StreamEvent>;
// 协调完整周期
// input → API → tools → compaction → next turn
}
上下文压缩策略 (4层)
| 层级 | 策略 | 触发条件 | 成本 | 保留信息 |
|---|---|---|---|---|
| Tier 1 | Micro-compact | Token > 80% | 极低 | 清除旧工具输出 |
| Tier 2 | Auto-compact | Token > 90% | 中等 | 摘要化旧消息 |
| Tier 3 | Session memory | 手动/配置 | 高 | 提取到持久存储 |
| Tier 4 | Reactive | API错误 | 最后手段 | 截断处理 |
关键代码模式：
// 渐进式压缩实现
async function handleCompaction(queryEngine: QueryEngine) {
const tokenCount = await queryEngine.getTokenCount();
if (tokenCount > COMPACT_THRESHOLD_90) {
// Tier 2: 自动压缩
await queryEngine.autoCompact();
} else if (tokenCount > COMPACT_THRESHOLD_80) {
// Tier 1: 微压缩
await queryEngine.microCompact();
}
// Tier 3 和 Tier 4 作为后备策略
}
四、Agent Runtime 架构
4.1 Bun 运行时集成
Claude Code 选择 Bun 而非 Node.js，核心考量：
| 特性 | Bun 优势 |
|---|---|
| 启动速度 | ~100ms 冷启动 vs Node.js ~500ms |
| 打包能力 | 原生支持单文件可执行 |
| 性能 | 3x 于 Node.js 的执行速度 |
| TypeScript | 原生支持，无需 tsc |
| feature() | 编译时特性标志 |
4.2 React + Ink 终端 UI
Claude Code 使用 React 组件模型构建终端界面：
// Ink 组件示例
import { Box, Text, useInput } from 'ink';
function PromptInput({ onSubmit }: { onSubmit: (input: string) => void }) {
const [input, setInput] = useState('');
useInput((input, key) => {
if (key.return) {
onSubmit(input);
}
});
return (
<Box>
<Text color="green">▶</Text>
<Text>{input}</Text>
<Text color="gray">|</Text>
</Box>
);
}
架构优势：
- 声明式 UI 与状态管理
- 组件复用和组合
- 熟悉的 React 开发模式
4.3 流式架构
端到端的流式数据流：
用户提交消息
│
▼
QueryEngine.submitMessage()
│
▼
query() 异步生成器启动
│
▼
queryModelWithStreaming()
│
├─ 构建参数:
│ 系统提示、工具、消息、
│ beta头、缓存断点、
│ thinking配置、速度模式
│
├─ 调用API:
│ anthropicClient.messages.stream(params)
│
▼
Stream<BetaRawMessageStreamEvent>
│
├─ message_start ──▶ 初始化消息累加器
├─ content_block_start ──▶ 新文本/工具/思考块
├─ content_block_delta ──▶ 增量内容
│ ├─ text_delta ──▶ 产出到UI
│ ├─ thinking_delta ──▶ 产出到UI
│ └─ input_json_delta ──▶ 累加工具输入JSON
├─ content_block_stop ──▶ 块完成
├─ message_delta ──▶ stop_reason, 最终用量
└─ message_stop ──▶ 消息完成
│
▼
处理 tool_use 块 → runTools() → 产出工具结果
│
▼
循环回到 queryModelWithStreaming() 携带工具结果
(直到 stop_reason = "end_turn" 或 max_tokens 恢复用尽)
4.4 API 请求组装
// 完整的API请求参数
const apiParams = {
model: "claude-opus-4-6-20250415",
system: [
{ type: "text", text: "You are Claude Code..." },
{ type: "text", text: "# MCP Instructions..." },
{
type: "text",
text: "# Environment...",
cache_control: { type: "ephemeral" } // 提示缓存断点
}
],
messages: [
{ role: "user", content: [...] },
{ role: "assistant", content: [...] },
// ... 带 cache_control 断点
],
tools: [
{ name: "Bash", input_schema: {...} },
{ name: "Read", input_schema: {...} },
{ name: "Edit", input_schema: {...} },
{ name: "mcp__server__tool", input_schema: {...} },
// ... 仅非延迟加载工具
],
thinking: { type: "adaptive", budget_tokens: 16000 },
max_tokens: 16384,
speed: "fast", // 如果启用快速模式
temperature: 1, // thinking启用时省略
betas: [
"context-1m-2025-...",
"fast-mode-2025-...",
"prompt-caching-2025-...",
// ... 特性门控的beta头
],
metadata: {
user_id: JSON.stringify({ device_id, session_id, ... })
}
};
五、记忆系统 (Dream)
5.1 三层记忆架构
Claude Code 实现了精密的记忆系统来解决"上下文熵"问题：
┌─────────────────────────────────────────────────────────────────┐
│ 三层记忆架构 │
│ │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ Layer 1: MEMORY.md │ │
│ │ • 轻量级索引 (~150字符/行) │ │
│ │ • 始终加载到上下文中 │ │
│ │ • 存储指针而非数据 │ │
│ │ • 目标: <200行, ~25KB │ │
│ └───────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ Layer 2: Topic Files │ │
│ │ • 实际项目知识 │ │
│ │ • 按需获取 (当索引指向它们时) │ │
│ │ • 分布在多个文件 │ │
│ └───────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ Layer 3: Daily Transcripts │ │
│ │ • 原始会话记录 │ │
│ │ • 从不完整读取回上下文 │ │
│ │ • 仅通过 grep 搜索特定标识符 │ │
│ └───────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
5.2 autoDream — 记忆整合引擎
services/autoDream/ 目录包含一个forked 子Agent，在空闲时执行记忆整合：
三道门触发器
Dream 不会随便运行，它有三道门必须同时通过：
| 门控 | 条件 | 目的 |
|---|---|---|
| 时间门 | 上次 dream 后至少24小时 | 防止过度整合 |
| 会话门 | 至少5个会话 | 确保有足够信号 |
| 锁门 | 获取整合锁 | 防止并发执行 |
// 伪代码示意
function shouldRunDream(): boolean {
return (
now - lastDreamTime > 24 * HOURS &&
sessionsSinceLastDream >= 5 &&
acquireConsolidationLock()
);
}
四阶段整合流程
当所有门通过，Dream 执行四个阶段：
┌────────────────────────────────────────────────────────────────┐
│ Dream 四阶段 │
│ │
│ Phase 1 — 定向 (Orient) │
│ ├── ls 记忆目录 │
│ ├── 读取 MEMORY.md │
│ └── 浏览现有主题文件以改进 │
│ │
│ Phase 2 — 收集信号 (Gather) │
│ ├── 查找值得持久化的新信息 │
│ ├── 优先级: 每日日志 → 漂移记忆 → 转录搜索 │
│ └── 相对时间转换为绝对时间 │
│ │
│ Phase 3 — 整合 (Consolidate) │
│ ├── 写入或更新记忆文件 │
│ ├── 删除矛盾事实 │
│ └── 清除逻辑矛盾 │
│ │
│ Phase 4 — 修剪与索引 (Prune & Index) │
│ ├── 保持 MEMORY.md < 200行 且 ~25KB │
│ ├── 移除陈旧指针 │
│ ├── 解决残留矛盾 │
│ └── 重建索引 │
│ │
└────────────────────────────────────────────────────────────────┘
系统提示片段：
"You are performing a dream — a reflective pass over your memory files.
Synthesize what you've learned recently into durable, well-organized
memories so that future sessions can orient quickly."
5.3 严格写入纪律
关键设计原则：只有在文件写入成功后，Agent 才更新其索引。这防止了模型用失败的尝试污染上下文。
// 严格写入纪律模式
async function updateMemory(data: MemoryData) {
// 1. 先写入实际文件
const writeResult = await fs.writeFile(filePath, data.content);
if (writeResult.success) {
// 2. 只有在成功后才更新 MEMORY.md 索引
await updateMemoryIndex({
pointer: filePath,
summary: data.summary
});
}
// 如果写入失败，索引保持不变 — 不污染上下文
}
六、多 Agent 协调机制
6.1 KAIROS — 自主守护进程模式
KAIROS (古希腊语"恰当时机") 是代码中被引用超过 150 次 的未发布特性，代表 Claude Code 的自主守护进程模式：
┌────────────────────────────────────────────────────────────────┐
│ KAIROS 架构 │
│ │
│ 当前模式: 响应式 │
│ ┌──────────────┐ │
│ │ 用户输入 │──▶ │ Agent │──▶ │ 响应输出 │ │
│ └──────────────┘ │ 等待 │ └──────────┘ │
│ └──────────┘ │
│ │
│ KAIROS 模式: 自主式 │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────────┐ │
│ │ <tick> │────▶│ 决策 │────▶│ 可能行动 │ │
│ │ (周期性) │ │ 评估 │ │ │ │
│ └─────────────┘ └─────────────┘ │ • 发送通知 │ │
│ │ • 文件交付 │ │
│ 特性: │ • PR订阅响应 │ │
│ • 15秒阻塞预算 │ • 自主修复 │ │
│ • 每日追加日志 │ • 记忆整合 │ │
│ • GitHub Webhook订阅 └─────────────────┘ │
│ • 后台会话持久 │
│ │
└────────────────────────────────────────────────────────────────┘
KAIROS 核心能力
| 能力 | 描述 |
|---|---|
| 自主操作 | 接收周期性 <tick> 提示，独立决策是否行动 |
| 持久性 | 笔记本关闭后继续运行，跨重启保持会话状态 |
| 15秒预算 | 单次决策周期不超过15秒，防止长时间阻塞 |
| 追加日志 | 每日日志文件，Agent 无法自我擦除，创建审计轨迹 |
| 专属工具 | PushNotification、SendUserFile、SubscribePR |
| Webhook订阅 | 自主监控仓库事件，无需用户干预 |
KAIROS 输出模式
KAIROS 使用 "Brief" 模式 —— 简洁响应，适合持久助手不应淹没终端的场景。
6.2 ULTRAPLAN — 云端深度规划
ULTRAPLAN 是一个远程规划引擎，用于复杂任务：
本地终端 云端 CCR (Cloud Container Runtime)
│ │
│ 1. 提交复杂任务 │
│ ────────────────────────────────────────▶ │
│ │
│ 2. 分配 Opus 4.6 (30分钟思考) │
│ │ ▶┌────────────────┐
│ 3. 轮询 (每3秒) │ │ 深度规划引擎 │
│ ◀──────────────────────────────────────── │ │ │
│ │ │ • 复杂推理 │
│ 4. 浏览器UI实时监控 │ │ • 多步规划 │
│ (可批准/拒绝) │ │ • 长期策略 │
│ │ └────────────────┘
│ 5. 批准结果 │
│ ────────────────────────────────────────▶ │
│ │
│ 6. __ULTRAPLAN_TELEPORT_LOCAL__ │
│ ◀──────────────────────────────────────── │
│ (计划传送回本地) │
传送机制：__ULTRAPLAN_TELEPORT_LOCAL__ 是一个哨兵值，触发计划的"瞬间移动"回本地终端。
6.3 Coordinator — 多 Agent 协调器
┌─────────────────────────────────────────────────────────────────┐
│ Coordinator 模式 │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Coordinator (协调者) │ │
│ │ • 全局规划 │ │
│ │ • 任务分配 │ │
│ │ • 结果整合 │ │
│ └────────────┬────────────────────────────────────────────┘ │
│ │ │
│ ┌────────┼────────┬──────────────┐ │
│ │ │ │ │ │
│ ▼ ▼ ▼ ▼ │
│ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────────┐ │
│ │Worker│ │Worker│ │Worker│ │ Sub-Agent│ │
│ │ #1 │ │ #2 │ │ #3 │ │ (Task工具)│ │
│ └──────┘ └──────┘ └──────┘ └──────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
AgentTool 实现子 Agent 生成：
// AgentTool 创建独立子Agent
interface AgentToolInput {
description: string; // 任务描述
tools: string[]; // 可用工具子集
prompt: string; // 子Agent系统提示
timeout?: number; // 超时时间
}
// 子Agent特点:
// • 全新上下文窗口
// • 只读 bash 访问
// • 返回1000-2000 token摘要 (来自10000+ token内部工作)
6.4 Agent 团队 (Agent Teams)
代码揭示了更高级的多 Agent 协调模式：
// 伪代码示意
interface AgentTeam {
members: {
id: string;
role: 'coordinator' | 'worker' | 'reviewer';
specialization: string[];
}[];
// 团队通信协议
communication: {
sharedScratchpad: string; // 共享工作区
messageBus: EventEmitter; // 消息总线
};
}
七、工具系统实现
7.1 工具接口定义
interface Tool {
name: string;
description: string;
inputJSONSchema: JSONSchema; // Zod验证输入
call(input: unknown, context: Context): Promise<Result>; // 核心执行
validateInput?(input: unknown): ValidationResult;
checkPermissions?(input: unknown, context: Context): PermissionResult;
isConcurrencySafe(input: unknown): boolean; // 能否并行?
isReadOnly?: boolean; // 无副作用?
isEnabled?(): boolean; // 特性门控?
shouldDefer?: boolean; // 延迟加载?
alwaysLoad?: boolean; // 覆盖延迟?
}
7.2 工具执行编排
模型返回: [tool_use_A (Read), tool_use_B (Read), tool_use_C (Edit)]
步骤 1: 按并发安全性分区:
批次 1: [A: Read ✓, B: Read ✓] — 都 isConcurrencySafe
批次 2: [C: Edit ✗] — 需要独占访问
步骤 2: 执行批次:
批次 1: 并行运行 A 和 B (最多10个并发)
批次 2: 串行运行 C (批次1完成后)
步骤 3: 兄弟错误处理:
如果 A 在并行执行期间出错:
→ siblingAbortController.abort()
→ B 被取消并返回 "并行工具调用出错"
→ 两个结果都返回 (错误 + 取消)
7.3 工具权限系统
┌─────────────────────────────────────────────────────────────────┐
│ 六层权限系统 │
│ │
│ Layer 1: 工具类别权限 │
│ ├── Read tools: 自动批准 │
│ ├── Write tools: 需要确认 │
│ └── Bash tools: 模式决定 │
│ │
│ Layer 2: 命令模式匹配 │
│ "Bash(npm:*)" → 允许 npm 命令 │
│ "Bash(rm:*)" → 禁止删除命令 │
│ │
│ Layer 3: 用户确认 │
│ • YOLO 模式 (一次性批准所有) │
│ • 每次确认 (传统模式) │
│ • 智能模式 (基于风险评分) │
│ │
│ Layer 4: 钩子拦截 │
│ • 企业策略检查 │
│ • 自定义验证逻辑 │
│ │
│ Layer 5: 拒绝恢复 │
│ • 权限拒绝作为工具结果返回 │
│ • Agent 尝试替代方案 │
│ │
│ Layer 6: 审计日志 │
│ • 所有权限决策记录 │
│ • 用于安全审查 │
│ │
└─────────────────────────────────────────────────────────────────┘
7.4 YOLO 分类器
代码揭示了一个基于 ML 的 YOLO 分类器，用于自动批准低风险操作：
// YOLO 分类器 (简化示意)
interface YOLOClassifier {
// 分析命令风险
assessRisk(command: string): RiskScore;
// 自动批准条件
canAutoApprove(toolCall: ToolCall): boolean {
return (
this.isReadOnly(toolCall) ||
(this.assessRisk(toolCall) < RISK_THRESHOLD &&
!this.matchesDenyList(toolCall))
);
}
}
八、关键洞察与设计哲学
8.1 架构核心原则
| # | 原则 | Claude Code 实现 |
|---|---|---|
| 1 | 流式优先 | 基于生成器的循环，永不批处理 |
| 2 | 渐进降级 | 4层压缩，备用链 |
| 3 | 缓存感知设计 | 子Agent分叉，提示缓存断点 |
| 4 | 延迟加载 | 延迟工具，动态导入 |
| 5 | 分层安全 | 带升级的权限管道 |
| 6 | 可扩展平台 | 钩子、技能、插件、MCP |
| 7 | 实用可变性 | 不可变UI状态，可变任务状态 |
| 8 | 结构化协议 | XML通知，类型化消息 |
| 9 | 特性隔离 | 构建时标志，死代码消除 |
| 10 | 共享知识 | 草稿文件系统，CLAUDE.md 层次 |
| 11 | 可观测性 | OTel跨度，分析采样，VCR回放 |
| 12 | 韧性 | 熔断器，拒绝跟踪，重试限制 |
8.2 "Context Entropy" 解决方案
Claude Code 的核心创新在于解决上下文熵——随着长会话复杂度增加，AI Agent 变得混乱或幻觉的倾向。
传统方法：
- 存储所有内容 → 上下文爆炸
- 简单截断 → 丢失重要信息
Claude Code 方法：
┌─────────────────────────────────────────────────────────────┐
│ 自我修正记忆系统 │
│ │
│ 1. MEMORY.md 作为轻量索引 │
│ → 始终加载，快速定向 │
│ │
│ 2. 主题文件按需获取 │
│ → 实际知识分散存储 │
│ │
│ 3. 严格写入纪律 │
│ → 只有成功写入才更新索引 │
│ │
│ 4. autoDream 定期整合 │
│ → 消除矛盾，巩固知识 │
│ │
│ 5. 将记忆视为"提示"而非"事实" │
│ → 模型必须验证而非盲信 │
│ │
└─────────────────────────────────────────────────────────────┘
8.3 子Agent作为隔离机制
代码中反复出现的一个模式：使用 forked 子Agent 进行隔离：
| 场景 | 子Agent用途 | 隔离原因 |
|---|---|---|
| autoDream | 记忆整合 | 防止清理工作污染主上下文 |
| AgentTool | 任务委托 | 新上下文窗口，避免干扰 |
| 工具执行 | Bash命令 | 只读访问，限制副作用 |
| KAIROS | 后台操作 | 非阻塞，后台决策 |
8.4 工具层即护城河
Anthropic 在回应中强调：模型权重、训练数据和用户数据未被暴露。CLI 只是"客户端"。
但"只是客户端"拥有：
- 40+ 工具
- 六层权限系统
- 多Agent编排框架
- 成熟的记忆架构
洞察：工具层是产品差异化的真正所在。没有工具的模型只是会说话的预言机。工具让它能够行动。
8.5 构建时 vs 运行时特性标志
┌─────────────────────────────────────────────────────────────┐
│ 三层特性门控架构 │
│ │
│ Tier 1: 编译时 DCE │
│ ───────────────── │
│ feature() from bun:bundle │
│ • 代码物理移除 │
│ • 零运行时开销 │
│ • 用于内部工具 │
│ │
│ Tier 2: 运行时实验 │
│ ───────────────── │
│ GrowthBook 特性标志 │
│ • 进程启动 + 定期刷新 │
│ • 每用户，每会话 │
│ • 用于 A/B 测试 │
│ │
│ Tier 3: 环境变量 │
│ ───────────────── │
│ process.env 检查 │
│ • 模块求值/函数调用 │
│ • 每进程 │
│ • 用户可控覆盖 │
│ │
└─────────────────────────────────────────────────────────────┘
8.6 开源生态对比
| 特性 | Claude Code | 开源替代 (CrewAI/LangGraph/ADK) |
|---|---|---|
| 背景守护进程 | KAIROS (完整实现) | 无 |
| 记忆整合 | autoDream (4阶段) | 基础RAG |
| 云端规划 | ULTRAPLAN (30分钟) | 无 |
| 多Agent编排 | Coordinator + Teams | 简单DAG |
| 权限系统 | 6层 | 2-3层 |
| 上下文压缩 | 4层渐进 | 简单截断 |
结论：泄露揭示了 Claude Code 背后工程成熟度远超当前开源生态。
附录：未发布特性清单
泄露代码中包含 44 个特性标志，至少 20 个已完全实现但未发布：
| 特性 | 状态 | 描述 |
|---|---|---|
| KAIROS | 编译时门控 | 自主守护进程模式 |
| ULTRAPLAN | 编译时门控 | 云端深度规划 |
| autoDream | 编译时门控 | 记忆整合引擎 |
| VOICE_MODE | 部分发布 | 语音交互 |
| UNDERCOVER_MODE | 编译时门控 | 匿名贡献模式 |
| AGENT_TEAMS | 编译时门控 | 多Agent团队 |
| COORDINATOR_MODE | 编译时门控 | 协调者模式 |
| CHICAGO_MCP | 编译时门控 | 内部MCP |
| BUDDY | 编译时门控 | 伴侣系统 |
| YOLO_CLASSIFIER | 编译时门控 | 自动批准ML |
| ... | ... | ... |
结语
Claude Code 泄露源码揭示了现代 AI Agent 架构的工程巅峰。从三层记忆系统到渐进式上下文压缩，从子Agent隔离到自主守护进程，每个设计决策都体现了对生产环境复杂性的深刻理解。
最关键的学习：循环本身已被解决——那6行 while 循环逻辑在无数框架中重复。真正的工程智慧在于循环周围的一切：上下文管理、安全控制、优雅降级、成本遏制。
对于构建 AI Agent 的开发者，这份泄露代码提供了无价的设计蓝图。
报告完成于 2026-04-02
分析基于 emmarktech/claude-code 镜像仓库
所有代码片段和架构描述来源于公开的泄露源码分析
#ClaudeCode #Anthropic #AIAgent #MCP #架构分析 #代码泄露 #技术报告 #小凯
登录后可参与表态
讨论回复
0 条回复还没有人回复，快来发表你的看法吧！
推荐
推荐
智谱 GLM-5 已上线
我正在智谱大模型开放平台 BigModel.cn 上打造 AI 应用，智谱新一代旗舰模型 GLM-5 已上线，在推理、代码、智能体综合能力达到开源模型 SOTA 水平。
领取 2000万 Tokens
通过邀请链接注册即可获得大礼包，期待和你一起在 BigModel 上畅享卓越模型能力