Claude Code Merge Queue 评测 2026：让并行智能体不再抢主分支

你在同一个仓库里跑起第二个 Claude Code 智能体的那一刻，就会冒出一类新 bug——而且它不在你的代码里。两个智能体同时 rebase，两个重量级构建抢 CPU，两个测试进程抢同一个端口。Claude Code Merge Queue 的存在就是让这些事在物理上不可能发生。

它是什么？

一个面向并行 Claude Code 智能体的本地、零成本合并队列。多个智能体同时落地、构建、测试时，队列把这些操作串行化，于是推送竞争、重复的重量级构建、共享资源导致的测试抖动都不会发生。

安装两条命令：

npm install --save-dev claude-code-merge-queue
npx claude-code-merge-queue init

init 会写入配置、CLAUDE.md、WorktreeCreate 钩子，以及 land / sync / promote / preview 几个脚本。

核心特性

• FIFO 落地队列——land 通过队列把当前 lane rebase 并推送到集成分支，保证任意时刻只有一个 lane 处于推送中。这条命令由智能体自己执行。
• 机器级构建锁——build-lock -- <cmd> 让你的构建在所有 lane 之间串行。
• 原生 Claude Code 钩子——WorktreeCreate 钩子把编号 lane（lane/1、lane/2……）接进 Claude 自己的 worktree 创建流程，每条 lane 分到独立端口（portBase + n）。
• pre-push 钩子让 land 变成强制项——直接 git push 到集成分支会被拒绝，并打印出应该执行的正确命令；同一个钩子会在放行前跑你的 checkCommand。没配 checkCommand 则默认所有推送都失败。
• promote 只允许人工——把集成分支发到生产这件事，文档明确规定绝不写进智能体指令、绝不自动化。
• preview——把某条 lane 的实时工作树（含未提交改动）瞬时镜像到你的主检出目录，不用构建就能看效果。
• 配置校验很吵——配置写错时，任何命令加载的那一刻就会把所有问题一次性列出来失败，而不是三步之后神秘地崩掉。

适合谁用？

如果你在同一个仓库上跑两个以上 Claude Code 智能体，这几乎是必备基础设施。如果只跑一个，那它纯属多余——根本没有需要串行的东西。

它和 wmux 天然互补：wmux 管编排（窗格、worktree、扇出），合并队列管落地。

对比 GitHub Merge Queue

项目自己给的对比很公道，值得复述：

	GitHub Merge Queue	Claude Code Merge Queue
私有仓库	仅企业云版	任意套餐、任意仓库
每次落地成本	每次尝试都烧 Actions 分钟数	$0——跑在你自己机器上
前置要求	必须有 PR	无——直接 rebase + push

同一个思路，只是跑在本地而不是别人计费的云上。由此也带来它真实的局限：因为跑在你的机器上，它串行的是这台机器上的 lane。它不是分布式团队合并队列，也没假装是。

优点与不足

优点： 消灭了一类真实存在的多智能体 bug；零运行时依赖；任意仓库（含私有）免费；安全默认值严格（没配检查命令就不许落地）；promote 刻意只留给人；配置校验大声报错；MIT 许可且带 CI。

不足： 仅单机，替代不了团队级合并队列；围绕 Claude Code 的 worktree 模型定制，而非通用 CI 队列；非常年轻（2026 年 7 月创建），fork 少、外部验证有限；必须接受它的 lane 与分支约定。

价格

免费开源（MIT），发布在 npm 上，零运行时依赖，需要 Node 18+。

常见问题

能配合 Claude Code 之外的智能体吗？ WorktreeCreate 钩子是 Claude Code 专属，但 land、build-lock、sync、preview 都是普通 CLI 命令，任何智能体或人都能调。

怎么防止智能体直推 main？ pre-push 钩子会拒绝，并打印应该执行的命令。有紧急出口，但需要明确写出具体分支名，而不是甩一个通用 flag。

必须开 PR 吗？ 不用。它直接 rebase 并推送——这正是它能在任意套餐、任意仓库上工作的原因。

它能发布到生产吗？ 只能由人来。promote 被文档明确定义为人工专属，并排除在智能体指令之外。