Mem0 Plugin Peek 技能解析：/mem0:peek 快速记忆检索、短 ID 直查与紧凑引文输出

Mem0 Plugin Peek 技能解析/mem0:peek 快速记忆检索、短 ID 直查与紧凑引文输出【免费下载链接】embedchainThe Memory Layer for AI Agents - Drop-in memory infrastructure for AI agents and apps. Context that persists. Built for production.项目地址: https://gitcode.com/GitHub_Trending/em/embedchainMem0 Plugin 为 Claude Code、Cursor、Codex、OpenCode、Antigravity 等 AI 编码环境提供持久化语义记忆其中peek技能/mem0:peek是面向「快速查证」场景的轻量检索命令既支持按关键词做双通道语义搜索也支持通过短 ID 或[mem0:id]引文直查单条记忆并以每行一条的紧凑格式返回结果。读完本文你能完整掌握 peek 的三步执行流程解析 → 并行搜索 → 去重展示、其背后的身份与项目作用域解析机制user_id/app_id从何而来以及 rerank 参数在平台 REST 接口上的真实行为从而在 Agent 工作流中可靠地用它来核对「某个决策是否被记录下来」或解析记忆引文。1. peek 在插件技能体系中的定位peek 技能定义在 skills/peek/SKILL.md其元信息声明的用途是Searches memories and displays compact one-liner results, or looks up a specific memory by ID. Use for quick memory lookups, checking if a decision was recorded, resolving[mem0:id]citations, or browsing memories without full category detail.也就是说它解决的是四个具体场景快速记忆检索、确认某个决策是否已被记录、解析[mem0:id]形式的记忆引文、以及不想展开完整分类详情的轻量浏览。原文档明确将它与/mem0:tour做了区分——「Quick search with compact output. Lighter than/mem0:tour」。两者对比可以理解为维度/mem0:peek/mem0:tourSKILL.md触发方式带搜索词如/mem0:peek auth middleware无参数全量分类浏览或带--all-projects跨项目数据获取2 次并行search_memories1 次get_memoriespage_size100 3 次补充语义搜索输出形态每行一条的记忆引文content 截断 80 字符按类别分组、展示完整记忆文本附加能力支持裸 ID /[mem0:hex]直查单条支持跨项目模式值得注意的是tour 技能文档中本身就内置了一段「Peek mode」流程当/mem0:tour带搜索词且不带--all-projects时会退化为与 peek 完全相同的紧凑搜索流程。这说明 peek 实质上是插件记忆检索的「紧凑显示协议」两个入口共用同一套双路搜索策略。2. Step 1解析查询与 Memory ID 检测用户提供搜索查询例如/mem0:peek auth middleware。若未提供查询词技能要求 Agent 反问 What should I search for?而不是凭空搜索。关键的工程细节是Memory ID 检测。如果查询词命中以下任一模式技能会把它当作「直接按 ID 查单条记忆」而不是搜索裸十六进制短 ID^[a-f0-9]{8}$8 位 hex 短 ID完整 UUID^[a-f0-9]{8}-[a-f0-9-]$引文引用[mem0:hex]—— 提取其中的 hex 部分检测到 ID 后的处理策略是三层降级直接调用 MCP 工具get_memory(id)如果是短 ID则作为完整 UUID 的前缀尝试匹配命中则跳过 Step 2 的搜索直接进入 Step 3 展示这一条结果未命中则回落到正常搜索——把这个 ID 当作文本 query 去检索。这个设计对应了 README 中提到的「17 个/mem0:命令」体系peek 输出的[mem0:short_id]标记是全局记忆引用协议的一部分后续/mem0:forget按 ID 删除、/mem0:pin保护等命令都以同一 ID 体系为操作对象而 peek 是其中最常用来「验证引文指向哪条记忆」的入口。3. Step 2双通道并行搜索Broad Targeted未命中 ID 检测时peek 要求发起2 个并行的search_memories调用1. Broad宽召回: query用户查询词 filters{AND: [{user_id: id}, {app_id: pid}]} top_k10 reranktrue 2. Targeted定向召回: query用户查询词 filters{AND: [{user_id: id}, {app_id: pid}, {metadata: {type: decision}}]} top_k5 reranktrue设计意图很清晰Broad 通道在user_idapp_id双约束下取 top 10保证召回面——任何类别的记忆决策、约定、反模式、工具链配置都可能命中Targeted 通道额外叠加metadata.type decision过滤专门捞「架构决策」类记忆——因为 peek 的典型用例之一就是「确认某个决策是否被记录过」两路都显式设置reranktrue让平台侧用 reranker 重排而不是只按原始向量相似度截断。3.1 作用域参数从哪里来user_id与app_id的解析链filters 里的id和pid并非手填而是插件共享脚本在会话期自动解析的身份与项目作用域user_id见 scripts/_identity.py 的resolve_user_id()——优先读MEM0_USER_ID环境变量否则取$USER再兜底defaultapp_id见 scripts/_project.py 的resolve_project_id()解析优先级为MEM0_PROJECT_ID环境变量显式覆盖对应/mem0:switch-project的能力~/.mem0/project_map.json按当前工作目录查找按 git remote URL 的 SHA-256 哈希键查找目录被移动/重命名后的自愈回退并会回填新的 cwd 键git remote slug如gitgithub.com:mem0ai/mem0.git→mem0ai-mem0兜底当前目录 basename。这解释了为什么 peek 的每次搜索都被严格限定在「某用户 × 某项目」的格子内——同一台机器上多个仓库的记忆互不串扰这也是空结果提示里出现for project project_id的原因。3.2rerank参数在平台接口上的真实语义peek 两次搜索都要求reranktrue这个要求在插件的共享搜索助手 scripts/_search.py 中有明确的源码级解释The REST search endpoint does not rerank whenrerankis omitted, so auto-injected context is ordered by raw vector similarity and the single most relevant memory can fall outside the injected top_k window.也就是说Mem0 的 REST 搜索端点POST /v3/memories/search/见 scripts/_search.py 的SEARCH_URL在省略rerank字段时不重排结果只按原始向量相似度排序唯一最相关的记忆可能掉出top_k窗口。为此插件提供了should_rerank()默认开启 rerank额外约 150–200ms 延迟在 hook 的 curl 预算内并允许用户通过MEM0_RERANK环境变量关闭——取值0、false、no、off大小写不敏感禁用未设置或其他值均启用。这些行为不是口说无凭仓库中有成体系的回归测试tests/test_search.pytest_search_memories_omits_rerank_by_default#L138-L155不传rerank时请求体中不得出现rerank字段回归 issue #5684避免「默认重排」造成意外的额外延迟/配额消耗test_search_memories_forwards_rerank_true#L158-L176rerankTrue必须真实到达请求体否则端点不会重排test_should_rerank_defaults_true/test_should_rerank_opt_out_values#L179-L196锁定MEM0_RERANK的默认开启与全部关闭取值。此外search_memories()的健壮性也有测试覆盖API key 为空直接返回空列表而不发请求test_search_memories_no_api_key_returns_empty网络异常时向 stderr 输出错误并返回[]而 429 限流必须留下可区分的错误日志test_search_memories_logs_rate_limit_error注释标注 Bug bash #22: a 429 must not look identical to a genuine empty result——这对 peek 使用者是个实用提示当 peek 返回「无结果」而会话恰好遇到限流时应先检查是否刚被 429。从源码结构看hook 自动注入路径走的是这个 Python 助手带 5 秒超时的urllib直连而/mem0:peek命令本身由 Agent 通过 MCP 工具search_memories发起两者最终打到同一个平台搜索端点参数语义filters的AND子句、top_k、threshold、rerank是一致的。4. Step 3去重与紧凑一行式展示两路结果合并后先按记忆 ID 去重Broad 的 top 10 与 Targeted 的 top 5 必然重叠再按固定模板输出## mem0 peek: query (N results) 1. [decision] Auth module uses JWT with RS256 keys (2025-05-15) [mem0:a3f8b2c1] 2. [anti_pattern] Dont use symmetric HS256 — leaked in env (2025-05-10) [mem0:7e2d9f4a] 3. [convention] All middleware in src/middleware/ (2025-05-08) [mem0:c4d5e6f7]每行的格式契约是number. [type] content, 80 chars (date) [mem0:short_id]type记忆类别来自metadata.type如decision、anti_pattern、conventioncontent记忆正文截断到 80 字符——这是「紧凑」的关键保证 Agent 上下文里一条记忆只占一行date记忆日期[mem0:short_id]8 位 hex 短 ID 引文即 Step 1 中可被再次用于直查的引用标记。无结果时的空状态输出是确定性的No memories matching query for project project_id.这套一行式引文格式并非 peek 独有插件的自动注入路径也使用同一族格式scripts/_search.py 中的format_results_for_context()把搜索结果渲染为- [category] text[:200] [mem0:id 前 8 位]注入 prompt。可以推断[mem0:xxxxxxxx]短 ID 引文是插件「记忆 → Agent 上下文 → 后续按 ID 操作」闭环的通用货币peek 打印它、hook 注入它、Agent 用get_memory/forget/pin消费它。5. 运行前提与相关组件peek 不是独立程序它依赖插件整体的三层组件见 integrations/mem0-plugin/README.md 与 plugin.json 的声明MCP Server插件通过 mcp_config.json 接入 Mem0 远程 MCP 端点https://mcp.mem0.ai/mcp/Authorization: Token ${MEM0_API_KEY}在会话启动时做环境变量插值。search_memories与get_memory正是 MCP 工具表中的两个工具API KeyMEM0_API_KEY以m0-开头必须已在 shell 环境或客户端本地环境中设置——scripts/_identity.py 的resolve_api_key()会按「环境变量 → Claude Code userConfig 注入 → shell profile 文件提取」的顺序兜底解析生命周期 Hooks可选但推荐hooks.json 将SessionStart、UserPromptSubmit、PreToolUse、Stop、PostToolUse等事件接到scripts/下的脚本自动捕获记忆并强制user_id/app_id元数据——UserPromptSubmit钩子on_user_prompt.sh超时 8 秒内部就调用 §3 所述的search_memories()助手做相关记忆注入。peek 之所以「有东西可查」很大程度依赖这些钩子在会话过程中持续写入记忆。典型验证链路也写在 README 中/mem0:health连通性→/mem0:stats计数→/mem0:remember we use TypeScript→/mem0:tour或/mem0:peek查看。6. 小结何时用 peek何时用 tour从这份技能文档可以提炼出一条清晰的决策准则用/mem0:peek query你只需要答案本身——「JWT 的决策记过没有」「a3f8b2c1这条记忆写的什么」——需要的是带引文的一行式结果可以直接粘进对话或 commit message用/mem0:tour你要审视图景——按类别浏览全部记忆、查看完整正文、在新项目 onboarding 时建立整体认知两者共享同一套双路搜索协议Broadtop_k10 Targeted decisiontop_k5均reranktrue因此检索质量一致差异只在展示密度。配合MEM0_RERANK调优重排开销、MEM0_PROJECT_ID固定项目作用域peek 就成为 Agent 编码工作流中「记忆可查证性」的最小可用单元每条输出都带[mem0:id]引文任何一条结果都可以被后续命令精确追踪、引用、更新或删除。【免费下载链接】embedchainThe Memory Layer for AI Agents - Drop-in memory infrastructure for AI agents and apps. Context that persists. Built for production.项目地址: https://gitcode.com/GitHub_Trending/em/embedchain创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考