并行编程智能体的共享磁盘隐患

多个 AI 编程会话同时干活，最先出问题的可能不是上下文或 token 开销，而是它们正在改同一块磁盘。作者曾为一份来历不明的 diff 排查了一个小时，于是做了一个极简告警，观察哪些仓库从干净变成了有改动。

运行约一周后，告警没有抓到 agent 越界，反倒让作者发现：真正打乱工作区的是自己。这篇经验值得读的地方，是把并行编程的风险落到了目录、分支和人的操作上，也交代了防护措施的成本。

会话各自独立，工作目录却未必隔离

作者忙的时候，一台机器上会同时跑十来个 agent 会话，各自处理不同项目。任务和对话可以分开，磁盘却是共享的。

一个会话可能进入另一个项目的 checkout，修改其他会话正在处理的文件，也可能切换共享目录的分支。checkout 在这里可以理解为磁盘上的那份 Git 工作目录：两个进程站在同一个目录里，看到的文件和当前分支就是同一套状态。

麻烦在于，这类干扰发生时通常没有明显提示。等人回来检查，才看到一份不认识的 diff，还得倒查是谁、什么时候、为什么改的。

对话彼此独立，不等于文件操作彼此隔离。

作者没有提供越界发生的频率，也没有证明某种 agent 更容易犯错。他指出的是一个成立的前提：只要多个进程能够写入同一目录，就存在互相干扰的可能。

一个只响一次的告警，究竟能证明什么

作者的做法很简单：先记录工作区内每个 checkout 的基线状态，再观察原本干净的仓库有没有变脏。一旦发生变化，就报告仓库名和分支，而且只报一次。

下面这段输出用来提示哪些仓库开始出现改动：

TRAMPLED: keryx was clean, now 1 changes on fix/npm-audit-advisories
TRAMPLED: skillup was clean, now 18 changes on master

要看的是每行的仓库、改动数量和分支；TRAMPLED 只是告警标签，不能据此认定发生了踩踏。

它没有锁，没有权限模型，也不判断谁能修改哪里，更无法阻止写入。它提供的是一个检查入口：哪些地方动了，需不需要过去看看。

只提醒一次，也是有意取舍。作者担心，逐次播报所有变化会迅速制造噪声，最后被人静音。不过这属于他的判断，原文没有给出不同告警策略的对照实验。

约一周里，告警涉及五个仓库，分别是 CI 修改、skills 更新、audit 修复、master 分支上的十八处变化，以及基础设施功能。检查之后，每项都是会话在指定仓库里完成已授权任务。

所以，这次观察没有验证告警抓越界的能力。它验证的是另一种用途：把「是不是有人互相踩了」变成可以查看的具体状态。

worktree 能隔开任务，清理时仍然会出问题

作者把预防放在告警前面。他制定的规则是：会话需要在启动时指定的仓库之外工作，就从最新 main 创建专用的 git worktree，不要直接使用共享 checkout。

git worktree 可以让同一个仓库拥有多个工作目录。两个会话分别在自己的目录和分支里操作，就能减少共享目录内切分支、改同一份文件造成的干扰。

这里有两个边界。第一，原文针对的是「进入其他仓库工作」的规则，没有完整说明所有并发任务如何分配目录。第二，规则后来写成了供会话加载的 skill，它仍然依赖执行者遵守，不是文件系统层面的强制隔离。

隔离还有维护成本。任务结束、会话退出之后，worktree 的登记可能继续留着。作者提到，同一时间段内有两个会话花了实际时间清理废弃 worktree，但没有给出具体耗时或自动回收方案。

更有意思的是，工作区里那些无法归因的删除、重命名和移动，最后查出来是作者自己做的。他一边让十来个自动化进程工作，一边手动整理目录，却没有告诉它们。

需要遵守工作区边界的，也包括坐在键盘前的人。

那个告警最终随启动它的会话一起结束，既没有常驻运行，也没有留下脚本。作者估计，重新写一个大约需要十分钟。真正保留下来的是 worktree 规则。

我的判断

我认同这篇文章把目录隔离放在前面的选择。对于同时运行多个编程会话的人，先明确每个任务在哪里改文件，比事后凭记忆认领 diff 更可靠。

但它提供的是小规模经验：约一周、五个发生变化的仓库，没有抓到 agent 越界，也没有比较采用规则前后的事故数量。因此，不能把它读成 worktree 已经被证明能杜绝冲突，更不能把零事故归因于那条规则。

这个告警的盲区也很明确。按原文描述，它关注的是「基线干净，后来变脏」；启动时已经有改动的仓库，未必能被同样覆盖。它也无法直接回答改动属于哪个会话，分支切换是否单独触发告警，原文没有说清。

与每个任务单独 clone、使用容器或限制目录写权限相比，worktree 适合先解决同仓库多任务的目录与分支分离问题，部署负担较小，但不提供同等级的权限边界。具体选哪种，要看团队需要防的是误操作，还是必须强制限制的访问。

能拿来做什么

• 同时让多个 AI 会话处理前端或 Node 项目时，先给每个任务指定工作目录和分支；需要进入其他仓库时，可以采用作者从最新 main 创建专用 worktree 的规则。
• 如果经常遇到来历不明的 diff，可以先做一次临时观察，记录干净仓库何时出现改动；把告警当作排查入口，随后核对任务归属。
• 把 worktree 清理纳入任务收尾，先确认相关会话已经结束，再处理目录和登记；有人正在工作时，也应避免直接跨项目移动或重命名目录。