开发者现在可以同时启动多个编码代理 (coding-agent) 会话，而无需担心状态文件被覆盖或隐藏的文件冲突。一种“无共享” (share-nothing) 的建议模式 (advisory pattern) 可以隔离每个代理的工作区，并对潜在冲突发出警告。该方法用轻量级注册表取代了硬锁 (hard locks)，在冲突发生前标记重叠的工作，即使在会话崩溃时也能保持流水线持续运行。
为什么并行代理会出错
在单个代码库中运行多个自动化编码助手可以加快代码生成、测试或重构的速度。但在实践中，会立即出现两个问题。
- 状态损坏 – 两个代理向同一个状态文件写入数据；后一次写入会覆盖前一次，从而抹除进度。
- 文件冲突 – 两个代理在互不知情的情况下编辑同一个源文件。冲突会在稍后通过 diff 显示出差异化更改时才显现出来。
这两个问题都会浪费开发者的时间，并可能引入难以追踪的 bug。
“无共享”规则
核心思想很简单：每个代理在磁盘上都有自己的私有暂存区 (scratchpad)，并且只向属于该会话的文件写入内容。每个分支仅允许一个刻意共享的文件，并且遵循“最后写入者胜” (last-writer-wins) 规则——最后写入的代理将决定最终内容。
一个存在层 (presence layer) 会跟踪每个活动的会话：
- 分支名称
- 正在操作的文件列表
- 最后一次活动的时间戳
当新会话启动时，它会查询注册表。如果另一个会话已经在处理任何相同的文件，开发者会在开始任何工作之前收到警告。
建议性锁 vs. 阻塞性锁
传统的锁文件就像死胡同：一旦锁被占用，任何其他进程都必须等待，直到锁被释放。如果持有锁的会话崩溃，锁可能会无限期地残留，迫使开发者手动寻找过期的锁文件。
建议模型则更加温和。它在检测到潜在冲突时发出警告，但不会停止新会话。如果注册表条目已过期（即创建它的进程已不存在），系统仍然仅发出警告，让开发者决定是否继续。
如何实现该模式
- 按写入者划分状态 – 为每个代理分配独立的临时文件和状态目录。仅为真正的全局数据保留共享文件，并仅在那里应用“最后写入者胜”规则。
- 在启动时注入感知能力 – 在代理开始工作之前，读取存在注册表，并将请求的文件列表与现有条目进行比较。如果发现重叠，则中止或发出警告。
- 在读取时验证存活性 – 在查询注册表条目时，检查记录的进程 ID 是否仍在操作系统中运行。丢弃属于已终止进程的条目。
- 优先选择建议性而非阻塞性 – 让开发者保留控制权。警告可以让开发者选择继续、暂停或取消，从而避免死锁。
- 跟踪等待状态 – 当有许多代理处于活动状态时，开发者的注意力会成为瓶颈。显示哪些代理正在等待人工输入，以便重新安排工作优先级。
所有这些都可以通过一个简单的 JSON 文件目录来实现；不需要外部数据库或消息总线。简单的存储格式使系统易于审计，并且可以在不同环境中移植。
风险与反论
一些团队可能会认为硬锁可以保证安全性：没有任何两个代理可以写入同一个文件。但代价是降低了韧性——崩溃的会话会留下孤立的锁，从而导致整个工作流停滞。
注意事项
如果你正在同时使用多个 AI 驱动的编码助手，“无共享”建议模式提供了一种务实的途径，防止它们相互干扰。通过隔离状态、尽早暴露意图并让开发者决定何时继续，该方法在安全性与现代开发流水线所需的灵活性之间取得了平衡。