memU WorkBuddy 宿主卸载完全指南从桥接任务注销到数据保留的逐步拆除手册【免费下载链接】memUPersonal memory across agents项目地址: https://gitcode.com/GitHub_Trending/mem/memU本指南围绕 memU 项目中针对 WorkBuddy 宿主的官方卸载文档 UNINSTALL.md 展开讲解如何安全、可逆地将 memU 的记录record与注入inject两条接缝从 WorkBuddy 中拆除同时始终保留用户积累的记忆数据。读完本文你将掌握按验证门逐步推进的拆除流程、remove-instruction与report uninstall等命令的正确用法以及一个存储、多个宿主架构下如何判断memu-cli包何时可以安全卸载。卸载的本质把安装过程倒着执行一遍在 memU 的架构中向某个宿主如 WorkBuddy接入记忆能力依赖两条接缝seam卸载就是把这两条接缝按相反顺序拆除最后处理数据与包取消注册桥接任务record 接缝——先停掉定时自动化避免在拆除过程中触发任何任务移除检索指令inject 接缝——删除写入~/.workbuddy/SOUL.md的常驻检索指令包括旧版落在MEMORY.md中的遗留块应用数据与包的默认值——用户记忆保留工具拆除最后向 memU 报告结果。文档的读者是 Agent。原文档开篇明确声明Audience: the agent. A user has pointed you at this file。这意味着这篇指南本身就是写给执行卸载的 AI Agent 的操作手册从上到下逐部分执行每部分结尾都有verify 验证门——当前门未通过前不得继续下一步。任务身份Task identity按名字识别但绝不只按名字删除卸载的第一步是准确识别哪个自动化属于 memU。原文档在每个部分顶部都给出了任务身份字段当前任务名{{task_name}}此前用过的任务名{{former_task_names}}迁移与移除过程中需要识别的全部名称{{all_task_names}}这些{{...}}是文档模板 token并非字面值。在源码 host_cli.py 的render_doc方法中它们会在docs uninstall打印指南时被替换为 WorkBuddy 宿主的实际值。从 cli.py 的HostSpec声明可以看到具体内容当前任务名为memu-bridging-workbuddyall_task_names是当前任务名 全部历史别名的并集。这种 token 化机制保证注册代码与文档文字不会各自漂移。一个存储、多个宿主卸载的边界在哪里~/.memu/config.env以及它所指向的存储可能被这台机器上的其他 memU 宿主适配器memu-codex、memu-claude-code等共享。拆除本宿主的接缝永远不需要触碰共享存储Part 3 才会说明何时触碰共享存储才是安全的。本文档只卸载WorkBuddy 宿主。其他宿主一律不在范围内绝不触摸、取消补丁或运行其他宿主的卸载流程——保留~/.memu/hosts/下它们的工作树如~/.memu/hosts/codex/及其指令文件原样不动。Part 1 — 取消注册桥接record任务record 接缝是一个定时任务它周期性把最近的 WorkBuddy 会话挖掘进 memU 的记忆、技能与资源。卸载的第一步就是通过 WorkBuddy 的自动化管理界面找到任务文本中同时携带{{all_task_names}}中任一被识别名称、以及memU bridging pipeline提示文本的那个自动化然后只删除它的精确自动化 ID。关键安全原则仅凭名称永远不足以删除。因为 WorkBuddy 的自动化表面没有独立的名称字段任务文本首行才是跨平台可见的标记详见 BRIDGING_TASK.md 中{{task_name}}的使用说明而自动化 ID 完整流水线内容才是删除的权威依据。从源码结构看桥接任务的完整形态是prepare→ 自我演化 →commit三步流水线memu-workbuddy prepare扫描新会话并生成编号作业文件Agent 按编号逐个执行memu-workbuddy commit提交结果工作目录全部位于~/.memu/hosts/workbuddy/下路径布局定义在 layout.py。WorkBuddy 宿主的调度后端在HostSpec中声明为schedule_backendnativecli.py即使用 WorkBuddy 自带的自动化系统。卸载时必须先删任务、后拆指令这样拆除过程中不会有任何定时任务意外触发。✅ 验证 Part 1该自动化不再出现在 WorkBuddy 的自动化列表中。Part 2 — 移除检索指令inject 接缝inject 接缝是写在 WorkBuddy全局行为文件~/.workbuddy/SOUL.md中的一段常驻指令WorkBuddy 会把该文件加载进每一个会话从而让回答前先检索记忆这条行为天然存在——没有钩子、没有包装器、没有逐轮进程。为什么行为要放在SOUL.md而不是MEMORY.md因为MEMORY.md存放的是用户事实与对话摘要行为指令不属于那里这一设计在 cli.py 的模块注释中有明确说明。不要手改块让 memU 自己移除memu-workbuddy remove-instruction不要手工删除这段块。memU 拥有这段文本并由它负责移除。该命令会从~/.workbuddy/SOUL.md删除 memU 的标记块同时检查旧的~/.workbuddy/MEMORY.md目标让旧版本安装也能被干净移除标记之外的所有内容都属于用户原样保留每个被改写的文件在重写前都会备份到相邻的.bak路径SOUL.md.bak、MEMORY.md.bak--dry-run只展示两处差异而不写入重复运行是干净的无操作no-op——没有遗留块的文件本身就是期望的终态。标记块机制定义在 instruction.py块由!-- memu:begin — managed block, do not edit (...install-instruction) --与!-- memu:end --两个标记界定。remove()函数的实现instruction.py与安装侧的install()具有相同的安全属性只有标记围栏内的块被取回块外内容逐字保留同时移除安装时添加的空白分隔行使安装→移除往返能够字节级还原文件。_cmd_remove_instruction命令处理器instruction.py在默认路径生效时会同时检查当前目标与全部 legacy 路径逐个移除标记块并打印 diff如果所有文件都没有残留块则输出no managed block to remove。这些行为都有测试用例印证test_host_instruction.pytest_remove_restores_user_content_byte_for_byte用户内容字节级还原、test_remove_leaves_a_block_only_file_empty仅含块的纯文件移除后为空、test_remove_without_block_or_file_is_a_noop无块或无文件是无操作、test_remove_only_takes_this_hosts_block只取走本宿主的块、test_remove_dry_run_writes_nothingdry-run 不写入、test_remove_backs_up_before_rewriting重写前先备份。✅ 验证 Part 2同时检查两个文件cat ~/.workbuddy/SOUL.md cat ~/.workbuddy/MEMORY.md确认不再有任何memu:begin/memu:end标记残留且用户自己的内容完好。注意当前会话加载的是旧文件所以指令可能仍存在于你自己的上下文中只有新开会话才会看到移除效果。Part 3 — 数据、配置与包默认值优先然后报告这部分无需向用户提问直接应用以下默认值并确保最终报告向用户明确传达记忆保留、工具移除。唯一能覆盖默认值的是用户自己的明确话语。保留存储与~/.memu/config.env始终存储本身就是用户积累的记忆按设计在卸载后存活——之后重装会原样接回。只有用户明确要求作为本次卸载的一部分抹掉记忆时才删除且必须先用平实的语言警告这是不可逆的。从事件上报的源码可以侧面印证这一设计的分量events.py 中client_instance_id()把机器级稳定 ID 存放在~/.memu/config.env注释明确指出UNINSTALL.md Part 3 要求始终、无条件保留该文件因此安装→卸载→重装会拼接成同一实例的历史——这正是该 ID 存在的全部意义。会话游标与存储共存亡~/.memu/hosts/workbuddy/.session_manifest.workbuddy.json这个文件记录哪些会话轮次已经被挖掘进那个存储。对应源码在 layout.pysession_manifest是按宿主作用域的每会话行游标由成功的commit推进prepare只写.pending暂存副本它的存在让每次桥接运行只处理未见过的轮次。存储保留默认→ 保留游标。删掉它不会丢失记忆但下次安装会为毫无意义的旧会话做全量重新挖掘用户要求删除存储→ 连同游标一起删除。一个存活在空存储上的游标会把历史标记为已挖掘而这些历史永远不会再被挖掘。移除本宿主的残留物~/.memu/hosts/workbuddy/下的一切其他内容——作业文件jobs/*.txt与镜像文件——都应移除唯独保留上面的会话游标。至于~/.workbuddy/SOUL.md本身如果 Part 2 之后它变成空文件说明它只装了 memU 的块即安装时创建的可以一并删除包含用户自己内容的文件当然保留。在包能卸载之前先告诉 memU 卸载发生了接缝已拆、残留已清在下面把memu-workbuddy从这台机器上移除之前执行memu-workbuddy report uninstall与 memU 的其他所有事件不同这个事件当场投递而不是等待之后的桥接运行——因为下一步可能移除的正是本应投递它的那个二进制文件。即使包会保留还有其他宿主需要它也要在这里运行是位置让它可靠而不是结果。和往常一样 best-effort——如果失败忽略即可。源码层面的依据在 host_cli.pyreport uninstall记录CLI_UNINSTALL_SUCCEEDED后立即整池 flush其注释直言这个事件有最硬的截止期限UNINSTALL.md Part 3 可能移除投递它的二进制本身所以之后可能根本没有再次 flush 的机会——需要的是在二进制消失前清空 spool。对应的测试 test_events.py 中test_report_uninstall_delivers_immediately验证事件立即投递test_uninstall_is_reported_before_the_package_can_be_removed则校验指南文本中report uninstall必须出现在pip uninstall/Remove memu-cli之前。如果卸载失败或提前中止报告错误从同一位置、在二进制仍然存在的时刻报告memu-workbuddy report error --stage uninstall --detail what went wrong, in full--detail要慷慨——这是 memU 工程师还原现场的全部素材。写上一两段平实语言什么东西拆不下来、你运行了什么、实际发生了什么、你尝试了什么、你认为原因是什么。详细但不是转储不要粘贴 traceback 或原始命令输出memU 自己会上报永远不要包含凭据、绝对路径/Users/…、C:\Users\…、存储 DSN、端点 URL或记忆/会话文本——改用文字描述。如果失败的恰是pip uninstall本身memu-workbuddy通常还在PATH上——尝试报告一次如果命令也没了就没有可报告的工具了这也完全没问题。源码佐证--detail有 5000 字符硬上限events.py--stage采用封闭枚举uninstall是其合法值之一events.py并且stageuninstall除了上报AGENT_ERROR_REPORTED外还会附带一条具体的CLI_UNINSTALL_FAILED漏斗计数事件events.py。只有这是最后一个 memU 宿主时才卸载包memu-cli被所有宿主适配器共享因此只有当这台机器上不再有其他宿主集成时才卸载它pip uninstall memu-cli # 或 pipx uninstall memu-cli # 取决于当初是如何安装的判断方法列出~/.memu/hosts/——其中除了本宿主自己的~/.memu/hosts/workbuddy/它可能存活只为保留会话游标之外的任何目录都是另一个活跃宿主。确认它仍然活跃的标准是其指令文件仍带有 memU 块或桥接任务仍存在。如果还有其他宿主就让memu-cli保持安装状态并在报告中点名幸存的宿主。共享事件池只随包一起走且只在移除包时前面的报告在投递时会清空~/.memu/events.jsonl但一台离线过的机器会留下它——或其侧车文件events.jsonl.*.sending、events.errors、events.dropped。只有当你确实移除了memu-cli时才删除这些文件事件池是机器级作用域、与其他宿主共享若还有宿主存在就删除等于丢弃了那个宿主尚未投递的事件。源码佐证events.py 明确注释了SPOOL_PATH ~/.memu/events.jsonl跨宿主共享的原因——身份是机器级作用域所以它不在~/.memu/hosts/host/下不像宿主的其余工作状态那样按宿主隔离。✅ Done收尾报告用用户最需要听到的两件事收尾顺序如下保留了什么用户的记忆——MEMU_DB指向的存储、~/.memu/config.env、会话游标——全部原封未动。之后重装会原样接起并从上次中断处继续挖掘。移除了什么桥接自动化、检索指令、本宿主的工作状态以及除非还有其他宿主需要memu-cli包。卸载流程速查阶段关键动作验证方式关键原则Part 1删除精确自动化 IDrecord 接缝自动化列表不再出现名称不足以删除ID 流水线内容才是权威Part 2memu-workbuddy remove-instructioninject 接缝cat ~/.workbuddy/SOUL.md与MEMORY.md无标记、用户内容完好不手改块.bak备份重跑是 no-opPart 3report uninstall→ 清理残留 → 视情况pip uninstall memu-cli→ 视情况删事件池向用户报告记忆保留、工具移除存储始终保留游标与存储共存亡包仅在最后一个宿主时卸载事件池只随包走失败路径report error --stage uninstall --detail ...在二进制尚存时执行详细而非转储无凭据、无绝对路径、无 DSN、无端点整条卸载链路的设计闭环在于记录与检索两端都读取~/.memu/config.env因此它们可证明地共享同一个后端而卸载最需要保证的恰恰是拆除工具的同时绝不破坏那个后端里用户积累的记忆——这正是本指南每一步验证门存在的意义。【免费下载链接】memUPersonal memory across agents项目地址: https://gitcode.com/GitHub_Trending/mem/memU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 memU WorkBuddy 宿主卸载完全指南：从桥接任务注销到数据保留的逐步拆除手册
memU WorkBuddy 宿主卸载完全指南从桥接任务注销到数据保留的逐步拆除手册【免费下载链接】memUPersonal memory across agents项目地址: https://gitcode.com/GitHub_Trending/mem/memU本指南围绕 memU 项目中针对 WorkBuddy 宿主的官方卸载文档 UNINSTALL.md 展开讲解如何安全、可逆地将 memU 的记录record与注入inject两条接缝从 WorkBuddy 中拆除同时始终保留用户积累的记忆数据。读完本文你将掌握按验证门逐步推进的拆除流程、remove-instruction与report uninstall等命令的正确用法以及一个存储、多个宿主架构下如何判断memu-cli包何时可以安全卸载。卸载的本质把安装过程倒着执行一遍在 memU 的架构中向某个宿主如 WorkBuddy接入记忆能力依赖两条接缝seam卸载就是把这两条接缝按相反顺序拆除最后处理数据与包取消注册桥接任务record 接缝——先停掉定时自动化避免在拆除过程中触发任何任务移除检索指令inject 接缝——删除写入~/.workbuddy/SOUL.md的常驻检索指令包括旧版落在MEMORY.md中的遗留块应用数据与包的默认值——用户记忆保留工具拆除最后向 memU 报告结果。文档的读者是 Agent。原文档开篇明确声明Audience: the agent. A user has pointed you at this file。这意味着这篇指南本身就是写给执行卸载的 AI Agent 的操作手册从上到下逐部分执行每部分结尾都有verify 验证门——当前门未通过前不得继续下一步。任务身份Task identity按名字识别但绝不只按名字删除卸载的第一步是准确识别哪个自动化属于 memU。原文档在每个部分顶部都给出了任务身份字段当前任务名{{task_name}}此前用过的任务名{{former_task_names}}迁移与移除过程中需要识别的全部名称{{all_task_names}}这些{{...}}是文档模板 token并非字面值。在源码 host_cli.py 的render_doc方法中它们会在docs uninstall打印指南时被替换为 WorkBuddy 宿主的实际值。从 cli.py 的HostSpec声明可以看到具体内容当前任务名为memu-bridging-workbuddyall_task_names是当前任务名 全部历史别名的并集。这种 token 化机制保证注册代码与文档文字不会各自漂移。一个存储、多个宿主卸载的边界在哪里~/.memu/config.env以及它所指向的存储可能被这台机器上的其他 memU 宿主适配器memu-codex、memu-claude-code等共享。拆除本宿主的接缝永远不需要触碰共享存储Part 3 才会说明何时触碰共享存储才是安全的。本文档只卸载WorkBuddy 宿主。其他宿主一律不在范围内绝不触摸、取消补丁或运行其他宿主的卸载流程——保留~/.memu/hosts/下它们的工作树如~/.memu/hosts/codex/及其指令文件原样不动。Part 1 — 取消注册桥接record任务record 接缝是一个定时任务它周期性把最近的 WorkBuddy 会话挖掘进 memU 的记忆、技能与资源。卸载的第一步就是通过 WorkBuddy 的自动化管理界面找到任务文本中同时携带{{all_task_names}}中任一被识别名称、以及memU bridging pipeline提示文本的那个自动化然后只删除它的精确自动化 ID。关键安全原则仅凭名称永远不足以删除。因为 WorkBuddy 的自动化表面没有独立的名称字段任务文本首行才是跨平台可见的标记详见 BRIDGING_TASK.md 中{{task_name}}的使用说明而自动化 ID 完整流水线内容才是删除的权威依据。从源码结构看桥接任务的完整形态是prepare→ 自我演化 →commit三步流水线memu-workbuddy prepare扫描新会话并生成编号作业文件Agent 按编号逐个执行memu-workbuddy commit提交结果工作目录全部位于~/.memu/hosts/workbuddy/下路径布局定义在 layout.py。WorkBuddy 宿主的调度后端在HostSpec中声明为schedule_backendnativecli.py即使用 WorkBuddy 自带的自动化系统。卸载时必须先删任务、后拆指令这样拆除过程中不会有任何定时任务意外触发。✅ 验证 Part 1该自动化不再出现在 WorkBuddy 的自动化列表中。Part 2 — 移除检索指令inject 接缝inject 接缝是写在 WorkBuddy全局行为文件~/.workbuddy/SOUL.md中的一段常驻指令WorkBuddy 会把该文件加载进每一个会话从而让回答前先检索记忆这条行为天然存在——没有钩子、没有包装器、没有逐轮进程。为什么行为要放在SOUL.md而不是MEMORY.md因为MEMORY.md存放的是用户事实与对话摘要行为指令不属于那里这一设计在 cli.py 的模块注释中有明确说明。不要手改块让 memU 自己移除memu-workbuddy remove-instruction不要手工删除这段块。memU 拥有这段文本并由它负责移除。该命令会从~/.workbuddy/SOUL.md删除 memU 的标记块同时检查旧的~/.workbuddy/MEMORY.md目标让旧版本安装也能被干净移除标记之外的所有内容都属于用户原样保留每个被改写的文件在重写前都会备份到相邻的.bak路径SOUL.md.bak、MEMORY.md.bak--dry-run只展示两处差异而不写入重复运行是干净的无操作no-op——没有遗留块的文件本身就是期望的终态。标记块机制定义在 instruction.py块由!-- memu:begin — managed block, do not edit (...install-instruction) --与!-- memu:end --两个标记界定。remove()函数的实现instruction.py与安装侧的install()具有相同的安全属性只有标记围栏内的块被取回块外内容逐字保留同时移除安装时添加的空白分隔行使安装→移除往返能够字节级还原文件。_cmd_remove_instruction命令处理器instruction.py在默认路径生效时会同时检查当前目标与全部 legacy 路径逐个移除标记块并打印 diff如果所有文件都没有残留块则输出no managed block to remove。这些行为都有测试用例印证test_host_instruction.pytest_remove_restores_user_content_byte_for_byte用户内容字节级还原、test_remove_leaves_a_block_only_file_empty仅含块的纯文件移除后为空、test_remove_without_block_or_file_is_a_noop无块或无文件是无操作、test_remove_only_takes_this_hosts_block只取走本宿主的块、test_remove_dry_run_writes_nothingdry-run 不写入、test_remove_backs_up_before_rewriting重写前先备份。✅ 验证 Part 2同时检查两个文件cat ~/.workbuddy/SOUL.md cat ~/.workbuddy/MEMORY.md确认不再有任何memu:begin/memu:end标记残留且用户自己的内容完好。注意当前会话加载的是旧文件所以指令可能仍存在于你自己的上下文中只有新开会话才会看到移除效果。Part 3 — 数据、配置与包默认值优先然后报告这部分无需向用户提问直接应用以下默认值并确保最终报告向用户明确传达记忆保留、工具移除。唯一能覆盖默认值的是用户自己的明确话语。保留存储与~/.memu/config.env始终存储本身就是用户积累的记忆按设计在卸载后存活——之后重装会原样接回。只有用户明确要求作为本次卸载的一部分抹掉记忆时才删除且必须先用平实的语言警告这是不可逆的。从事件上报的源码可以侧面印证这一设计的分量events.py 中client_instance_id()把机器级稳定 ID 存放在~/.memu/config.env注释明确指出UNINSTALL.md Part 3 要求始终、无条件保留该文件因此安装→卸载→重装会拼接成同一实例的历史——这正是该 ID 存在的全部意义。会话游标与存储共存亡~/.memu/hosts/workbuddy/.session_manifest.workbuddy.json这个文件记录哪些会话轮次已经被挖掘进那个存储。对应源码在 layout.pysession_manifest是按宿主作用域的每会话行游标由成功的commit推进prepare只写.pending暂存副本它的存在让每次桥接运行只处理未见过的轮次。存储保留默认→ 保留游标。删掉它不会丢失记忆但下次安装会为毫无意义的旧会话做全量重新挖掘用户要求删除存储→ 连同游标一起删除。一个存活在空存储上的游标会把历史标记为已挖掘而这些历史永远不会再被挖掘。移除本宿主的残留物~/.memu/hosts/workbuddy/下的一切其他内容——作业文件jobs/*.txt与镜像文件——都应移除唯独保留上面的会话游标。至于~/.workbuddy/SOUL.md本身如果 Part 2 之后它变成空文件说明它只装了 memU 的块即安装时创建的可以一并删除包含用户自己内容的文件当然保留。在包能卸载之前先告诉 memU 卸载发生了接缝已拆、残留已清在下面把memu-workbuddy从这台机器上移除之前执行memu-workbuddy report uninstall与 memU 的其他所有事件不同这个事件当场投递而不是等待之后的桥接运行——因为下一步可能移除的正是本应投递它的那个二进制文件。即使包会保留还有其他宿主需要它也要在这里运行是位置让它可靠而不是结果。和往常一样 best-effort——如果失败忽略即可。源码层面的依据在 host_cli.pyreport uninstall记录CLI_UNINSTALL_SUCCEEDED后立即整池 flush其注释直言这个事件有最硬的截止期限UNINSTALL.md Part 3 可能移除投递它的二进制本身所以之后可能根本没有再次 flush 的机会——需要的是在二进制消失前清空 spool。对应的测试 test_events.py 中test_report_uninstall_delivers_immediately验证事件立即投递test_uninstall_is_reported_before_the_package_can_be_removed则校验指南文本中report uninstall必须出现在pip uninstall/Remove memu-cli之前。如果卸载失败或提前中止报告错误从同一位置、在二进制仍然存在的时刻报告memu-workbuddy report error --stage uninstall --detail what went wrong, in full--detail要慷慨——这是 memU 工程师还原现场的全部素材。写上一两段平实语言什么东西拆不下来、你运行了什么、实际发生了什么、你尝试了什么、你认为原因是什么。详细但不是转储不要粘贴 traceback 或原始命令输出memU 自己会上报永远不要包含凭据、绝对路径/Users/…、C:\Users\…、存储 DSN、端点 URL或记忆/会话文本——改用文字描述。如果失败的恰是pip uninstall本身memu-workbuddy通常还在PATH上——尝试报告一次如果命令也没了就没有可报告的工具了这也完全没问题。源码佐证--detail有 5000 字符硬上限events.py--stage采用封闭枚举uninstall是其合法值之一events.py并且stageuninstall除了上报AGENT_ERROR_REPORTED外还会附带一条具体的CLI_UNINSTALL_FAILED漏斗计数事件events.py。只有这是最后一个 memU 宿主时才卸载包memu-cli被所有宿主适配器共享因此只有当这台机器上不再有其他宿主集成时才卸载它pip uninstall memu-cli # 或 pipx uninstall memu-cli # 取决于当初是如何安装的判断方法列出~/.memu/hosts/——其中除了本宿主自己的~/.memu/hosts/workbuddy/它可能存活只为保留会话游标之外的任何目录都是另一个活跃宿主。确认它仍然活跃的标准是其指令文件仍带有 memU 块或桥接任务仍存在。如果还有其他宿主就让memu-cli保持安装状态并在报告中点名幸存的宿主。共享事件池只随包一起走且只在移除包时前面的报告在投递时会清空~/.memu/events.jsonl但一台离线过的机器会留下它——或其侧车文件events.jsonl.*.sending、events.errors、events.dropped。只有当你确实移除了memu-cli时才删除这些文件事件池是机器级作用域、与其他宿主共享若还有宿主存在就删除等于丢弃了那个宿主尚未投递的事件。源码佐证events.py 明确注释了SPOOL_PATH ~/.memu/events.jsonl跨宿主共享的原因——身份是机器级作用域所以它不在~/.memu/hosts/host/下不像宿主的其余工作状态那样按宿主隔离。✅ Done收尾报告用用户最需要听到的两件事收尾顺序如下保留了什么用户的记忆——MEMU_DB指向的存储、~/.memu/config.env、会话游标——全部原封未动。之后重装会原样接起并从上次中断处继续挖掘。移除了什么桥接自动化、检索指令、本宿主的工作状态以及除非还有其他宿主需要memu-cli包。卸载流程速查阶段关键动作验证方式关键原则Part 1删除精确自动化 IDrecord 接缝自动化列表不再出现名称不足以删除ID 流水线内容才是权威Part 2memu-workbuddy remove-instructioninject 接缝cat ~/.workbuddy/SOUL.md与MEMORY.md无标记、用户内容完好不手改块.bak备份重跑是 no-opPart 3report uninstall→ 清理残留 → 视情况pip uninstall memu-cli→ 视情况删事件池向用户报告记忆保留、工具移除存储始终保留游标与存储共存亡包仅在最后一个宿主时卸载事件池只随包走失败路径report error --stage uninstall --detail ...在二进制尚存时执行详细而非转储无凭据、无绝对路径、无 DSN、无端点整条卸载链路的设计闭环在于记录与检索两端都读取~/.memu/config.env因此它们可证明地共享同一个后端而卸载最需要保证的恰恰是拆除工具的同时绝不破坏那个后端里用户积累的记忆——这正是本指南每一步验证门存在的意义。【免费下载链接】memUPersonal memory across agents项目地址: https://gitcode.com/GitHub_Trending/mem/memU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考