Context Mem

---

问题

如今的 AI 工具存在两个问题，却没有任何单一软件包能同时解决。

你的 AI 会遗忘。 每次新会话都从零开始。上周四敲定的架构决策、花了 4 小时才追查到是环境变量配置错误的 bug，以及你重复说过 3 次的偏好——这些都不会保留下来。每次会话开始的前 10 分钟，你都要重新解释已经存在的上下文。再乘以团队中的每位开发者、每个项目和每一天，情况更是如此。

你的上下文会膨胀。 长时间编码会话会超出上下文窗口。典型会话中，50 次工具输出会累积 365 KB 原始文本——堆栈跟踪、测试输出、文件读取内容、Shell 命令。每个 token 都要花钱，或拖慢模型速度。简单截断会丢掉模型恰恰需要的证据。全部保留则会让响应变慢，推理成本迅速攀升。

这两个问题会相互加剧。解决遗忘问题的方法（全部保留）与解决上下文膨胀问题的方法（全部丢弃）恰恰相反。因此，大多数工具都迫使你接受一种虚假的取舍：要么 AI 忘掉一切，要么成本暴涨。context-mem 通过构建可索引、可压缩、可检索的记忆存储，同时解决这两个问题，而不是把原始历史记录一股脑塞进上下文窗口。

---

解决方案——一个工具，两大支柱

支柱 1：记忆（LLM Wiki）

每次工具调用都会自动摄取、摘要，并写入可浏览的 Markdown 知识库——这是一个由 AI 维护、关于你项目的动态 Wiki。实体有各自带反向链接的页面；主题有综合页面；会话则成为可浏览的源文档；决策不断累积，形成可还原的轨迹。

知识库位于 .context-mem/vault/，并持续与底层 SQLite 存储同步。你可以在 Obsidian 中阅读、在终端中使用 grep 搜索，或通过 45+ 个 MCP 工具进行查询，支持混合 BM25 + 向量 + 可选的 LLM 评判器搜索。原始 SQLite 存储是权威记录；Markdown 知识库则是由此派生、便于人阅读的层。

这是 Andrej Karpathy LLM Wiki 模式 的参考实现——包含三层（原始来源 / Wiki / 架构），并支持从工具调用自动摄取，这是其他系统都不具备的功能。

支柱 2：压缩（14 种摘要器）

每条观察内容在存储前都会经过感知内容类型的摘要器处理。堆栈跟踪不会与 JSON 配置文件采用相同的处理方式。构建过程的 Shell 输出与 TypeScript 编译器错误也会采用不同的压缩方式。系统会根据内容类型应用恰当的压缩方式。

结果是：包含 50 次工具输出的完整编码会话，大小会从 365 KB 降至 3.2 KB——已验证可节省 99.1% 的 token。压缩方式会自适应调整：近期且重要性高的观察内容保持原样；较旧且重要性低的内容则逐步压缩。无论存放多久，固定条目都不会被压缩。

---

一条命令

npm i context-mem && npx context-mem init

init 会自动检测你的编辑器并写入相应的配置文件：

编辑器	写入的配置
Claude Code	.mcp.json + 8 个钩子 + CLAUDE.md
Cursor	.cursor/mcp.json + .cursor/rules/context-mem.mdc
Windsurf	.windsurf/mcp.json + .windsurf/rules/context-mem.md
VS Code / Copilot	.vscode/mcp.json + .github/copilot-instructions.md
Cline	.cline/mcp_settings.json + .clinerules/context-mem.md
Roo Code	.roo-code/mcp_settings.json + .roo/rules/context-mem.md
Aider	.aider.conf.yml（MCP 配置块）
Continue	.continue/config.json（MCP 配置块）
JetBrains AI	.idea/mcp.json

无需 API 密钥。无需云账户。数据不会离开你的设备。

---

60 秒了解双支柱架构

[ placeholder: GIF or video — Claude Code session with split view showing Obsidian graph updating in real time alongside the context-mem dashboard token savings chart ]

---

架构（Karpathy 的 LLM Wiki 模式参考实现）

                    ┌─────────────────────────────────────────┐
                    │            Raw Sources (immutable)       │
                    │  tool calls · observations · file reads  │
                    └──────────────────┬──────────────────────┘
                                       │
                                       ▼
                    ┌─────────────────────────────────────────┐
                    │           Observation Pipeline           │
                    │                                          │
                    │  PrivacyEngine (9 detectors)             │
                    │    → 14 content-aware summarizers        │
                    │    → entity extraction (100+ aliases)    │
                    │    → topic detection                     │
                    │    → importance scoring (0.0–1.0)        │
                    │    → adaptive compression tier           │
                    └────────────────┬────────────────────────┘
                                     │
                   ┌─────────────────┴───────────────────┐
                   │                                     │
                   ▼                                     ▼
    ┌──────────────────────────┐       ┌─────────────────────────────┐
    │    SQLite (primary)      │       │   Markdown Vault (derived)  │
    │                          │       │                             │
    │  observations            │──────▶│  .context-mem/vault/        │
    │  entities + graph        │  sync │    index.md                 │
    │  knowledge               │       │    log.md                   │
    │  events                  │       │    sources/<session>.md     │
    │  FTS5 index              │       │    entities/<name>.md       │
    │  vector embeddings       │       │    topics/<name>.md         │
    └──────────────────────────┘       │    knowledge/<id>.md        │
                   │                   └─────────────────────────────┘
                   │
                   ▼
    ┌──────────────────────────────────────────────────────────────┐
    │              Hybrid Retrieval                                │
    │                                                              │
    │  BM25 (8 strategies + synonym expansion)                     │
    │  + Vector (nomic-embed-text-v1.5, 768-dim)                   │
    │  + Trigram + Levenshtein                                     │
    │  → Fusion (intent-adaptive weights, IDF reranker)            │
    │  → Optional LLM judge (Haiku, 50/50 blend, 100% R@5)        │
    └──────────────────────────────────────────────────────────────┘

三个层（根据 Karpathy）：

• 原始来源 — 你的工具调用输出、文件读取、Shell 命令和观察结果。只写入一次，从不修改。永久记录。
• Wiki — 由大模型维护的 Markdown 知识库（.context-mem/vault/）。自动从 SQLite 同步。便于人类阅读、兼容 Obsidian、便于 grep。包含实体页面、主题页面、会话页面、知识页面、索引和事件日志。
• Schema — docs/llm-wiki-schema.md 规定页面结构、链接约定、Agent 工作流配方和互操作契约。这是一份公开规范，其他工具也能生成符合规范的 Wiki。

与大多数记忆系统的区别在于：context-mem 并非用 Markdown 取代 SQLite。SQLite 是权威数据源，观察结果存储、搜索和索引都在其中完成。知识库则是在其上构建的、可浏览、可链接、可比较差异的界面层，让人或大模型无需数据库客户端即可浏览。如果删除知识库目录，不会丢失任何重要内容。如果手动编辑知识库页面，这些编辑会保留，不会在下次同步时被覆盖。

这是将 Karpathy 的三层模型应用于正在运行的 AI 开发环境：不可变的输入、经过维护的综合层，以及用于规范综合内容的公开 Schema。知识库可以脱离 MCP 工具独立使用，它只是一组 Markdown 文件。你可以用任意编辑器打开它，将它纳入 git，在不同提交之间比较差异，或将页面复制粘贴到新对话中，作为长篇上下文使用。MCP 工具提供自动化路径；Markdown 知识库则提供可移植、持久且便于人类阅读的路径。

---

检索基准（诚实的方法论）

所有分数衡量的都是会话级检索召回率：前 k 个结果中是否出现了任一正确的证据会话？这与端到端 QA 准确率（检索 + 生成 + 评判）不同；后者更难，而且所有系统的表现都更低。这里公布了这两种测量结果。

纯本地（零 API 调用，完全免费）

基准	检索召回率	端到端 QA 准确率	问题数	会话数
LongMemEval	97.8% R@5	v3.4 后公布	500	约 53 个/对话
LoCoMo	98.1% R@10	v3.4 后公布	1,977	每个对话 19–35 个
MemBench	98.0% R@5	—	500	—
ConvoMem	97.7% R@10	—	250	—

启用可选 LLM 重排（约每 500 次查询 1 美元）

基准测试	检索召回率
LongMemEval	100.0% R@5（500/500）

LLM 评判器（Claude Haiku）会为 BM25+向量候选结果中的前 N 项打 0–10 分，并与检索分数按 50/50 的比例合并。启用条件为 ai_curation.enabled = true。按 Haiku 定价，每次查询约增加 0.002 美元的费用。

方法说明：

• 如果前 k 项中出现任一正确的证据会话，即计为一次“命中”。这不是端到端问答测试。
• LoCoMo 基准测试会将数据集提供的元数据（session_summary、observation、event_summary）附加到会话文档中；生产系统会通过摘要器和实体提取应用等效的丰富处理。
• 同义词扩展：核心查询构建器包含通用词汇同义词（movie → film、sibling → brother）。完全不使用同义词扩展时，结果会低约 1–2%。
• 所有基准测试代码均开源且可运行：npm run bench。请参阅 benchmarks/。

完整方法说明：docs/benchmarks/methodology.md（随 v3.4 发布）。

---

压缩基准测试（已验证）

场景	原始大小	压缩后	节省空间
典型编码会话（50 个工具输出）	365 KB	3.2 KB	99.1%

各摘要器的具体表现：

摘要器	压缩率
日志输出	97%
错误	95%
Shell / CLI	~95%
代码	92%
JSON	89%
TS 编译器错误	~88%
测试	~85%
构建输出	~94%
Git 日志	~90%
HTML	~92%
Markdown	~75%
CSV	~80%
网络响应	~88%
二进制（十六进制转储）	~98%

对于高重要性的观察结果（DECISION、MILESTONE、PROBLEM 标记），压缩在语义层面无损——无论内容有多旧，这些信息都会保持原样。压缩仅应用于常规工具输出。

---

核心功能

记忆

• LLM Wiki 底层系统 — .context-mem/vault/ 中的 Markdown 知识库，由 SQLite 自动同步。包含实体页面、主题页面、会话源页面、知识页面、index.md 和 log.md。兼容 Obsidian，便于 grep 搜索。
• 14 种内容感知摘要器 — JSON、shell、代码、日志、错误、TS 错误、测试、构建、Git 日志、HTML、Markdown、CSV、二进制、网络。每种都针对相应内容类型进行了调优。
• 自适应四层压缩 — 原样保留（0–7 天）→ 轻度压缩（7–30 天）→ 中度压缩（30–90 天）→ 提炼（90 天以上）。固定条目将永久保持原样。
• 知识图谱 — 类型化实体关系模型：文件、模块、模式、决策、Bug、人员、库、服务、API、配置。可通过 graph_query、graph_neighbors、add_relationship 遍历。
• 时序事实 — 所有知识条目均包含 valid_from/valid_to。支持取代链。temporal_query 可回答“在时间 T，关于 X 的事实是什么？”
• 决策轨迹重建 — explain_decision 沿证据链反向追溯：读取文件 → 错误 → 搜索 → 决策。提供完整溯源信息。
• 实体智能 — 自动检测技术、人员、文件路径、驼峰式标识符、全大写常量。包含 100 多个规范别名（React.js → React、Node → Node.js 等）。
• 会话叙述 — 4 种现成模板：PR 描述、站会更新、ADR、入职指南。context-mem story --format pr。
• 唤醒导引 — 在会话开始时注入受令牌预算约束的上下文。分 4 层：项目简介（15%）、关键信息（40%）、近期决策（30%）、重要实体（15%）。
• 逐提示词注入 — UserPromptSubmit 钩子会在每条消息中自动注入相关记忆。具备速率限制和主题去重功能。无需手动执行命令。

压缩

• 14 种内容感知型摘要器——并非一刀切。堆栈跟踪和 JSON 响应会采用不同的处理方式。
• 固定内容原样保留——决策、里程碑和手动固定的观察记录永远不会被压缩。
• 按优先级分层的截断级联——如果超出上下文预算，会优先压缩重要性较低的内容。高重要性内容会保留下来。
• 可配置的令牌预算——提供三种溢出策略：压缩最早的内容、压缩重要性最低的内容，或直接截断。
• 365 KB → 3.2 KB——已在典型的 50 个工具输出的编码会话中验证。

两者兼备

• 混合搜索——BM25（8 种策略 + 同义词扩展）+ 向量（nomic-embed-text-v1.5，768 维）+ 三元组 + Levenshtein 并行运行，通过根据意图自适应调整的权重进行融合，并使用 IDF 加权内容重新排序。可选 LLM 评判器重新排序。
• 时间解析器——确定性解析相对日期查询（“3 天前”“上周六”“上周”）。零 LLM 成本。返回带有置信度的绝对日期范围。
• 45+ 个 MCP 工具——观察、搜索、回忆、询问、时间线、知识图谱、实体检测、时间查询、会话交接、多 Agent 协调、令牌预算、仪表板、诊断等。
• 完全本地运行，不依赖云端——数据存储在你本机的 SQLite 中。无遥测。核心功能无需 API 密钥。
• 9 种检测器组成的隐私引擎——剥离 <private> 标签、应用自定义正则表达式脱敏规则，并检测 API 密钥、令牌、密码和个人身份信息模式。敏感信息不会离开你的设备。
• 亚毫秒级操作——重要性分类速度为 556K 次操作/秒，实体提取速度为 179K 次操作/秒，BM25 搜索速度为 3.3K 次操作/秒，全部在本地运行。

---

对比

记忆领域已有多个成熟项目，上下文压缩领域则更多一些。没有其他工具能同时解决这两个方面的问题。

	context-mem v4	Mem0	Graphiti	Zep	Letta
LLM Wiki / markdown 库	✅	❌	❌	❌	❌
从工具调用自动摄取	✅	❌	❌	❌	❌
检索召回率（本地）	97.8–98.1% R@k	未发布	未发布	未发布	未发布
令牌压缩	99.1%	❌	❌	❌	部分支持
带类型的知识图谱	✅	✅	✅	部分支持	部分支持
时间图谱查询	✅	✅	✅	❌	❌
混合 BM25 + 向量 + LLM 重排	✅	部分支持	❌	部分支持	❌
完全本地运行（无需云端）	✅	❌	❌	❌	❌
决策轨迹重建	✅	❌	❌	❌	❌
兼容 Obsidian 的输出	✅	❌	❌	❌	❌
MCP 工具	45+	部分支持	部分支持	部分支持	部分支持
许可证	MIT	Apache/云端	Apache	Apache	Apache

**关于此表的说明：**Mem0、Graphiti、Zep 和 Letta 尚未发布与我们采用可比方法、基于相同基准（LongMemEval、LoCoMo、MemBench、ConvoMem）进行会话级检索召回率测试的数据。如果其文档中有已发布的数据，这些数据采用了不同的数据集、不同的粒度（块级而非会话级），或未披露基础设施。请勿直接比较。context-mem 的端到端问答数据将在 v3.4 发布。其他所有对比均基于截至 2026 年 4 月的公开文档。

“令牌压缩”这一行需要特别说明：Mem0、Graphiti 和 Zep 主要是检索系统，并未声称能解决上下文窗口的成本问题。Letta 通过摘要提供部分压缩能力。context-mem 的 99.1% 数据是在真实编码会话中测得的（50 个工具输出，365 KB → 3.2 KB）。该测量可复现：你可以对自己的项目运行 context-mem stats --raw 和 context-mem stats --compressed 并进行比较。

---

真实案例

You: "Why did we choose Postgres over MySQL?"
→ recall returns the exact verbatim quote from March 15 (importance 0.95)
  with the full evidence chain: error → file_read → search → decision

You: "What did Sarah work on last sprint?"
→ browse by person shows 14 observations mentioning Sarah,
  grouped by topic (auth, database, deployment)

You: "What are we about to forget?"
→ predict_loss shows 8 entries at risk: low importance, 45+ days old,
  never accessed. Pin the critical ones before they decay.

You: "Generate a PR description for this branch"
→ context-mem story --format pr assembles changes, decisions,
  resolved issues, and test plan from the current session

You: "What was our database schema in January?"
→ temporal_query returns what was true about the schema at that point
  in time, including since-superseded knowledge

---

开始使用

1. 安装

npm i context-mem && npx context-mem init

init 会为你的编辑器创建合适的 MCP 配置。Claude Code 无需重启 IDE。对于 Cursor、Windsurf 和 VS Code，请在运行 init 后重启 IDE。

2. 配置 MCP（手动选项）

如果你更喜欢手动配置，请将以下内容添加到 MCP 配置中：

{
  "mcpServers": {
    "context-mem": {
      "command": "npx",
      "args": ["context-mem", "serve"],
      "env": {}
    }
  }
}

对于 Claude Code，init 还会将 8 个钩子写入 .claude/settings.json，在每次提交提示词时自动注入相关记忆——正常开发过程中无需手动调用 observe。

3. 启用 LLM Wiki 知识库（v3.4+ 可选）

将以下内容添加到 context-mem 配置（.context-mem/config.json）中：

{
  "vault": {
    "enabled": true,
    "vaultDir": ".context-mem/vault"
  }
}

知识库目录会在下次摄取观察记录时自动填充。在 Obsidian 中打开 .context-mem/vault/，浏览项目知识的图谱视图。

知识库在 v3.4 中为可选启用，v4.0 起将默认启用。

4. 仪表板

context-mem dashboard

此操作会在 http://localhost:3141 打开本地 Web UI，其中包含 6 个页面：智能概览、知识图谱、主题、时间线、实体和诊断。

5. 基准测试（自行运行）

npm run bench          # quick mode (all 4 benchmarks, sample sizes)
npm run bench:full     # full benchmarks
npm run bench:e2e-qa   # E2E QA: retrieve → Haiku answer → Haiku judge

所有基准测试代码均为开源代码。没有任何会虚增数据的隐藏适配器。请参阅 benchmarks/ 和 docs/benchmarks/methodology.md。

---

MCP 工具参考（45+）

context-mem 将其全部功能以 MCP 工具的形式开放——无需专有 SDK、封装库或受限于单一平台。任何支持 MCP 的宿主（Claude Code、Cursor、Windsurf、VS Code、Cline、Roo Code、Aider、Continue、JetBrains AI、CrewAI、LangChain、AutoGen）都能直接使用这些工具。没有需要付费才能使用的“高级”工具，也没有任何功能要求订阅云服务。本 README 中列出的所有功能都可通过开放的 MCP 接口使用。

核心记忆工具：

工具	用途
observe	保存观察记录，自动生成摘要、评估重要性、提取实体并检测主题
recall	按筛选条件（重要性、类型、标记、时间）检索原文内容
search	混合搜索（BM25 + 向量 + 可选的大模型评判）
ask	基于完整记忆库进行自然语言问答
timeline	按时间倒序查看观察记录，并显示重要性徽标和标记
stats	统计当前会话的 Token 用量（原始值与压缩值）

知识图谱工具：

工具	用途
save_knowledge	保存知识条目，并检测矛盾 + 设置有效时间范围
search_knowledge	搜索知识（默认过滤掉已被取代的条目）
promote_knowledge	将知识提升至跨项目全局存储
global_search	同时搜索所有项目
resolve_contradiction	解决知识冲突（取代 / 合并 / 保留 / 归档）
merge_suggestions	查看跨项目重复项建议
graph_query	遍历实体关系
add_relationship	为实体添加带类型的关联
graph_neighbors	查找关联实体（可配置深度）

时间与智能工具：

工具	用途
temporal_query	查询特定时间点的真实情况
time_travel	比较项目在两个任意时间戳时的状态
explain_decision	沿证据链回溯，还原做出决策的原因
predict_loss	找出可能因压缩或删除而丢失的观察记录
generate_story	生成 PR 描述、站会更新、ADR 或入门指南
entity_detect	检测任意文本中的实体
find_tunnels	查找跨项目的主题关联

会话与 Agent 工具：

工具	用途
wake_up	为会话启动生成受 Token 预算限制的上下文导览
restore_session	从检查点恢复会话
handoff_session	生成跨会话衔接包
agent_register	注册具有角色和能力的 Agent
agent_status	检查所有活跃 Agent 及其声明的资源
claim_files	声明文件以避免并行 Agent 之间发生冲突
agent_broadcast	向项目中的所有 Agent 广播发现

系统工具：

工具	用途
configure	更新运行时配置
budget_status / budget_configure	管理 Token 预算
summarize	总结内容但不保存（单次操作）
execute	运行代码（JS、TS、Python、Shell、Ruby、Go、Rust、PHP、Perl、R、Elixir）
index_content	使用代码感知型分块建立索引
search_content	搜索已建立索引的内容块
list_people / list_topics	浏览实体和主题
import_conversations	导入对话历史
browse	按人员、实体或主题检索观察记录
diagnostics	查看错误日志、流水线统计信息和存储健康状况

---

诊断 API

如果需要检查系统正在执行的操作：

# MCP tool
mcp__context-mem__diagnostics

# HTTP (when dashboard is running)
curl http://localhost:3141/api/diagnostics

返回错误日志、流水线统计信息、活跃会话、存储健康状况和搜索索引状态。

---

多 Agent 支持

context-mem 支持多个 AI Agent 在同一项目中并行工作，且不会发生冲突：

// Agent A registers and claims a file
mcp__context-mem__agent_register({ agent_id: "agent-a", role: "backend" })
mcp__context-mem__claim_files({ files: ["src/api.ts"] })

// Agent B sees Agent A's claim and avoids the conflict
mcp__context-mem__agent_status({})
// → { "agent-a": { files: ["src/api.ts"], status: "active" } }

// Broadcast a finding to all agents
mcp__context-mem__agent_broadcast({ message: "auth module has a race condition on token refresh" })

共享记忆可避免重复工作。声明文件可防止合并冲突。广播可让所有 Agent 同步发现。

---

架构参考：搜索流水线

检索栈并行运行 8 种 BM25 策略，每种策略具有不同的权重以及精确率／召回率取舍：

策略	权重	用途
AND 模式	2.0	精确率高，要求包含所有词项
短语匹配	1.9	连续关键词对
实体聚焦	1.8	专有名词、日期、标识符
清理后的 FTS5	1.5	默认分词
放宽的 AND	1.2	实体 + 重要关键词
OR 模式 + 同义词	1.0	通过语义扩展扩大召回范围
单个关键词	0.5	捕获长尾结果
单个同义词	0.2	弥合语义差异（sibling → brother）

此外还有时间解析（权重 1.6）：相对日期查询（“last Saturday”）会在搜索前确定性地解析为绝对日期范围，无需消耗 LLM 资源。

向量搜索（nomic-embed-text-v1.5，768 维）与 BM25 并行运行，处理排名前 30 的候选项，而非级联执行。结果通过意图自适应权重（BM25：0.45，trigram：0.15，Levenshtein：0.05，vector：0.35）融合，并使用 IDF 加权内容重新排序。可选的 LLM 评判器会将检索分数与最终前 N 项按 50/50 的比例融合。

---

LLM Wiki 架构

知识库遵循 docs/llm-wiki-schema.md 中记录的架构。该架构规定了：

• 目录布局（sources/、entities/、topics/、knowledge/）
• 页面类型和 frontmatter 约定
• 链接语法（[[entity-name]] 会解析为 entities/entity-name.md）
• 操作：摄取／查询／检查
• 面向 CLAUDE.md / AGENTS.md 的 Agent 工作流配方
• 互操作契约——其他工具可以生成符合规范的 Wiki，供 context-mem 导入

这是一份公开规范。欢迎在 github.com/JubaKitiashvili/context-mem/discussions 提交社区 RFC。

---

性能特征

所有核心操作均为同步操作，耗时低于 1 毫秒。默认操作均无需 LLM。

操作	吞吐量	延迟
重要性分类	556K 次操作/秒	0.002ms
实体提取	179K 次操作/秒	0.006ms
主题检测	162K 次操作/秒	0.006ms
压缩层级计算	3M 次操作/秒	<0.001ms
逐字 FTS5 搜索	50K 次操作/秒	0.020ms
BM25 混合搜索	3.3K 次操作/秒	0.3ms
唤醒引导内容组装	9K 次操作/秒	0.111ms
叙事生成	6K 次操作/秒	0.164ms

启用向量搜索时，向量嵌入（nomic-embed-text-v1.5）会为每次查询增加约 5–15ms 的耗时，仍快于任何网络调用。可选的 LLM 评判器会额外调用一次 Haiku API（约 100ms），且仅在 ai_curation.enabled = true 时调用。

---

更新日志亮点

• v4.0.0 — 完整版 LLM Wiki 发布。综合页面、Obsidian 插件、8 种 IDE 集成、Context Protocol RFC、压缩优化。目标日期：2026-05-22。
• v3.4.0 — LLM Wiki 预览版。Markdown 知识库层、架构规范 v1、端到端 QA 基准测试、关闭 issue #6（披露基准测试方法）。
• v3.3.0 — 基础功能。CI、错误日志、诊断。静默补丁。
• v3.2.0 — 混合并行搜索。BM25 与向量并行运行，采用意图自适应融合。
• v2.5.0 — 仪表板。实时 Web UI、知识图谱可视化。

---

许可证：MIT

由 Juba Kitiashvili 构建。

致谢：感谢 Andrej Karpathy 提出 LLM Wiki 构想（2026-04-04）。感谢 Vannevar Bush 提出 Memex（1945 年）。