跳转至

Architecture Evolution

我们解决的问题

目标: 构建一个记忆系统,让 Claude 在多次会话中变得更聪明,而用户不会察觉到它的存在。

挑战: 如何观察 AI 代理的行为,智能地压缩它,并在合适的时机将其回放给 Claude——整个过程都不能拖慢或干扰主工作流?

这就是 claude-mem 从一个简单想法演进为生产就绪系统的过程,以及支撑它运作的关键架构决策。


v5.x:成熟度与用户体验

在确立了稳健的 v4 架构之后,v5.x 将重点放在用户体验、可视化和打磨上。

v5.1.2:主题切换(2025 年 11 月)

变更内容:为查看器 UI 添加了亮色/暗色模式主题切换。

新功能: - 用户可选择的主题偏好(浅色、深色、跟随系统) - 在 localStorage 中持久化保存主题设置 - 平滑的主题过渡 - 系统偏好检测

实现:

// Theme context with persistence
const ThemeProvider = ({ children }) => {
  const [theme, setTheme] = useState<'light' | 'dark' | 'system'>(() => {
    return localStorage.getItem('claude-mem-theme') || 'system';
  });

  useEffect(() => {
    localStorage.setItem('claude-mem-theme', theme);
  }, [theme]);

  return (
    <ThemeContext.Provider value={{ theme, setTheme }}>
      {children}
    </ThemeContext.Provider>
  );
};

为什么重要:现在,在不同光照条件下工作的用户可以根据需要自定义查看器,以获得舒适的体验。

v5.1.1:Worker 启动修复(2025 年 11 月)- 已弃用

注意:本节描述的是历史上基于 PM2 的启动方式,后续版本已改用 Bun。

问题:使用 PM2 在 Windows 上启动 Worker 时,因 ENOENT 错误而失败。

历史解决方案:使用 PM2 二进制的完整路径,而不是依赖 PATH。

当前方案:项目现已使用 Bun 进行进程管理,这提供了更好的跨平台兼容性,并消除了这些 PATH 相关问题。

影响:恢复了跨平台兼容性,Windows 用户可以正常使用 claude-mem。

v5.1.0:基于 Web 的查看器 UI(2025 年 10 月)

突破:记忆流的实时可视化。

我们构建的内容: - 基于 React 的 Web UI,地址为 http://localhost:37777 - 使用 Server-Sent Events(SSE)实现实时更新 - 无限滚动分页 - 项目筛选 - 设置持久化(侧边栏状态、选中的项目) - 带指数退避的自动重连 - GPU 加速动画

新增 Worker 端点(8 个):

GET /                    # Serves viewer HTML
GET /stream              # SSE real-time updates
GET /api/prompts         # Paginated user prompts
GET /api/observations    # Paginated observations
GET /api/summaries       # Paginated session summaries
GET /api/stats           # Database statistics
GET /api/settings        # User settings
POST /api/settings       # Save settings

数据库增强:SessionStore 新增了分页查询,用于获取最近的 prompts、observations 和 summaries(可按项目筛选),并提供了数据库统计和项目列表来支撑查看器端点。(这些查看器专用方法后来被统一的搜索层取代。)

React 架构:

src/ui/viewer/
├── components/
│   ├── Header.tsx          # Navigation + stats
│   ├── Sidebar.tsx         # Project filter
│   ├── Feed.tsx            # Infinite scroll
│   └── cards/
│       ├── ObservationCard.tsx
│       ├── PromptCard.tsx
│       ├── SummaryCard.tsx
│       └── SkeletonCard.tsx
├── hooks/
│   ├── useSSE.ts           # Real-time events
│   ├── usePagination.ts    # Infinite scroll
│   ├── useSettings.ts      # Persistence
│   └── useStats.ts         # Statistics
└── utils/
    ├── merge.ts            # Data deduplication
    └── format.ts           # Display formatting

构建流程:

// esbuild bundles everything into single HTML file
esbuild.build({
  entryPoints: ['src/ui/viewer/index.tsx'],
  bundle: true,
  outfile: 'plugin/ui/viewer.html',
  loader: { '.tsx': 'tsx', '.woff2': 'dataurl' },
  define: { 'process.env.NODE_ENV': '"production"' },
});

为什么重要:用户现在可以实时看到正在捕获的确切内容,使记忆系统透明且可调试。

v5.0.3:智能安装缓存(2025 年 10 月)

问题:每次 SessionStart 都会运行 npm install(耗时 2-5 秒)

洞察:依赖在两次会话之间很少变化

解决方案:基于版本的缓存

// Check version marker before installing
const currentVersion = getPackageVersion();
const installedVersion = readFileSync('.install-version', 'utf-8');

if (currentVersion !== installedVersion) {
  // Only install if version changed
  await runNpmInstall();
  writeFileSync('.install-version', currentVersion);
}

缓存检查逻辑: 1. node_modules 是否存在? 2. .install-version 是否与 package.json 中的版本匹配? 3. better-sqlite3 是否存在?(旧版:现在使用 bun:sqlite,无需额外安装)

影响: - SessionStart 钩子:2-5 秒 → 10ms(提速 99.5%) - 仅在以下情况安装:首次运行、版本变更、缺少依赖 - 更好的 Windows 错误提示,并附带构建工具帮助

v5.0.2:Worker 健康检查(2025 年 10 月)

变更内容:更健壮的 Worker 启动和监控。

新功能:

// Health check endpoint
app.get('/health', (req, res) => {
  res.json({
    status: 'ok',
    uptime: process.uptime(),
    port: WORKER_PORT,
    memory: process.memoryUsage(),
  });
});

// Smart worker startup
async function ensureWorkerHealthy() {
  const healthy = await isWorkerHealthy(1000);
  if (!healthy) {
    await startWorker();
    await waitForWorkerHealth(10000);
  }
}

优势: - Worker 不可用时优雅降级 - 崩溃后自动恢复 - 更好的调试错误提示

v5.0.1:稳定性改进(2025 年 10 月)

变更内容:各种 bug 修复和稳定性增强。

关键修复: - 修复了观察队列处理中的竞态条件 - 改进了 SDK worker 的错误处理 - 更有效地清理过期的 worker 进程 - 增强了调试日志记录

v5.0.0:混合搜索架构(2025年10月){#v500-hybrid-search-architecture-october-2025}

演进历程:SQLite FTS5 + Chroma 向量搜索

我们新增了什么:

┌─────────────────────────────────────────────────────────┐
│                    HYBRID SEARCH                         │
│                                                          │
│  Text Query → SQLite FTS5 (keyword matching)            │
│                      ↓                                   │
│            Chroma Vector Search (semantic)               │
│                      ↓                                   │
│              Merge + Re-rank Results                     │
└─────────────────────────────────────────────────────────┘

新依赖项: - chromadb:用于语义搜索的向量数据库 - Python 3.8+:chromadb 所需的运行环境

MCP 工具增强:

// Chroma-backed semantic search
search_observations({
  query: "authentication bug",
  useSemanticSearch: true  // Uses Chroma
});

// Falls back to FTS5 if Chroma unavailable

为何采用混合搜索: - FTS5:快速关键词匹配,无依赖 - Chroma:语义理解,发现相关概念 - 优雅降级:没有 Chroma 也能正常工作(仅 FTS5)

权衡取舍: - 增加了 Python 依赖(可选) - 增加了安装复杂性 - 提升了搜索相关性


MCP 架构简化(2025年12月){#mcp-architecture-simplification-december-2025}

问题:复杂的 MCP 实现

之前:

9+ MCP tools registered at session start:
- search_observations
- find_by_type
- find_by_file
- find_by_concept
- get_recent_context
- get_observation
- get_session
- get_prompt
- help

Problems:
- Overlapping operations (search_observations vs find_by_type)
- Complex parameter schemas (~2,500 tokens in tool definitions)
- No built-in workflow guidance
- High cognitive load for Claude (which tool to use?)
- Code size: ~2,718 lines in mcp-server.ts

洞察: 渐进式披露应内建于工具设计本身,而不是让 Claude 去记住的东西。

解决方案:三层工作流

之后:

4 MCP tools following 3-layer workflow:

1. important_workflow - Workflow documentation (always visible)
   "3-LAYER WORKFLOW (ALWAYS FOLLOW):
    1. search(query) → Get index with IDs
    2. timeline(anchor=ID) → Get context
    3. get_observations([IDs]) → Fetch details
    NEVER fetch full details without filtering first."

2. search - Layer 1: Get index with IDs (~50-100 tokens/result)
3. timeline - Layer 2: Get chronological context
4. get_observations - Layer 3: Fetch full details (~500-1,000 tokens/result)

Benefits:
- Progressive disclosure enforced by tool structure
- No overlapping operations
- Simple schemas (additionalProperties: true)
- Clear workflow pattern
- Code size: ~312 lines in mcp-server.ts (88% reduction)
- ~10x token savings

迁移:移除基于技能(Skill)的搜索

之前: 使用基于技能的搜索 - mem-search 技能通过自然语言调用 - HTTP API 通过 curl 直接调用 - 通过技能加载实现渐进式披露 - 17 个技能文档文件

现在: 已移除基于技能的方式 - 仅 MCP 架构 - 原生 MCP 协议(与 Claude 集成更好) - 同时兼容 Claude Desktop 与 Claude Code - 维护更简单(无需技能文件) - 已移除全部 19 个 mem-search 技能文件(约 2,744 行)

关键架构变更

MCP 服务器重构:

之前:

// Complex parameter schemas
{
  name: "search_observations",
  inputSchema: {
    type: "object",
    properties: {
      query: { type: "string", description: "..." },
      type: { type: "array", items: { enum: [...] } },
      format: { enum: ["index", "full"] },
      limit: { type: "number", minimum: 1, maximum: 100 },
      // ... many more parameters
    }
  }
}

之后:

// Simple schemas with workflow guidance
{
  name: "search",
  description: "Step 1: Search memory. Returns index with IDs.",
  inputSchema: {
    type: "object",
    properties: {},
    additionalProperties: true  // Accept any parameters
  }
}

工作流强制:

之前:Claude 必须记住渐进式披露模式

之后:工具结构使跳过步骤变得不可能 - 没有 search 提供的 ID 就无法获取详情 - 不看到 important_workflow 提醒就无法搜索 - timeline 提供了中间地带(有上下文但无完整详情)

影响

Token 效率:

Traditional: Fetch 20 observations upfront
→ 10,000-20,000 tokens
→ Only 2 observations relevant (90% waste)

3-Layer Workflow:
→ search (20 results): ~1,000-2,000 tokens
→ timeline around relevant IDs: ~300-600 tokens
→ Review context, select 3 relevant IDs
→ get_observations (3 IDs): ~1,500-3,000 tokens
→ Total: ~2,800-5,600 tokens

代码简洁性: - MCP 服务器:2,718 行 → 312 行(减少 88%) - 移除:19 个技能文件(约 2,744 行) - 净减少:移除约 5,150 行代码

用户体验: - 相同的自然语言交互 - 更好的 Token 效率 - 更清晰的架构 - 在 Claude Desktop 和 Claude Code 上表现一致

设计理念

通过结构实现渐进式披露:

三层工作流在架构层面体现了渐进式披露:

  1. 第 1 层(索引)——“存在什么?”——以极低成本概览可选内容
  2. 第 2 层(时间线)——“当时发生了什么?”——围绕特定时间点的上下文
  3. 第 3 层(详情)——“告诉我一切”——仅在必要时提供完整详情

每一层都为 Claude 提供了一个决策点,使其可以: - 若无关则停止 - 若不确信则获取更多上下文 - 若确信则深入查看

这使得浪费 tokens 在结构上变得困难。


v1-v2:朴素方法

最初的尝试:全部转储

架构:

PostToolUse Hook → Save raw tool outputs → Retrieve everything on startup

我们学到的重要教训: - ❌ 上下文污染(数千个无关数据的 token) - ❌ 没有压缩(原始工具输出冗长) - ❌ 没有搜索(只能线性扫描所有内容) - ✅ 验证了概念:跨会话的记忆很有价值

出错的示例:

SessionStart loaded:
- 150 file read operations
- 80 grep searches
- 45 bash commands
- Total: ~35,000 tokens
- Relevant to current task: ~500 tokens (1.4%)


v3:智能压缩,错误的架构

突破:AI 驱动的压缩

新想法: 使用 Claude 本身来压缩观察结果

架构:

PostToolUse Hook → Queue observation → SDK Worker → AI compression → Store insights

我们新增的内容: 1. Claude Agent SDK 集成 - 使用 AI 压缩观察结果 2. 后台工作进程 - 不阻塞主会话 3. 结构化观察结果 - 提取事实、决策、洞察 4. 会话摘要 - 生成全面的摘要

有效的地方: - ✅ 压缩比:10:1 到 100:1 - ✅ 语义理解(不仅仅是关键词匹配) - ✅ 后台处理(Hook 保持快速) - ✅ 搜索变得有用

无效的地方: - ❌ 仍然会预先加载所有内容 - ❌ Session ID 管理有问题 - ❌ 激进的清理中断了摘要生成 - ❌ 每个 Claude Code 会话创建了多个 SDK 会话


关键发现

领悟 1:渐进式披露

问题: 即使压缩后的观察结果,如果全部加载,也可能污染上下文。

洞察: 人类在开始工作前不会阅读所有内容。AI 为什么要呢?

解决方案: 先显示索引,需要时再获取详情。

❌ Old: Load 50 observations (8,500 tokens)
✅ New: Show index of 50 observations (800 tokens)
        Agent fetches 2-3 relevant ones (300 tokens)
        Total: 1,100 tokens vs 8,500 tokens

影响: - 上下文使用量减少 87% - 100% 相关性(只获取需要的内容) - Agent 自主性(自行判断哪些是相关的)

领悟 2:Session ID 混乱

问题: SDK 会话 ID 在每一轮都会改变。

我们原本以为:

// ❌ Wrong assumption
UserPromptSubmit → Capture session ID once → Use forever

实际情况:

// ✅ Actual behavior
Turn 1: session_abc123
Turn 2: session_def456
Turn 3: session_ghi789

为什么这很重要: - 如果不跟踪 ID 更新,就无法恢复会话 - 会话状态在每一轮之间丢失 - 观察结果变成孤儿数据

解决方案:

// Capture from system init message
for await (const msg of response) {
  if (msg.type === 'system' && msg.subtype === 'init') {
    sdkSessionId = msg.session_id;
    await updateSessionId(sessionId, sdkSessionId);
  }
}

领悟 3:优雅清理 vs 激进清理

v3 方案:

// ❌ Aggressive: Kill worker immediately
SessionEnd → DELETE /worker/session → Worker stops

问题: - 摘要生成在过程中被打断 - 待处理的观察结果丢失 - 到处都是竞态条件

v4 方案:

// ✅ Graceful: Let worker finish
SessionEnd → Mark session complete → Worker finishes → Exit naturally

优点: - 摘要成功生成 - 没有丢失观察结果 - 状态转换干净清晰

代码:

// v3: Aggressive
async function sessionEnd(sessionId: string) {
  await fetch(`http://localhost:37777/sessions/${sessionId}`, {
    method: 'DELETE'
  });
}

// v4: Graceful
async function sessionEnd(sessionId: string) {
  await db.run(
    'UPDATE sdk_sessions SET completed_at = ? WHERE id = ?',
    [Date.now(), sessionId]
  );
}

领悟 4:一个会话,而非多个

问题: 我们为每个 Claude Code 会话创建了多个 SDK 会话。

我们原本以为:

Claude Code session → Create SDK session per observation → 100+ SDK sessions

实际情况应该是:

Claude Code session → ONE long-running SDK session → Streaming input

为什么这很重要: - SDK 维护对话状态 - 上下文自然累积 - 效率高得多

实现方式:

// ✅ Streaming Input Mode
async function* messageGenerator(): AsyncIterable<UserMessage> {
  // Initial prompt
  yield {
    role: "user",
    content: "You are a memory assistant..."
  };

  // Then continuously yield observations
  while (session.status === 'active') {
    const observations = await pollQueue();
    for (const obs of observations) {
      yield {
        role: "user",
        content: formatObservation(obs)
      };
    }
    await sleep(1000);
  }
}

const response = query({
  prompt: messageGenerator(),
  options: { maxTurns: 1000 }
});


v4:有效的架构

核心设计

┌─────────────────────────────────────────────────────────┐
│              CLAUDE CODE SESSION                         │
│  User → Claude → Tools (Read, Edit, Write, Bash)        │
│                    ↓                                     │
│              PostToolUse Hook                            │
│              (queues observation)                        │
└─────────────────────────────────────────────────────────┘
                     ↓ SQLite queue
┌─────────────────────────────────────────────────────────┐
│              SDK WORKER PROCESS                          │
│  ONE streaming session per Claude Code session          │
│                                                          │
│  AsyncIterable<UserMessage>                             │
│    → Yields observations from queue                     │
│    → SDK compresses via AI                              │
│    → Parses XML responses                               │
│    → Stores in database                                 │
└─────────────────────────────────────────────────────────┘
                     ↓ SQLite storage
┌─────────────────────────────────────────────────────────┐
│              NEXT SESSION                                │
│  SessionStart Hook                                       │
│    → Queries database                                    │
│    → Returns progressive disclosure index               │
│    → Agent fetches details via MCP                      │
└─────────────────────────────────────────────────────────┘

五钩架构

目的: 注入来自先前会话的上下文

时机: 当 Claude Code 启动时

功能: - 查询最近 10 条会话摘要 - 格式化为渐进式披露索引 - 通过 stdout 注入到上下文中

相对 v3 的关键变更: - ✅ 索引格式(而非完整详情) - ✅ Token 计数可见 - ✅ 包含 MCP 搜索指令

目的: 初始化会话追踪

时机: 在 Claude 处理提示词之前

功能: - 创建会话记录 - 保存原始用户提示词(v4.2.0+) - 按需启动 worker

相对 v3 的关键变更: - ✅ 存储原始提示词以供搜索 - ✅ 自动启动 Worker Service

目的: 捕获工具观察结果

时机: 每次工具执行之后

功能: - 将观察结果加入数据库队列 - 立即返回

相对 v3 的关键变更: - ✅ 仅入队(不处理) - ✅ Worker 处理所有 AI 调用

目的: 生成会话摘要

时机: 由 Worker 触发(会话进行中)

功能: - 收集观察结果 - 发送给 Claude 生成摘要 - 存储结构化摘要

相对 v3 的关键变更: - ✅ 每个会话可生成多个摘要 - ✅ 摘要是检查点,而非终点

目的: 优雅清理

时机: 会话结束时

功能: - 将会话标记为完成 - 让 Worker 完成处理

相对 v3 的关键变更: - ✅ 优雅(而非激进) - ✅ 无 DELETE 请求 - ✅ Worker 自然结束

数据库模式演进

v3 模式:

-- Simple, flat structure
CREATE TABLE observations (
  id INTEGER PRIMARY KEY,
  session_id TEXT,
  text TEXT,
  created_at INTEGER
);

v4 模式:

-- Rich, structured schema
CREATE TABLE observations (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  session_id TEXT NOT NULL,
  project TEXT NOT NULL,

  -- Progressive disclosure metadata
  title TEXT NOT NULL,
  subtitle TEXT,
  type TEXT NOT NULL,  -- decision, bugfix, feature, etc.

  -- Content
  narrative TEXT NOT NULL,
  facts TEXT,  -- JSON array

  -- Searchability
  concepts TEXT,  -- JSON array of tags
  files_read TEXT,  -- JSON array
  files_modified TEXT,  -- JSON array

  -- Timestamps
  created_at TEXT NOT NULL,
  created_at_epoch INTEGER NOT NULL,

  FOREIGN KEY(session_id) REFERENCES sdk_sessions(id)
);

-- FTS5 for full-text search
CREATE VIRTUAL TABLE observations_fts USING fts5(
  title, subtitle, narrative, facts, concepts,
  content=observations
);

-- Auto-sync triggers
CREATE TRIGGER observations_ai AFTER INSERT ON observations BEGIN
  INSERT INTO observations_fts(rowid, title, subtitle, narrative, facts, concepts)
  VALUES (new.id, new.title, new.subtitle, new.narrative, new.facts, new.concepts);
END;

变更内容: - ✅ 结构化字段(title、subtitle、type) - ✅ FTS5 全文搜索 - ✅ 支持项目范围查询 - ✅ 丰富的元数据以实现渐进式披露

Worker Service 重新设计

v3 worker:

// Multiple short SDK sessions
app.post('/process', async (req, res) => {
  const response = await query({
    prompt: buildPrompt(req.body),
    options: { maxTurns: 1 }
  });

  for await (const msg of response) {
    // Process single observation
  }

  res.json({ success: true });
});

v4 worker:

// ONE long-running SDK session
async function runWorker(sessionId: string) {
  const response = query({
    prompt: messageGenerator(),  // AsyncIterable
    options: { maxTurns: 1000 }
  });

  for await (const msg of response) {
    if (msg.type === 'text') {
      parseObservations(msg.content);
      parseSummaries(msg.content);
    }
  }
}

优势: - 维护对话状态 - SDK 自动处理上下文 - 更高效(更少的 API 调用) - 自然的多轮流程


过程中的关键修复

修复 1:上下文注入污染(v4.3.1){#fix-1-context-injection-pollution-v431}

问题: SessionStart 钩子输出被 npm install 日志污染

# Hook output contained:
npm WARN deprecated ...
npm WARN deprecated ...
{"hookSpecificOutput": {"additionalContext": "..."}}

出错原因: - Claude Code 期望干净的 JSON 或纯文本 - npm install 的 stderr/stdout 与钩子输出混合在一起 - 上下文未能正确注入

解决方案:

{
  "command": "npm install --loglevel=silent && node context-hook.js"
}

结果: 干净的 JSON 输出,上下文注入正常

修复 2:重复 Shebang 问题(v4.3.1){#fix-2-double-shebang-issue-v431}

问题: 钩子可执行文件包含重复的 shebang

#!/usr/bin/env node
#!/usr/bin/env node  // ← Duplicate!

// Rest of code...

发生原因: - 源文件包含 shebang - esbuild 在构建过程中添加了另一个 shebang

解决方案:

// Remove shebangs from source files
// Let esbuild add them during build

结果: 干净的可执行文件,无解析错误

修复 3:FTS5 注入漏洞(v4.2.3){#fix-3-fts5-injection-vulnerability-v423}

问题: 用户输入直接传递给 FTS5 查询

// ❌ Vulnerable
const results = db.query(
  `SELECT * FROM observations_fts WHERE observations_fts MATCH '${userQuery}'`
);

攻击示例:

userQuery = "'; DROP TABLE observations; --"

解决方案:

// ✅ Safe: Use parameterized queries
const results = db.query(
  'SELECT * FROM observations_fts WHERE observations_fts MATCH ?',
  [userQuery]
);

修复 4:NOT NULL 约束违规(v4.2.8){#fix-4-not-null-constraint-violation-v428}

问题: 当提示词为空时,会话创建失败

INSERT INTO sdk_sessions (claude_session_id, user_prompt, ...)
VALUES ('abc123', NULL, ...)  -- ❌ user_prompt is NOT NULL

解决方案:

// Allow NULL user_prompts
user_prompt: input.prompt ?? null

模式变更:

-- Before
user_prompt TEXT NOT NULL

-- After
user_prompt TEXT  -- Nullable


性能优化

优化 1:预处理语句

之前:

for (const obs of observations) {
  db.run(`INSERT INTO observations (...) VALUES (?, ?, ...)`, [obs.id, obs.text, ...]);
}

之后:

const stmt = db.prepare(`INSERT INTO observations (...) VALUES (?, ?, ...)`);
for (const obs of observations) {
  stmt.run([obs.id, obs.text, ...]);
}
stmt.finalize();

影响: 批量插入速度提升 5 倍

优化 2:FTS5 索引

之前:

// Manual full-text search
const results = db.query(
  `SELECT * FROM observations WHERE text LIKE '%${query}%'`
);

之后:

// FTS5 virtual table
const results = db.query(
  `SELECT * FROM observations_fts WHERE observations_fts MATCH ?`,
  [query]
);

影响: 大数据集上的搜索速度提升 100 倍

优化 3:索引格式默认值

之前:

// Always return full observations
search_observations({ query: "hooks" });
// Returns: 5,000 tokens

之后:

// Default to index format
search_observations({ query: "hooks", format: "index" });
// Returns: 200 tokens

// Fetch full only when needed
search_observations({ query: "hooks", format: "full", limit: 1 });
// Returns: 150 tokens

影响: 平均搜索结果大小减少 25 倍


经验总结

经验 1:上下文很宝贵

原则: 放入上下文窗口的每个 Token 都会消耗注意力。

应用: - 渐进式披露将浪费减少 87% - 索引优先的方法让 Agent 掌控主动权 - Token 计数让成本可视化

经验 2:会话状态很复杂

原则: 分布式状态很难处理。SDK 能比我们更好地处理它。

应用: - 使用 SDK 内置的会话恢复功能 - 不要尝试手动重建状态 - 从初始化消息中跟踪会话 ID

经验 3:优雅胜过激进

原则: 在终止进程之前,让它们完成自己的工作。

应用: - 优雅清理可防止数据丢失 - Worker 完成重要操作 - 干净的状态转换减少 Bug

经验 4:AI 是压缩器

原则: 不要手动压缩。让 AI 进行语义压缩。

应用: - 10:1 到 100:1 的压缩比 - 语义理解,而非关键词提取 - 结构化输出(XML 解析)

经验 5:一切渐进式

原则: 先显示元数据,按需获取详情。

应用: - 上下文注入中的渐进式披露 - 搜索结果中的索引格式 - 第 1 层(标题)→ 第 2 层(摘要)→ 第 3 层(完整详情)


未来规划

规划中:自适应索引大小

SessionStart({ source: "startup" }):
  → Show last 10 sessions (normal)

SessionStart({ source: "resume" }):
  → Show only current session (minimal)

SessionStart({ source: "compact" }):
  → Show last 20 sessions (comprehensive)

规划中:相关性评分

// Use embeddings to pre-sort index by semantic relevance
search_observations({
  query: "authentication bug",
  sort: "relevance"  // Based on embeddings
});

规划中:多项目上下文

// Cross-project pattern recognition
search_observations({
  query: "API rate limiting",
  projects: ["api-gateway", "user-service", "billing-service"]
});

规划中:协作记忆

// Team-shared observations (optional)
createObservation({
  title: "Rate limit: 100 req/min",
  scope: "team"  // vs "user"
});

迁移指南:v3 → v5

步骤 1:备份数据库

cp ~/.claude-mem/claude-mem.db ~/.claude-mem/claude-mem-v3-backup.db

步骤 2:更新插件

cd ~/.claude/plugins/marketplaces/thedotmack
git pull

步骤 3:更新插件

/plugin update claude-mem

自动完成的事情: - 依赖项自动更新(包括 v5.0.0+ 新增的依赖,如 chromadb) - 数据库 Schema 迁移自动运行 - Worker Service 使用新代码重启 - 智能安装缓存自动激活(v5.0.3+)

步骤 4:测试

# Start Claude Code
claude

# Check that context is injected
# (Should see progressive disclosure index with v5 viewer link)

# Open viewer UI (v5.1.0+)
open http://localhost:37777

# Submit a prompt and watch real-time updates in viewer

步骤 5:探索新功能

# View memory stream in browser (v5.1.0+)
open http://localhost:37777

# Toggle theme (v5.1.2+)
# Click theme button in viewer header

# Check worker health
npm run worker:status
curl http://localhost:37777/health

关键指标

v3 性能

指标 值
每次会话的上下文使用量 ~25,000 Tokens
相关上下文 ~2,000 Tokens(8%)
Hook 执行时间 ~200ms
搜索延迟 ~500ms(LIKE 查询)

v4 性能

指标 值
每次会话的上下文使用量 ~1,100 Tokens
相关上下文 ~1,100 Tokens(100%)
Hook 执行时间 ~45ms
搜索延迟 ~15ms(FTS5)

v5 性能

指标 值
每次会话的上下文使用量 ~1,100 Tokens
相关上下文 ~1,100 Tokens(100%)
Hook 执行时间 ~10ms(缓存安装)
搜索延迟 ~12ms(FTS5)或 ~25ms(混合模式)
查看器 UI 加载时间 ~50ms(打包 HTML)
SSE 更新延迟 ~5ms(实时)

v3 → v4 改进: - 上下文浪费减少 96% - 相关性提升 12 倍 - Hook 速度提升 4 倍 - 搜索速度提升 33 倍

v4 → v5 改进: - Hook 速度提升 78%(智能缓存) - 实时可视化(查看器 UI) - 更好的搜索相关性(混合模式) - 增强的用户体验(主题切换、持久化)


结论

从 v3 到 v5 的旅程让我们理解了这些基本真理:

  1. 上下文是有限的:渐进式披露尊重注意力预算
  2. AI 是压缩器:语义理解胜过关键词提取
  3. Agent 很聪明:让它们决定获取什么
  4. 状态很难处理:使用 SDK 的内置机制
  5. 优雅胜出:让进程干净地完成

其结果是一个既强大又无形的记忆系统。用户从未注意到它在工作——Claude 只是随着时间推移变得越来越聪明。

v5 增加了可见性:现在用户可以(通过查看器 UI)看到记忆系统的运作,只要他们愿意,但它仍然不具备侵入性。


延伸阅读


这次架构演进源于数百小时的实验、数十条死胡同,以及实际使用中获得的宝贵经验。v5 架构正是在理解哪些方法真正有效的基础上应运而生——并将其展示给用户。

本页原文 Markdown:在 AtomGit 查看·内容源自开源项目 cl/claude-mem