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 层(索引)——“存在什么?”——以极低成本概览可选内容
- 第 2 层(时间线)——“当时发生了什么?”——围绕特定时间点的上下文
- 第 3 层(详情)——“告诉我一切”——仅在必要时提供完整详情
每一层都为 Claude 提供了一个决策点,使其可以: - 若无关则停止 - 若不确信则获取更多上下文 - 若确信则深入查看
这使得浪费 tokens 在结构上变得困难。
v1-v2:朴素方法¶
最初的尝试:全部转储¶
架构:
我们学到的重要教训: - ❌ 上下文污染(数千个无关数据的 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 本身来压缩观察结果
架构:
我们新增的内容: 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 在每一轮都会改变。
我们原本以为:
实际情况:
为什么这很重要: - 如果不跟踪 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 方案:
问题: - 摘要生成在过程中被打断 - 待处理的观察结果丢失 - 到处都是竞态条件
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 会话。
我们原本以为:
实际情况应该是:
为什么这很重要: - 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 与钩子输出混合在一起 - 上下文未能正确注入
解决方案:
结果: 干净的 JSON 输出,上下文注入正常
修复 2:重复 Shebang 问题(v4.3.1){#fix-2-double-shebang-issue-v431}¶
问题: 钩子可执行文件包含重复的 shebang
发生原因: - 源文件包含 shebang - esbuild 在构建过程中添加了另一个 shebang
解决方案:
结果: 干净的可执行文件,无解析错误
修复 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}'`
);
攻击示例:
解决方案:
// ✅ 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
解决方案:
模式变更:
性能优化¶
优化 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:备份数据库¶
步骤 2:更新插件¶
步骤 3:更新插件¶
自动完成的事情: - 依赖项自动更新(包括 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 的旅程让我们理解了这些基本真理:
- 上下文是有限的:渐进式披露尊重注意力预算
- AI 是压缩器:语义理解胜过关键词提取
- Agent 很聪明:让它们决定获取什么
- 状态很难处理:使用 SDK 的内置机制
- 优雅胜出:让进程干净地完成
其结果是一个既强大又无形的记忆系统。用户从未注意到它在工作——Claude 只是随着时间推移变得越来越聪明。
v5 增加了可见性:现在用户可以(通过查看器 UI)看到记忆系统的运作,只要他们愿意,但它仍然不具备侵入性。
延伸阅读¶
- 渐进式披露 - v4 背后的理念
- Hooks 架构 - hooks 如何驱动整个系统
- 上下文工程 - 基础原则
- Worker Service - 实时可视化(v5.1.0+)
这次架构演进源于数百小时的实验、数十条死胡同,以及实际使用中获得的宝贵经验。v5 架构正是在理解哪些方法真正有效的基础上应运而生——并将其展示给用户。
本页原文 Markdown:在 AtomGit 查看·内容源自开源项目 cl/claude-mem