前阵子我一直在为 WorkBuddy 的会话管理头疼。不是功能不好用恰恰相反WorkBuddy 这种把 AI Agent 开发当成正经工程来做的工具能力越强暴露出来的问题越明显——每个会话都是一次性消耗品。开一个窗口聊完关掉上下文没了中间产出的方案、数据、推理过程全部丢在聊天记录的黑洞里。等过两天想接着做发现又要从头讲一遍需求Agent 一脸茫然我也一脸茫然。这个状态持续了一段时间我越来越觉得不对劲。网盘会满、会乱、会找不到文件Agent 会话其实也一样。你把一堆对话记录摊在云盘里、摊在本地目录里、摊在几个不同工具的缓存里要用的时候根本不知道去哪翻。所以我决定动手做一件事给每个 Agent 会话一个“家”。一个固定的、结构化的、可回溯的存储位置让每一次会话不只活在上下文窗口里而是落成一个可以随时找回的工作档案。这篇文章就是这次折腾的完整记录包括我的设计思路、目录结构、配置文件、踩坑过程以及最终的方案。如果你也在用 WorkBuddy 或者类似的 Agent 开发工具被“会话一关全忘光”这个问题烦过这篇内容应该能给你不少可以直接抄作业的参考。1. 焦虑从哪来不是网盘容量是会话上下文在“裸奔”1.1 网盘、会话与上下文断裂的共同本质先说清楚我为什么把这个问题叫作“云盘焦虑”。大家用过网盘都知道那种感觉刚开始觉得空间够大随便存后来发现存进去容易找出来难。更麻烦的是同一个文件可能被同步到好几台设备上本地一份、云端一份、同事分享链接又是一份哪一份是最新的谁也说不清。我的 Agent 会话管理问题本质和这个一模一样会话记录散落在不同地方。WorkBuddy 的会话历史、我自己随手存的文本、终端里跑过的日志、临时复制到桌面上的中间结果没有一个统一的归置方案。每次新会话都在“重新认识彼此”。Agent 不记得上次讨论到哪一步不记得已经排除过哪些方案更不记得用户偏好什么风格。我总是在重复自我介绍。想回溯时找不到入口。昨天明明让 Agent 写过一个很不错的正则表达式今天想找出来用结果翻遍历史记录也不知道是哪个会话里生成的了。一句话总结Agent 的上下文窗口就像网盘的可用容量今天不用完明天也会被新的内容覆盖。如果中间产物没有持久化所有“刚刚想清楚的事情”都会在下一次会话里彻底失忆。1.2 WorkBuddy 的会话模型与痛点放大效应WorkBuddy 这类工具本质上是一个带记忆的 Agent 运行环境。它的优势在于把模型能力、文件操作、命令执行、技能调用这些东西整合到一个工作台里。但正因为它把能力整合得太多会话里产生的信息量远高于普通聊天机器人——有代码、有输出日志、有中间决策、有修改过的文件路径、有验证过的命令。这些高价值信息全部堆在会话记录里关掉窗口以后就成了“不可检索的存档”。用 WorkBuddy 做过实际项目的朋友应该都有这个体感单次会话内Agent 的理解能力非常在线你让它改代码、跑测试、写文档它都能接得住。可一旦这个会话结束你重新开一个新的哪怕模型还是同一个模型工作台还是同一个工作台它对你的项目一无所知对你的偏好一无所知甚至对你昨天刚和它确认过的技术选型也一无所知。我一开始以为是模型记忆能力的问题后来发现不是。大模型本来就没有跨会话的持久记忆这是架构决定的。问题出在我自己——我没有把“需要记住的东西”主动沉淀下来没有给会话安排一个可复用的上下文“基地”。我把 Agent 当成一个记忆力正常的同事来用但它本质上是一个每次见面都把你当陌生人的实习生。1.3 什么样的焦虑才是真正需要解决的在和这个焦虑共处了一段时间后我列了一个需求清单用来明确什么才是我真正需要解决的问题每个任务从一开始就有独立的工作目录不和其他任务混在一起。目录里必须包含所有 Agent 需要用到的背景资料不靠聊天记录“补课”。每次会话结束时能自动或半自动地生成一份“会话交接文档”记录做了什么、做到哪了、下一步是什么。任何时候重新打开项目都能让 Agent 在 30 秒内恢复到上次的工作状态。所有内容遵循“本地优先”原则即使不同步到云端也不会丢失同步到云端只是备份而非依赖。这个清单把我从“要不要买个更大的网盘会员”的伪需求里拉了出来。我要解决的问题不是存储空间不够而是存储结构不合理。给 Agent 会话一个“家”拆开了看其实是给每一次工作建一个“档案室”。2. 给会话安家的整体设计一个任务一个目录让 Agent 有处可归2.1 目录结构设计从“对话列表”到“任务档案”我用的方案非常朴素核心思想就是八个字一个任务一个目录。所有的会话文件、上下文资料、中间产物、最终输出全部收纳进这个目录里由目录结构自己表达“这个任务进行到哪一步了”。我最终确定的目录模板如下workbuddy/projects/ ├── 任务名/ │ ├── context/ │ │ ├── 项目说明.md # 任务背景、目标、约束条件 │ │ ├── 参考资料/ # Agent 需要阅读的外部资料 │ │ ├── 技术决策.md # 已经确认的技术选型和理由 │ │ └── 用户偏好.md # 风格偏好、输出格式要求、禁忌事项 │ ├── sessions/ │ │ ├── session-index.md # 会话索引按时间倒序记录每次会话摘要 │ │ ├── 2025-06-01-需求梳理.md │ │ ├── 2025-06-02-方案设计.md │ │ └── 2025-06-03-编码实现.md │ ├── output/ │ │ ├── 最终产出/ # 可交付的成果物 │ │ └── 中间产物/ # 过程中的数据和临时文件 │ ├── logs/ │ │ ├── 运行日志/ │ │ └── 错误记录/ │ └── AGENTS.md # 该任务的专属 Agent 指令 └── workbuddy-global/ └── AGENTS.md # 全局指令对所有会话生效这个结构最关键的一点是我把“会话列表”这个概念彻底抛弃了不再按时间顺序堆砌聊天记录而是按任务维度组织一切。会话记录只是任务档案里的一个子目录它存在的意义是记录进度而不是承载全部记忆。真正承载记忆的是 context 里的资料和 sessions 里的索引。2.2 为什么选择“本地优先 结构化目录”而不是“云端同步 一键搜索”我其实也认真考虑过另一条路把所有会话和历史记录交给云盘自动同步用搜索功能来找信息。试了大概几天很快就放弃了。原因有三个搜索是穷人的记忆法结构是富人的记忆法。云盘搜索即使能做到全文检索也只能找到“出现过这个词”的文件找不回“当时为什么这么决策”的前因后果。而结构化的目录天然自带逻辑关系看一眼目录结构就知道任务状态。云盘同步会产生版本冲突。Agent 会话过程中文件改动非常高频如果 sync 到云盘经常出现“本地这个文件已经改了但云盘还是旧版”的错乱反而加剧焦虑。云端存储的检索延迟和批量操作能力很弱。我想写脚本批量归档、批量重命名、批量提取关键词做索引云盘网页端根本干不了这个活本地文件系统才是真正可控的。所以我最后的策略是“本地优先云端只做备份”项目进行中一切读写都在本地目录里完成只有任务告一段落时才把整个目录压缩归档传到云盘留底。这样既保住了文件系统的灵活性也拿到了云盘的容灾能力。2.3 Agent 如何“认路”规则文件与会话索引的双层保障目录结构只是骨架真正让 Agent 能够“认路”的是规则文件和会话索引。第一层是 AGENTS.md。这个文件在 WorkBuddy 里是全局约定的规则入口每次会话启动时 Agent 都会自动读取。我做的事情是把整个目录结构说明、文件写入规范、会话交接要求都写进这个规则文件里相当于在 Agent 的“入职手册”里明确写了工作规范。第二层是 session-index.md。如果说 AGENTS.md 是工作手册session-index 就是项目日志。每次会话结束时我会让 Agent 更新这个文件写入本次会话解决的问题、关键决策、产生的文件、遗留事项。下次会话一开始Agent 只需要读这一个文件就能快速恢复工作记忆。层结构很像一个成熟的团队协作方式手册管流程日志管进度。Agent 不需要真的“记住”上一次聊了什么它只需要知道去哪里查。3. 实操实录把 WorkBuddy 配置成“会记忆”的工作台3.1 初始化全局规则文件我的第一步是建立全局规则文件。在 WorkBuddy 中这个文件位于工作台的数据目录下具体路径不同版本略有差异我的做法是直接在设置里找到“全局指令”或“自定义指令”的入口粘贴以下内容# 全局工作规则 你运行在多任务工作环境中必须遵循以下存储约定 1. 每个任务必须在 workbuddy/projects/ 下拥有独立目录目录名使用短横线命名。 2. 任务相关背景资料存放于 context/ 子目录新会话开始时应优先读取该目录。 3. 每个会话结束前必须更新 sessions/session-index.md追加本次会话摘要。 4. 会话摘要模板 - 日期时间 - 本次目标 - 完成事项 - 关键结论/决策 - 产出文件列表 - 遗留问题与下一步 5. 涉及可交付成果时写入 output/ 目录并同步更新 README。 6. 不要依赖聊天记录记忆所有重要信息必须以文件形式落盘。这段规则的作用是双重的。表面上它是在给 Agent 布置存储任务实际上它在帮我建立“会话结束前必须做交接归档”这个习惯。我发现如果不定这个规则即使目录结构摆在那里Agent 其实更喜欢把信息留在会话里而不主动写文件——因为写文件对它来说是一次额外的工具调用。所以必须用规则把它“逼”成习惯。3.2 创建任务模板与一键初始化流程目录结构不能每次手工创建那样太容易懈怠。我写了一个简单的初始化脚本放在 workbuddy/init_project.sh 里#!/bin/bash # 用法: ./init_project.sh 任务名 NAME$1 BASE$HOME/workbuddy/projects/$NAME if [ -d $BASE ]; then echo 目录已存在跳过创建。 exit 1 fi mkdir -p $BASE/{context/{参考资料,},sessions,output/{最终产出,中间产物},logs} cat $BASE/AGENTS.md EOF # 项目指令$NAME ## 项目背景 待补充 ## 目标 - 待定义 ## 约束 - 遵循全局工作规则 ## 当前进度 尚未开始详见 sessions/session-index.md EOF cat $BASE/sessions/session-index.md EOF # 会话索引 暂无记录 EOF echo 项目 $NAME 已初始化 tree $BASE这个脚本帮我省掉了很多重复劳动。现在我在 WorkBuddy 里接到一个新任务第一件事不是直接开聊而是先在终端里跑一下 init_project.sh 建好目录再开始会话。所有背景资料扔进 context/然后让 Agent 先读一遍目录结构再开工。实测下来这套流程有个额外的好处因为每次新任务都有一个独立的 AGENTS.md我可以在里面写针对该任务的特殊偏好比如“回复尽量简洁”“代码必须带注释”“不要修改 public 目录下的文件”等。这比在全局规则里堆一堆杂七杂八的条件要干净得多。3.3 会话中如何让 Agent 保持“上下文在线”目录建好之后真正的挑战在于会话进行中的节奏控制。我摸索出来的一个关键操作是在长任务中主动让 Agent 阶段性落盘。以前我习惯于让 Agent 一口气把整个任务做完。后来发现能一口气做完的任务基本都不复杂复杂的任务做到一半上下文就快满了Agent 开始忽略早期的约束甚至忘记最初的代码风格要求。我的对策是把任务拆成若干阶段每个阶段结束后直接让 Agent 做两件事更新 context/技术决策.md把本阶段做的关键选择记录下来。更新 sessions/session-index.md写上进度和下一步计划。这样做的好处立竿见影。即使上下文窗口满了我清空会话重新开一个Agent 只需要读 session-index.md 就能无缝续上。上下文窗口的本质是一个高速缓存真正的工作记忆应该放在持久化的文件系统里。另外我还设置了一个自定义指令WorkBuddy 里可以直接作为斜杠命令或快捷指令保存内容只有一句“在继续本次工作前先阅读 sessions/session-index.md 的最新三条记录然后开始。”每次新会话我先发这个指令相当于给 Agent 做了个快速热身。3.4 用“会话交接文档”代替冗长的聊天记录最后是收尾环节。以前我开完一个会话离开时留下一堆聊天记录毫无章法。现在每次会话结束前我都要求 Agent 按模板生成一份交接文档追加到 session-index.md 里。模板我固定下来了长这样## [2025-06-03 14:20] 编码实现阶段 - 目标完成数据清洗模块的单元测试 - 完成事项 - 修复了日期解析函数的时区 bug - 新增 5 个测试用例全部通过 - 关键结论依赖注入方式比全局单例更利于测试 - 产出output/中间产物/test_report.html - 遗留性能优化尚未开始预计还需 1 个会话 - 下一步实现批处理模式参考 context/参考资料/批量处理设计方案.md这个过程看起来煞有介事但它其实解决了一个非常实际的问题下次我继续这个任务时不需要从头翻对话记录也不需要靠回忆把任务背景重新讲一遍。交接文档就是 Agent 的“项目简报”让它在几十秒内完成语境重建。对我自己来说也一样隔了两周再打开一个任务文件夹看几眼 session-index就能迅速想起来当时做到哪一步、为什么这么设计。3.5 云端同步与容灾备份的实际做法容灾备份这步我没有省。我的具体做法是项目进行期间所有读写都在本地每隔两三天用 rsync 把整个 projects 目录增量备份到外接硬盘任务全部完结后把整个项目目录 tar 压缩传到云盘归档。# 增量备份 rsync -av --delete ~/workbuddy/projects/ /Volumes/Backup/workbuddy-projects/ # 任务归档 tar -czf ~/archive/数据清洗项目-20250603.tar.gz -C ~/workbuddy/projects 数据清洗项目这里有一个我的个人偏好archive 里的 tar 包是只进不出的任务结束后这个目录就只读不再改动。这样云盘上存的是一个个完整、稳定、可整体下载的备份而工作目录里是活跃的、不断变化的工作区。两者彻底分离互不干扰再也没出现过“云端覆盖本地最新版本”这种惨剧。这个方案实测下来很稳我已经用了几个星期没有一次因为会话丢失导致重新“讲需求”。唯一要适应的就是每次会话多花一两分钟让 Agent 读文件、写交接文档。但这笔开销和找回丢失上下文的成本比起来完全不值一提。4. 常见问题与排查方法我踩过的坑和解决办法4.1 问题一新会话开启后 Agent 仍然“失忆”现象明明已经在全局规则里写了“新会话先读 session-index”也把交接文档写得清清楚楚但新会话里 Agent 还是像没看见一样直接就开始回答完全暴露出没读过文件。排查思路这种情况八成不是规则没写而是 Agent 在流程上偷懒了。很多模型习惯性地“尽量少调用工具”能靠对话历史回答就不去读文件。我试过几个办法在全局规则里把“读取 session-index.md”从“应该做”改成“必须先做”并且写清楚“在读取该文件之前禁止开始任何实质性工作”。在新会话的第一条消息里主动点名请先阅读 path/to/session-index.md然后总结这个任务目前的进度。如果 Agent 还是无视我会直接看图穷匕见把文件内容贴进对话里再说一次。虽然笨但最可靠。4.2 问题二交接文档越写越长反而找不到重点现象session-index.md 初期还好项目做到中后期文件里堆了几十条记录Agent 每次读取要消耗大量上下文。排查思路索引文件不是流水账它需要“总—分”结构。我在文件开头维护了一段固定置顶的内容“当前进度一句话 最近一次会话的关键结论 立刻要做的事”。每次会话结束后不只追加记录还要更新置顶这三条。这样 Agent 只需要读文件前几十行就能掌握全局想看细节再翻历史记录。这个结构调整之后效果非常明显。我把读取 session-index 的上下文开销压到了非常低的水平同时信息召回率反而提高了因为置顶内容就是最核心的“现在”。建议所有用这个方法的人都养成维护置顶摘要的习惯。4.3 问题三目录结构越用越乱文件该放哪全靠猜现象执行了几天之后发现 context、sessions、output 里开始混放文件有时 Agent 把中间结果写到了 output/最终产出 里有时把参考文档放到了 sessions 目录下。排查思路结构规范不能只写“应该这么放”还要给出判断依据。我在 AGENTS.md 里加了一段明确的“文件归属判断规则”这个文件是“背景信息”还是“过程记录”还是“最终成果”背景信息去 context过程记录去 sessions 或 logs最终成果去 output。这个文件需要长期复用吗需要就放 context临时验证一下的放中间产物目录。这个文件是某个会话的专属产出吗如果是它的简要说明进 session-index文件本体按类型归位。加了这段规则之后结构化程度明显好转。另外我每周会花几分钟做一次“目录巡检”用 tree 命令扫一眼发现放错位置的文件顺手归置一下。这个习惯很轻量但能防止结构在不知不觉中腐烂。4.4 问题四同一任务开多个会话状态不同步现象一个任务开了一堆会话窗口每个窗口里的 Agent 各自为政session-index 文件出现并发写入后写的覆盖了先写的记录丢了。排查思路这是最容易踩的并发坑。Agent 会话操作文件时没有加锁概念两个进程同时写同一个文件必然出现覆盖或者写入错乱。我的对策很朴素同一时间只允许一个会话处理同一个任务目录。一个任务一个“活跃会话”原则如果开新的先把旧的收尾关掉。如果确实需要并行给每个会话安排单独的会话文件例如 session-index-01.md、session-index-02.md最后再人工合并。定时用 git 对 projects 目录做版本管理。每次会话结束 commit 一次虽然不能防止覆盖但至少能随时回滚找回被冲掉的内容。我后来干脆把整个 projects 目录变成了 git 仓库。这个动作带来的安全感和网盘完全不同——git 记录的是每次变化的差异而不是整文件覆盖即使发生了错乱也能精准还原到某个时间点。4.5 常见问题速查表症状可能原因解决方案新会话 Agent 完全失忆未读取 session-index 文件规则中强制“先读后做”首条消息直接点明文件路径接手旧项目半天进入不了状态交接文档缺失或信息过时定期维护置顶摘要保持“当前进度一句话”更新文件越放越乱目录失去意义缺少文件归属判断规则在 AGENTS.md 中加入落盘规则和文件分类标准多会话并行后索引记录丢失并发写入互相覆盖一个任务只开一个活跃会话配合 git 做版本回滚上下文被长文件撑爆索引文件太长Agent 全量读取置顶摘要精简详情下沉必要时拆分索引文件本地误删文件找不回来没有备份机制引入 git 提交 定期 rsync 到外部存储这套方法并不复杂但它把一个模糊的“云盘焦虑”转化成了具体的、可管理的工程实践。我最大的感受是Agent 的潜力很大但它是彻底的“被动记忆者”。你给它什么样的工作环境它就会回馈给你什么样的表现。给每个会话一个家本质上是在给 Agent 搭建一个可持续运行的认知底座。5. 我最后想分享的一点经验整套方案跑下来我最深刻的体会是别指望 Agent 自己学会“记事情”。模型天生没有跨会话记忆工具也没有默认的归档逻辑这些都可以靠规则和目录结构补上。关键是你必须先想清楚结构然后强势地把结构植入到工作流里。我之所以把“会话数测试”“自定义指令”这些零零碎碎的需求都揉进这篇记录里是因为它们本质上指向同一个问题大家都在想办法让 Agent 记住自己做过什么。我个人的建议是从今天起就做一个最小实验挑一个正在进行的任务建一个目录写一份交接文档然后故意关掉会话重开一次看看 Agent 在读了 session-index 之后能不能接上。如果可以你大概就再也不想回到“每次开聊都从头讲起”的日子了。最后再分享一个小技巧任何项目里AGENTS.md 这个文件本身也要更新。不要只把背景和需求写在开头就再也不管技术决策、当前进度、踩坑记录这些动态信息持续回写Agent 才能真正做到“随叫随到、随到随懂”。