Lore

为你的软件项目打造的动态知识图谱。

状态：1.0 版本前，个人维护。 Lore 功能完备且已在生产项目中使用，但 API、模式和 MCP 接口在小版本更新间仍可能发生变动。欢迎提交 Bug 报告；在设计稳定之前，功能性 PR 可能不会被合并。一旦 API 稳定（目标：1.0），存储库将开放更广泛的协作。

Lore 将项目的业务逻辑（模块、能力、流程、事件、规则、表单、实体和决策）捕获为由 SQLite 支持的类型化图谱，并通过 MCP 公开，以便 AI 编码助手（Claude Code、Cursor、Claude Desktop）可以在日常工作中查询和维护它。

它可以在一次工具调用中回答诸如“有多少种注册支付的方式？”、“如果我修改 flow-checkout 会破坏什么？”或“哪些规则保护此实体？”之类的问题，并提供来源证明，无需每次都重新探索代码库。

为什么选择 Lore

• 跨会话持久化记忆 — 图谱在上下文重置后依然存在。

• 零文档负担 — 助手在做出决策时即时记录，无需作为单独的琐事处理。

• 可审计 — 每个节点都带有 source（来源）、confidence（置信度）、source_context（来源上下文）。每个 MCP 调用都会被记录。

• Token 高效 — 仅摘要列表、批量操作、用于探索的低成本子代理、WAL 模式的 SQLite。

Related MCP server: kg-memory-mcp

安装（Claude Code 插件 — 推荐）

/plugin marketplace add YACB2/lore
/plugin install lore@lore

重新加载后，在你想要建模的项目中运行 lore init（或运行 /lore:bootstrap 进行引导式入门，它会使用 Haiku 扫描代码）。“项目”可以是单个仓库，也可以是包含多个仓库的工作区 — Lore 不做限制，.lore/lore.db 会在你启动 Claude Code 的目录中创建。

该插件包含：

• MCP 服务器：公开 lore_add_node、lore_add_nodes、lore_update_node、lore_delete_node、lore_get_node、lore_add_edge、lore_add_edges、lore_remove_edge、lore_query、lore_traverse、lore_list、lore_find_variants、lore_audit、lore_history、lore_stats、lore_export_markdown。

• 自动调用技能 (lore-usage)：告知 Claude 在行动前阅读并在决策时写入，遵循来源证明规则和生命周期约定。

• 子代理 lore-explorer (Haiku, 只读)：用于广泛探索，无需消耗昂贵的 Token。

• 斜杠命令：/lore:init、/lore:bootstrap、/lore:audit、/lore:show <id>、/lore:recent、/lore:impact <id>、/lore:probe <path>（在不切换目录的情况下审计另一个项目的图谱）。

安装（独立 CLI / 其他 MCP 主机）

pipx install projectlore   # or: uv tool install projectlore
lore init

对于 Cursor / Claude Desktop：

{
  "mcpServers": {
    "lore": {
      "command": "lore",
      "args": ["mcp", "--db", ".lore/lore.db"]
    }
  }
}

CLI 参考

lore init                      # create .lore/lore.db
lore list [--type flow]        # summary listing (id, type, title, status)
lore show <id>                 # full detail + edges
lore query "payment"           # exact id → title substring → tag fallback
lore variants <capability-id>  # flows implementing a capability
lore audit                     # orphans, cycles, id hygiene
lore stats [--since ISO]       # token/usage analytics from the audit log
lore export --out .lore/export # one markdown file per node

模式

八种节点类型（与技术栈无关）：module（模块）、capability（能力）、flow（流程）、event（事件）、rule（规则）、form（表单）、entity（实体）、decision（决策）。

九种关系：part_of（属于）、implements（实现）、depends_on（依赖）、triggers（触发）、validates（验证）、enforces（强制执行）、supersedes（取代）、references（引用）、conflicts_with（冲突）。类型对受到限制（参见 schema.py）。

状态：active（活跃）| draft（草稿）| deprecated（已弃用）| superseded（已取代）| archived（已归档）。默认使用软删除；lore_delete_node 仅保留用于纠正拼写错误，并会发出关于边丢失的警告。

核心抽象是 capability（能力）—— 系统知道如何做的一件事，与具体实现方式无关。多个 flow 节点可以 implements 同一个能力，从而显现出用户体验/逻辑上的差异。

模型路由

操作按成本划分：

• 读取（广泛扫描、遍历、审计）：通过 lore-explorer 子代理委托给 Haiku，或在斜杠命令上使用 model: haiku 前置元数据。

• 写入与建模决策：调用者的模型（Sonnet/Opus）。子代理提出 JSON；调用者进行审查并持久化。

在 .lore/config.json 中按项目覆盖：

{
  "language": "es",
  "app_name": "my-app",
  "models": { "exploration": "haiku", "write": "sonnet" }
}

来源证明与历史记录

每个节点都带有 metadata.{source, confidence, source_context}，并在相关时包含 source_ref (path:line)、last_verified_at、deprecated_at、deprecated_reason、replaced_by。

lore_update_node(metadata_patch=…) 在不破坏来源证明的情况下进行合并；metadata 仍然存在，以应对罕见的完全替换情况。

lore_history(id) 从仅追加的审计日志中返回该节点的所有 MCP 事件（最新的在前）。lore_stats 按工具/操作进行聚合，并报告输入/输出字节数。

状态

Pre-MVP，Alpha 阶段。模式和 MCP 工具接口在 0.1.0 之前可能会发生变化。

开发

uv sync --all-groups
uv run pytest -q
uv run ruff check src tests

测试位于 tests/ 中。插件布局由 test_plugin_structure.py 验证。

许可证

MIT。