search-memory

搜索记忆

使用 Nowledge Mem 在个人知识库中进行 AI 驱动的搜索。

适用场景

强烈信号 — 出现以下情况时应搜索：

• 用户提到之前的工作、先前的修复或早先的决策
• 任务继续处理某个已命名的功能、错误、重构、事件或子系统
• 任务涉及审查、回归、发布、文档一致性或连接器行为问题
• 调试模式与之前解决的问题相似
• 用户询问理由、偏好、流程或反复使用的工作流细节
• 用户使用隐含的回忆表达：“那个方法”“像之前一样”“我们用过的模式”

上下文信号 — 出现以下情况时可考虑搜索：

• 复杂调试中，先前的上下文有助于缩小搜索范围
• 架构讨论可能涉及过去的决策
• 用户之前确立过的领域特定惯例
• 当前结果含糊不清，而过去的上下文有助于给出更准确的回答

检索路由

如果主机提供 Nowledge Mem MCP 工具，优先使用这些工具：用 memory_search 搜索持久化知识，用 thread_search 搜索过往对话，并用 thread_fetch_messages 检查匹配的对话。否则：

1. 首先运行 nmem --json m search "query" -n 5 搜索持久化知识。
2. 运行 nmem --json t search "query" --limit 5 搜索过往对话或特定会话记录。
3. 如果结果包含 source_thread，使用 nmem --json t show <thread_id> --limit 8 --offset 0 --content-limit 1200 检查一次，获取所需的具体消息。
4. 选择足以回答问题的最小检索范围。

对于需要大量延续上下文的工程工作，应在任务开始时尽早搜索。不要等到用户明确要求搜索记忆。

保留已配置的端点、所有者、Agent 身份和当前空间。如果运行时已知当前活动通道，请通过支持的 MCP 参数传递该范围，或在 CLI 命令中添加 --space "<space name>"。切勿根据当前文件夹推断空间，也不要为了获取更多结果而切换所有者或空间。

检索模式

• 普通（默认）：使用 memory_search 并设置 mode="normal"，或运行 nmem --json m search "query" --mode normal -n 5，以检索具体事实和有限范围内的信息。
• 深度：概念性问题、理由、历史或跨主题关联，请使用 mode="deep" 或 --mode deep。如果普通模式返回的证据为空、含糊、相互矛盾或不足，请升级到深度模式。不要自行编造服务端未返回的分数阈值。
• 渐进式图搜索：用户要求查找相关节点、谱系或逐步探索时，从准确的 Memory ID 开始。没有种子时，先进行有界的普通或深度搜索，并使用搜索结果中准确返回的 ID。遵循 explore-graph 技能的一跳协议和停止界限；展示聚焦图并不意味着自动开始图遍历。

展示检索结果

每次 memory_search 或等效 CLI/KFS Memory 搜索成功，且至少返回一条 Memory 后，自动展示一个聚焦图谱。保留排序顺序和所有返回的 Memory ID；绝不推断或替换 ID。

1. 对于能够渲染内嵌 MCP App 的宿主，优先使用 MCP explore_graph，传入以逗号分隔的 ID，并设置 depth=1 和 limit=15。
2. 对于独立浏览器或链接回退方案，以及有界渐进式展开，使用 explore-graph skill。如果未安装该 skill，请说明回退方案不可用，并建议与 search-memory 一起安装。
3. 内嵌渲染成功时，不要再打开重复的独立图谱。结果集为空或仅检索到线程时，不要生成图谱。

渲染时保持相同的所有者／成员权限、身份和空间。精确的结果 ID 不会强制执行访问控制：对于受 Space 或 Team 限制的检索，只有在确认相应界面会执行相同限制时，才能生成图谱。返回浏览器 URL 前，遵循 explore-graph 的身份和范围检查。图谱生成失败不得导致成功的检索报错：简要说明原因，然后继续使用检索到的证据。如果没有找到匹配的证据，请如实说明。

当 Memory 结果为回答提供依据时，简要报告查询、模式、范围，以及匹配度最高的 Memory ID 和标题。仅在服务器返回分数时才报告；不要编造缺失的元数据或隐藏推理。

原生连接器

这些 skills 通过 CLI 或宿主现有的 MCP 连接运行；查看聚焦图谱不需要原生连接器。如需自动召回、转录捕获和宿主生命周期钩子，优先使用 Agent 专用的连接器。安装后运行 check-integration，或参阅集成指南。

有界线程读取

先搜索记忆或线程，再选择所需的特定对话和消息范围。每个问题最多调用一次 thread_fetch_messages、宿主的线程获取工具或 nmem --json t show，并使用较小的消息数量上限（例如 8）；在支持的情况下，将内容上限设为 1200。已知目标范围时，可以使用一次非零偏移量。

绝不要循环遍历偏移量来重建对话。不要为了弥补读取缓慢或不完整而提高 --content-limit。较小的输出上限并不保证所有已部署后端的服务器端工作量都较低。如果读取缓慢、不完整、失败或超时，请停止，说明证据缺口，并改进搜索，而不要重试分页读取。用户之后明确要求读取其他范围时，可进行一次新的有界读取；常规的“继续”不代表允许读完整个线程。