优先级
标出真正重要的记忆，又不让召回被一堆“看起来重要”的内容淹没。
优先级告诉 Lore 一条记忆相对于其他记忆有多重要。使用三个层级：0 为核心身份，1 为关键事实，2 及以上为一般内容。容量上限让 0 和 1 保持足够少，才有意义。
三个层级
| 优先级 | 含义 | 上限（全库） | 典型内容 |
|---|---|---|---|
0 | 核心身份：每次会话都应当遵守的规则和身份信息 | 5 | 启动记忆（boot）节点，以及极少数每次会话都必须遵守的规则 |
1 | 关键事实：大多数项目工作都需要的约束、偏好和工作流 | 15 | 项目约束、稳定偏好、高价值工作流 |
2+ | 一般内容。数字越大，越偏向背景和历史。 | 无 | 实现笔记、决策、命令、历史背景 |
容量上限
优先级容量检查默认开启。新建记忆时，或把记忆调整为 0 或 1 时，如果该层级已满，Lore 会拒绝写入，并提示你先降低一条现有节点的优先级。
上限是固定值，无法在设置中修改。你可以关闭这项检查（对应 policy.priority_budget_enabled）。在 Loremem 云服务中，它位于设置 → 策略；在自托管服务中，位于 /settings。关闭后就没有这道限制了，除非有明确理由，否则请保持开启。
说明
启动记忆节点也会占用容量。首次设置流程会把启动记忆节点创建为优先级 0，因此三个全局启动记忆节点已经占用了该层级 5 个名额中的三个。每增加一个运行时的启动记忆节点，就再占用一个。
优先级在排序中的作用
优先级只会带来一点排序加分。默认值如下：
| 优先级 | 排序加分 |
|---|---|
| 0 | 0.05 |
| 1 | 0.04 |
| 2 | 0.03 |
| 3 | 0.02 |
| 4 | 0.01 |
| 5 及以上 | 0 |
这些默认值来自 recall.bonus.priority_base（0.05）和 recall.bonus.priority_step（0.01）。请记住以下几点：
- 加分很小，相关性仍然是主要因素。
- 优先级不会强制让记忆出现在召回结果中，展示阈值（默认 0.60）依然生效。
- 得分相同时，优先级数字更小（更重要）的排在前面。
- 优先级为
0和1的记忆，不会随时间推移而减少时间加分。参见召回如何工作。
典型的优先级分布
大部分记忆应当是优先级 2。较高层级刻意保持很少。
| 层级 | 典型用途 | 数量预期 |
|---|---|---|
0 | 启动记忆节点，以及每次会话都必须遵守的少数规则 | 很少，上限是 5 |
1 | 项目的关键约束、稳定偏好，以及大多数任务都需要的工作流 | 有一些，上限是 15 |
2 | 实现笔记、普通决策和常用命令 | 大部分记忆 |
3+ | 背景、历史，以及很少用到的上下文 | 不限，它们本身排序就较低 |
当所有内容都“很重要”时
如果每条记忆看起来都该是 0 或 1，请按以下步骤整理：
- 先问：哪些记忆是 Agent 每次会话都必须知道的？只有这些可以是
0或1。 - 如果某个层级已满，找出其中最不重要的一条节点，用
lore_update_node把它降到2。 - 如果一条记忆只对某一类任务重要，就把它留在
1，并让它的触发条件更具体。不要为了弥补而提高优先级。 - 用几个真实提示词跑一遍召回。如果记忆仍然不出现，问题出在触发条件或术语，而不是优先级。
优先级只能为已经匹配上的记忆排序，无法让一条匹配不上的记忆出现。
之后调整优先级
用 lore_update_node 修改节点的优先级，只需传入 uri 和新的 priority，其他字段保持不变。
{
"uri": "project://checkout_api/testing",
"priority": 2
}你也可以在 Loremem 云服务的记忆页面，或自托管服务的 /memory 页面中，在记忆编辑器里修改优先级字段。
只有当节点从其他层级调整为 0 或 1 时才会检查容量。已经处于该层级的节点不会重复检查。把节点降到 2 或以上，永远不会被容量上限阻止。