作者：林岚｜OC 开发者生态编辑

Depot 认为，GitHub 以人类开发者逐个创建 PR、等待审查和 CI 的协作模型，难以承受代码 Agent 带来的高提交吞吐。开源项目 claude-code-merge-queue 则尝试在本地把多个 Claude Code 分支的拉取、构建、测试和同步串行化。

一句话结论：代码生成速度提高后，最先爆满的不是 Git 仓库容量，而是共享构建环境、测试端口、审查注意力和主分支更新顺序。

人类团队一天提交有限数量 PR，失败后会阅读日志、协调重试。多个 Agent 可以在几分钟内同时完成任务，每个分支都触发完整构建。它们修改相邻文件、争用同一个预览端口，还可能基于已经落后的主分支继续工作。

合并队列的作用是把最终验证放在可控顺序中：先同步最新主分支，再构建和测试，通过后才推送下一个分支。这样可以减少两个单独通过测试的 PR 合并后彼此冲突，也避免十个 Agent 同时占满本地 CPU 和 CI 配额。

claude-code-merge-queue 强调本地、零额外服务成本和自定义分支、端口与构建命令。它适合单机或小团队实验，却不能替代 GitHub 的权限、审查和受保护分支。自动重基和直接推送如果配置错误，反而会把 Agent 的错误更快送进主分支。

Depot 的观点更激进：未来工具链需要把源代码、执行环境和工件当作高吞吐基础原语。问题不在 GitHub 必须消失，而是以“一个 PR 页面等一个人点通过”为中心的流程，需要增加机器可读的验收和资源调度。

关键事实

• 来源：Depot 工程博客、claude-code-merge-queue 仓库
• 涉及平台：GitHub、Claude Code、本地 CI
• 核心技术：合并队列、重基、构建序列化、预览端口、分支保护
• 项目许可：claude-code-merge-queue 采用 MIT 许可证

OC 判断

多 Agent 开发的瓶颈正在从写代码转向验收。团队应该先明确哪些测试可以并行、哪些资源必须串行，以及谁有最终合并权限。没有稳定验收链，增加 Agent 数量只会把等待队列和错误一起放大。

为什么重要

• 对开发者：本地队列能减少资源争用，但要保留人工审查与回滚。
• 对平台：CI 计费、预览环境和合并策略需要适应机器级提交频率。
• 对团队：性能指标应从“生成多少代码”转向“多少变更安全进入生产”。

参考来源

• GitHub is the wrong shape for this new world
• claude-code-merge-queue