我两个代理的 git 工作树的干净合并，但它自身的测试失败了

十次合并。五次返回了冲突标记。另外五次合并是干净的，但这五次都在合并树上失败了测试套件。每个二十个工作树在它的代理停止时都是绿色的。设置：一个150行的 Python CLI 有四个测试，一个基础提交，两个分支上的两个工作树，两个代理同时启动，任务从不提及彼此。五对任务，每对运行两次。在每一对中，第二个任务都静默地依赖于第一个任务更改的内容：一个代理将 done 重命名为 completed，而另一个代理编写一个读取它的 stats 命令；一个将 store 文件包装在版本化的对象中，而另一个添加 import；一个将整数 id 替换为 hex，而另一个添加 edit ID --title。两者都得到相同的指令，在停止前运行测试，两者都做到了。git 对两个分支的操作是比较每个文件与公共祖先的区域。只有一方触及的区域逐字放入。它不知道字段名是什么。因此，在五次干净合并中，stats 从现在写 completed 的 store 中读取 n["done"]，importer 拒绝了 store 新版本化的文件，edit 因 hex id 的 "invalid int value" 而失败。失败的测试总是代理 B 自己的测试，未更改，几分钟前在 B 自己的工作树中还是绿色的。在所有五次干净合并中，两个代理都编辑了至少一个相同的文件，在不同的区域，所以 git 没有话说。让我困惑的一点：id 对，运行两次。第一次运行，代理 B 在其 edit 子解析器中将其放置在代理 A 编辑位置的上方一行，git 合并了。第二次运行，B 将其直接放在该行下方，git 标记了三个文件。我是得到冲突标记还是红色套件取决于模型将代码块放在哪里。有人在十五年前在三个带有测试套件的开源项目上重放了1,694次人类合并：76% 干净，16% 文本冲突，1% 合并干净但破坏了构建，6% 合并干净但测试失败。它发现的三分之一冲突是版本控制系统称为干净的。那是人类，他们至少可以互相询问。我的两个代理无法读取彼此的工作树。这正是工作树的意义。这也是确切的问题。当你并行运行代理时，实际上谁在信任之前运行合并树？