最近整理 WorkBuddy 工作目录的时候我突然被一种“云盘焦虑”击中了。WorkBuddy 是我写 Agent、调 Agent、跑日常自动化任务的主用工具每次开启一个会话就会自然产生一堆东西对话记录、临时脚本、Skill 输出、调试日志、最终跑通的流程文件。这些东西默认散落在系统临时目录、我的个人文件夹、各个项目目录里时间一长连我自己都找不到哪个 Agent 在哪儿干了什么。再叠加云盘同步的“助攻”本地一份、云端一份、手机临时一份版本冲突和重复文件能让人瞬间血压升高。更烦躁的是WorkBuddy 会话一旦关掉那个上下文就像人间蒸发一样想回溯只能靠记忆等于前面几小时的思考全部白费。所以我做了一个决定给每个 Agent 会话一个“家”。不是简单建个文件夹散养而是把每一个会话当成一个有结构、有状态、可回溯、能归档的独立项目来管理。这篇文章就把我整套方案讲透为什么会有这种焦虑、目录结构怎么设计、怎么让 WorkBuddy 照着这套规矩干活、云盘在其中到底该扮演什么角色以及我踩过的所有坑。如果你也是 WorkBuddy 的用户或者你在用别的 AI Agent 工具并且已经快被散落的会话搞崩溃了这篇内容应该能帮你省下不少时间。1. 先从焦虑说起WorkBuddy 会话和云盘叠加为什么这么乱1.1 会话数据到底散在哪里我先复盘了一下自己一天的工作流。早上开一个会话写爬虫中午开第二个会话调 Prompt下午又开第三个会话整理数据。你以为每个会话是独立干净的实际上 WorkBuddy 的默认行为并不会主动把会话产物归拢到某个固定位置很多文件会落在我当前所在目录、临时目录、甚至 Agent 内部的工作目录里。一旦会话结束这些文件就成了“无主之物”。具体来说最常散落的东西有这么几类对话上下文相关会话摘要、历史消息、自定义指令模板这些一般由 WorkBuddy 自己保存但保存位置比较隐蔽混在配置文件里。Agent 执行的产物跑 Python 脚本生成的 CSV、JSON、临时数据库文件通常会掉在执行目录或其下变里面。Skill 输出我给 WorkBuddy 配过不少自定义 Skill有些 Skill 会写文件但不同 Skill 的输出路径不统一有的甚至是相对路径。调试日志与报错信息这类最容易被忽略。Agent 进程崩溃、agent execution terminated due to error这类提示出现时日志往往散在 logs 目录或系统临时目录会话一关就谁都找不着。消息多、文件杂、路径乱这才是焦虑的第一层想复盘的时候根本不知道该去哪个角落找自己当时的思路。1.2 云盘给这份混乱补了最后一刀本地乱也就乱了我后来还想用云盘“救”一下结果差点把问题升级成事故。最开始我想得很简单把 WorkBuddy 的工作目录直接放到云盘同步文件夹里这样我在公司电脑上的会话回家也能无缝继续。听起来很美实际上问题一个接一个。首先是同步冲突。同一个会话目录下我在公司改了plan.md在家里改了context.md两边几乎同时同步到云端很多云盘会生成一堆“冲突副本”文件名后面带各种时间和计算后缀。一觉醒来目录里多了十来个不明文件比原来更乱。其次是第三方客户端的限制。我试过用某些网盘的桌面挂载盘充当工作目录比如直接把整个家目录放在挂载盘上结果 WorkBuddy 每次启动要读写大量配置和小文件云盘的实时同步延迟完全跟不上导致 Agent 在执行中途读到了过期文件。还有自动升级弹窗比如百度网盘客户端那个自动升级正跑着任务呢它弹出来要重启软件直接把进程带崩。我当时还纠结过 MEGA 在国内访问的稳定性、123 云盘会员权益之类的问题最后发现核心矛盾不在“用哪家云盘”而在“云盘根本不适合当实时工作目录”。还有一个隐患是安装器捆绑。市面上很多软件的安装包会默认勾选附带云盘组件装完系统里莫名其妙多出一个云盘客户端很多人会疑惑“为什么下载谷歌浏览器会出现谷歌的云盘”其实多半就是安装器强行装了个配套组件。这类客户端如果开机自启还会抢占网络资源影响会话连接的稳定性。所以结论很清晰本地目录才行云盘只能做归档和备份。这个认知是整个方案的基础。2. 停下来设计给每个 Agent 会话一个真正能落脚的“家”2.1 核心理念会话即目录经历了那段混乱期我彻底明白了一件事把“会话”当成一个抽象概念去管理是永远管不好的。必须把会话“物化”成一个文件系统里的目录让每个会话都有一个确定的地址。我给这套方法起了个名字就叫“会话即目录”。简单说每次开启一个新的 WorkBuddy 会话时我先在统一的工作台目录下创建一个新文件夹这个文件夹就是本次会话的“家”。所有对话记录、生成的脚本、Skill 输出、日志、参考资料全部放在这个文件夹里不越出半步。会话之间井水不犯河水想复盘就打开对应目录想归档就打包这个目录想迁移就把目录整个搬走。这个思路并不是我拍脑袋想出来的。Agent 框架领域经常会提到 Harness 和 Agent 的区别Harness 是调度外壳Agent 是执行内核但不管哪个框架最终执行产物都应该是可落盘、可追踪的。把会话固化成目录正是让结果可见的第一步也符合“一切皆文件”的老 Unix 哲学。2.2 目录结构设计与命名规范有了理念下一步就是设计具体结构。我的 Agent 工作台根目录叫agent-home放在本地磁盘的固定位置里面按功能划分子目录agent-home/ 01_projects/ # 进行中的会话项目 02_skills/ # 自定义 Skill 的源码与配置 03_templates/ # 会话模板、目录模板 04_archive/ # 已结束会话的归档 05_assets/ # 全局共享的素材、词典、公共数据 06_notes/ # 跨会话的心得笔记 _tmp/ # 临时文件随时可清空每个会话项目内部我固定放这几个文件session.json会话元数据包括会话ID、开始时间、目标、使用的 Agent/模型/Tool、关联 Skill。context.md会话上下文记录用户需求、约束条件、关键决策相当于把 WorkBuddy 的上下文外置了一份。plan.md执行计划Agent 每一轮任务前先更新这个文件。logs/日志目录Agent 的执行日志统一写到这里。artifacts/产物目录所有生成的脚本、数据文件、图片、打包文件放这里。目录名命名规范也很关键。我统一用日期_动词_对象_关键词的格式。比如2025-06-15_build_web-crawler_blog 2025-06-16_analyze_sales-data_q2 2025-06-18_fix_workbuddy-skill_json-escape日期放在最前面排序的时候自动按时间排列一眼就知道哪个是最新的。动词和对象能说明我干了什么即使过了两周翻回来不用打开文件也知道这个会话的主题。2.3 为什么选择单根多级而不是按项目平行收纳在设计的时候我也犹豫过要不要按大项目来分比如一个客户项目一个目录所有该项目的 Agent 会话都塞进去。后来试了一段时间放弃了。原因很简单一个大的业务项目通常会持续几个月几十个会话混在同一棵大树下新会话和旧会话边界模糊归档的时候很难判断哪些该留、哪些该清。单根多级的好处在于根目录是唯一的我可以把整个agent-home作为备份单元、同步单元、检索边界。想备份就把整个目录打包想迁移就整体复制想找东西就全局搜索一次。而且每个会话目录是平铺的用文件管理器或者命令行的排序就能直接看到所有会话不用一层层点进去猜。当然单根多级的代价是根目录下文件会越来越多。所以我强制要求会话结束后必须走归档流程把不活跃的会话打包压缩挪到04_archive。这样01_projects始终保持“正在进行”的干净状态不会变成垃圾场。3. 实操记录从初始化到日常使用一步步落地3.1 初始化工作台目录结构这套方案要落地第一步就是把骨架搭出来。我用一条命令完成了根目录初始化mkdir -p ~/agent-home/{01_projects,02_skills,03_templates,04_archive,05_assets,06_notes,_tmp}然后在agent-home下放一个README.md写清楚这个目录是干什么的、命名规范是什么、归档周期是多久。这个 README 不是为了给别人看而是防止我自己几个月后忘了规矩。接着我创建了一套会话模板放在03_templates/session_starter/下包含session.json和context.md的空白模板。以后每次新会话直接把模板复制一份改名字就行。cd ~/agent-home/01_projects cp -r ../03_templates/session_starter/ 2025-06-18_build_portfolio-page_work这里有个小细节session.json里留有一个id字段我会用日期加随机短码生成唯一 ID。这样做是为了避免以后在云盘归档时两个不同会话因为目录名太相似而混淆。3.2 让 WorkBuddy 记住这个“家”目录搭好只是第一步还得让 WorkBuddy 配合执行。WorkBuddy 支持自定义指令和自定义 Skill我把整套工作流固化成了两类配置。第一类是一个全局自定义指令叫home。每次新会话开始我只要对 WorkBuddy 说一声“home”它就会自动完成以下操作读取当前日期的会话目录模板创建新的会话文件夹在context.md中写入本次会话的目标来自对话开头明确约定所有生成文件一律输出到该目录的artifacts/下日志写入logs/不允许写系统临时目录。第二类是一套 Skill用来做会话结束清理。我给它起名为session_end执行逻辑是把 Agent 运行过程中产生的调试日志整理为logs/session.log把对话的关键结论摘要写入context.md的末尾将临时文件清空压缩整个会话目录移动到04_archive/并推送一份到云盘归档空间。有了这些配置WorkBuddy 就不光是“记住”了这个家而是真的按照家里的规矩干活了。这也解答了很多搜“WorkBuddy 自定义指令推荐”的人的问题指令的意义不只是调模型语气更重要的是把工作流固化成可重复执行的约束。3.3 云盘同步的取舍只做归档不做实时工作区我后来反复测试终于找到了云盘和 Agent 工作区之间最舒服的相处方式本地是主战场云盘只负责异地归档和跨设备拉取。具体做法是01_projects不加入云盘同步至少不同步整个目录的实时状态因为这些文件正在高频读写非常容易触发冲突。会话结束后压缩包放04_archive这个目录加入云盘同步相当于归档级的异地备份。02_skills和03_templates这种低频改动目录可以加入云盘同步但我会设置只同步不实时编辑。我在不同设备之间传文件不再依赖云盘的实时同步而是明确用“导出压缩包”“网盘手动上传”的方式反而更稳。关于云盘选型我当时重点考虑过三个方向MEGA 在国内访问的稳定性和速度不可控123 云盘的 VIP 权益对大文件上传有限制百度网盘客户端自动升级和弹窗又太折腾。绕了一圈最终我用的方案是本地硬盘做主存储天翼云盘助手做归档推送。选择它的原因很简单有命令行接口可以配置定时上传不会在任务执行中弹窗也不影响会话连接的网络稳定性。3.4 会话生命周期管理进行中、已结束、已归档、已拆除会话跟人一样也是有生命周期的。我把会话分成四个状态进行中目录在01_projectsWorkBuddy 可以随时打开继续。暂停还在01_projects但context.md里标记了“TODO 下次继续”适合那种临时中断的任务。已结束已经完成或废弃目录被压缩成 tar.gz移入04_archive。已拆除归档超过 3 个月且确认不再需要删除本地压缩包仅在云盘保留一份。每个会话的session.json中都有一个status字段我在做清理时会统一脚本扫描这个字段自动决定是否归档或删除。这样即使有几十个会话我也不会“想不起”某个会话到底是完成了还是烂尾了。有个小细节必须提在 WorkBuddy 里“继续会话”并不是默认总会成功的。如果你的会话目录或者上下文文件路径变了Agent 可能找不到之前的记录。所以我要求自己在每次会话结束时把context.md补充完整这样才能在下次“继续会话”时快速恢复上下文而不是对着一个空的对话框发呆。4. 常见问题与排查技巧实录4.1 我的五个经典翻车现场任何方案都是在踩坑中成熟的。这套“会话之家”流程我也踩了不少坑挑几个最典型的说说你们可别再掉进去。翻车一Agent 报agent execution terminated due to error.目录权限不对有一阵子我经常会话刚开头就报这个错。排查半天发现是 WorkBuddy 的执行用户没有新会话目录的写权限。因为我有的目录是用 root 建的有的目录是用普通用户建的权限混在一起Agent 想往artifacts/写文件直接被拒。解决办法很简单统一目录所有者chown -R $USER:$USER ~/agent-home/翻车二两台设备同时编辑同一个会话云盘冲突文件满天飞这个问题前面说过根源就是我试图把进行中的会话放云盘实时同步。后来改成“本地工作、云盘归档”之后冲突问题直接消失。如果你还是想在不同设备间无缝切换请务必给同一个会话目录设置“唯一入口”不要两头同时写。翻车三软链接跨设备失效Skill 引用的资源找不到我给agent-home配过软链接把某个公共资源目录链到另一个磁盘分区。本地没问题一旦整个目录同步到云端再拉取到另一台电脑软链就断了所有 Skill 引用全部失效。教训是涉及云盘同步的目录不要用绝对路径的软链接要么统一使用相对路径要么干脆把资源物理复制进会话目录。翻车四修改路径后“继续会话”失败有次我手欠把一个进行中会话从01_projects/2025-06-15_build_web-crawler_blog改名成01_projects/2025-06-15_build_web-crawler_site结果 WorkBuddy 再加载这个会话时读不到记录。后来才知道会话关联的上下文文件路径已经在 session 记录里写死了。所以我立了新规矩会话目录建好之后除非走完整归档流程否则不许改名。翻车五下载安装软件时被绑定了云盘客户端这在前面提过很多人发现“为什么下载谷歌浏览器会出现谷歌的云盘”本质是安装器默认勾选了附带组件。它不仅占用磁盘空间还可能在后台创造同步任务莫名其妙消耗网络。我现在装任何软件都刻意选择自定义安装把附带的云盘、浏览器首页锁定之类组件全部取消。4.2 不只 WorkBuddy远程工具也该把会话固化成文件在研究“给会话一个家”的过程中我发现这个思路不是 WorkBuddy 独有很多工具早就开始这么干了。比如 MobaXterm 默认能保存有限数量的会话超过限制旧会话就会被冲掉有人搜“MobaXterm 会话保存最大数”其实就是想知道怎么不让会话丢失。解决办法是把会话导出成文件固化成可保存的“会话配置”。同样地SecureCRT 里也可以设置把会话配置文件保存为 txt 格式方便批量备份和迁移。这些都是“让会话有迹可循”的策略跟我的“会话即目录”本质上一回事。包括在虚拟机里用增强会话工具也是把“远程操作”固化成可恢复的会话状态而不是靠人脑记忆。所以当你觉得 WorkBuddy 的会话不好管理时不妨先跳出来想想是不是自己压根没给会话一个足够的“ego”会话不该是转瞬即逝的聊天框它应该是一块可以被文件系统记住的实体。4.3 问题排查速查表我把常见的会话目录与云盘联动问题整理成一张表方便大家直接对照排查症状可能原因快速解决Agent 报 “error executing”工作目录无写权限统一chown目录所有者云盘出现大量冲突副本多个设备同时编辑进行中会话本地实时工作云盘只做归档软链接跨设备失效绝对路径软链被同步破坏改用相对路径或物理复制“继续会话”失败会话目录被重命名或移动归档前禁止改名恢复原路径Agent 读到的文件是旧版本当前进程读挂载盘同步延迟挂载盘只做归档不执行实时任务运行任务时弹云盘更新提示客户端自动更新未关闭在客户端设置中关闭自动更新4.3 与 Agent 框架的联动思考做我这套整理方案的时候正好遇上 Agent 开源框架快速迭代的阶段。如果你在开发自己的 Agent我的建议是尽早把“会话产物目录”当作一等公民写进设计里。现在很多框架把重心放在“模型调度”和“Tool 调用”上反而忽略了会话产物管理。但实际上Agent 执行时间越长产物越丰富越需要一套清晰的目录管理。Harness 和 Agent 的区别也在这里体现得比较明显Agent 负责思考与执行而 Harness 负责提供稳定的运行环境和产物收口。俗话说巧妇难为无米之炊如果连 Agent 的输出都散得满地都是再强的模型也很难“回顾”自己的执行细节更不用说后续优化和复用。5. 这套方案还能怎么延伸写完这套方案我明显感觉自己的“云盘焦虑”缓解了大半。只要会话有一个确定的家云盘上的文件再多、同步再乱我也能通过本地的agent-home快速定位一切。目前在考虑的两个延伸方向是给归档压缩包生成一个简单的索引文件文件名列表 摘要放在04_archive/index.json里方便全局搜索。写一个轻量脚本每周自动扫描01_projects下连续 7 天没有改动的目录提示我是否归档避免月末集中清理时工作量爆炸。这两个方向如果做出来我再单独写一篇完整记录。最后再分享一个小技巧给会话目录命名时如果拿不准用什么动词就选“build”“test”“analyze”“fix”这四个高频动词。它们覆盖面广而且归档之后看目录名就能猜出内容。不要用“处理”“弄一下”“临时”这类模糊词否则过了两周你自己都认不出这个“家”是谁的。会话可以有千千万万个家最好还是清清爽爽的那种。