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命令的四步執(zhí)行流水線內(nèi)容提取、類型分類、直存寫入、異步確認并結(jié)合插件內(nèi)身份解析腳本與架構(gòu)參考文檔說明inferFalse原文直存模式、user_id/app_id作用域的來源以及event_id異步事件機制背后的實現(xiàn)依據(jù)。讀完本文你可以理解如何在 Claude Code、Cursor、Codex 等 AI 編碼工具中把決策、偏好、約定和踩坑經(jīng)驗以“原文直存”方式沉淀為跨會話記憶并驗證寫入是否成功。一、remember 技能在 Mem0 插件中的定位Mem0 插件是一個為 AI 編碼工具提供持久化記憶的能力包支持 Claude CodeCLI、Claude Cowork桌面端、Cursor、Codex、OpenCode 和 Antigravity。插件的清單文件 plugin.json 聲明其核心是“通過 Mem0 Platform MCP server 實現(xiàn)的跨會話、用戶級語義記憶檢索”并通過 16 個斜杠命令和生命周期鉤子完成自動捕獲與元數(shù)據(jù)約束。插件連接遠程 MCP server 的配置見 mcp_config.json{ mcpServers: { mem0: { serverUrl: https://mcp.mem0.ai/mcp/, headers: { Authorization: Token ${MEM0_API_KEY} } } } }也就是說/mem0:remember并不在本地存儲任何數(shù)據(jù)它的最終落點是通過 MCP 工具add_memory調(diào)用遠程的 Mem0 Platform。MEM0_API_KEY以m0-開頭是前置條件安裝方式與 API key 配置見 插件 README 的 Step 1/Step 2。插件共提供 17 個/mem0:技能命令其中與 remember 直接相關(guān)的有/mem0:tour瀏覽全部記憶、/mem0:peek快速檢索、/mem0:stats統(tǒng)計、/mem0:forget刪除等。remember 在其中承擔“顯式寫入入口”的角色——當用戶說 “remember this”、“save this”、“store this”、“note that”或明確要求記錄某個決策、偏好、約定、經(jīng)驗時就該技能被觸發(fā)見其 frontmatter 中的 description 字段。二、四步執(zhí)行流水線SKILL.md 原文流程SKILL.md 將執(zhí)行過程拆成四個步驟提取內(nèi)容、分類、存儲、確認。下面逐步還原并展開。Step 1提取內(nèi)容用戶以參數(shù)形式提供要記住的內(nèi)容/mem0:remember text如果用戶沒有給出文本技能規(guī)定必須先反問“What should I remember?”而不是猜測或留空寫入。這是一個防御性設(shè)計remember 的語義是“用戶明確陳述的事實”空寫入沒有意義。Step 2對記憶分類技能要求根據(jù)內(nèi)容信號為記憶挑選最合適的metadata.type分類規(guī)則表如下完整繼承自原文檔內(nèi)容信號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“l(fā)earned that...”, “figured out...”task_learning環(huán)境、工具、配置類setup, env, tooling, configenvironmental其他任何情況task_learning注意兜底策略無法歸入前六類的內(nèi)容一律落為task_learning保證每條通過 remember 寫入的記憶都帶有可檢索的metadata.type標簽。這個標簽并非擺設(shè)——stats 技能 在統(tǒng)計記憶分布時會把metadata.typeagent 側(cè)打的標簽作為平臺categories缺失時的次級分組維度形成“平臺自動分類 agent 手動分類”的雙通道統(tǒng)計。Step 3調(diào)用 add_memory 直存分類完成后技能指示調(diào)用 MCP 工具add_memory參數(shù)為text用戶原文 user_idactive_user_id app_idactive_project_id metadata{type: 分類得到的類型, branch: 當前分支, confidence: 1.0, source: remember_command} inferFalse各參數(shù)含義與約束text原樣保存用戶的文本不做改寫、總結(jié)或抽取。user_id當前活躍用戶決定記憶掛在哪個用戶維度下。app_id當前項目作用域使記憶限定在當前倉庫/應用內(nèi)。metadata.typeStep 2 的分類結(jié)果。metadata.branch當前 Git 分支便于后續(xù)按分支檢索記憶。metadata.confidence 1.0因為用戶是顯式要求保存的可信度記滿分。metadata.source remember_command標記來源通道。這一點與 import 技能 中metadata.sourcetool-import的寫法一致形成插件內(nèi)統(tǒng)一的來源標記約定。inferFalse核心參數(shù)含義見下一節(jié)深入解析。Step 4確認寫入結(jié)果SKILL.md 明確指出add_memory的響應返回的是event_id而非memory_id因為 Mem0 v3 的寫入是異步的。因此技能要求緊接著調(diào)用一次get_event_status(event_idevent_id)狀態(tài)為SUCCEEDED從事件結(jié)果中打印記憶 ID狀態(tài)為PENDING或processing以 event ID 作為兜底信息打印不阻塞。最終確認輸出格式繼承自原文檔Remembered as type: 內(nèi)容前 80 個字符 Memory ID: 來自事件狀態(tài)的結(jié)果 ID其中只有當內(nèi)容超過 80 個字符被截斷時才在末尾追加...避免對短內(nèi)容畫蛇添足。三、為什么必須 inferFalse原文直存的架構(gòu)依據(jù)remember 技能反復強調(diào)inferFalse并給出兩條理由“用戶已明確陳述事實無需抽取”“用戶顯式要求保存所以 confidence1.0”。這一選擇可以在插件自帶的架構(gòu)參考文檔 architecture.md 中得到印證。該平臺記憶處理流水線分為抽取、去重、存儲三個階段Messages In │ ▼ 1. EXTRACTION (inferTrue) 單次 LLM 調(diào)用抽取全部新事實 inferFalse 時原樣存儲文本 ▼ 2. DEDUPLICATION 基于哈希去重MD5 防精確重復 v3 為 ADD-only無 UPDATE/DELETE ▼ 3. STORAGE 批量向量化 → 向量庫 實體抽取 → 實體庫 ▼ Memory Object其中對兩種抽取模式的界定是inferTrue默認LLM 從對話中抽取結(jié)構(gòu)化事實附帶沖突消解與去重適合“自然對話 → 記憶”的場景inferFalseraw 模式文本按提供原樣存儲不經(jīng)過 LLM 處理跳過沖突消解同一事實可能被存兩次僅保存user角色的消息。適合批量導入、已結(jié)構(gòu)化數(shù)據(jù)、遷移等場景。文檔同時給出一條重要警告不要對同一份數(shù)據(jù)混用inferTrue和inferFalse否則同一事實會被重復存儲。這正是 remember 技能選擇 raw 模式的深層原因——用戶已經(jīng)用一句話把事實說清楚了再走一次 LLM 抽取不僅浪費時延還可能改變用戶原話的措辭而remember的契約就是“verbatim”逐字保存。mem0 技能主文檔 也把這條列為記憶管理的關(guān)鍵注意事項。四、user_id、app_id 與 branch 從哪里來身份解析腳本SKILL.md 中出現(xiàn)的active_user_id、active_project_id、active_branch三個占位符并不是憑空取值——插件提供了一組共享解析腳本鉤子hooks與技能共用以保證口徑一致。user_id 的解析鏈_identity.py 中定義了 API key 與 user_id 的解析優(yōu)先級API key取第一個非空值MEM0_API_KEY環(huán)境變量 →CLAUDE_PLUGIN_OPTION_API_KEYClaude Code userConfig 注入→CLAUDE_PLUGIN_OPTION_MEM0_API_KEY舊版 userConfig→ 從 shell profile 文件~/.zshrc、~/.bashrc等中用正則提取。最后一步是為了覆蓋桌面應用場景桌面應用不會繼承 shell profile 里的環(huán)境變量只能讀取PATH。user_id優(yōu)先MEM0_USER_ID環(huán)境變量顯式覆蓋否則取系統(tǒng)$USER再兜底為default。也就是說remember 寫入時默認把記憶掛在當前系統(tǒng)用戶名下多用戶或 CI 場景可以通過MEM0_USER_ID顯式指定身份。project_id 與 branch 的解析鏈_project.py 定義了app_id即 project_id的四級解析優(yōu)先級MEM0_PROJECT_ID環(huán)境變量顯式覆蓋~/.mem0/project_map.json中按當前工作目錄查找的映射按 Git remote 哈希回查映射自修復機制目錄被移動/重命名后仍能命中舊映射并自動把新 CWD 寫回映射文件從git remote get-url origin推導 slug如gitgithub.com:mem0ai/mem0.git→mem0ai-mem0兼容 HTTPS/SSH/ssh:// 等多種 URL 形態(tài)最終兜底當前工作目錄名。branch則直接來自git branch --show-current失敗時為unknown。從源碼結(jié)構(gòu)看這套解析保證無論鉤子還是技能命令在同一個倉庫里讀到的作用域三元組user/project/branch始終一致/mem0:remember寫入的記憶才能被同項目的/mem0:tour、/mem0:peek等命令檢索回來。插件的 health 技能 在“身份解析”檢查項中正是復用同一套腳本_identity.sh驗證 user_id、project_id、branch 三者非空才判 PASS——這為 remember 的前置條件提供了可執(zhí)行的自檢手段。五、異步寫入與 event_id 事件機制remember 的 Step 4 之所以要先拿event_id再輪詢狀態(tài)是因為 Mem0 v3 的寫入語義API 立即返回{status: PENDING, event_id: evt-...}后臺異步完成抽取/存儲客戶端通過事件狀態(tài)查詢GET /v1/event/{event_id}/即 MCP 工具get_event_status或 webhook 獲取完成通知。這一機制在插件內(nèi)有兩處交叉印證health 技能 的“寫入能力”檢查項用add_memory寫入一條探針記憶metadata{type: health_check, probe: true}、inferFalse然后調(diào)用get_event_status判斷——SUCCEEDED則提取記憶 ID 并調(diào)用delete_memory清理探針PENDING持續(xù) 5 秒以上仍判 PASS寫入已被接受只是處理延遲。這與 remember 的確認邏輯完全同構(gòu)。architecture.md 的“Performance Characteristics”一節(jié)將異步 add 的響應時延標注在 50ms 以內(nèi)也就是說 remember 命令的主體交互延遲很低等待的只是后臺處理完成。這里還有一個與 stats 技能相關(guān)的細節(jié)stats 技能 明確告誡不要用run_id或metadata.session_id過濾去查“本會話寫了什么”因為記憶本身不以run_id存儲、metadata 過濾結(jié)果不可靠會話級統(tǒng)計應走本地統(tǒng)計文件。remember 技能寫入時恰好只帶user_idapp_id不帶run_id與這一約束自洽remember 沉淀的是長期項目記憶而非會話臨時上下文。六、配套操作驗證、檢索與撤銷安裝插件并運行/mem0:onboard驗證 API key 與 MCP 連接、導入項目文件、安裝編碼優(yōu)化的記憶分類之后官方推薦的驗證路徑是/mem0:health檢查連通性與讀寫能力/mem0:stats查看記憶數(shù)量試寫一條/mem0:remember we use TypeScript再運行/mem0:tour確認它被按分類存儲。寫入后如需管理這些記憶插件內(nèi)形成了完整閉環(huán)檢索/mem0:peek用search_memories快速搜索結(jié)果可展示metadata.type與創(chuàng)建時間統(tǒng)計/mem0:stats的類別表中decision、convention、anti_pattern、task_learning、user_preference等行主要就是 remember 通道貢獻的平臺未分配categories時按metadata.type分組撤銷forget 技能 支持“undo last N memories”——通過本地會話統(tǒng)計腳本session_stats.py peek讀取recent_ids數(shù)組確認后調(diào)用delete_memory刪除也支持按搜索詞或 memory ID 刪除且任何刪除前都會二次確認。七、小結(jié)/mem0:remember技能是 Mem0 插件中“顯式記憶寫入”的標準入口其設(shè)計可以歸納為四個要點逐字保存verbatim以inferFalse走 raw 存儲路徑跳過 LLM 事實抽取忠實保留用戶原話避免同一數(shù)據(jù)混用兩種模式造成的重復存儲強制分類metadata.type七類信號映射表 task_learning兜底讓每條顯式記憶都帶類型標簽供 stats 分組、peek 檢索使用確定性作用域user_id/app_id/branch復用插件共享解析腳本與生命周期鉤子保持同一口徑跨命令可檢索、跨會話可復用異步確認event_id → get_event_status適應 v3 平臺“立即返回 PENDING 事件、后臺處理”的寫入模型SUCCEEDED 時輸出記憶 IDPENDING 時以事件 ID 兜底80 字符截斷規(guī)則保證確認信息緊湊可讀。相關(guān)倉庫入口技能定義 integrations/mem0-plugin/skills/remember/SKILL.md、身份解析 integrations/mem0-plugin/scripts/_identity.py 與 integrations/mem0-plugin/scripts/_project.py、平臺架構(gòu)參考 integrations/mem0-plugin/skills/mem0/references/architecture.md、插件安裝與命令總覽 integrations/mem0-plugin/README.md?！久赓M下載鏈接】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創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 Mem0 Plugin 的 /mem0:remember 技能詳解：原文直存、類型分類與異步寫入的四步流水線
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命令的四步執(zhí)行流水線內(nèi)容提取、類型分類、直存寫入、異步確認并結(jié)合插件內(nèi)身份解析腳本與架構(gòu)參考文檔說明inferFalse原文直存模式、user_id/app_id作用域的來源以及event_id異步事件機制背后的實現(xiàn)依據(jù)。讀完本文你可以理解如何在 Claude Code、Cursor、Codex 等 AI 編碼工具中把決策、偏好、約定和踩坑經(jīng)驗以“原文直存”方式沉淀為跨會話記憶并驗證寫入是否成功。一、remember 技能在 Mem0 插件中的定位Mem0 插件是一個為 AI 編碼工具提供持久化記憶的能力包支持 Claude CodeCLI、Claude Cowork桌面端、Cursor、Codex、OpenCode 和 Antigravity。插件的清單文件 plugin.json 聲明其核心是“通過 Mem0 Platform MCP server 實現(xiàn)的跨會話、用戶級語義記憶檢索”并通過 16 個斜杠命令和生命周期鉤子完成自動捕獲與元數(shù)據(jù)約束。插件連接遠程 MCP server 的配置見 mcp_config.json{ mcpServers: { mem0: { serverUrl: https://mcp.mem0.ai/mcp/, headers: { Authorization: Token ${MEM0_API_KEY} } } } }也就是說/mem0:remember并不在本地存儲任何數(shù)據(jù)它的最終落點是通過 MCP 工具add_memory調(diào)用遠程的 Mem0 Platform。MEM0_API_KEY以m0-開頭是前置條件安裝方式與 API key 配置見 插件 README 的 Step 1/Step 2。插件共提供 17 個/mem0:技能命令其中與 remember 直接相關(guān)的有/mem0:tour瀏覽全部記憶、/mem0:peek快速檢索、/mem0:stats統(tǒng)計、/mem0:forget刪除等。remember 在其中承擔“顯式寫入入口”的角色——當用戶說 “remember this”、“save this”、“store this”、“note that”或明確要求記錄某個決策、偏好、約定、經(jīng)驗時就該技能被觸發(fā)見其 frontmatter 中的 description 字段。二、四步執(zhí)行流水線SKILL.md 原文流程SKILL.md 將執(zhí)行過程拆成四個步驟提取內(nèi)容、分類、存儲、確認。下面逐步還原并展開。Step 1提取內(nèi)容用戶以參數(shù)形式提供要記住的內(nèi)容/mem0:remember text如果用戶沒有給出文本技能規(guī)定必須先反問“What should I remember?”而不是猜測或留空寫入。這是一個防御性設(shè)計remember 的語義是“用戶明確陳述的事實”空寫入沒有意義。Step 2對記憶分類技能要求根據(jù)內(nèi)容信號為記憶挑選最合適的metadata.type分類規(guī)則表如下完整繼承自原文檔內(nèi)容信號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“l(fā)earned that...”, “figured out...”task_learning環(huán)境、工具、配置類setup, env, tooling, configenvironmental其他任何情況task_learning注意兜底策略無法歸入前六類的內(nèi)容一律落為task_learning保證每條通過 remember 寫入的記憶都帶有可檢索的metadata.type標簽。這個標簽并非擺設(shè)——stats 技能 在統(tǒng)計記憶分布時會把metadata.typeagent 側(cè)打的標簽作為平臺categories缺失時的次級分組維度形成“平臺自動分類 agent 手動分類”的雙通道統(tǒng)計。Step 3調(diào)用 add_memory 直存分類完成后技能指示調(diào)用 MCP 工具add_memory參數(shù)為text用戶原文 user_idactive_user_id app_idactive_project_id metadata{type: 分類得到的類型, branch: 當前分支, confidence: 1.0, source: remember_command} inferFalse各參數(shù)含義與約束text原樣保存用戶的文本不做改寫、總結(jié)或抽取。user_id當前活躍用戶決定記憶掛在哪個用戶維度下。app_id當前項目作用域使記憶限定在當前倉庫/應用內(nèi)。metadata.typeStep 2 的分類結(jié)果。metadata.branch當前 Git 分支便于后續(xù)按分支檢索記憶。metadata.confidence 1.0因為用戶是顯式要求保存的可信度記滿分。metadata.source remember_command標記來源通道。這一點與 import 技能 中metadata.sourcetool-import的寫法一致形成插件內(nèi)統(tǒng)一的來源標記約定。inferFalse核心參數(shù)含義見下一節(jié)深入解析。Step 4確認寫入結(jié)果SKILL.md 明確指出add_memory的響應返回的是event_id而非memory_id因為 Mem0 v3 的寫入是異步的。因此技能要求緊接著調(diào)用一次get_event_status(event_idevent_id)狀態(tài)為SUCCEEDED從事件結(jié)果中打印記憶 ID狀態(tài)為PENDING或processing以 event ID 作為兜底信息打印不阻塞。最終確認輸出格式繼承自原文檔Remembered as type: 內(nèi)容前 80 個字符 Memory ID: 來自事件狀態(tài)的結(jié)果 ID其中只有當內(nèi)容超過 80 個字符被截斷時才在末尾追加...避免對短內(nèi)容畫蛇添足。三、為什么必須 inferFalse原文直存的架構(gòu)依據(jù)remember 技能反復強調(diào)inferFalse并給出兩條理由“用戶已明確陳述事實無需抽取”“用戶顯式要求保存所以 confidence1.0”。這一選擇可以在插件自帶的架構(gòu)參考文檔 architecture.md 中得到印證。該平臺記憶處理流水線分為抽取、去重、存儲三個階段Messages In │ ▼ 1. EXTRACTION (inferTrue) 單次 LLM 調(diào)用抽取全部新事實 inferFalse 時原樣存儲文本 ▼ 2. DEDUPLICATION 基于哈希去重MD5 防精確重復 v3 為 ADD-only無 UPDATE/DELETE ▼ 3. STORAGE 批量向量化 → 向量庫 實體抽取 → 實體庫 ▼ Memory Object其中對兩種抽取模式的界定是inferTrue默認LLM 從對話中抽取結(jié)構(gòu)化事實附帶沖突消解與去重適合“自然對話 → 記憶”的場景inferFalseraw 模式文本按提供原樣存儲不經(jīng)過 LLM 處理跳過沖突消解同一事實可能被存兩次僅保存user角色的消息。適合批量導入、已結(jié)構(gòu)化數(shù)據(jù)、遷移等場景。文檔同時給出一條重要警告不要對同一份數(shù)據(jù)混用inferTrue和inferFalse否則同一事實會被重復存儲。這正是 remember 技能選擇 raw 模式的深層原因——用戶已經(jīng)用一句話把事實說清楚了再走一次 LLM 抽取不僅浪費時延還可能改變用戶原話的措辭而remember的契約就是“verbatim”逐字保存。mem0 技能主文檔 也把這條列為記憶管理的關(guān)鍵注意事項。四、user_id、app_id 與 branch 從哪里來身份解析腳本SKILL.md 中出現(xiàn)的active_user_id、active_project_id、active_branch三個占位符并不是憑空取值——插件提供了一組共享解析腳本鉤子hooks與技能共用以保證口徑一致。user_id 的解析鏈_identity.py 中定義了 API key 與 user_id 的解析優(yōu)先級API key取第一個非空值MEM0_API_KEY環(huán)境變量 →CLAUDE_PLUGIN_OPTION_API_KEYClaude Code userConfig 注入→CLAUDE_PLUGIN_OPTION_MEM0_API_KEY舊版 userConfig→ 從 shell profile 文件~/.zshrc、~/.bashrc等中用正則提取。最后一步是為了覆蓋桌面應用場景桌面應用不會繼承 shell profile 里的環(huán)境變量只能讀取PATH。user_id優(yōu)先MEM0_USER_ID環(huán)境變量顯式覆蓋否則取系統(tǒng)$USER再兜底為default。也就是說remember 寫入時默認把記憶掛在當前系統(tǒng)用戶名下多用戶或 CI 場景可以通過MEM0_USER_ID顯式指定身份。project_id 與 branch 的解析鏈_project.py 定義了app_id即 project_id的四級解析優(yōu)先級MEM0_PROJECT_ID環(huán)境變量顯式覆蓋~/.mem0/project_map.json中按當前工作目錄查找的映射按 Git remote 哈希回查映射自修復機制目錄被移動/重命名后仍能命中舊映射并自動把新 CWD 寫回映射文件從git remote get-url origin推導 slug如gitgithub.com:mem0ai/mem0.git→mem0ai-mem0兼容 HTTPS/SSH/ssh:// 等多種 URL 形態(tài)最終兜底當前工作目錄名。branch則直接來自git branch --show-current失敗時為unknown。從源碼結(jié)構(gòu)看這套解析保證無論鉤子還是技能命令在同一個倉庫里讀到的作用域三元組user/project/branch始終一致/mem0:remember寫入的記憶才能被同項目的/mem0:tour、/mem0:peek等命令檢索回來。插件的 health 技能 在“身份解析”檢查項中正是復用同一套腳本_identity.sh驗證 user_id、project_id、branch 三者非空才判 PASS——這為 remember 的前置條件提供了可執(zhí)行的自檢手段。五、異步寫入與 event_id 事件機制remember 的 Step 4 之所以要先拿event_id再輪詢狀態(tài)是因為 Mem0 v3 的寫入語義API 立即返回{status: PENDING, event_id: evt-...}后臺異步完成抽取/存儲客戶端通過事件狀態(tài)查詢GET /v1/event/{event_id}/即 MCP 工具get_event_status或 webhook 獲取完成通知。這一機制在插件內(nèi)有兩處交叉印證health 技能 的“寫入能力”檢查項用add_memory寫入一條探針記憶metadata{type: health_check, probe: true}、inferFalse然后調(diào)用get_event_status判斷——SUCCEEDED則提取記憶 ID 并調(diào)用delete_memory清理探針PENDING持續(xù) 5 秒以上仍判 PASS寫入已被接受只是處理延遲。這與 remember 的確認邏輯完全同構(gòu)。architecture.md 的“Performance Characteristics”一節(jié)將異步 add 的響應時延標注在 50ms 以內(nèi)也就是說 remember 命令的主體交互延遲很低等待的只是后臺處理完成。這里還有一個與 stats 技能相關(guān)的細節(jié)stats 技能 明確告誡不要用run_id或metadata.session_id過濾去查“本會話寫了什么”因為記憶本身不以run_id存儲、metadata 過濾結(jié)果不可靠會話級統(tǒng)計應走本地統(tǒng)計文件。remember 技能寫入時恰好只帶user_idapp_id不帶run_id與這一約束自洽remember 沉淀的是長期項目記憶而非會話臨時上下文。六、配套操作驗證、檢索與撤銷安裝插件并運行/mem0:onboard驗證 API key 與 MCP 連接、導入項目文件、安裝編碼優(yōu)化的記憶分類之后官方推薦的驗證路徑是/mem0:health檢查連通性與讀寫能力/mem0:stats查看記憶數(shù)量試寫一條/mem0:remember we use TypeScript再運行/mem0:tour確認它被按分類存儲。寫入后如需管理這些記憶插件內(nèi)形成了完整閉環(huán)檢索/mem0:peek用search_memories快速搜索結(jié)果可展示metadata.type與創(chuàng)建時間統(tǒng)計/mem0:stats的類別表中decision、convention、anti_pattern、task_learning、user_preference等行主要就是 remember 通道貢獻的平臺未分配categories時按metadata.type分組撤銷forget 技能 支持“undo last N memories”——通過本地會話統(tǒng)計腳本session_stats.py peek讀取recent_ids數(shù)組確認后調(diào)用delete_memory刪除也支持按搜索詞或 memory ID 刪除且任何刪除前都會二次確認。七、小結(jié)/mem0:remember技能是 Mem0 插件中“顯式記憶寫入”的標準入口其設(shè)計可以歸納為四個要點逐字保存verbatim以inferFalse走 raw 存儲路徑跳過 LLM 事實抽取忠實保留用戶原話避免同一數(shù)據(jù)混用兩種模式造成的重復存儲強制分類metadata.type七類信號映射表 task_learning兜底讓每條顯式記憶都帶類型標簽供 stats 分組、peek 檢索使用確定性作用域user_id/app_id/branch復用插件共享解析腳本與生命周期鉤子保持同一口徑跨命令可檢索、跨會話可復用異步確認event_id → get_event_status適應 v3 平臺“立即返回 PENDING 事件、后臺處理”的寫入模型SUCCEEDED 時輸出記憶 IDPENDING 時以事件 ID 兜底80 字符截斷規(guī)則保證確認信息緊湊可讀。相關(guān)倉庫入口技能定義 integrations/mem0-plugin/skills/remember/SKILL.md、身份解析 integrations/mem0-plugin/scripts/_identity.py 與 integrations/mem0-plugin/scripts/_project.py、平臺架構(gòu)參考 integrations/mem0-plugin/skills/mem0/references/architecture.md、插件安裝與命令總覽 integrations/mem0-plugin/README.md?！久赓M下載鏈接】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創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考