我们在108个由智能体编写的拉取请求上启用了自动合并。只有一个合并了。

一天晚上，一个控制会话在十个仓库的大约108个拉取请求上启用了自动合并，然后静默了。到早上，只有一个合并成功。智能体们已经起草了更改，在本地检查过，推送了它们，并启用了自动合并。根据它们自己的统计，它们完成了一个富有成效的班次。它们不理解的是从完成差异到合并提交之间的机制。大多数拉取请求处于失败状态。失败来自一个被突发流量饱和的共享CI运行器池。在我们最繁忙的仓库中，一次推送可以创建数十个小检查作业，每个作业占用一个运行器并克隆仓库以执行几秒钟的工作。足够多的智能体紧密推送创建了池无法消化的积压。更奇怪的部分后来才出现。一旦运行器恢复，红色的拉取请求仍然是红色的。自动合并只是一个条件。它不会重试失败的检查。一个红色的拉取请求是惰性的，直到有人重新运行失败的作业或创建新提交。然后我们的自动化系统花了大约五个小时仔细监控一个无法移动的队列。一旦开始主动分类，四个更改在大约四十分钟内合并了。它们的代码没有改变。过时的CI失败只是被重新运行。教训是编码智能体使创作成本大大降低，但没有增加落地能力。我们测量的是创建的工作量，而不是被共享分支接受的更改。打开的拉取请求看起来很好。合并的拉取请求揭示了真相。这改变了我对智能体吞吐量的思考方式。系统不能只针对完成的任务、产生的差异或打开的拉取请求进行优化。它需要理解运行器容量、必要检查成本、过时失败、依赖链、合并队列和每小时实际合并数。否则，智能体产生的库存速度超过了落地层的吸收能力。你的智能体不发布代码。你的CI和合并控制系统才发布代码。还有其他人测量过他们的仓库每小时实际能落地多少由智能体生成的更改，而不是智能体能写多少吗？