企业官网建设流程全解析

前阵子我一直在为 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 的潜力很大，但它是彻底的“被动记忆者”。你给它什么样的工作环境，它就会回馈给你什么样的表现。给每个会话一个家，本质上是在给 Agent 搭建一个可持续运行的认知底座。

5. 我最后想分享的一点经验

整套方案跑下来，我最深刻的体会是：别指望 Agent 自己学会“记事情”。模型天生没有跨会话记忆，工具也没有默认的归档逻辑，这些都可以靠规则和目录结构补上。关键是你必须先想清楚结构，然后强势地把结构植入到工作流里。我之所以把“会话数测试”“自定义指令”这些零零碎碎的需求都揉进这篇记录里，是因为它们本质上指向同一个问题：大家都在想办法让 Agent 记住自己做过什么。

我个人的建议，是从今天起就做一个最小实验：挑一个正在进行的任务，建一个目录，写一份交接文档，然后故意关掉会话重开一次，看看 Agent 在读了 session-index 之后能不能接上。如果可以，你大概就再也不想回到“每次开聊都从头讲起”的日子了。最后再分享一个小技巧：任何项目里，AGENTS.md 这个文件本身也要更新。不要只把背景和需求写在开头就再也不管，技术决策、当前进度、踩坑记录这些动态信息持续回写，Agent 才能真正做到“随叫随到、随到随懂”。