同一项工作可能跨过几个工具：在一个 Agent 里调研，在另一个工具里写代码，再用第三个入口整理资料。切换时最费力的部分，往往是重新交代项目进度、找回已经确认的决定，以及分清哪个文件才是最新成果。
第九期谈到，把工作资料集中到 Notion 或 GitHub 等自己选定的位置，再让不同 Agent 使用这些材料。讨论还区分了临时调用的子任务和持续保留的会话。这里的共同问题是：一次任务结束后，下一次工作能否找到足够的依据继续进行。
把决定和成果从聊天里取出来
聊天记录保留了讨论过程，却不一定适合作为下一次任务的唯一入口。一个决定可能被反复修改，最后确认的版本埋在很长的对话中。让下一个工具完整重读，既增加消耗，也可能把早已作废的要求重新带回来。
可以先留下几类简单材料：项目的当前目标、已经确认的决定、实际产物的位置，以及尚未完成的问题。比如网站更新完成后，记录上线地址、对应提交和仍在草稿中的文章；下一次修改就能从这些事实开始，而不必重建整段对话。
这些记录最好指向实际文件。写着视频已经导出，还需要对应文件和版本；写着某项测试通过，还需要知道检查的是哪一版。摘要负责帮助定位，原始材料负责支持核对。
共用资料需要知道哪些内容可以改
让多个 Agent 访问同一个目录，并不自动产生一致的上下文。假设一个工具还在按旧标题做封面，另一个工具已经修改了文章标题；如果两者都把自己的输出标成最终版，公共目录反而会增加混淆。
一种做法是把可修改的工作稿与已确认的交付物分开，任务开始时说明依据哪个版本，完成时更新当前记录。存在并行修改时，还需要检查冲突。使用 Git 的项目可以借助提交记录核对差异；不使用 Git 的资料，也需要有清楚的版本与恢复方式。
资料组织不必从大型数据库开始。项目很少时，一份索引加若干稳定路径就够用；当关系、状态和查询需求增长，再决定是否需要表格、数据库或专门的界面。节目里也出现了按需临时生成看板的想法，展示形式可以随任务变化，材料本身应当仍然找得到。
可迁移还包括权限和备份
把资料集中起来，会同时扩大一次错误操作可能影响的范围。只需要阅读背景的任务，不必获得整个资料库的修改权限；需要调用服务的工具，也不应因为共用上下文就默认获得全部凭据。
GitHub 的认证文档介绍了不同访问方式。实际接入时应按任务选择权限，避免把访问令牌写进会被其他工具读取的普通笔记。具体权限范围还要结合所用应用与接口确认。
可迁移也不能只靠一个远端账号。保存一份能实际恢复的资料副本，明确哪些内容只存在平台内部，比单纯把所有文件搬到同一个服务更有用。备份是否成功，要看能否找回需要的内容，而不只是同步图标有没有变绿。
用一次切换检验组织方式
可以选择一项已经完成的小任务，让另一个工具仅凭项目索引、当前决定和成果文件继续修改。检查它是否能找到正确版本，是否还需要重复询问已经确认的事情，以及是否把历史草稿误当成现状。
这次试验若暴露缺口，就补足缺少的记录，而不是把全部聊天无限追加到下一次提示里。值得积累的上下文，是下一次工作确实能使用、能核对，也能在事实改变后修正的材料。