Lore 如何工作

了解 Lore 在会话的每一步向 Agent 发送什么、Agent 怎样使用这些内容，以及 Lore 会记录什么。想弄清楚 Agent 为什么看到了某条记忆，或者哪些设置可以调整，就从这里开始。

会话开始复制锚点链接

会话开始时，Lore 按以下顺序发送四项内容：

1. 全局使用规则。 服务器管理的 Lore 使用说明，可以在设置中编辑。对应设置项为 lifecycle.guidance.enabled，默认开启。
2. 启动记忆（boot）块。 下文说明的固定基线。
3. 启动召回。 可选。根据工作目录和仓库名选出的候选记忆。
4. 技能规则（仅 Loremem 云服务）。一段固定的 <lore_skills> 块，说明 Lore 托管的技能怎么用。技能包本身不经由这段内容下发，而是通过各 Agent 自己的技能目录到达。

启动节点复制锚点链接

启动节点是固定的，因此每次会话都从同一份基线开始。

技能（仅 Loremem 云服务）复制锚点链接

<lore_skills> 块只携带规则，不携带技能包：插件会把该 Agent 可见、已启用的技能同步到宿主自己的技能目录，Agent 用自己的技能系统列出、触发和加载它们。你自己用 Agent 的触发方式调用，比如 Claude Code 的 /lore:<名称> 或 Pi 的 /skill:<名称>。参见技能。

每条提示词：召回复制锚点链接

每次提交提示词之前，Lore 会查找与之匹配的记忆，并加入一个 <recall> 块：

<recall session_id="sess_8f3c" query_id="q_41" phase="prompt">
0.82 | project://checkout_api/webhooks | refund · idempotency key
0.71 | project://checkout_api/testing | flaky test · fake clock
0.64 | preferences://user | test first
</recall>

每一行依次是分数、URI 和命中的线索词。这一行只是线索，不是事实。依赖它之前，先打开这个节点。

Lore 默认采用以下展示规则：

设置项的键名列在设置项参考中。

召回会根据以下因素为候选打分：路径、术语和查询词的精确匹配；术语和记忆视图的语义相似度；全文匹配。此外还有少量加分：优先级、多个视图同时命中，以及近期更新。近期加分的半衰期为 180 天；优先级 0 和 1 的记忆不会衰减。

会话期间：读取复制锚点链接

Agent 需要某条记忆时，用 lore_get_node 打开它。如果 URI 来自 <recall> 块，Agent 还要带上该标签中的 session_id 和 query_id：

{
  "uri": "project://checkout_api/webhooks",
  "session_id": "sess_8f3c",
  "query_id": "q_41"
}

只有 Agent 带着这些 ID 打开记忆时，Lore 才会把这条召回记为“采用”，因此分析能显示 Agent 真正用到了哪些召回结果。想浏览而不是召回，Agent 可以调用 lore_search（查询内容为空或为 *，并指定 domain），也可以调用 lore_list_domains。

会话期间：写入复制锚点链接

Agent 用 lore_create_node、lore_update_node、lore_move_node 和 lore_delete_node 保存长期有效的变更。默认会执行两项写入检查：

• 优先级容量：限制优先级 0 的记忆最多 5 条，优先级 1 的记忆最多 15 条。创建和更新时都会检查。
• 触发条件检查：触发条件缺失，或使用“A 或 B”这样的写法时给出提醒。

Lore 会把每次创建、更新、移动和删除都记录在节点历史中，并标明是哪个运行时做的修改。

维护复制锚点链接

• Dream 默认每天 03:00 运行，需要配置 View LLM。它直接用记忆工具执行修改，并把每项改动标记出来等你审查；最近一次运行可以整体回滚。详见 Dream。
• 备份 默认每天 04:00 运行。自托管服务器保留最近 7 份本地备份。Loremem 云服务的 设置 中，备份标签页提供相同的设置。详见备份与恢复。

集成如何工作复制锚点链接

每个 Agent 通过轻量插件或 MCP 服务器接入。插件本身不携带提示词。每个生命周期事件都走同样的流程：

1. 运行时到达一个生命周期节点，例如会话开始或提交提示词。
2. 插件把事件发送到 POST /api/lifecycle/event，附上会话 ID、提示词文本（如有）和 client_type。
3. 服务器返回可以直接注入的文本：使用规则、启动记忆块或召回块。
4. 插件把这段文本交给运行时。

这种设计带来三个特点：

• 规则文本保存在服务器上。 在设置中修改一次，所有已接入的 Agent 会在下一次会话或提示词时使用新文本。
• client_type 标识运行时。 Lore 用它加载对应的启动节点，并按运行时统计召回和使用情况。其他 MCP 客户端需要在端点 URL 中带上 client_type=mcp。
• 插件故障放行。 如果 Lore 无法访问或响应缓慢，插件什么都不返回，Agent 在该步骤中不使用记忆继续工作。

Lore 能看到什么复制锚点链接

Lore 能看到以下内容：

• 提示词文本，用来为这条提示词查找召回候选。
• 会话 ID，把召回和使用情况关联到具体会话。
• 会话开始时的工作目录名，以及该目录是 Git 仓库且配置了远程地址时，从远程地址中取出的仓库名。这是尽力获取的信息。
• Agent 写入的内容，例如新建或更新的记忆节点。

Lore 从不读取你的源代码文件。插件只向 Git 询问第一个远程仓库的地址。

Lore 还会保存召回事件用于分析。除非开启“包含召回事件”，备份中默认不包含这些事件。