一、首版流程
- 严格串行
- 直到前一个 PR 合并成功，才会触发下一个 PR 的 agent
这样做是为了每一个新 issue 的开发都是站在前一个开发好的基础之上，从源头上避免冲突的产生。既然相互间不会产生冲突，那就不需要冲突处理的机制了。
但是这样做的后果就是效率很低，每次只能处理一个 PR。
二、优化
这样的流程走第一次的时候，我就认为需要进行优化，因为等待的时间很明显，这个还有很大的改进空间。
因为现在 agent 处理多分支冲突的能力很强，并且很多时候我本地遇到 remote 和 local 依赖的情况，也是直接让 agent 去处理的。 它处理完提交，我本地运行下测试套件，完全没有问题。
依据上面这个情况
- 假设有 10 个 issue
- 我同时起 10 个 agent 去分别处理
- 拿到了 10 个 pr
- 专门起一个 agent 去处理这些 pr 的合并（这一步是新增的）
遇到排队的情况下 一处分出多个枝条 多个枝条再合并为一处 合并这个动作再用一次 agent 专门用来合并多个 PR 这样的话 就不用再去等待了
这个情况，repo 锁还需要吗？似乎没有存在的必要了。
