虚拟员工系统的工作树自动化演进之路

不知道你们有没有这种感觉——Git Worktree 用起来确实香，但时间一长，仓库里堆满了各种临时工作树，想清理又怕漏掉什么。这种"不敢删、不想删"的纠结，相信做多分支开发的人都懂。

虚拟员工系统也是这么过来的。从一开始的单点工具，到后来一套完整的自动化方案，踩了不少坑，也沉淀了一些经验。今天就聊聊我们是怎么把工作树管理这件事从"头疼"变成"省心"的。

怎么就想到要自动化了？

最早用 Worktree，是因为虚拟员工系统需要同时跑多个任务。每个 Persona 分一个独立目录，互不干扰，这招确实管用。但问题也随之而来：

分支合并后，工作树没及时删，久而久之磁盘就开始报警。远程分支一堆"孤儿"——就是那种已经合并但没人要的跟踪分支，看着膈应。手动同步也麻烦，一不小心就把主分支搞乱。

我们被逼得没办法，才开始慢慢做自动化。

一步步是怎么过来的

第一阶段：先让同步能跑通

最早的需求其实很简单——能不能一键把工作树同步到最新？不想每次手动 rebase。

于是做了 ve sync 命令，大致逻辑是：自动检测哪些工作树需要同步，用安全的 rebase 策略处理，完了给个报告。整个过程半自动，有些边界情况还是需要人工确认。

第二阶段：开始管" lifecycle"

光同步不够，清理也得跟上。这一阶段加了几个实用功能：

• Cleanup Mode：自动识别已合并的分支，提示可以删掉对应的工作树
• Audit Log：所有操作都记下来，出了问题能回溯
• 陈旧分支回收：把那些已经没用的远程跟踪分支清理掉

另外在 rebase 这块，我们也加了保护机制——先在临时分支上搞，冲突了会保留现场，不会直接硬改主分支。

第三阶段：彻底甩手

后来干脆把维护做成定时任务，放到 GitHub Actions 或自托管的 mac-mini 上跑。每天/每周自动执行，生成一份报告发到群里。基本上不用人操心了。

踩过的几个坑

1. "孤儿分支"不是孤儿：一开始我们理解的 Orphan Branches 和 Git 官方定义不太一样，后来改成"陈旧分支"（Stale Branches），更准确
2. MEMORY.md 的作用：清理前我们会先把工作树里的一些元数据存到 MEMORY.md，方便后续查证
3. 冲突处理：目前还是半自动为主，冲突保留现场人工接入，完全自动化还有风险

后续打算做什么

• 跨仓库支持（目前只在自己的 Monorepo 里跑）
• 可视化面板（命令行看久了确实累）
• AI 辅助决策（让 AI 帮忙判断哪些分支该删）

这套方案现在也在 openclaw-persona 的隔离工作区里跑着，效果还行。如果你也在被工作树管理折磨，或许可以参考参考。

---

有问题欢迎评论区聊。