那天下午我打开 OneDrive右上角的同步图标已经不再转圈了——不是同步完成而是彻底卡死。点开冲突提示一整排“WorkBuddy_session_billing_api(1)(2)(3)”的副本整齐地躺在那里算下来吞掉了 3.2GB 空间。我在删除副本和解除同步之间犹豫了两分钟最后决定做个更彻底的事给每个 Agent 会话一个真正属于自己的“家”。这里的“家”不是个比喻是一套可落地的目录工作区方案。它把 WorkBuddy 运行期间产生的会话数据、上下文快照、工具调用记录和日志全部按会话隔离存放同时通过云盘排除规则让 OneDrive 不再插手中间过程只负责归档最终结果。这套思路大概花了我两个晚上调试之后一周跑下来云盘安静了会话可追溯了连模型犯错的回溯都顺手很多。如果你是 WorkBuddy 的重度用户、Agent 开发者或者只是被“会话同步冲突副本”烦过的人这篇应该对你有用。1. 焦虑从哪来Agent 会话的存储模型天生和云盘不对付先说清一个问题为什么别的软件放云盘里没什么事WorkBuddy 这类 Agent 一放进去就出事答案在于写入模式完全不同。1.1 一次普通会话到底会产生多少文件我之前对 Agent 会话的理解是“聊天记录”以为最多就是一个 JSON 文件。真去翻了工作目录才发现一次稍微复杂点的任务大约会经历这样的过程Agent 接收用户指令后先写一份任务描述快照每次调用工具前记录工具名、入参、返回值摘要中途如果执行了脚本或写了临时文件这些内容也会落在会话目录附近模型上下文太长被截断时会生成历史摘要文件最后还有完整的 token 消耗统计和会话日志。也就是说一次跑通“修复登录接口超时”这样的小任务最少会生成 30 到 80 个小文件。单个文件通常只有几KB到几十KB但量大。一个工作日下来新增上千个文件是常态。这些文件本身不可怕可怕的是它们会被云盘客户端逐个“关注”。Windows 上的 OneDrive、macOS 上的 iCloud Drive底层都依赖文件系统事件监听。文件一变化客户端就要去比对版本、计算哈希、上传差异。Agent 会话是典型的写密集型负载频率极高、单文件极小、总数极大这正好踩在云盘同步引擎最难受的位置。1.2 云盘同步机制的“三宗罪”以我在 OneDrive 上的观测问题集中在这三件事上第一同步队列频繁拥堵。当一个目录里几百个小文件不断被创建和修改OneDrive 的队列会越排越长CPU 占用肉眼可见地上升到 20%-30%风扇开始转其他文件的同步全部被堵在后面。第二冲突副本泛滥。云盘的多端同步基于“最后写入者胜”的朴素逻辑。WorkBuddy 生成的会话文件如果被另一个设备同步下来本地 Agent 又恰好要回写双方各自持有一个版本客户端就会悄悄复制一份命名为“会话名(1)”。跑一天目录里能冒出一堆带编号的副本。这个问题的本质是两个写入源在毫秒级时间内修改同一个文件而云盘没有合并能力。第三隐私和体积的隐性风险。会话文件里往往包含完整的需求描述、代码片段、API 返回结果。把这些内容实时传到云端本身就是一种不必要的暴露。再加上历史会话只增不减云盘配额很快就会被撑满。所以答案很直接WorkBuddy 的中间产物不应该被云盘同步只有最终成果才配得上云盘的位置。2. 为什么每个会话都该有一个“家”工作区的三层价值与其给云盘写一堆排除规则不如换个思路让会话在本地拥有一个稳定、可识别、结构完整的工作目录。这个决定不只是为了解决同步问题它更像是给 Agent 的使用方式补上了一块缺失的拼图。2.1 会话即任务目录即边界最早我也是在 WorkBuddy 默认的全局会话目录里跑所有任务结果就是所有 Agent 的“记忆”混在一起。一周后想找某个需求的相关记录只能靠关键词全文搜索效率极低。后来我意识到每个会话本质上是一次任务task它有明确的起点、过程和终点。既然任务有边界那它的数据就应该有边界。给每个会话分配一个独立目录相当于给这次任务划了一个房间所有上下文、所有产物、所有中间日志都在这个房间里不会跑到别人家去。这个做法和软件工程里的“模块边界”是同一个道理。目录一旦成为边界你就可以对它做任何批量操作一键归档、一键清理、一键导出而不用害怕误伤其他任务。2.2 有了家才能谈恢复、回滚和清理当会话数据是散落状态时所谓“恢复”是不可能的。你会话里的每一步操作都分散在不同文件里缺少一个统一的入口。按照会话目录组织之后三层价值就很清晰了恢复WorkBuddy 如果中途崩了或者你切换了设备只要把那个会话目录拉回来就能从最后的状态继续跑而不是从头再来。回滚Agent 改坏了一段代码你可以对比会话目录里的中间版本凡是改过的文件都有记录定位是哪一步引入的问题非常快。清理所有会话目录都按统一模式命名清理策略可以写成脚本。超过 N 天的目录自动打包归档彻底告别手动删文件的痛苦。有人问这跟 WorkBuddy 自带的会话列表有什么区别区别在于会话列表是工具的视角目录是文件的视角。你操作的是真实存在的文件可以配合 git、rsync、压缩工具、任意脚本使用。工具可以换文件结构是自己的。3. WorkBuddy 会话工作区方案目录结构、环境变量与初始化脚本下面是我的完整落地方案。先从目录结构讲起再讲如何在 WorkBuddy 里配置最后给出初始化脚本。3.1 目录结构怎么设计我在用户目录下建了一个顶层工作区~/workbuddy_workbench内部结构如下~/workbuddy_workbench/ ├── active/ # 进行中的会话按日期和任务名命名 │ ├── 20241120_fix_auth_timeout/ │ └── 20241120_billing_api_refactor/ ├── archive/ # 已归档的会话按月份再分一层 │ └── 202411/ ├── exports/ # 可同步到云盘的最终产物 │ ├── 20241120_fix_auth_timeout_summary.md │ └── 20241120_billing_api_refactor_diff.patch ├── workspace/ # 会话共享的工作文件比如克隆下来的仓库 │ └── billing-service/ └── logs/ # 全局运行日志排除同步关键设计是三层隔离active/是“施工现场”文件变动最频繁本地存放云盘完全排除exports/是“作品展示区”只有当你确认一个会话结束时顺手把总结或补丁丢进去云盘同步这一层archive/是“储藏室”定期把active/里不再使用的目录压缩后移进来。这样设计之后云盘同步的对象是稳定且小体积的而高频次的中间文件永远不会被云端看到。3.2 WorkBuddy 侧的核心配置要让 WorkBuddy 真正“住进”这个工作区只建目录是不够的还要告诉它“工作区在哪里、会话文件往哪放”。我做的第一件事是在 WorkBuddy 配置文件里指定工作目录根路径。不同版本的 WorkBuddy 配置方式略有差异但核心就是设置用户级的工作目录指向~/workbuddy_workbench/workspace同时把默认会话存储目录指向~/workbuddy_workbench/active。第二件事是修改启动方式。我不再直接打开 WorkBuddy 后随手发指令而是给每个新任务先创建独立目录再在 WorkBuddy 里以此目录为当前工作目录开启新会话。这一步看起来多花了十秒钟收益却是值得的。3.3 初始化脚本用一条命令起一个会话纯手动建目录太啰嗦我写了一个wb-new脚本放在 PATH 里启动新会话时只需要wb-new fix_auth_timeout脚本内容大致如下#!/usr/bin/env bash # wb-new: 创建一个新的 WorkBuddy 会话工作目录 # 用法: wb-new task_name set -euo pipefail BASE_DIR$HOME/workbuddy_workbench/active TASK_NAME${1:?usage: wb-new task_name} DATE_TAG$(date %Y%m%d) SESSION_DIR${BASE_DIR}/${DATE_TAG}_${TASK_NAME//[^a-zA-Z0-9_-]/_} if [ -d $SESSION_DIR ]; then echo 会话目录已存在: $SESSION_DIR exit 1 fi mkdir -p $SESSION_DIR/{context,artifacts,tmp,logs} echo $TASK_NAME $SESSION_DIR/context/task.md echo 会话目录已创建: $SESSION_DIR脚本里有几个细节值得解释一下日期前缀%Y%m%d保证同名任务不会覆盖排序时也会按时间自然排列内部四个子目录context、artifacts、tmp、logs分别存放上下文、最终产物、临时文件、会话日志这样后续清理策略可以只针对tmp下手不用顾虑其他文件//[^a-zA-Z0-9_-]/_是 Bash 的替换语法可以自动过滤任务名里的特殊字符避免生成含空格或斜杠的非法目录名。3.4 自定义指令和 Skill 的配合WorkBuddy 支持自定义指令这正好用来固化“会话目录纪律”。我在 WorkBuddy 的自定义指令里加了一行每个任务开始前先确认会话工作目录是否存在。如果不存在请先创建目录并初始化 context/task.md再开始执行任务。这个指令本身很简单但它让 Agent 在无人监督时也会先落目录、再动手而不是把文件散落在各处。如果你用了 WorkBuddy 的 Skill 功能还可以把“目录初始化”封装成一个 Skill让 Agent 在识别到新任务时自动调用。本质上这个 Skill 就是脚本wb-new的 Agent 化版本传入任务名返回会话目录路径。目前这类 Skill 的常用做法就是写一个指令模板加一个可执行脚本门槛不高但长期收益非常明显。4. 把云盘从“同步者”变成“归档者”排除规则与容量控制的实战目录方案只是第一步。如果没有云盘排除规则前面的一切都会被同步客户端重新搅乱。这一部分讲讲我排障的过程以及最终是怎么让云盘只做归档的。4.1 同步冲突副本的完整排查链路先回顾一下我当时是怎么定位到“冲突副本是 WorkBuddy 会话文件导致的”起初我以为是云盘客户端出了问题于是先做了三件事重启 OneDrive、取消并重新关联账号、把“按需文件”关闭再打开。结果是当时安静了半小时之后冲突副本继续出现。然后我开始看 OneDrive 的同步日志发现冲突的文件路径都在 WorkBuddy 会话目录附近。再对照时间线每次我让 Agent 跑一个任务大概几十秒后就开始出现冲突副本。到这里基本可以确认问题不是云盘故障而是写入模式不兼容。触发冲突的典型场景是Agent 在任务中同时更新了会话摘要文件和当前状态文件OneDrive 还没来得及上传第一个版本就收到了第二个变更而其他设备比如另一台电脑如果有旧版本同步记录就会生成冲突副本。4.2 云盘排除规则的配置参考定位问题之后我做了两处设置第一处是把~/workbuddy_workbench/active、logs、tmp目录排除出 OneDrive 同步范围。OneDrive 的排除逻辑是文件夹级别的我目录设计时就把这些独立建在工作区的顶层配置起来一条规则就够了。配置好后我把 OneDrive 的同步状态从“所有文件”改成了“仅导出目录”也就是只允许exports/文件夹进入云端。这样 WorkBuddy 的会话数据不会实时上传只有你手动放入exports/的总结文档、补丁包才会同步云端扮演的角色也从“实时同步者”降级成了“定期归档者”。如果你用其他云盘配置方式类似只是排除规则的入口名称不同。这里是通用的原则目录对象是否同步到云端原因active/ 会话现场否高频写入同步无意义且容易冲突workspace/ 工作文件按需如果网络足够快可以同步否则建议只同步 git 仓库exports/ 最终产物是体积小、变动少、需要跨设备访问archive/ 归档可选建议本地压缩后再同步单文件大但数量少logs/ 日志否内容敏感且变动频繁4.3 容量失控的清理策略排除同步之后还剩下一个绕不开的问题会话目录只增不减磁盘空间迟早告急。我的做法是“三步清理法”已经跑了两周稳定有效第一步会话结束时手动归档。任务完成后在 WorkBuddy 里把最终总结写入exports/把 diff 或关键产物也复制过去然后在 active 目录里做一次“收尾”。第二步tmp目录实时瘦身。WorkBuddy 的中间临时文件全部都落在会话目录的tmp/子目录里。我在脚本里加上了一句find $SESSION_DIR/tmp -type f -mtime 1 -delete意思是删除一天前的临时文件。这一步能省掉一半以上的会话体积。第三步每月压缩归档。月底把active/里超过 14 天没有变动的目录打包成 tar.gz 放入archive/再从 active 里移除。一条 cron 就能定时完成不用人工介入。有人可能会担心删除 tmp 文件会影响会话恢复。实际上会话恢复依赖的是 context 里的状态文件和摘要临时文件被删顶多意味着某些中间产物无法复现但任务上下文不会丢。用文件的生命周期管理来换磁盘空间我觉得是划算的。5. 落地一周后的真实体感与三个细节补充方案跑了一周最直观的变化有三个第一OneDrive 的同步队列不再卡死。因为同步的文件从每天几千次小文件变更降到了个位数CPU 占用恢复正常通知栏也再没出现过冲突副本。第二会话追溯快了。上周四排查一个线上问题时我直接进active/20241118_xxx目录把当时的 tool call 日志和中间产物全部翻出来对比之后立刻定位到是某次参数变更导致的兼容问题。这在以前是不可想象的因为我根本不知道那些文件在哪里。第三手动清理没有任何心理负担。看到磁盘空间紧张跑一条清理 tmp 的脚本过期的临时文件全部清掉我知道它不会影响任何正在进行的任务。最后分享三个细节都是实际用过之后才体会到的。细节一会话命名规范和“上下文笔记”的直接关系。WorkBuddy 的上下文恢复质量很大程度取决于会话目录里存了什么。我建议每个会话启动时都在context/task.md里写清楚任务目标、约束条件、验收标准。这不仅是给 Agent 看的也是给你自己看的。三周后回看这个文件能立刻想起来当时这个任务在干嘛。细节二云盘同步和 Agent 的“open read”习惯不冲突。我一开始担心排除了 active 目录之后其他设备就无法读取会话记录了。后来才意识到跨设备读取会话本来就不该依赖云盘而应该依赖 Archive 或者手动导出。会话期间的中间产物本来就只有正在运行的那台机器需要访问。细节三worktree 和会话工作区的配合。如果你的 Agent 要改代码与其在同一个 git 仓库里反复切换分支不如让每个会话对应一个独立的 git worktree。这样每个会话目录自带一套完整的代码状态互不干扰。配合 WorkBuddy 使用后你会觉得“给会话一个家”这个决定把 Agent 开发中最头疼的上下文污染问题也一并解决了。如果你也被 Agent 会话和云盘同步的冲突搞到头大不妨先试试局部排除只排除 active 目录、让 exports 参与同步。不用一上来就把整个方案搬走。等你感受到“会话目录化”带来的检索和恢复优势自然会想把那套初始化脚本也布置上。工具是死的工作流是活的把文件结构理顺了Agent 才能真正成为你手里顺手的工具。
那天下午我打开 OneDrive右上角的同步图标已经不再转圈了——不是同步完成而是彻底卡死。点开冲突提示一整排“WorkBuddy_session_billing_api(1)(2)(3)”的副本整齐地躺在那里算下来吞掉了 3.2GB 空间。我在删除副本和解除同步之间犹豫了两分钟最后决定做个更彻底的事给每个 Agent 会话一个真正属于自己的“家”。这里的“家”不是个比喻是一套可落地的目录工作区方案。它把 WorkBuddy 运行期间产生的会话数据、上下文快照、工具调用记录和日志全部按会话隔离存放同时通过云盘排除规则让 OneDrive 不再插手中间过程只负责归档最终结果。这套思路大概花了我两个晚上调试之后一周跑下来云盘安静了会话可追溯了连模型犯错的回溯都顺手很多。如果你是 WorkBuddy 的重度用户、Agent 开发者或者只是被“会话同步冲突副本”烦过的人这篇应该对你有用。1. 焦虑从哪来Agent 会话的存储模型天生和云盘不对付先说清一个问题为什么别的软件放云盘里没什么事WorkBuddy 这类 Agent 一放进去就出事答案在于写入模式完全不同。1.1 一次普通会话到底会产生多少文件我之前对 Agent 会话的理解是“聊天记录”以为最多就是一个 JSON 文件。真去翻了工作目录才发现一次稍微复杂点的任务大约会经历这样的过程Agent 接收用户指令后先写一份任务描述快照每次调用工具前记录工具名、入参、返回值摘要中途如果执行了脚本或写了临时文件这些内容也会落在会话目录附近模型上下文太长被截断时会生成历史摘要文件最后还有完整的 token 消耗统计和会话日志。也就是说一次跑通“修复登录接口超时”这样的小任务最少会生成 30 到 80 个小文件。单个文件通常只有几KB到几十KB但量大。一个工作日下来新增上千个文件是常态。这些文件本身不可怕可怕的是它们会被云盘客户端逐个“关注”。Windows 上的 OneDrive、macOS 上的 iCloud Drive底层都依赖文件系统事件监听。文件一变化客户端就要去比对版本、计算哈希、上传差异。Agent 会话是典型的写密集型负载频率极高、单文件极小、总数极大这正好踩在云盘同步引擎最难受的位置。1.2 云盘同步机制的“三宗罪”以我在 OneDrive 上的观测问题集中在这三件事上第一同步队列频繁拥堵。当一个目录里几百个小文件不断被创建和修改OneDrive 的队列会越排越长CPU 占用肉眼可见地上升到 20%-30%风扇开始转其他文件的同步全部被堵在后面。第二冲突副本泛滥。云盘的多端同步基于“最后写入者胜”的朴素逻辑。WorkBuddy 生成的会话文件如果被另一个设备同步下来本地 Agent 又恰好要回写双方各自持有一个版本客户端就会悄悄复制一份命名为“会话名(1)”。跑一天目录里能冒出一堆带编号的副本。这个问题的本质是两个写入源在毫秒级时间内修改同一个文件而云盘没有合并能力。第三隐私和体积的隐性风险。会话文件里往往包含完整的需求描述、代码片段、API 返回结果。把这些内容实时传到云端本身就是一种不必要的暴露。再加上历史会话只增不减云盘配额很快就会被撑满。所以答案很直接WorkBuddy 的中间产物不应该被云盘同步只有最终成果才配得上云盘的位置。2. 为什么每个会话都该有一个“家”工作区的三层价值与其给云盘写一堆排除规则不如换个思路让会话在本地拥有一个稳定、可识别、结构完整的工作目录。这个决定不只是为了解决同步问题它更像是给 Agent 的使用方式补上了一块缺失的拼图。2.1 会话即任务目录即边界最早我也是在 WorkBuddy 默认的全局会话目录里跑所有任务结果就是所有 Agent 的“记忆”混在一起。一周后想找某个需求的相关记录只能靠关键词全文搜索效率极低。后来我意识到每个会话本质上是一次任务task它有明确的起点、过程和终点。既然任务有边界那它的数据就应该有边界。给每个会话分配一个独立目录相当于给这次任务划了一个房间所有上下文、所有产物、所有中间日志都在这个房间里不会跑到别人家去。这个做法和软件工程里的“模块边界”是同一个道理。目录一旦成为边界你就可以对它做任何批量操作一键归档、一键清理、一键导出而不用害怕误伤其他任务。2.2 有了家才能谈恢复、回滚和清理当会话数据是散落状态时所谓“恢复”是不可能的。你会话里的每一步操作都分散在不同文件里缺少一个统一的入口。按照会话目录组织之后三层价值就很清晰了恢复WorkBuddy 如果中途崩了或者你切换了设备只要把那个会话目录拉回来就能从最后的状态继续跑而不是从头再来。回滚Agent 改坏了一段代码你可以对比会话目录里的中间版本凡是改过的文件都有记录定位是哪一步引入的问题非常快。清理所有会话目录都按统一模式命名清理策略可以写成脚本。超过 N 天的目录自动打包归档彻底告别手动删文件的痛苦。有人问这跟 WorkBuddy 自带的会话列表有什么区别区别在于会话列表是工具的视角目录是文件的视角。你操作的是真实存在的文件可以配合 git、rsync、压缩工具、任意脚本使用。工具可以换文件结构是自己的。3. WorkBuddy 会话工作区方案目录结构、环境变量与初始化脚本下面是我的完整落地方案。先从目录结构讲起再讲如何在 WorkBuddy 里配置最后给出初始化脚本。3.1 目录结构怎么设计我在用户目录下建了一个顶层工作区~/workbuddy_workbench内部结构如下~/workbuddy_workbench/ ├── active/ # 进行中的会话按日期和任务名命名 │ ├── 20241120_fix_auth_timeout/ │ └── 20241120_billing_api_refactor/ ├── archive/ # 已归档的会话按月份再分一层 │ └── 202411/ ├── exports/ # 可同步到云盘的最终产物 │ ├── 20241120_fix_auth_timeout_summary.md │ └── 20241120_billing_api_refactor_diff.patch ├── workspace/ # 会话共享的工作文件比如克隆下来的仓库 │ └── billing-service/ └── logs/ # 全局运行日志排除同步关键设计是三层隔离active/是“施工现场”文件变动最频繁本地存放云盘完全排除exports/是“作品展示区”只有当你确认一个会话结束时顺手把总结或补丁丢进去云盘同步这一层archive/是“储藏室”定期把active/里不再使用的目录压缩后移进来。这样设计之后云盘同步的对象是稳定且小体积的而高频次的中间文件永远不会被云端看到。3.2 WorkBuddy 侧的核心配置要让 WorkBuddy 真正“住进”这个工作区只建目录是不够的还要告诉它“工作区在哪里、会话文件往哪放”。我做的第一件事是在 WorkBuddy 配置文件里指定工作目录根路径。不同版本的 WorkBuddy 配置方式略有差异但核心就是设置用户级的工作目录指向~/workbuddy_workbench/workspace同时把默认会话存储目录指向~/workbuddy_workbench/active。第二件事是修改启动方式。我不再直接打开 WorkBuddy 后随手发指令而是给每个新任务先创建独立目录再在 WorkBuddy 里以此目录为当前工作目录开启新会话。这一步看起来多花了十秒钟收益却是值得的。3.3 初始化脚本用一条命令起一个会话纯手动建目录太啰嗦我写了一个wb-new脚本放在 PATH 里启动新会话时只需要wb-new fix_auth_timeout脚本内容大致如下#!/usr/bin/env bash # wb-new: 创建一个新的 WorkBuddy 会话工作目录 # 用法: wb-new task_name set -euo pipefail BASE_DIR$HOME/workbuddy_workbench/active TASK_NAME${1:?usage: wb-new task_name} DATE_TAG$(date %Y%m%d) SESSION_DIR${BASE_DIR}/${DATE_TAG}_${TASK_NAME//[^a-zA-Z0-9_-]/_} if [ -d $SESSION_DIR ]; then echo 会话目录已存在: $SESSION_DIR exit 1 fi mkdir -p $SESSION_DIR/{context,artifacts,tmp,logs} echo $TASK_NAME $SESSION_DIR/context/task.md echo 会话目录已创建: $SESSION_DIR脚本里有几个细节值得解释一下日期前缀%Y%m%d保证同名任务不会覆盖排序时也会按时间自然排列内部四个子目录context、artifacts、tmp、logs分别存放上下文、最终产物、临时文件、会话日志这样后续清理策略可以只针对tmp下手不用顾虑其他文件//[^a-zA-Z0-9_-]/_是 Bash 的替换语法可以自动过滤任务名里的特殊字符避免生成含空格或斜杠的非法目录名。3.4 自定义指令和 Skill 的配合WorkBuddy 支持自定义指令这正好用来固化“会话目录纪律”。我在 WorkBuddy 的自定义指令里加了一行每个任务开始前先确认会话工作目录是否存在。如果不存在请先创建目录并初始化 context/task.md再开始执行任务。这个指令本身很简单但它让 Agent 在无人监督时也会先落目录、再动手而不是把文件散落在各处。如果你用了 WorkBuddy 的 Skill 功能还可以把“目录初始化”封装成一个 Skill让 Agent 在识别到新任务时自动调用。本质上这个 Skill 就是脚本wb-new的 Agent 化版本传入任务名返回会话目录路径。目前这类 Skill 的常用做法就是写一个指令模板加一个可执行脚本门槛不高但长期收益非常明显。4. 把云盘从“同步者”变成“归档者”排除规则与容量控制的实战目录方案只是第一步。如果没有云盘排除规则前面的一切都会被同步客户端重新搅乱。这一部分讲讲我排障的过程以及最终是怎么让云盘只做归档的。4.1 同步冲突副本的完整排查链路先回顾一下我当时是怎么定位到“冲突副本是 WorkBuddy 会话文件导致的”起初我以为是云盘客户端出了问题于是先做了三件事重启 OneDrive、取消并重新关联账号、把“按需文件”关闭再打开。结果是当时安静了半小时之后冲突副本继续出现。然后我开始看 OneDrive 的同步日志发现冲突的文件路径都在 WorkBuddy 会话目录附近。再对照时间线每次我让 Agent 跑一个任务大概几十秒后就开始出现冲突副本。到这里基本可以确认问题不是云盘故障而是写入模式不兼容。触发冲突的典型场景是Agent 在任务中同时更新了会话摘要文件和当前状态文件OneDrive 还没来得及上传第一个版本就收到了第二个变更而其他设备比如另一台电脑如果有旧版本同步记录就会生成冲突副本。4.2 云盘排除规则的配置参考定位问题之后我做了两处设置第一处是把~/workbuddy_workbench/active、logs、tmp目录排除出 OneDrive 同步范围。OneDrive 的排除逻辑是文件夹级别的我目录设计时就把这些独立建在工作区的顶层配置起来一条规则就够了。配置好后我把 OneDrive 的同步状态从“所有文件”改成了“仅导出目录”也就是只允许exports/文件夹进入云端。这样 WorkBuddy 的会话数据不会实时上传只有你手动放入exports/的总结文档、补丁包才会同步云端扮演的角色也从“实时同步者”降级成了“定期归档者”。如果你用其他云盘配置方式类似只是排除规则的入口名称不同。这里是通用的原则目录对象是否同步到云端原因active/ 会话现场否高频写入同步无意义且容易冲突workspace/ 工作文件按需如果网络足够快可以同步否则建议只同步 git 仓库exports/ 最终产物是体积小、变动少、需要跨设备访问archive/ 归档可选建议本地压缩后再同步单文件大但数量少logs/ 日志否内容敏感且变动频繁4.3 容量失控的清理策略排除同步之后还剩下一个绕不开的问题会话目录只增不减磁盘空间迟早告急。我的做法是“三步清理法”已经跑了两周稳定有效第一步会话结束时手动归档。任务完成后在 WorkBuddy 里把最终总结写入exports/把 diff 或关键产物也复制过去然后在 active 目录里做一次“收尾”。第二步tmp目录实时瘦身。WorkBuddy 的中间临时文件全部都落在会话目录的tmp/子目录里。我在脚本里加上了一句find $SESSION_DIR/tmp -type f -mtime 1 -delete意思是删除一天前的临时文件。这一步能省掉一半以上的会话体积。第三步每月压缩归档。月底把active/里超过 14 天没有变动的目录打包成 tar.gz 放入archive/再从 active 里移除。一条 cron 就能定时完成不用人工介入。有人可能会担心删除 tmp 文件会影响会话恢复。实际上会话恢复依赖的是 context 里的状态文件和摘要临时文件被删顶多意味着某些中间产物无法复现但任务上下文不会丢。用文件的生命周期管理来换磁盘空间我觉得是划算的。5. 落地一周后的真实体感与三个细节补充方案跑了一周最直观的变化有三个第一OneDrive 的同步队列不再卡死。因为同步的文件从每天几千次小文件变更降到了个位数CPU 占用恢复正常通知栏也再没出现过冲突副本。第二会话追溯快了。上周四排查一个线上问题时我直接进active/20241118_xxx目录把当时的 tool call 日志和中间产物全部翻出来对比之后立刻定位到是某次参数变更导致的兼容问题。这在以前是不可想象的因为我根本不知道那些文件在哪里。第三手动清理没有任何心理负担。看到磁盘空间紧张跑一条清理 tmp 的脚本过期的临时文件全部清掉我知道它不会影响任何正在进行的任务。最后分享三个细节都是实际用过之后才体会到的。细节一会话命名规范和“上下文笔记”的直接关系。WorkBuddy 的上下文恢复质量很大程度取决于会话目录里存了什么。我建议每个会话启动时都在context/task.md里写清楚任务目标、约束条件、验收标准。这不仅是给 Agent 看的也是给你自己看的。三周后回看这个文件能立刻想起来当时这个任务在干嘛。细节二云盘同步和 Agent 的“open read”习惯不冲突。我一开始担心排除了 active 目录之后其他设备就无法读取会话记录了。后来才意识到跨设备读取会话本来就不该依赖云盘而应该依赖 Archive 或者手动导出。会话期间的中间产物本来就只有正在运行的那台机器需要访问。细节三worktree 和会话工作区的配合。如果你的 Agent 要改代码与其在同一个 git 仓库里反复切换分支不如让每个会话对应一个独立的 git worktree。这样每个会话目录自带一套完整的代码状态互不干扰。配合 WorkBuddy 使用后你会觉得“给会话一个家”这个决定把 Agent 开发中最头疼的上下文污染问题也一并解决了。如果你也被 Agent 会话和云盘同步的冲突搞到头大不妨先试试局部排除只排除 active 目录、让 exports 参与同步。不用一上来就把整个方案搬走。等你感受到“会话目录化”带来的检索和恢复优势自然会想把那套初始化脚本也布置上。工具是死的工作流是活的把文件结构理顺了Agent 才能真正成为你手里顺手的工具。
