recall

/recall

使用自然语言查询搜索 Origin 的记忆。返回按混合向量 + FTS 搜索排名的匹配记忆，然后由 Agent 在有帮助时重新排序。

两个阶段

配置了本地模型或 API 密钥时，守护进程可以在服务端重新排序并扩展查询。本地记忆模式下则无法做到。该技能始终会自行执行Agent 端扩展和重新排序——成本低，而且在两种模式下都能获得良好结果。

阶段 1 — 扩展查询（Agent 端）

调用 recall 前，将用户的查询改写为更适合搜索的形式：

• 用指代对象替换代词（“它” → 实际事物）。
• 补充嵌入模型可能不熟悉的缩写。
• 原始术语过于狭窄时，添加显而易见的同义词（例如，“auth” → “auth OR authentication”）。

不要过度扩展。如果查询已经足够具体，就保持原样。 每次 /recall 调用只调用一次 recall——重复调用会使嵌入负载加倍，而合并步骤通常不值得。如果需要多查询场景，守护进程提供的 search_memory_expanded 可供使用；若有需要，请改用该端点，而不要在此处并行调用。

阶段 2 — 调用 MCP 工具

recall(query="<expanded query>", space=<inferred>, memory_type=<inferred>)

推断（不要询问用户）：

• space：当前工作目录（例如，~/Repos/origin/... → "origin"）、正在讨论的主题，或近期对话中提到的任意空间。已知范围时务必传入；不确定时，稍后运行 list_spaces（post-PR-C），或省略。
• memory_type：仅当查询本身指定了类型时使用（“关于 X 的决定”“关于 Y 的经验教训”“对 Z 的偏好”）。否则省略，交由混合搜索排序。
• limit：默认为 10。快速查找使用 3-5，探索时使用 10-20。

阶段 3 — 重新排序（Agent 端）

守护进程会返回按混合搜索排名的命中结果。这个排名不错，但并不完美——它不了解用户的确切意图。

根据原始查询重新阅读返回的记忆。将直接回答问题的记忆排到前面；将只是关键词相同的记忆排到后面。

向用户展示重新排序后的前 3-5 条命中结果。只有在用户询问时才展示其余结果。

阶段 4 — 呈现修订上下文（逐条结果）

每条记忆都可能包含修订字段：version、pending_revision、merged_from、last_delta_summary。大多数记忆都是最新的（v1，未设置其他字段）——这类记忆无需额外呈现。只有在存在有意义的信息时才添加标签行。

条件： 满足以下任一条件时，输出标签行：

• version > 1
• merged_from 非空
• pending_revision == true

格式 — 在记忆正文上方显示一行简短信息：

<id>  v<N> (merged <K> memories)         ← merged_from has K entries
<id>  v<N>, pending revision against <id> ← pending_revision true
<id>  v<N> — <last_delta_summary>         ← version > 1, delta populated
<id>  v<N>                                ← version > 1, no delta

规则：

• 标签中，合并状态优先于 pending_revision。
• last_delta_summary 为空或为 null 时，省略 — <delta>。
• 当 version == 1（或为 null）且没有其他标记时，完全跳过标签行。这样可保留新记忆的当前输出形式。

何时使用

• “我对 X 说过什么？”
• “你还记得关于 Y 的决定吗？”
• 继续之前需要确认某个具体事实。

何时不要使用

• 广泛了解会话背景 → 改用 /brief。
• 存储新记忆 → 使用 /capture。

提示：编写具体查询

“Alice 的数据库偏好”比“数据库相关的东西”能找到更多内容。语义匹配器会优先处理具体查询。如果返回结果太多，请添加筛选条件，而不是把查询写得更长。