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工具，scheduleType=recurring。
Step 1——确定调度计划
如果用户请求中没有包含调度计划，先询问用户。默认：每小时一次（RRULE：FREQ=HOURLY;INTERVAL=1）。创建之前需要与用户确认。
Step 2——注册调度自动化
创建一个运行桥接流水线的 WorkBuddy 自动化。提示词描述三个步骤；接手该自动化的 agent 会执行它们。
WorkBuddy 文档化的自动化接口没有独立的名称字段。注册时使用以下参数：
| 参数 | 值 | 说明 |
|---|---|---|
| task | 以{{task_name}}行开头，随后逐字附加下方流水线提示词 | WorkBuddy 没有独立名称字段，这个标记让跨平台名称可见，而删除的权威依据是自动化 ID 加完整流水线内容 |
| scheduleType | recurring | 周期性调度 |
| rrule | 用户选择的规则（默认FREQ=HOURLY;INTERVAL=1） | 唯一由用户决定的变量 |
| 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 会话时才有活可干。
设计要点与故障处理（Notes）
Leftovers 先于 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）只认三类记录：type=message且role为 user/assistant 的对话轮次（内容块用input_text/output_text而非其他宿主惯用的text/tool_use）、type=function_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 uninstall，host_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），仅供参考
