Mem0 Plugin 的 /mem0:remember 技能详解原文直存、类型分类与异步写入的四步流水线【免费下载链接】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本文围绕 Mem0 插件中的 remember 技能 展开完整拆解/mem0:remember命令的四步执行流水线内容提取、类型分类、直存写入、异步确认并结合插件内身份解析脚本与架构参考文档说明inferFalse原文直存模式、user_id/app_id作用域的来源以及event_id异步事件机制背后的实现依据。读完本文你可以理解如何在 Claude Code、Cursor、Codex 等 AI 编码工具中把决策、偏好、约定和踩坑经验以“原文直存”方式沉淀为跨会话记忆并验证写入是否成功。一、remember 技能在 Mem0 插件中的定位Mem0 插件是一个为 AI 编码工具提供持久化记忆的能力包支持 Claude CodeCLI、Claude Cowork桌面端、Cursor、Codex、OpenCode 和 Antigravity。插件的清单文件 plugin.json 声明其核心是“通过 Mem0 Platform MCP server 实现的跨会话、用户级语义记忆检索”并通过 16 个斜杠命令和生命周期钩子完成自动捕获与元数据约束。插件连接远程 MCP server 的配置见 mcp_config.json{ mcpServers: { mem0: { serverUrl: https://mcp.mem0.ai/mcp/, headers: { Authorization: Token ${MEM0_API_KEY} } } } }也就是说/mem0:remember并不在本地存储任何数据它的最终落点是通过 MCP 工具add_memory调用远程的 Mem0 Platform。MEM0_API_KEY以m0-开头是前置条件安装方式与 API key 配置见 插件 README 的 Step 1/Step 2。插件共提供 17 个/mem0:技能命令其中与 remember 直接相关的有/mem0:tour浏览全部记忆、/mem0:peek快速检索、/mem0:stats统计、/mem0:forget删除等。remember 在其中承担“显式写入入口”的角色——当用户说 “remember this”、“save this”、“store this”、“note that”或明确要求记录某个决策、偏好、约定、经验时就该技能被触发见其 frontmatter 中的 description 字段。二、四步执行流水线SKILL.md 原文流程SKILL.md 将执行过程拆成四个步骤提取内容、分类、存储、确认。下面逐步还原并展开。Step 1提取内容用户以参数形式提供要记住的内容/mem0:remember text如果用户没有给出文本技能规定必须先反问“What should I remember?”而不是猜测或留空写入。这是一个防御性设计remember 的语义是“用户明确陈述的事实”空写入没有意义。Step 2对记忆分类技能要求根据内容信号为记忆挑选最合适的metadata.type分类规则表如下完整继承自原文档内容信号Content signal类型Type“we decided...”, “always use...”, “never...”decision“X doesnt work because...”, “dont try...”anti_pattern“I prefer...”, “use X instead of Y”user_preference“the convention is...”, “we always...”convention“learned that...”, “figured out...”task_learning环境、工具、配置类setup, env, tooling, configenvironmental其他任何情况task_learning注意兜底策略无法归入前六类的内容一律落为task_learning保证每条通过 remember 写入的记忆都带有可检索的metadata.type标签。这个标签并非摆设——stats 技能 在统计记忆分布时会把metadata.typeagent 侧打的标签作为平台categories缺失时的次级分组维度形成“平台自动分类 agent 手动分类”的双通道统计。Step 3调用 add_memory 直存分类完成后技能指示调用 MCP 工具add_memory参数为text用户原文 user_idactive_user_id app_idactive_project_id metadata{type: 分类得到的类型, branch: 当前分支, confidence: 1.0, source: remember_command} inferFalse各参数含义与约束text原样保存用户的文本不做改写、总结或抽取。user_id当前活跃用户决定记忆挂在哪个用户维度下。app_id当前项目作用域使记忆限定在当前仓库/应用内。metadata.typeStep 2 的分类结果。metadata.branch当前 Git 分支便于后续按分支检索记忆。metadata.confidence 1.0因为用户是显式要求保存的可信度记满分。metadata.source remember_command标记来源通道。这一点与 import 技能 中metadata.sourcetool-import的写法一致形成插件内统一的来源标记约定。inferFalse核心参数含义见下一节深入解析。Step 4确认写入结果SKILL.md 明确指出add_memory的响应返回的是event_id而非memory_id因为 Mem0 v3 的写入是异步的。因此技能要求紧接着调用一次get_event_status(event_idevent_id)状态为SUCCEEDED从事件结果中打印记忆 ID状态为PENDING或processing以 event ID 作为兜底信息打印不阻塞。最终确认输出格式继承自原文档Remembered as type: 内容前 80 个字符 Memory ID: 来自事件状态的结果 ID其中只有当内容超过 80 个字符被截断时才在末尾追加...避免对短内容画蛇添足。三、为什么必须 inferFalse原文直存的架构依据remember 技能反复强调inferFalse并给出两条理由“用户已明确陈述事实无需抽取”“用户显式要求保存所以 confidence1.0”。这一选择可以在插件自带的架构参考文档 architecture.md 中得到印证。该平台记忆处理流水线分为抽取、去重、存储三个阶段Messages In │ ▼ 1. EXTRACTION (inferTrue) 单次 LLM 调用抽取全部新事实 inferFalse 时原样存储文本 ▼ 2. DEDUPLICATION 基于哈希去重MD5 防精确重复 v3 为 ADD-only无 UPDATE/DELETE ▼ 3. STORAGE 批量向量化 → 向量库 实体抽取 → 实体库 ▼ Memory Object其中对两种抽取模式的界定是inferTrue默认LLM 从对话中抽取结构化事实附带冲突消解与去重适合“自然对话 → 记忆”的场景inferFalseraw 模式文本按提供原样存储不经过 LLM 处理跳过冲突消解同一事实可能被存两次仅保存user角色的消息。适合批量导入、已结构化数据、迁移等场景。文档同时给出一条重要警告不要对同一份数据混用inferTrue和inferFalse否则同一事实会被重复存储。这正是 remember 技能选择 raw 模式的深层原因——用户已经用一句话把事实说清楚了再走一次 LLM 抽取不仅浪费时延还可能改变用户原话的措辞而remember的契约就是“verbatim”逐字保存。mem0 技能主文档 也把这条列为记忆管理的关键注意事项。四、user_id、app_id 与 branch 从哪里来身份解析脚本SKILL.md 中出现的active_user_id、active_project_id、active_branch三个占位符并不是凭空取值——插件提供了一组共享解析脚本钩子hooks与技能共用以保证口径一致。user_id 的解析链_identity.py 中定义了 API key 与 user_id 的解析优先级API key取第一个非空值MEM0_API_KEY环境变量 →CLAUDE_PLUGIN_OPTION_API_KEYClaude Code userConfig 注入→CLAUDE_PLUGIN_OPTION_MEM0_API_KEY旧版 userConfig→ 从 shell profile 文件~/.zshrc、~/.bashrc等中用正则提取。最后一步是为了覆盖桌面应用场景桌面应用不会继承 shell profile 里的环境变量只能读取PATH。user_id优先MEM0_USER_ID环境变量显式覆盖否则取系统$USER再兜底为default。也就是说remember 写入时默认把记忆挂在当前系统用户名下多用户或 CI 场景可以通过MEM0_USER_ID显式指定身份。project_id 与 branch 的解析链_project.py 定义了app_id即 project_id的四级解析优先级MEM0_PROJECT_ID环境变量显式覆盖~/.mem0/project_map.json中按当前工作目录查找的映射按 Git remote 哈希回查映射自修复机制目录被移动/重命名后仍能命中旧映射并自动把新 CWD 写回映射文件从git remote get-url origin推导 slug如gitgithub.com:mem0ai/mem0.git→mem0ai-mem0兼容 HTTPS/SSH/ssh:// 等多种 URL 形态最终兜底当前工作目录名。branch则直接来自git branch --show-current失败时为unknown。从源码结构看这套解析保证无论钩子还是技能命令在同一个仓库里读到的作用域三元组user/project/branch始终一致/mem0:remember写入的记忆才能被同项目的/mem0:tour、/mem0:peek等命令检索回来。插件的 health 技能 在“身份解析”检查项中正是复用同一套脚本_identity.sh验证 user_id、project_id、branch 三者非空才判 PASS——这为 remember 的前置条件提供了可执行的自检手段。五、异步写入与 event_id 事件机制remember 的 Step 4 之所以要先拿event_id再轮询状态是因为 Mem0 v3 的写入语义API 立即返回{status: PENDING, event_id: evt-...}后台异步完成抽取/存储客户端通过事件状态查询GET /v1/event/{event_id}/即 MCP 工具get_event_status或 webhook 获取完成通知。这一机制在插件内有两处交叉印证health 技能 的“写入能力”检查项用add_memory写入一条探针记忆metadata{type: health_check, probe: true}、inferFalse然后调用get_event_status判断——SUCCEEDED则提取记忆 ID 并调用delete_memory清理探针PENDING持续 5 秒以上仍判 PASS写入已被接受只是处理延迟。这与 remember 的确认逻辑完全同构。architecture.md 的“Performance Characteristics”一节将异步 add 的响应时延标注在 50ms 以内也就是说 remember 命令的主体交互延迟很低等待的只是后台处理完成。这里还有一个与 stats 技能相关的细节stats 技能 明确告诫不要用run_id或metadata.session_id过滤去查“本会话写了什么”因为记忆本身不以run_id存储、metadata 过滤结果不可靠会话级统计应走本地统计文件。remember 技能写入时恰好只带user_idapp_id不带run_id与这一约束自洽remember 沉淀的是长期项目记忆而非会话临时上下文。六、配套操作验证、检索与撤销安装插件并运行/mem0:onboard验证 API key 与 MCP 连接、导入项目文件、安装编码优化的记忆分类之后官方推荐的验证路径是/mem0:health检查连通性与读写能力/mem0:stats查看记忆数量试写一条/mem0:remember we use TypeScript再运行/mem0:tour确认它被按分类存储。写入后如需管理这些记忆插件内形成了完整闭环检索/mem0:peek用search_memories快速搜索结果可展示metadata.type与创建时间统计/mem0:stats的类别表中decision、convention、anti_pattern、task_learning、user_preference等行主要就是 remember 通道贡献的平台未分配categories时按metadata.type分组撤销forget 技能 支持“undo last N memories”——通过本地会话统计脚本session_stats.py peek读取recent_ids数组确认后调用delete_memory删除也支持按搜索词或 memory ID 删除且任何删除前都会二次确认。七、小结/mem0:remember技能是 Mem0 插件中“显式记忆写入”的标准入口其设计可以归纳为四个要点逐字保存verbatim以inferFalse走 raw 存储路径跳过 LLM 事实抽取忠实保留用户原话避免同一数据混用两种模式造成的重复存储强制分类metadata.type七类信号映射表 task_learning兜底让每条显式记忆都带类型标签供 stats 分组、peek 检索使用确定性作用域user_id/app_id/branch复用插件共享解析脚本与生命周期钩子保持同一口径跨命令可检索、跨会话可复用异步确认event_id → get_event_status适应 v3 平台“立即返回 PENDING 事件、后台处理”的写入模型SUCCEEDED 时输出记忆 IDPENDING 时以事件 ID 兜底80 字符截断规则保证确认信息紧凑可读。相关仓库入口技能定义 integrations/mem0-plugin/skills/remember/SKILL.md、身份解析 integrations/mem0-plugin/scripts/_identity.py 与 integrations/mem0-plugin/scripts/_project.py、平台架构参考 integrations/mem0-plugin/skills/mem0/references/architecture.md、插件安装与命令总览 integrations/mem0-plugin/README.md。【免费下载链接】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），仅供参考