实测显示并行编程AI代理提速有限，仅约为单代理1.5倍

2026年11月9日发布 阅读时长14分钟

本文内容

在同一个代码库上工作的并行编码 agent，吞吐量大约只有单个 agent 的1.5倍，而不是 N 个 agent 就有 N 倍。2026年7月2日至11月7日期间，我在 Stackness 仓库中对 Claude Code 的364次任务运行做了计时，平均同时有1.21个 agent 在工作。我最忙的四天开了两条 lane、最多四个 agent 同时跑，峰值达到1.46。11月6日引发讨论的那次运行——106个任务、六个 agent——测得1.82。

所以不管 agent 数量是多少，都按1.2到1.8倍来规划。agent 会等待测试套件、等待彼此的文件、等待合并，而并行的一周里大多数时间根本没有 agent 在跑，因为下一个任务在等我 review diff。多加一条 lane，还不如把已有的 lane 早点合并。

在我能找到数据的真实项目里，并行编码 agent 比单个 agent 快1.2到3倍，而在所有把测试时间计入计时的运行中都不足2倍。更快的数字要么来自不计测试时间的 benchmark，要么来自从不合并的搜索分支。下表列出截至2026年11月9日已公布的、把 wall clock 时间与同一批工作在单个 agent 上所需时间做对比的数字。

有效并行度等于 agent 小时数除以至少有一个 agent 在运行的小时数。它衡量的是相对于一个 agent 依次完成同样任务的加速比。我的1.46没有算合并，而 mythical-agent-month 的1.82已经计入了它的96次合并运行。一次1.82的六 agent 运行只用了上限的30%，mythical-agent-month 仓库的经验法则“有效并行度 ≈ 0.3 × 你的 agent 上限”就来自这里。

这个话题背后的帖子是2026年11月6日发在 r/vibecoding 上的“Claude 报价50天，subagent 35小时做完，慢的部分是我”，它一句话说清了：“6个 agent ≠ 6倍速度。真实吞吐是1.8个 agent。”正如一位评论者指出的，它的标题是拿估算值和一次运行做比较，所以“50天到35小时”不是加速比。1.82来自398份 subagent transcript 中读出的、35.3个忙碌小时里完成的64.2个 agent 小时工作量。Cursor 自己的团队后来对同一个20-agent 实验给出的数字是“1-3”。

我最忙的并行时段同时运行1.46个 agent。2026年10月11日至15日，一个 git worktree 构建了21个组织相关任务，主 checkout 构建了另外20个，两者都通过同一个 Claude Code 任务命令执行。合计41次运行、55.2个 agent 小时、37.9个忙碌小时，窗口跨度94小时。把合并花掉的56分钟加进忙碌小时，数字变成1.42。

我仓库里的每个任务都通过 /rock 运行，这是我自己写的一个 Claude Code 命令，它实现一个任务、运行完整检查套件、做安全审查、更新端到端场景并提交。/work 运行一批任务，由一个只读的 prep agent 提前读取下一个任务，/wt 在它自己的 git worktree 中启动一批任务，配有自己的 PostgreSQL 数据库、Redis 数据库和端口。每次运行都会写一份计时报告。我把364份报告和 git log 做了关联：一次运行在其 commit 落地时结束，其 wall time 从更早的时间开始算。

四个 agent 同时跑了大约九分钟。整个窗口有60%的时间没有任何 agent 在跑，共19段空档，其中七段超过两小时，最长的一段12.9小时。这七段里有五段发生在夜间，两段在白天，较长的那段是某个周二的七个小时。一个 /work 批次会背靠背地运行任务，在批次结束或某个任务因需要我回答问题而暂停时停下，所以每段空档都是一条 lane 在等我回答或启动下一批。那位 Reddit 发帖人对自己的运行也写了同样的话：“最慢的部分是我们：review、决策、本地环境搭建。”

自7月以来全部364次运行的数字是1.21，因为大多数周我只跑一条 lane。worktree lane 我跑过三次，都在10月，1.46来自其中最长的一次。

合并是并行 lane 偿还它借来的时间的地方。我10月那个 worktree 在10月15日完成了最后一个任务，直到11月8日才合并进 stage，晚了24天。那时 stage 已有96个新 commit，而 worktree 是46个。Git 无法自行合并92个文件，解决它们花了 Claude Code 一个会话56分钟和四次完整检查运行。

那次合并的四次检查运行依次失败于15个 lint 和格式错误、3个包里的8个 Go 测试、11,541个前端测试中的15个，第四次才通过。没有一次失败是文本冲突。worktree 开着期间，stage 引入了新的全站规则、一次采用新配色和字号体系的改版，以及一条要求每个页面声明自己社交卡片 URL 的规则，每条都由测试强制。worktree 的新页面破坏了它们编写时尚不存在的测试，而一个带固定日期的测试 fixture 在分支等待期间过期了。

没有任何东西强迫等这24天：是我在 stage 继续前进时把 worktree 一直开着。一条 lane 开得越久，它需要吸收的另一条 lane 的变更就越多，合并成本也随之增长。mythical-agent-month 那次运行则相反，它不停合并：96次合并运行，只在 per-repo 锁之后做 fast-forward，总共2.2小时。它的锁本身也有代价。按 lane 加锁把其最忙的仓库串行化了，仓库日志里记作“某个阶段大部分时间处于1×并行度”。它把后来从1.7降到1.4归因于“磁盘压力、Docker 重启和用量限制”。

共享机器是合并之后的下一道队列。在我的仓库里，没有其他 agent 运行时 make check 的中位耗时是2.12分钟，当另一次运行与任务重叠至少一半时是2.90分钟。对于涉及最多25个文件的任务，耗时从1.81分钟增至2.48分钟，长了37%；对于25到60个文件的任务，从2.30分钟增至3.54分钟，长了54%。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）