一个人和多个 Agent 会话的分工
实战手记第 02 篇
上一篇讲了单个 Agent 会话怎样把一件事做完。真实的工作日不是这样的：上午一个会话在给私有化语音服务打交付包，另一个在云平台上跑发布后回归，第三个在修会议纪要应用的界面，我自己在几个终端之间来回切换，回答它们的问题、批准它们的操作。
同时开多个会话以后，最先暴露的问题不是模型不够聪明，而是两件很朴素的事：会话结束以后它知道的事情去了哪里，以及两个会话改到同一个仓库时怎样不互相踩。这一篇讲我的做法。读完你应该能为自己的多会话工作设计一套交接方式，并知道哪类信息该写在哪里。
一个项目一个会话
我的基本习惯是一个项目、一条工作线开一个会话。云平台的国内区域迁移是一条线，私有化识别的交付是一条线，博客和作品集是一条线。会话里积累的是这条线的上下文：读过哪些文件，试过哪些方案，哪些已经验证、哪些还没有。
两类工具我都在用。Codex 跑大部分长任务，Claude Code 接手其中一部分；有时一条线上两边轮流推进，一个会话做到一半，另一个工具里的会话接着做。这就要求交接不能依赖任何一个工具自带的记忆，而要落在两边都能读到的地方。
会话会结束，事实要写到更持久的地方
会话的上下文有寿命。对话太长时，工具会压缩早先的内容，细节会丢；会话关掉，上下文就没了。所以我把信息分成四层存放。
最上面是会话上下文，只活到会话结束，不指望它保存任何东西。
第二层是仓库内的文档：AGENTS.md 写项目规则，HANDOFF.md 写当前进度和接手须知，docs/ 下按日期存验收记录。它们跟着 git 走，换一台电脑、换一个工具，读到的都是同一份。会议纪要项目的 docs/ 下有约 40 份带日期的验收文档，语音交互平台有 61 份；全双工语音服务的 HANDOFF.md 开头直接写明读者是“接手的 agent（Claude、Codex）和同事”，每完成一个阶段更新一次。
第三层是本机知识笔记。跨项目的经验，比如博客怎样发布、GitLab 怎样升级、私有化包怎样打，放在一个笔记目录里，目前 57 篇，由一份 INDEX.md 索引。索引把最新状态写在最前面并带上日期和时间，旧结论明确标成历史。每个会话开始做部署、交付这类重复性工作之前，先读索引，只加载相关的那一篇。
第四层是个人记忆：偏好、红线和指针。比如“回复用中文”“作品集源头在另一个仓库，改了要回写”。它只指向前三层，不重复事实，因为重复的事实迟早会和源头不一致。
还有一条贯穿四层的规则：哪一层都不放密钥。笔记里写“密钥在哪里、怎么取”，不写密钥本身。
交接写什么
交接文档最容易写成流水账：“先试了 A，失败了，又试了 B……”。接手的会话读完这些，还是不知道现在该做什么。我要求交接只写三件事：结论、位置、待办。
云平台迁移时，一个 Claude Code 会话从 Codex 会话手里接过国内区域的工作，交接笔记的开头就是这三段：哪些服务已经在测试环境通过、哪些还没有；代码在哪个分支、验收报告在哪个目录；接下来要处理的事项。失败的尝试也会保留，但作为“反例”单独列出，并写清楚失败原因是方法本身不行，还是当时的环境不对。
还有一个细节：交接笔记把结论标为“记录时的状态”，接手的会话必须先核对线上现状再行动。笔记写着某个服务已部署，可能在那之后被别人回滚过。
两个会话改同一个仓库
10 月 23 日，两个会话同时在改博客仓库：一个在写一篇 Agent 长任务的文章，另一个在更新项目案例。后者提交时把暂存区里属于前者、还没准备好的文件一起提交了。
这件事之后，博客仓库加了三条规则：
- 每个会话只提交自己改过的路径，用
git commit -- <路径>明确列出文件。 - 发布时从目标提交建一个独立的
git worktree，在里面构建，不在混着别人草稿的主工作区里构建。 - 发布前比较线上文件清单和构建产物：线上有而构建没有的文件，说明会被误删，停止发布；发布后反过来比较，构建有而线上原来没有的文件，说明夹带了不该发布的页面。
GPU 也是共享资源。全双工语音服务调试时，多个会话需要同一台 GPU 服务器做压测，项目的交接文档规定：用之前向协调会话申请一个不超过 20 分钟的时段，用完报告“GPU 已释放”。规则写在仓库里，每个接手的会话都能看到。
总结
多会话工作的瓶颈在信息的寿命，而不在模型的能力。会话上下文会消失，所以事实要写进仓库文档或知识笔记；交接只写结论、位置和待办，并要求接手者先核对现状；多个会话共享仓库和机器时，提交范围、构建环境和资源占用都要有明确规则。
这些规则本身写在哪里、怎样让每个会话都遵守？下一篇讲 AGENTS.md、技能和单次授权。