尧图网站建设 
memU WorkBuddy 桥接定时任务注册指南prepare → self-evolve → commit 三阶段流水线的完整落地【免费下载链接】memUPersonal memory across agents项目地址: https://gitcode.com/GitHub_Trending/mem/memU本篇指南围绕 memU 开源仓库中的 WorkBuddy 桥接任务文档讲解如何为 WorkBuddy 注册一个周期性的桥接bridging自动化任务它会在每小时默认自动把 WorkBuddy 会话中新产生的轮次turns沉淀为 memU 的记忆文件、技能与资源提交。读完本文你将掌握该任务的三步流水线prepare → self-evolve → commit的每一步职责、完整的注册提示词模板、调度参数与故障处理约定并能结合 host_cli.py 与 pipeline.py 的源码理解其底层工作原理。任务定位把记录接缝接到 WorkBuddy 上在 memU 的多宿主multi-host架构中每个宿主适配器Codex、Claude Code、Cursor、WorkBuddy 等都暴露同一套动词——retrieve、install-instruction、prepare、commit、doctor等——因为背后的流水线是宿主无关的对应 ADR 0008/0009。区别只在数据而非代码二进制名、会话日志位置、常驻指令落盘位置见 host_cli.py 的HostSpec定义。WorkBuddy 桥接任务正是 WorkBuddy 宿主的记录record接缝一个周期性调度任务把 WorkBuddy 会话中 agent 最近做过的事转化为 memU 中的持久记忆、技能与资源提交。它的完整安装流程见 INSTALL.md可通过memu-workbuddy docs install打印而本指南描述的是其中注册调度任务这一部分——它也可以独立使用。在注册任务时需要注意一个事实边界记忆与技能在两种模式下都是持久的而在云模式cloud mode下当前服务会接受流水线提交的工作区资源但尚不持久化或检索它们。这一点在 host_cli.py 的doctor输出中也有体现resources accepted but not currently persisted by memU Cloud。核心目标注册一个周期性的 WorkBuddy 自动化其提示词就是下面三段式流水线。你现在不是在运行流水线而是在注册一个将来会运行它的调度。桥接任务做什么三步流水线整个桥接任务由三个步骤组成其中只有第 1 步和第 3 步是代码Prepare——memu-workbuddy prepare扫描 WorkBuddy 会话中新增的轮次把 memU 当前的回溯文件recall files镜像到~/.memu/hosts/workbuddy/memory与~/.memu/hosts/workbuddy/skill按内容哈希做快照并写入带编号的作业指令文件到~/.memu/hosts/workbuddy/jobs/1.txt、2.txt、…。Self-evolve——agent 按数字顺序逐个打开作业文件并执行把一个会话挖掘为用户记忆、把一个会话挖掘为技能、以及描述会话触碰过的文件。什么都不做do nothing对任何作业来说都是允许且常见的产出。Commit——memu-workbuddy commit将受跟踪目录与第 1 步的快照做 diff把 agent 实际创建或修改的内容提交回 memU。第 2 步是真正的 agent 工作阅读转录、做判断、写 markdown因此调度运行的提示词必须指示 agent 去执行它而不是通过脚本转包shell out——这正是 pipeline.py 模块注释所强调的设计prepare 的职责是留下一组自包含的指令文件commit 的职责是捡起 agent 实际留在磁盘上的东西而中间步骤是真实的人工智能判断过程。从源码看prepare返回的是本次准备的会话数0 是完全正确且常见的产出pipeline.py_cmd_prepare会打印prepared N session(s) - M job(s)其中作业数遵循2 * num_sessions 1的计算关系每个会话生成一个记忆作业 一个技能作业外加一个资源描述作业无新会话则没有资源作业见 host_cli.py 与 pipeline.py。任务身份Task identity注册类文档都带有任务身份元数据由memu-workbuddy docs task在打印时通过受控的{{token}}词汇渲染host_cli.py 的render_doc当前任务名{{task_name}}——对 WorkBuddy 宿主而言实际是memu-bridging-workbuddy见 cli.py 的SPEC声明曾用任务名{{former_task_names}}迁移与移除时需识别的全部名称{{all_task_names}}即当前名 所有历史别名host_cli.py。前置条件Prerequisites在注册之前必须满足两条memU 已安装且memu-workbuddy在PATH上。用memu-workbuddy doctor验证如果失败先按 INSTALL.md 的 Part 1 完成安装。注意调度任务运行于裸的、非交互的环境不继承你的交互式 shell 配置因此该命令必须能在那里解析INSTALL.md。WorkBuddy 的自动化系统可用。调度运行使用 WorkBuddy 内置的automation_update工具scheduleTyperecurring。Step 1——确定调度计划如果用户请求中没有包含调度计划先询问用户。默认每小时一次RRULEFREQHOURLY;INTERVAL1。创建之前需要与用户确认。Step 2——注册调度自动化创建一个运行桥接流水线的 WorkBuddy 自动化。提示词描述三个步骤接手该自动化的 agent 会执行它们。WorkBuddy 文档化的自动化接口没有独立的名称字段。注册时使用以下参数参数值说明task以{{task_name}}行开头随后逐字附加下方流水线提示词WorkBuddy 没有独立名称字段这个标记让跨平台名称可见而删除的权威依据是自动化 ID 加完整流水线内容scheduleTyperecurring周期性调度rrule用户选择的规则默认FREQHOURLY;INTERVAL1唯一由用户决定的变量cwd用户的主目录或主要工作目录调度任务的运行目录流水线提示词完整原文Run the memU bridging pipeline. Do the four steps strictly in order; do not skip a step even if the previous one looks like it produced nothing. 1. LEFTOVERS. If ~/.memu/hosts/workbuddy/jobs/ already contains job files, they are unfinished work from an earlier run (a crash, or the install itself). Process them exactly as step 3 describes, then run memu-workbuddy commit — and only then continue. 2. PREPARE. Run this exact command with bash: memu-workbuddy prepare — it regenerates ~/.memu/hosts/workbuddy/jobs/. If the command exits non-zero, stop and report the error. 3. SELF-EVOLVE. List ~/.memu/hosts/workbuddy/jobs/*.txt and process them in ascending numeric order (1.txt, then 2.txt, …). The count changes every run — always glob and sort. If there are no job files, skip to step 4. For each job file: read it and follow its instructions to the letter. Each job is self-contained and already carries the concrete paths it needs. Emitting no files for a job is a valid outcome; do not invent content. 4. COMMIT. Run this exact command with bash: memu-workbuddy commit — it commits whatever the jobs created or changed. If it exits non-zero, report the error. ON FAILURE. If step 2 or step 4 exited non-zero, run this once before you stop: memu-workbuddy report error --stage remember --detail a full account of what went wrong — that detail is all a memU engineer gets to work out what is broken on this machine, so be generous: which step, what you ran, what happened instead, what you already tried, and what you think the cause is. Write it as prose for a human, not as a transcript — do not paste the traceback or raw command output, which the CLI already reports on its own, and keep credentials, absolute paths, and memory or transcript text out of it. Ignore any failure of that command; it is never part of the run. Finish with a one-line summary: how many jobs ran (leftovers included) and what was committed.提示词块是固定的只有 RRULE 是用户的选择。其中没有任何机器相关的部分——流水线完全通过PATH命令调用在 INSTALL.md 中同样强调如果你发现自己往里面替换绝对路径那你做错了。Step 3——确认向用户回报两件事自动化已创建给出其 id以及用自然语言描述调度计划例如每小时。同时说明首次运行只有在自上次运行以来出现了新的 WorkBuddy 会话时才有活可干。设计要点与故障处理NotesLeftovers 先于 prepare 运行有界重做而非静默丢失运行开始时已存在于磁盘上的作业文件属于未完成的工作——可能是中途崩溃的运行也可能是安装过程自身的验证留下的。prepare会删除未处理的作业文件而游标已经把这些会话标记为已见所以那一刻被跳过的内容永远不会再被挖掘先排空 leftovers 可以把半截循环变成有界重做而不是静默丢失。在源码层面这与 commit 的先持久化后推进原则完全一致pipeline.py 的模块注释标注了 issue #518游标由prepare暂存.pending只在 commit 成功之后才通过os.replace提升为正式游标快照也只在成功提交后重拍。因此一次运行在任何更早的点崩溃都会让之前的游标与快照保持生效所有未完成的内容下次会重新提供——有界重做绝不静默丢失。幂等与增量基于行的会话游标prepare在~/.memu/hosts/workbuddy/.session_manifest.workbuddy.json中跟踪每个会话的行级游标因此每次运行只处理它没见过的轮次。从 layout.py 看游标文件是按宿主隔离的.session_manifest.{host}.json——两个宿主的会话键互不相关共享一个游标文件会让一个宿主隐藏另一个宿主的新轮次。prepare知道它看见了什么只有commit知道什么存活进了存储两个时刻不同所以用了两个文件。顺序是承重的ordering is load-bearing记忆作业在技能作业之前编号资源描述作业排在最后。始终按数字升序处理。每个作业都是自包含的已经携带了它需要的具体路径见 instructions.py 的模板设计读输入 → 读现状 → 决定 → 写入agent 无需做任何路径推理。工作树是宿主作用域的~/.memu/hosts/workbuddy/下的所有内容都是本适配器运行作用域的工作状态其他 memU 宿主适配器Codex、Claude Code、…各自有独立的工作树永远不会与本宿主的运行竞争host_cli.py 明确说明这是 ADR 0009 遗留问题、ADR 0010 解决的——两个宿主的桥接运行绝不会在同一个jobs/目录上竞争。它们共享的持久化后端由~/.memu/config.env中的MEMU_MEMORY_MODE选择本地模式使用其中的MEMU_DB。这正是记录与注入都读同一个~/.memu/config.env因此它们可证明共享同一个后端的机制INSTALL.md。失败处理第 1 步prepare和第 3 步commit是仅有的两个应该中止运行的失败点。第 2 步中单个什么都不做的作业是正常现象不是错误。从 host_cli.py 的_cmd_commit可以看出更多细节commit 会记录成功/失败事件与计数recall 文件数、资源数、会话数、延迟毫秒数成功后才清理运行标记run marker与临时工作文件——作业文件、会话切片、触碰日志的清理严格放在存储接受提交、游标与快照推进之后这样任何更早的崩溃都会保留jobs/与sessions/完整让下一次运行的 LEFTOVERS 步骤能够恢复它们。报告命令memu-workbuddy report error --stage … --detail …的--detail是 memU 工程师排查本机故障的全部依据所以必须写得慷慨且像给人读的散文——不要粘贴 traceback 或原始命令输出CLI 自己会报告异常类型与栈帧也不要包含凭证、绝对路径或记忆/转录文本。源码层面的深度补充作业文件的生成自包含的指令每个会话的转录切片存放在~/.memu/hosts/workbuddy/sessions/prepare_instruction_jobs依据记忆模板与技能模板为每个会话生成编号作业资源作业则由prepare_resource_job在2 * num_sessions 1的位置生成pipeline.py。模板会先从服务器拉取最新版依次回退到 last-good 缓存与 SDK 内置副本templates.resolve因此一次完全断网会静默降级为随包发布的文本。单次运行默认最多处理10 个会话MAX_JOBS 10可用--max-jobs覆盖host_cli.py。快照与 diff内容哈希而非 mtime快照文件.memory_manifest.json记录的是受跟踪文件memory/与skill/两个目录见 layout.py 的TRACK_DIRS的SHA-256 内容哈希manifest.py。commit 重新哈希并对照快照 diff从而得知 agent 实际创建或修改了哪些文件——哈希内容而不是 mtime也不是 agent 对自己做了什么的自述意味着字节完全相同的重写会被正确视为未变化manifest.py。删除不会被 diff 返回——清单里有但磁盘上已消失的文件会被静默丢弃直到提交 API 增长出删除路径。会话发现WorkBuddy 特有的转录格式WorkBuddy 的会话日志位于~/.workbuddy/projects/escaped-cwd/*.jsonl每个项目一个目录绝对路径中的/与\展平为-每个会话一个 JSONL 文件以会话 UUID 命名旁边的sessions.json索引不是 JSONL会被自然跳过sessions.py。分类逻辑sessions.py只认三类记录typemessage且role为 user/assistant 的对话轮次内容块用input_text/output_text而非其他宿主惯用的text/tool_use、typefunction_call/function_call_result的独立工具记录、以及其余噪声reasoning追踪、file-history-snapshot元数据、ai-title自动标题——挖掘作业永远不该看到这些。时间戳以 epoch 毫秒记录sessions.py。与完整安装/卸载的关系本任务是 INSTALL.md 三步安装安装 memU → 注册桥接任务 → 修补~/.workbuddy/SOUL.md检索指令中 Part 2 的记录接缝。移除时按 UNINSTALL.md 执行反向三步先注销调度自动化只用自动化 ID 删除名称永远不足以删除再memu-workbuddy remove-instruction移除检索指令最后按默认值处理数据与包记忆保留、工具移除。两个生命周期指南与本文档一样都由memu-workbuddy docs命令从包内打印docs install/docs task/docs uninstallhost_cli.py 的DOCS映射。结语WorkBuddy 桥接任务把 memU 的记录接缝变成了一个可调度、可恢复、宿主隔离的自动化prepare以增量游标切分会话并生成自包含作业agent 按序执行 self-evolve允许什么都不做commit以内容哈希 diff 并只在持久化成功后才推进状态。注册时只需固定提示词 用户选择的 RRULE配合memu-workbuddy doctor、prepare、commit、report系列命令即可让 WorkBuddy 会话中的经验稳定地沉淀为跨宿主可检索的持久记忆。【免费下载链接】memUPersonal memory across agents项目地址: https://gitcode.com/GitHub_Trending/mem/memU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 memU WorkBuddy 桥接定时任务注册指南：prepare → self-evolve → commit 三阶段流水线的完整落地
memU WorkBuddy 桥接定时任务注册指南prepare → self-evolve → commit 三阶段流水线的完整落地【免费下载链接】memUPersonal memory across agents项目地址: https://gitcode.com/GitHub_Trending/mem/memU本篇指南围绕 memU 开源仓库中的 WorkBuddy 桥接任务文档讲解如何为 WorkBuddy 注册一个周期性的桥接bridging自动化任务它会在每小时默认自动把 WorkBuddy 会话中新产生的轮次turns沉淀为 memU 的记忆文件、技能与资源提交。读完本文你将掌握该任务的三步流水线prepare → self-evolve → commit的每一步职责、完整的注册提示词模板、调度参数与故障处理约定并能结合 host_cli.py 与 pipeline.py 的源码理解其底层工作原理。任务定位把记录接缝接到 WorkBuddy 上在 memU 的多宿主multi-host架构中每个宿主适配器Codex、Claude Code、Cursor、WorkBuddy 等都暴露同一套动词——retrieve、install-instruction、prepare、commit、doctor等——因为背后的流水线是宿主无关的对应 ADR 0008/0009。区别只在数据而非代码二进制名、会话日志位置、常驻指令落盘位置见 host_cli.py 的HostSpec定义。WorkBuddy 桥接任务正是 WorkBuddy 宿主的记录record接缝一个周期性调度任务把 WorkBuddy 会话中 agent 最近做过的事转化为 memU 中的持久记忆、技能与资源提交。它的完整安装流程见 INSTALL.md可通过memu-workbuddy docs install打印而本指南描述的是其中注册调度任务这一部分——它也可以独立使用。在注册任务时需要注意一个事实边界记忆与技能在两种模式下都是持久的而在云模式cloud mode下当前服务会接受流水线提交的工作区资源但尚不持久化或检索它们。这一点在 host_cli.py 的doctor输出中也有体现resources accepted but not currently persisted by memU Cloud。核心目标注册一个周期性的 WorkBuddy 自动化其提示词就是下面三段式流水线。你现在不是在运行流水线而是在注册一个将来会运行它的调度。桥接任务做什么三步流水线整个桥接任务由三个步骤组成其中只有第 1 步和第 3 步是代码Prepare——memu-workbuddy prepare扫描 WorkBuddy 会话中新增的轮次把 memU 当前的回溯文件recall files镜像到~/.memu/hosts/workbuddy/memory与~/.memu/hosts/workbuddy/skill按内容哈希做快照并写入带编号的作业指令文件到~/.memu/hosts/workbuddy/jobs/1.txt、2.txt、…。Self-evolve——agent 按数字顺序逐个打开作业文件并执行把一个会话挖掘为用户记忆、把一个会话挖掘为技能、以及描述会话触碰过的文件。什么都不做do nothing对任何作业来说都是允许且常见的产出。Commit——memu-workbuddy commit将受跟踪目录与第 1 步的快照做 diff把 agent 实际创建或修改的内容提交回 memU。第 2 步是真正的 agent 工作阅读转录、做判断、写 markdown因此调度运行的提示词必须指示 agent 去执行它而不是通过脚本转包shell out——这正是 pipeline.py 模块注释所强调的设计prepare 的职责是留下一组自包含的指令文件commit 的职责是捡起 agent 实际留在磁盘上的东西而中间步骤是真实的人工智能判断过程。从源码看prepare返回的是本次准备的会话数0 是完全正确且常见的产出pipeline.py_cmd_prepare会打印prepared N session(s) - M job(s)其中作业数遵循2 * num_sessions 1的计算关系每个会话生成一个记忆作业 一个技能作业外加一个资源描述作业无新会话则没有资源作业见 host_cli.py 与 pipeline.py。任务身份Task identity注册类文档都带有任务身份元数据由memu-workbuddy docs task在打印时通过受控的{{token}}词汇渲染host_cli.py 的render_doc当前任务名{{task_name}}——对 WorkBuddy 宿主而言实际是memu-bridging-workbuddy见 cli.py 的SPEC声明曾用任务名{{former_task_names}}迁移与移除时需识别的全部名称{{all_task_names}}即当前名 所有历史别名host_cli.py。前置条件Prerequisites在注册之前必须满足两条memU 已安装且memu-workbuddy在PATH上。用memu-workbuddy doctor验证如果失败先按 INSTALL.md 的 Part 1 完成安装。注意调度任务运行于裸的、非交互的环境不继承你的交互式 shell 配置因此该命令必须能在那里解析INSTALL.md。WorkBuddy 的自动化系统可用。调度运行使用 WorkBuddy 内置的automation_update工具scheduleTyperecurring。Step 1——确定调度计划如果用户请求中没有包含调度计划先询问用户。默认每小时一次RRULEFREQHOURLY;INTERVAL1。创建之前需要与用户确认。Step 2——注册调度自动化创建一个运行桥接流水线的 WorkBuddy 自动化。提示词描述三个步骤接手该自动化的 agent 会执行它们。WorkBuddy 文档化的自动化接口没有独立的名称字段。注册时使用以下参数参数值说明task以{{task_name}}行开头随后逐字附加下方流水线提示词WorkBuddy 没有独立名称字段这个标记让跨平台名称可见而删除的权威依据是自动化 ID 加完整流水线内容scheduleTyperecurring周期性调度rrule用户选择的规则默认FREQHOURLY;INTERVAL1唯一由用户决定的变量cwd用户的主目录或主要工作目录调度任务的运行目录流水线提示词完整原文Run the memU bridging pipeline. Do the four steps strictly in order; do not skip a step even if the previous one looks like it produced nothing. 1. LEFTOVERS. If ~/.memu/hosts/workbuddy/jobs/ already contains job files, they are unfinished work from an earlier run (a crash, or the install itself). Process them exactly as step 3 describes, then run memu-workbuddy commit — and only then continue. 2. PREPARE. Run this exact command with bash: memu-workbuddy prepare — it regenerates ~/.memu/hosts/workbuddy/jobs/. If the command exits non-zero, stop and report the error. 3. SELF-EVOLVE. List ~/.memu/hosts/workbuddy/jobs/*.txt and process them in ascending numeric order (1.txt, then 2.txt, …). The count changes every run — always glob and sort. If there are no job files, skip to step 4. For each job file: read it and follow its instructions to the letter. Each job is self-contained and already carries the concrete paths it needs. Emitting no files for a job is a valid outcome; do not invent content. 4. COMMIT. Run this exact command with bash: memu-workbuddy commit — it commits whatever the jobs created or changed. If it exits non-zero, report the error. ON FAILURE. If step 2 or step 4 exited non-zero, run this once before you stop: memu-workbuddy report error --stage remember --detail a full account of what went wrong — that detail is all a memU engineer gets to work out what is broken on this machine, so be generous: which step, what you ran, what happened instead, what you already tried, and what you think the cause is. Write it as prose for a human, not as a transcript — do not paste the traceback or raw command output, which the CLI already reports on its own, and keep credentials, absolute paths, and memory or transcript text out of it. Ignore any failure of that command; it is never part of the run. Finish with a one-line summary: how many jobs ran (leftovers included) and what was committed.提示词块是固定的只有 RRULE 是用户的选择。其中没有任何机器相关的部分——流水线完全通过PATH命令调用在 INSTALL.md 中同样强调如果你发现自己往里面替换绝对路径那你做错了。Step 3——确认向用户回报两件事自动化已创建给出其 id以及用自然语言描述调度计划例如每小时。同时说明首次运行只有在自上次运行以来出现了新的 WorkBuddy 会话时才有活可干。设计要点与故障处理NotesLeftovers 先于 prepare 运行有界重做而非静默丢失运行开始时已存在于磁盘上的作业文件属于未完成的工作——可能是中途崩溃的运行也可能是安装过程自身的验证留下的。prepare会删除未处理的作业文件而游标已经把这些会话标记为已见所以那一刻被跳过的内容永远不会再被挖掘先排空 leftovers 可以把半截循环变成有界重做而不是静默丢失。在源码层面这与 commit 的先持久化后推进原则完全一致pipeline.py 的模块注释标注了 issue #518游标由prepare暂存.pending只在 commit 成功之后才通过os.replace提升为正式游标快照也只在成功提交后重拍。因此一次运行在任何更早的点崩溃都会让之前的游标与快照保持生效所有未完成的内容下次会重新提供——有界重做绝不静默丢失。幂等与增量基于行的会话游标prepare在~/.memu/hosts/workbuddy/.session_manifest.workbuddy.json中跟踪每个会话的行级游标因此每次运行只处理它没见过的轮次。从 layout.py 看游标文件是按宿主隔离的.session_manifest.{host}.json——两个宿主的会话键互不相关共享一个游标文件会让一个宿主隐藏另一个宿主的新轮次。prepare知道它看见了什么只有commit知道什么存活进了存储两个时刻不同所以用了两个文件。顺序是承重的ordering is load-bearing记忆作业在技能作业之前编号资源描述作业排在最后。始终按数字升序处理。每个作业都是自包含的已经携带了它需要的具体路径见 instructions.py 的模板设计读输入 → 读现状 → 决定 → 写入agent 无需做任何路径推理。工作树是宿主作用域的~/.memu/hosts/workbuddy/下的所有内容都是本适配器运行作用域的工作状态其他 memU 宿主适配器Codex、Claude Code、…各自有独立的工作树永远不会与本宿主的运行竞争host_cli.py 明确说明这是 ADR 0009 遗留问题、ADR 0010 解决的——两个宿主的桥接运行绝不会在同一个jobs/目录上竞争。它们共享的持久化后端由~/.memu/config.env中的MEMU_MEMORY_MODE选择本地模式使用其中的MEMU_DB。这正是记录与注入都读同一个~/.memu/config.env因此它们可证明共享同一个后端的机制INSTALL.md。失败处理第 1 步prepare和第 3 步commit是仅有的两个应该中止运行的失败点。第 2 步中单个什么都不做的作业是正常现象不是错误。从 host_cli.py 的_cmd_commit可以看出更多细节commit 会记录成功/失败事件与计数recall 文件数、资源数、会话数、延迟毫秒数成功后才清理运行标记run marker与临时工作文件——作业文件、会话切片、触碰日志的清理严格放在存储接受提交、游标与快照推进之后这样任何更早的崩溃都会保留jobs/与sessions/完整让下一次运行的 LEFTOVERS 步骤能够恢复它们。报告命令memu-workbuddy report error --stage … --detail …的--detail是 memU 工程师排查本机故障的全部依据所以必须写得慷慨且像给人读的散文——不要粘贴 traceback 或原始命令输出CLI 自己会报告异常类型与栈帧也不要包含凭证、绝对路径或记忆/转录文本。源码层面的深度补充作业文件的生成自包含的指令每个会话的转录切片存放在~/.memu/hosts/workbuddy/sessions/prepare_instruction_jobs依据记忆模板与技能模板为每个会话生成编号作业资源作业则由prepare_resource_job在2 * num_sessions 1的位置生成pipeline.py。模板会先从服务器拉取最新版依次回退到 last-good 缓存与 SDK 内置副本templates.resolve因此一次完全断网会静默降级为随包发布的文本。单次运行默认最多处理10 个会话MAX_JOBS 10可用--max-jobs覆盖host_cli.py。快照与 diff内容哈希而非 mtime快照文件.memory_manifest.json记录的是受跟踪文件memory/与skill/两个目录见 layout.py 的TRACK_DIRS的SHA-256 内容哈希manifest.py。commit 重新哈希并对照快照 diff从而得知 agent 实际创建或修改了哪些文件——哈希内容而不是 mtime也不是 agent 对自己做了什么的自述意味着字节完全相同的重写会被正确视为未变化manifest.py。删除不会被 diff 返回——清单里有但磁盘上已消失的文件会被静默丢弃直到提交 API 增长出删除路径。会话发现WorkBuddy 特有的转录格式WorkBuddy 的会话日志位于~/.workbuddy/projects/escaped-cwd/*.jsonl每个项目一个目录绝对路径中的/与\展平为-每个会话一个 JSONL 文件以会话 UUID 命名旁边的sessions.json索引不是 JSONL会被自然跳过sessions.py。分类逻辑sessions.py只认三类记录typemessage且role为 user/assistant 的对话轮次内容块用input_text/output_text而非其他宿主惯用的text/tool_use、typefunction_call/function_call_result的独立工具记录、以及其余噪声reasoning追踪、file-history-snapshot元数据、ai-title自动标题——挖掘作业永远不该看到这些。时间戳以 epoch 毫秒记录sessions.py。与完整安装/卸载的关系本任务是 INSTALL.md 三步安装安装 memU → 注册桥接任务 → 修补~/.workbuddy/SOUL.md检索指令中 Part 2 的记录接缝。移除时按 UNINSTALL.md 执行反向三步先注销调度自动化只用自动化 ID 删除名称永远不足以删除再memu-workbuddy remove-instruction移除检索指令最后按默认值处理数据与包记忆保留、工具移除。两个生命周期指南与本文档一样都由memu-workbuddy docs命令从包内打印docs install/docs task/docs uninstallhost_cli.py 的DOCS映射。结语WorkBuddy 桥接任务把 memU 的记录接缝变成了一个可调度、可恢复、宿主隔离的自动化prepare以增量游标切分会话并生成自包含作业agent 按序执行 self-evolve允许什么都不做commit以内容哈希 diff 并只在持久化成功后才推进状态。注册时只需固定提示词 用户选择的 RRULE配合memu-workbuddy doctor、prepare、commit、report系列命令即可让 WorkBuddy 会话中的经验稳定地沉淀为跨宿主可检索的持久记忆。【免费下载链接】memUPersonal memory across agents项目地址: https://gitcode.com/GitHub_Trending/mem/memU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考