Braidkeep

我用多个并行运行的 Claude Code agents 来构建——每个都在自己的 git worktree 中，每个都在自己的分支上。配套的工具已经很成熟了：Claude Squad、Conductor、Vibe Kanban 都能防止 agents 在工作时互相干扰。

但当工作成果需要重新汇合时，却没有任何工具能帮上忙。你要等所有 agent 都完成之后，挨个尝试合并分支时，才会发现有两条分支冲突。审查成了我的瓶颈，而不是生成。

所以我做了 Braidkeep。三件事：

它能预测。它对每一对在飞分支都运行 git merge-tree——只读、在内存中执行，绝不触碰你的工作区——然后展示一张实时的冲突矩阵。当某个 agent 提交时，矩阵会更新，某个单元格就会翻转。

它能约束范围。你可以在 braidkeep.yaml 中声明每个 agent 拥有哪些文件。一个 Claude Code 钩子会在写入时拦截越界编辑；一项 CI 检查则无论 agent 是如何被调用的，都会捕获到越界情况。

它能排序。它会找出彼此之间零冲突的分支集合（可以现在就按任意顺序合并），并把剩下纠缠不清的部分按冲突从少到多排序，让你最后才去解决那些困难的合并，此时你也拥有最多的上下文。

两点坦率的提醒，因为你自己也会发现：

它预测的是可合并性，而不是正确性。如果一个 agent 重命名了一个函数，另一个 agent 在另一个文件里调用了旧名字，git 会干净地合并，Braidkeep 也会显示干净。语义冲突检测是一个难得多的问题，我并没有声称自己已经解决了它。

还有，合并批次是精确的，但排序是一种贪心启发式——最优排序是 NP-hard 问题。

它是 Apache-2.0 协议，完全免费。没有云端套餐，没有注册，单个二进制文件就能跑。

有一点我得承认：Braidkeep 本身就是由五个并行 agent 在各自独立的 worktree 中构建的，它自己的 CI 会在每个 PR 上运行 braidkeep check——所以如果任何工作流偏离了它声明的范围，构建就会失败。它没有失败。这是我能给出的最接近真实测试的东西。

你最糟糕的并行 agent 合并经历是什么？我想知道我还有哪些冲突形态没有覆盖到。