4月1日（Claude code源码+Openclaw记忆系统改进）

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小时运行：

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

性能对比

未来计划

短期（1个月）

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

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

跨Agent记忆共享

中期（3个月）

记忆遗忘曲线模拟

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

记忆图谱可视化

长期（6个月）

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

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

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

核心洞察

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

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

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

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

2. Token优化是分层的

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

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

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

3. 记忆需要主动管理

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

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

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