如果你也在用 WorkBuddy 这类本地优先的 AI 工作台大概率遇到过同一个尴尬Agent 在会话里帮你干了一堆活文件却散落在临时目录、下载文件夹、桌面甚至某个连你自己都忘了的隐藏路径里。我最初的情况更糟——WorkBuddy 里同时挂着十几个 Agent 会话有的在整理用户反馈有的在写周报有的在跑数据分析。每个会话刚开始都思路清晰但一旦隔上几天再打开别说上下文了连上次产出的文件放在哪儿都找不到。真正让我下定决心改变的是云盘里的那堆同名文件。我习惯把重要产出丢进云盘备份但 Agent 会话产生的文件既没有统一命名也没有固定位置每次备份都像一次大规模搬家搬着搬着就乱了。更难受的是云盘上只有孤立文件文件和会话的关联关系完全断了。后来我想明白一件事与其让每一个 Agent 会话自生自灭不如主动给它们一个家——一个标准化、可恢复、能自动同步到云盘的工作空间。这篇博文就是我把这套方案落地过程中的完整记录包含目录设计、WorkBuddy Skill 写法、自定义指令模板、云盘同步策略以及我翻过的车适合同样在用 WorkBuddy 管理多个 Agent 会话的人参考。1. 先聊聊我为什么会有云盘焦虑1.1 WorkBuddy 是个什么样的工具WorkBuddy 本质上是一个面向 AI Agent 的本地工作台。它和那种纯网页端对话工具不一样它把对话式任务执行和本地文件系统、命令行工具、第三方 API 串在了一起。你可以把 WorkBuddy 理解成给 Agent 准备的工位它有工作记忆上下文窗口有工具调用能力Skills 插件机制有自定义指令用来约束 Agent 的行为边界。正因为 Agent 可以直接和你电脑里的真实文件打交道它才会源源不断地产生新文件——这是好事但也带来一个很多人忽略的问题这些文件谁来管在 Web 端 AI 工具里你不需要关心文件管理所有交互都在对话框里完成。但在 WorkBuddy 这样的本地工具里Agent 生成的每一个 CSV、每一张图表、每一版文档草稿都是真实磁盘上的文件。我最初的做法是让 Agent看着办结果就是它把文件随手写在当前工作目录甚至自己新建了一堆莫名其妙的子目录。短期看没什么等你积累了几十个会话问题就爆发了你根本不知道哪个目录属于哪个会话。1.2 会话数据无家可归的三个典型场景场景一数据分析任务。我让一个 Agent 分析某个数据文件夹它跑完脚本后往相邻目录丢了三个 CSV 和两张图表。当时我还在会话里盯着知道这些文件是干什么的。三天后再看只剩一堆文件名完全对不上当时的需求。场景二文档撰写。Agent 生成了周报初稿、修订稿、最终稿三个版本分别躺在不同的目录里。我把它们手动备份到云盘后过几天又出现了同名文件冲突根本分不清哪个版本更新。事实是我根本没有给这个会话分配一个专属空间所有版本都是散养的。场景三多项目并行。WorkBuddy 支持多个 Agent 并行每个 Agent 有自己的上下文但文件系统是共享的。这就导致 A 项目生成的中间文件可能会在 B 项目执行时被误读。尤其是当某个 Agent 被赋予了较强的自主决策权时它真的会去扫描当前目录下的所有文件然后自作主张地把别的项目文件当输入。这三个场景的共同点会话的状态上下文和会话的产物文件之间缺乏稳定的对应关系。云盘确实是很好的存储工具但如果我们把未经组织的文件直接丢给云盘那只是把混乱复制了一份。我后来意识到云盘焦虑的本质不是云盘不好用而是文件在进入云盘之前就乱掉了。2. 整体方案给每个 Agent 会话一个标准化的家2.1 四个核心设计原则在动手做目录结构之前我先给自己定了四条原则后面的所有实现都是围绕这些原则展开的。第一目录即上下文。每个会话对应一个独立的目录目录里的文件就是 Agent 在这个会话中的记忆载体。会话一旦打开Agent 应该能从这个目录里读到自己曾经是谁、做过什么、接下来要做什么。第二文件即记忆。不是所有文件都有长期价值。临时产物、中间缓存、过程草稿要跟正式产出分开。只有需要长期保留的内容才会进入 notes/ 和 output/这样既控制了记忆文件的规模也避免了云盘同步时被垃圾文件拖慢。第三会话状态可序列化。每个会话目录里必须有一个 session.json里面记录这个会话的所有关键元数据。只要这份 JSON 还活着这个会话就能在任意时间点被完整重建。第四云盘只做同步不做整理。整理和归档必须在本地完成云盘只是透明的同步通道。云盘客户端的作用是把 sessions 目录搬到另一台设备上而不是帮我在混乱中找出最新版本。整理的动作发生在本地目录结构里这是整套方案的前提。这四条原则里第四条最容易被忽视。很多人以为装了云盘客户端就算同步了其实没有。真正好用的同步是你把本地的目录结构定好之后云盘只需要做机械复制一旦本地的文件本身就乱云盘的版本历史、冲突处理、找回功能全都成了事后补救体验极差。2.2 目录骨架长什么样我最终定下的目录结构是这样工作根目录/ └── sessions/ └── 2025-06-18_user-feedback-analysis/ ├── session.json # 会话元数据程序自动维护 ├── brief.md # 任务简报启动会话时加载 ├── input/ # 输入材料Agent 只读 ├── output/ # 正式产出交付物都在这里 ├── notes/ # 过程笔记Agent 自主写入 └── temp/ # 临时文件可随时清空每个子目录的角色很明确。input/ 只读放原始素材我明确要求 Agent 不要修改这个目录下的文件避免源数据被污染。output/ 集中放最终交付物不管是报告、图表还是代码包凡是给人类看的结果都到这里。notes/ 是 Agent 的过程记忆包括阶段性结论、踩坑记录、下一步计划这些内容在恢复会话时会重新注入上下文。temp/ 是临时体操场地Agent 可以随便折腾反正不同步到云盘随时可删。session.json 是最核心的文件WorkBuddy 恢复会话时首先读它。字段我后面会展开讲。brief.md 是给 Agent 看的任务简报里面写清楚任务目标、输入材料位置、交付物要求。这两份文件是整个会话的户口本和工作证。为什么一定要用固定骨架因为 Agent 的行为会被结构影响。给一个 Agent 展示清晰的目录结构它就会倾向于把文件放到对应分类下如果什么都不给它它只会按训练数据里的默认习惯乱放。模型不是没有组织能力而是缺少约束。我们作为使用者要给 Agent 立规矩。2.3 为什么会话目录名用日期_语义名目录命名我纠结过一阵子。最开始用纯数字编号 001、002、003人眼一看根本不知道里面是什么。后来换成纯语义名用户反馈分析结果没几天就重名了同一类任务开了两个并行的会话目录直接撞车。最终定下来用日期_语义名2025-06-18_user-feedback-analysis 2025-06-18_weekly-report-draft 2025-06-19_data-cleanup这个方案的优点有三个。一是天然按时间排序ls 出来的列表就是时间线。二是语义可读看到 user-feedback-analysis 就知道是分析用户反馈的。三是避免重名同一天做两个相同任务时加序号后缀。有一个细节值得注意目录名尽量不要用中文因为某些脚本、工具跨平台处理中文路径时会遇到编码问题。我都是把中文可读名称放在 session.json 的 name 字段里目录名用英文短横线连接。这样既保证了人对目录的可读性又从根源上避开了编码坑。3. 实操落地从目录骨架到云盘自动备份3.1 第一步搭建会话工作区骨架我先写了一个 bash 脚本专门用来创建新的会话目录。它要做的事很简单生成带日期前缀的目录名、创建六个标准子目录、写入初始化的 session.json 和 brief.md。脚本如下#!/usr/bin/env bash # 用法: ./new_session.sh 用户反馈分析 set -euo pipefail SESSIONS_ROOT${WORKBUDDY_SESSIONS:-$HOME/workbuddy_sessions} DATE_TAG$(date %Y-%m-%d) RAW_NAME${1:?请传入会话名称} SAFE_NAME$(echo $RAW_NAME | tr [:upper:] [:lower:] | sed s/[^a-z0-9]/-/g) SESSION_ID${DATE_TAG}_${SAFE_NAME} SESSION_DIR${SESSIONS_ROOT}/${SESSION_ID} if [ -d $SESSION_DIR ]; then echo 会话目录已存在: $SESSION_DIR exit 1 fi mkdir -p $SESSION_DIR/{input,output,notes,temp} cat $SESSION_DIR/session.json EOF { id: $SESSION_ID, name: $RAW_NAME, created_at: $(date -Iseconds), status: active, model: , skills: [], cloud_sync: true } EOF cat $SESSION_DIR/brief.md EOF # $RAW_NAME ## 任务目标 ## 输入材料 - input/ 目录下放置原始文件 ## 交付物 - output/ 目录下放置最终结果 EOF echo 已创建会话: $SESSION_DIR脚本里的几个细节我说一下。set -euo pipefail 是 bash 脚本的安全开关任何一个命令出错就会停止避免脚本中途失败还假装成功。SAFE_NAME 把中文和空格都转成小写连字符防止目录名里出现非法字符。session.json 里预留了 model 和 skills 字段暂时留空后续可以在 WorkBuddy 操作界面里补填。有些朋友可能用的是 Windows 环境没有 bash 脚本。没关系你完全可以用 Python 写一个等价脚本核心逻辑就三条拼接目录名、mkdir、写 JSON 文件。骨架本身很轻重点在于每次新建会话都走同一个流程而不是手动 mkdir。3.2 第二步用 WorkBuddy Skill 一键新建会话光有脚本还不够最好能在 WorkBuddy 对话框里用一句话触发。WorkBuddy 的 Skill 机制这时候就派上用场了。你可以把一个 Skill 理解成一个可复用的指令包它会告诉 Agent遇到什么情况、按什么步骤执行哪些操作。我写的 Skill 长这样name: session_workspace description: 创建或恢复一个 Agent 会话工作区 version: 1.0.0 triggers: - 新建会话 - 创建工作区 steps: - action: run_script script: new_session.sh args_from: user_input - action: load_file file: session.json into: context - action: load_file file: brief.md into: context这个 Skill 做的事情分三步先调用刚才那个脚本创建物理目录然后把 session.json 和 brief.md 的内容加载进 Agent 的上下文窗口。这样一来Agent 在会话刚刚建立的时候就已经知道三件事我的工作目录在哪、我的任务目标是什么、我们的协作约定是什么。实测下来自然语言触发非常顺滑。我直接在 WorkBuddy 对话框里输入新建会话用户反馈分析它就会自动调用脚本创建 workbuddy_sessions/2025-06-18_user-feedback-analysis/ 目录然后把 brief.md 里的任务模板注入上下文。整个过程不到十秒比我手动建目录再写任务描述快得多。不同版本的 WorkBuddy 对 Skill 的定义格式可能有差异上面是我用的版本的结构。核心思路是通用的创建目录、写元数据、注入上下文。你不需要纠结具体字段名照着这个流程在你自己的工具里实现一遍就行。3.3 第三步自定义指令把协作约定写死目录建好了、任务简报注入了还差最后一层约束Agent 在这个家里到底该怎么干活。如果不对行为做约定每个模型在这个场景下的默认习惯都不一样有的喜欢把中间结果丢在根目录有的会频繁改写已有文件有的干脆不写任何过程记录。我在 WorkBuddy 的自定义指令Custom Instructions里加了一段固定内容你是本会话工作区的管家。你的工作目录是 {{SESSION_DIR}}。 - 输入文件一律放在 input/只读不要修改。 - 所有过程稿、草稿、中间版本写入 notes/不要删改已有笔记。 - 最终交付物写入 output/。 - 临时文件一律放 temp/不参与云盘同步。 - 每当完成一个重要步骤更新 notes/CHANGELOG.md记录时间、做了什么、下一步计划。 - 退出前检查 session.json 中 status 字段必要时更新。你别小看这段约定它的价值在于让 Agent 的行为可预期。以前两个不同模型跑同一个任务产出的目录结构完全对不上有了这段约定之后不管底层模型换成哪个只要它遵循了自定义指令最终的文件结构基本一致。这对我后来做归档和云盘管理帮助极大。尤其要强调 CHANGELOG.md 这个文件。它其实是给未来的你看的。每次恢复会话时只需要读一遍 CHANGELOG人就能快速想起上次做到哪儿、卡在什么问题上、下一步计划是什么。Agent 也能通过它接上断点。没有这个文件恢复会话就变成翻垃圾桶找记忆痛苦不堪。3.4 第四步云盘同步策略与排除规则到这里给会话一个家的本地部分已经完成了接下来是云盘同步。这一步直接解决我最初的云盘焦虑。我的做法是选择支持选择性同步和排除规则的云盘客户端把 workbuddy_sessions 目录作为同步根目录然后配置排除规则。通用的排除规则如下temp/ *.tmp *.swp .DS_Store .cache/ __pycache__/ node_modules/排除 temp/ 是必须的它里面全是临时产物不同步能节省大量空间和时间。排除 .git 是我踩了坑之后才加的。如果你在会话目录里初始化了 git 仓库千万不要把 .git 目录同步到云盘那里有大量小文件且容易出现索引锁冲突拖慢同步速度。同步方向我推荐单向备份 手动恢复。云盘作为主备份跨设备恢复时从云盘拉取而不是两个设备同时双向实时同步。同一时间尽量只在一台设备上写某个会话目录否则两个设备同时修改 session.json云盘大概率会生成冲突副本到时候清理起来更麻烦。关于云盘客户端的选择市面上的主流个人云盘产品基本都支持自定义同步目录和排除规则我用的就是我自己常备的那一款。核心不是选哪个品牌而是选一个能把 workbuddy_sessions 整个目录原样同步、并且支持排除规则的客户端。这一点你最好在动手之前确认一下有些轻量级同步工具是不支持排除规则的那就得换方案。4. 会话恢复与多设备协同让家真正好用4.1 断点续聊从 session.json 恢复会话目录结构和云盘同步都搭好了接下来要解决的是怎么把断掉的会话接回来。这是整套方案里最让人舒服的环节也是我最初决定做这个项目的直接原因。我在 session.json 里逐步扩展了字段最终长这样{ id: 2025-06-18_user-feedback-analysis, name: 用户反馈分析, created_at: 2025-06-18T10:30:0008:00, last_updated: 2025-06-18T18:20:0008:00, status: paused, model: gpt-4o, skills: [session_workspace, data_analysis], objective: 分析 6 月用户反馈输出 Top 10 问题清单, cloud_sync: true, restore_points: [notes/CHANGELOG.md, notes/context_summary.md] }恢复会话的操作就三句话打开 WorkBuddy 的恢复会话入口选择对应的 session.json告诉 Agent继续。WorkBuddy 读取 JSON 后会把 objective 字段复述给模型再把 restore_points 里指定的文件注入上下文。Agent 读到 CHANGELOG.md 后就相当于看到了自己的工作日记能快速接上断点。我特别建议把 last_updated 字段维护好。按照自定义指令里的约定Agent 每次退出前更新 session.json 的 status 字段时会连带更新这个时间戳。这样你扫一眼目录就知道哪个会话最近还在动哪个已经凉了很久。4.2 多设备协同的边界在哪里这套方案出来之后最顺手的场景是电脑之间的切换。我白天在公司台式机上跑长任务晚上回家用笔记本查看结果。以前两个设备的 WorkBuddy 各有各的会话历史文件完全对不上号现在只要两个设备都同步同一个 workbuddy_sessions 根目录回家后打开笔记本上的 WorkBuddy选择同一个 session.json就能读到完整上下文连 Agent 的记忆都是连续的。不过多设备协同有一条边界必须守住绝不在两台设备上同时激活同一个会话。你可以在家里查看、读取、分析但一旦 Agent 要在该会话目录下写入文件就必须确保另一台设备没有在操作同一个目录。我吃过一次亏两台设备同时跑一个数据清洗会话结果 session.json 被写乱云盘上多了一个冲突副本。另外如果你用云盘客户端的网页版或在线预览功能不要在网页端直接编辑 session.json容易破坏 JSON 格式。宁可下载到本地改完再传回去也别图方便在预览窗口里改。4.3 一个完整使用案例我拿一个实际任务用户反馈分析来走一遍完整流程。早上到公司我在 WorkBuddy 对话框输入新建会话用户反馈分析Skill 自动创建目录骨架。然后把昨天导出的用户反馈表格放进 input/在 brief.md 里补充任务目标和交付要求。Agent 启动后按自定义指令约定先扫描 input/ 目录把数据整体情况写进 notes/CHANGELOG.md然后开始分析。中间它会生成一些中间结果比如去重后的临时 CSV、初版图表草稿这些被放进 temp/ 或者 notes/。最终生成的 Top 10 问题清单和图表版本放到了 output/。中午我关掉这个会话Agent 在退出前更新了 session.json把 last_updated 和 status 都改掉了。云盘客户端检测到文件变化把新增内容同步上去。晚上回家我打开笔记本恢复这个会话。WorkBuddy 把 session.json 和 notes/CHANGELOG.md 注入上下文Agent 读到自己上午已经做到问题清单初稿完成、但还差数据可视化于是自动接上这个断点继续完成图表。整个过程就像上午那个 Agent 从未离开过一样。5. 踩坑实录这套方案里最容易翻车的5个地方5.1 典型问题排查速查表方案跑了一个多月说完全顺滑那是骗人的。实际操作中我遇到了不少问题有些很快就解决了有些折腾了大半天。我整理了一个速查表按照现象、可能原因、解决办法三列列出最常见的情况。现象可能原因解决办法云盘出现冲突副本文件多台设备同时写同一个会话目录遵循单写多读原则明确当前活跃设备云盘空间很快被占满排除规则没写对或没生效检查 temp/ 是否被排除清空已有 temp 内容恢复会话后上下文失忆notes/ 里的记忆文件没被加载在 session.json 的 restore_points 里显式声明Agent 报路径不存在中文目录名在不同平台编码不一致目录名统一用英文短横线中文名只放 session.json云盘同步速度极慢目录里混入 .git、node_modules 等海量小文件排除规则里加对应项必要时清理历史这五类问题里最坑的是第一类冲突副本。冲突本身不可怕可怕的是你不知道哪个版本才是最新的。我后来在 brief.md 里加了一行注释专门记录当前活跃设备名称。哪个设备上要开始写这个会话了就先顺手改一下这行注释。等云盘同步完成另一台设备也能看到。第二类问题也很有意思。我一开始以为自己在排除规则里写了 temp/ 就够了但实际测试发现有些云盘客户端的排除规则是目录名完全不匹配的写法跟我理解的前缀匹配不一样。你最好在配置完排除规则后手动在 temp/ 里放一个大文件验证它到底有没有被同步别等盘满了才发现规则无效。5.2 容易被忽略的三个细节除了上面这些显性问题还有三个细节是容易被忽略、但影响很大的。第一session.json 的编码。这个文件必须用 UTF-8 编码保存而且要避免在 Windows 记事本默认的 ANSI 编码下编辑。我建议所有写 session.json 的操作都通过脚本完成不要手敲。手敲容易引入不可见字符或错误编码恢复会话时就会解析失败。第二input/ 目录的只读约束。脚本创建目录之后默认所有子目录都是可写的。Agent 在自主动作时可能会修改 input/ 里的原始文件。我在 Linux 上用 chmod 给 input/ 设了只读权限Windows 上没这么方便就只能靠自定义指令约束。如果你处理的输入数据非常重要强烈建议给 input/ 做只读保护。第三归档策略。会话一多sessions 目录会越来越大云盘同步也没必要把所有历史全留在本地。我每季度做一次归档把已经交付完成的会话目录移动到 archive/ 目录下archive/ 不同步到云盘本地端只保留一个压缩包放在网盘存储区。这样日常同步的只是活跃会话速度明显提升。5.3 从能用到好用的最后一公里这个方案做到最后真正拉开体验差距的其实是一个理念转变不要指望着记住每个会话在干嘛而要设计一套机制让忘记也变成安全的操作。只要目录骨架在、session.json 在、CHANGELOG.md 在任何会话过了一个月再回来也能用五分钟把上下文完整捞起来。我也越来越习惯把 CHANGELOG 当作给未来自己的信。每次 Agent 写完一条记录我并不会逐条读。但等到我真的需要翻旧账时按时间线扫一遍 CHANGELOG整个项目的脉络立刻清晰。这种感觉比当初面对一堆同名文件、不知道哪个是最新版时的焦虑好太多了。如果你现在也正被 Agent 会话的文件管理搞得焦头烂额我的建议很简单不要一次性追求完美方案先从一个目录骨架开始把每一个新会话的根目录结构定下来然后加上 session.json 和 brief.md再逐步接入云盘同步和恢复机制。目录结构一旦定下来后面所有事情都会顺很多。至少对我来说给每个 Agent 会话一个家这个决定是我今年在 AI 工具使用习惯上做的最值得的一次调整。