Claude code的源码泄露

怎么泄露的

泄露的原因很简单

当你用 JavaScript/TypeScript 开发一个 npm 包时，构建工具通常会生成 source map 文件（.map 文件）。这个文件的用途是把打包压缩后的代码映射回原始源码，方便调试时定位问题。source map 文件里有一个 sourcesContent 字段，直接包含了每一个原始源文件的完整内容

正常情况下，.map 文件不应该出现在发布到 npm 的生产包里。你需要在 .npmignore 里排除它们，或者在构建配置里关闭 source map 生成

Claude Code 使用 Bun 作为打包工具。Bun 的打包器默认生成 source map，除非你显式关掉。这次泄露的直接原因，据社区分析，大概率是构建流水线里没有做好 .map 文件的清理，发布时把一个 59.8 MB 的 source map 文件一起发到了 npm registry

工具系统：40 多个权限控制的工具

Claude Code 的每一项能力都被封装成一个独立的工具模块，放在 tools/ 目录下。每个工具定义了自己的输入格式、权限模型和执行逻辑

已公开的核心工具包括：文件读写和编辑、Shell 执行（支持沙箱）、文件搜索、网页访问、Jupyter 笔记本编辑、子 Agent 调度、LSP 通信、MCP 资源访问等

工具的权限系统分为四个模式：default（交互式逐次询问用户）、auto（通过 ML 分类器自动决策）、bypass（跳过检查）、yolo（拒绝所有）。每个工具动作被分为低、中、高三个风险等级

查询引擎：46,000 行

query/ 目录是整个代码库里最大的单一模块，负责所有 LLM API 调用、流式传输、缓存和编排

系统提示词采用模块化设计，把提示词分成静态段（可跨用户缓存）和动态段（每次会话独立生成）。有一个函数叫 DANGEROUS_uncachedSystemPromptSection()，从命名就能看出来有人在这上面踩过坑

Dream 记忆系统：Claude 的「做梦」

services/autoDream/ 下有一个叫 autoDream 的后台记忆整合引擎

它的工作方式是这样的：当三个条件同时满足的时候（距上次执行超过 24 小时、至少经历了 5 次会话、成功获取了整合锁），系统会启动一个后台子 Agent，对记忆文件做一次整理。这个子 Agent 只有只读权限，不能修改项目文件

整理分四步：先读取记忆目录和现有记忆文件，然后从最近的日志和会话中提取新信息，接着更新或合并记忆文件（把相对日期转成绝对日期、删除过时信息），最后做裁剪，保持在 200 行以内

源码里的提示词：「你正在做一次梦，对记忆文件做一次反思性的回顾。把你最近学到的东西整合成持久的、组织良好的记忆，方便未来的会话快速定位」

KAIROS 模式：常驻后台的 Claude

assistant/ 目录下有一个叫 KAIROS 的模式，外部版本里完全不存在

从代码看，KAIROS 是一个持续运行的后台助手。它不需要你主动输入，会通过定时的 信号自主决定是否采取行动。它维护着一个只追加的每日日志文件，记录观察、决策和操作

这个模式有一个 15 秒 的阻塞预算限制：任何可能打断用户工作流的主动操作，如果执行时间超过 15 秒，会被延后

KAIROS 有三个普通 Claude Code 没有的专属工具：SendUserFile（给用户推送文件）、PushNotification（发推送通知）、SubscribePR（订阅 Pull Request 动态）

Coordinator 模式：多 Agent 编排

coordinator/ 目录实现了一个完整的多 Agent 编排系统。开启后，Claude Code 会从单个 Agent 变成一个调度器，同时管理多个工作 Agent 并行执行任务

工作流程分四个阶段：Research（多个 Agent 并行调查代码库）、Synthesis（调度器汇总发现、制定方案）、Implementation（Agent 按方案执行修改并提交）、Verification（验证修改是否生效）

调度器提示词里有一条规则：「不要说"根据你的发现"，去读实际的发现，然后精确地说明该做什么」

ULTRAPLAN：远程规划

一个把复杂规划任务卸载到远程云容器的模式。它会启动一个运行 Opus 4.6 的远程会话，给它最多 30 分钟 思考时间。本地终端每 3 秒轮询一次结果，同时有一个浏览器界面让你实时查看和审批规划方案

claude-code/
├── assistant/       # KAIROS 常驻助手模式
├── bridge/          # IDE 桥接（VS Code / JetBrains）
├── buddy/           # 电子宠物系统
├── commands/        # Slash 命令（约 50 个）
├── components/      # React 终端渲染组件（约 140 个）
├── coordinator/     # 多 Agent 编排
├── memdir/          # 持久化记忆目录
├── plugins/         # 插件系统
├── query/           # 查询引擎（46K 行，最大模块）
├── services/        # 服务层（含 autoDream 记忆整合）
├── skills/          # 用户自定义技能
├── tools/           # 40+ 工具模块
├── utils/           # 工具函数（含 undercover.ts）
├── voice/           # 语音输入
├── main.tsx         # 入口（785KB）
├── QueryEngine.ts   # 查询引擎核心
└── Tool.ts          # 工具基类（29K 行）

OpenClaw记忆系统：线性笔记到分层大脑

痛点：AI的金鱼记忆

当我们养虾的时候，都会有这样的经历：

• 昨天讨论的重要角色，今天问起来，他一脸茫然；
• 分散在十几个对话的知识点，他无法形成关联；
• 每次都要从头解释背景，浪费大量的token。

这主要是我们的龙虾记忆系统出现了问题，大多数AI助手的记忆方式是通过线性JSONL文件存储，就是按时间顺序塞进一个抽屉，没有分类，没有索引，也没有优先级

解决方案：分层记忆系统

三层架构

L0层：完整原始记录
  └─ 保留所有细节，用于深度检索

L1层：关键点提取
  └─ 提取对话中的要点，省70% token

L2层：结构化知识
  └─ 转化为可复用的知识模块

L3层：核心洞察
  └─ 跨对话提炼的深层认知

实际效果

• 之前 ：加载一次历史对话，需要传递50,000 tokens
• 现在 ：智能组合 L3(30%) + L2(40%) + L1(30%)，只需5,000 tokens
• Token节省：90%

核心组件：6大模块

1. 数据库层（SQLite）

告别JSONL文件，改用SQLite数据库：

• 对话树 ：支持分支、合并，像Git一样管理对话演进
• 索引优化 ：全文检索快10倍
• 事务支持 ：数据一致性有保障

2. 三级缓存

L1缓存（内存）：LRU算法，最近使用的记忆
  └─ 访问速度：微秒级

L2缓存（Redis可选）：分布式缓存
  └─ 访问速度：毫秒级

L3缓存（SQLite）：持久化存储
  └─ 访问速度：秒级

3. 异步I/O

• 之前 ：每条消息立即写入磁盘，阻塞对话
• 现在 ：

• • 批量写入（50条/批）
  • 5秒定时刷新
  • 失败自动重试（3次）

性能提升：5倍

4. 后台任务调度

5个自动任务，24小时运行：

任务	频率	功能
记忆压缩	每天3点	L0→L1→L2→L3 自动分层
衰减重算	每小时	根据访问频率调整记忆权重
向量索引	每5分钟	更新语义检索索引
缓存清理	每小时	清理过期缓存
统计收集	每天午夜	生成使用报告

5. 分支管理系统

类似Git的对话版本控制：

# 创建新分支（探索新思路）
memory.branch("alternative-approach")

# 合并分支（整合多个视角）
memory.merge("feature-branch")

# 切换分支（回到某个时刻）
memory.checkout("version-2026-03-15")

6. Obsidian同步模块

每15分钟自动同步到Obsidian知识库：

C:\OpenClaw图书馆\OpenClaw-Memory\
├── _系统概览.md          # 系统状态报告
├── 核心记忆/              # L3层核心洞察
├── 对话树/                # 可视化对话分支
└── 知识图谱/              # 关联网络展示

技术实现：关键代码

记忆分层算法

async functioncompressMemory(conversationId) {
// L0 → L1：提取关键点
const l1 = awaitextractKeyPoints(l0);

// L1 → L2：结构化知识
const l2 = awaitstructureKnowledge(l1);

// L2 → L3：提炼核心洞察
const l3 = awaitderiveInsights(l2);

// 保存分层结果
awaitsaveLayers({ l1, l2, l3 });
}

智能上下文组合

function buildContext(query, limit = 5000) {
const l3Ratio = 0.3;  // 30% 核心洞察
const l2Ratio = 0.4;  // 40% 结构化知识
const l1Ratio = 0.3;  // 30% 关键点

const l3Tokens = limit * l3Ratio;
const l2Tokens = limit * l2Ratio;
const l1Tokens = limit * l1Ratio;

// 按比例组合各层记忆
returncombine({ l3: l3Tokens, l2: l2Tokens, l1: l1Tokens });
}

异步批量写入

class AsyncMemoryWriter {
constructor() {
    this.buffer = [];
    this.flushInterval = 5000;  // 5秒
    this.batchSize = 50;        // 50条/批
  }

asyncwrite(message) {
    this.buffer.push(message);
    
    if (this.buffer.length >= this.batchSize) {
      awaitthis.flush();
    }
  }

asyncflush() {
    const batch = this.buffer.splice(0);
    awaitretry(() => db.insert(batch), { maxRetries: 3 });
  }
}

部署指南

1. 安装依赖

cd C:\Users\Administrator\.openclaw
npm install better-sqlite3 redis lru-cache

2. 启动系统

node start-advanced-memory-system.js

3. 配置Obsidian同步

在Obsidian中安装 Local REST API 插件，配置端口： 27124

4. 查看系统状态

访问Obsidian中的 _系统概览.md ，查看：

• 记忆总量（L0/L1/L2/L3）
• Token节省统计
• 后台任务状态
• 缓存命中率

使用方法

# 克隆项目
git clone https://github.com/your-repo/openclaw-advanced-memory

# 安装依赖
npm install

# 启动系统
node start-advanced-memory-system.js

# 查看Obsidian同步
# 打开 C:\OpenClaw图书馆\OpenClaw-Memory\_系统概览.md

性能对比

指标	之前（JSONL）	现在（SQLite+分层）
检索速度	2秒	0.2秒（10x）
Token消耗	50,000	5,000（90%↓）
并发支持	单线程	多线程异步
数据一致性	无保障	事务+重试
记忆分层	无	4层（L0-L3）
后台优化	无	5个自动任务

未来计划

短期（1个月）

向量数据库集成（Pinecone/Qdrant）

多模态记忆支持（图片、音频）

跨Agent记忆共享

中期（3个月）

记忆遗忘曲线模拟

主动记忆推送（基于上下文预测）

记忆图谱可视化

长期（6个月）

联邦学习（跨用户知识提炼）

记忆市场（用户交换记忆资产）

自我进化记忆（AI自动优化分层策略）

核心洞察

1. 记忆不是存储，是计算

• 传统方案 ：把对话存起来，需要时全文检索
• 优化方案 ：对话结束时就开始"计算记忆"

• • 提取关键点（L1）
  • 结构化知识（L2）
  • 提炼洞察（L3）

• 结果 ：存储的是"经过计算的记忆"，不是原始数据

2. Token优化是分层的

• 误区 ：直接截断历史对话
• 正确做法 ：

• • L3层（核心洞察）：永远保留
  • L2层（结构化知识）：优先保留
  • L1层（关键点）：按需保留
  • L0层（原始记录）：深度检索时才用

• 结果 ：在有限token内传递最大信息密度

3. 记忆需要主动管理

• 被动方案 ：存进去就不动了
• 主动方案 ：

• • 衰减重算：不用的记忆降权
  • 记忆压缩：定期L0→L3
  • 缓存清理：释放内存

• 结果 ：记忆系统会"自我进化"