并行编码Agent不是5倍速：你才是真正的瓶颈

早上九点，五个Agent同时启动

想象一个场景。早上9:00，你在五个worktree、五个终端里启动了五个编码Agent，每个负责一个任务。四十分钟后：两个已经完成，等待你review；一个在9:15报错卡住；一个在9:07问你关于数据库schema的问题，从此再无动静；第五个据你所知还在运行。

那个问问题的Agent，花了33分钟等你去注意到它的提问。延迟与打字速度无关——你有五个地方要看，但你只有一双眼睛。

工具让启动Agent变得极其廉价。Claude Code的agent view列出了你启动过的所有后台会话，跨所有项目。Cursor 2.0在2025年10月29日发布了管理Agent的侧边栏，以及"在单个prompt上并行运行多达八个Agent"的选项。启动Agent很便宜，但这些都没让你读diff的速度变快。

Simon Willison在记录自己的并行Agent配置时，用一句话点出了极限："所有这一切的天然瓶颈，是我review结果的速度。"他仍然跑多个Agent，但他对自己从中获得什么非常精确："我一次只能集中精力review和落地一个有意义的变更。"并行确实能买到的，是更多低负载工作同时运行——尤其是调研和概念验证。

这才是并行Agent宣传的诚实版本。五个Agent给你五个工人。它们不会给你五个reviewer、五个回答"我该删掉这一列吗？"的人，或者五个批准shell命令的人。这些人只有一个，就是你。

队列数学不站在你这边

每个Agent都在同一个循环里打转：工作，被问题或权限弹窗阻塞，等你，再工作。等待期间它什么都不做，但时钟一直在跑。

排队论里有两个结论非常契合这个场景。Little's law说，稳定系统中平均项目数等于到达率乘以每个项目停留的平均时间：L = λW。用Agent来读：闲置等你回应的Agent数，等于它们向你提问的频率乘以每个等待回答的时间。跑更多Agent，λ上升。如果W不下降，任意时刻就有更多Agent闲置。

Kingman's formula估算单服务器队列的等待时间。它的第一个因子是ρ/(1−ρ)，ρ是服务器的忙碌程度。你就是那个服务器。50%忙碌时因子是1，80%是4，90%是9。等待在低负载时爬升缓慢，接近顶部时急剧上升。

公式的第二个因子在到达时间扎堆时增长，而Agent提问倾向于扎堆。同一分钟启动的五个Agent，可能几乎同时到达各自的第一个决策点。

这是一个粗略模型。人不是有固定服务速率的服务器，但形状成立：你加的第五个Agent，比第二个让你多等的更多。

Little's law（利特尔法则）由麻省理工学院教授John Little于1961年证明，是排队论中最基础也最稳健的结论之一：在一个稳定的系统中，系统中的平均项目数L等于到达率λ乘以每个项目在系统中停留的平均时间W，即L = λW。它的巧妙之处在于几乎不依赖任何分布假设——不管服务时间服从指数分布还是任意分布，只要系统处于稳定状态，这个关系就成立。因此它被广泛用于呼叫中心、医院急诊、制造流水线和网络流量分析。应用到并行Agent场景，你把"到达率"理解为Agent向你提问的频率，"停留时间"理解为每个Agent等待你回应的时间，乘积就是任意时刻闲置等待你的Agent平均数。这意味着：在响应速度不变的情况下，Agent数量翻倍，闲置等待你的Agent数大致也翻倍，而不是保持不变。

Kingman's formula（金曼公式）是1961年由英国数学家John Kingman提出的近似公式，用于估算单服务器排队系统（GI/G/1队列）的平均等待时间。它把等待时间分解为多个因子相乘，其中最关键的一项就是ρ/(1−ρ)，ρ代表服务器的利用率（即忙碌程度的比例）。当利用率从50%升到80%，这一因子从1跳到4；当逼近95%时，它达到19，等待时间呈爆炸式增长。公式的另一个因子反映了到达时间和服务时间的波动性：到达越扎堆，等待越长。这解释了为什么在人力（单服务器）固定的前提下，简单增加Agent数量会导致等待时间非线性恶化——你不断把利用率推向高位，而高位正是等待增长最快的区域。

每次切换的成本远不止回答

这个模型把回答问题当作固定成本。并非如此，因为每个回答都从回忆那个Agent在干什么开始。

Chris Parnin和Spencer Rugaber专门研究过程序员这个问题。在《Resumption Strategies for Interrupted Programming Tasks》中，他们分析了85位程序员的10000次录制编程会话。他们发现"只有10%的编程会话在一分钟以内开始编码活动"，且只有7%的会话在编辑前没有导航到代码其他位置。回到一个任务通常意味着先在代码里走一圈来重建上下文。

有五个Agent时，你整天都在做这件事。Agent 2的问题关于你四十分钟前才想过的schema。Agent 4的diff触及你本周还没打开过的模块。每一次跳转都要重新支付恢复成本。而且那项研究测量的是程序员回到自己的代码；Agent的diff是别人的代码，很少更容易。

这里还有一个陷阱。Gloria Mark、Daniela Gudith和Ulrich Klocke在CHI 2008的《The Cost of Interrupted Work: More Speed and Stress》中测试了被打断的工作。人们用更少时间完成了被打断的任务，质量没有差异，但摘要道出了代价："人们通过更快工作来补偿打断，但这有代价：经历更多压力、更高挫败感、时间压力和努力。"

那项研究针对的是办公室任务。我对Agent的担忧是"更快工作"会变成什么。是更快批准。是扫一眼权限提示。是合并你只读了一半的diff。队列变短了，你却在压力或review质量上付账。

Chris Parnin和Spencer Rugaber的研究发表在2009年IEEE国际程序理解会议（ICPC）上，他们通过录制85位程序员、累计约10000次编程会话，系统分析了程序员被打断后如何恢复任务。核心发现是：恢复一个被打断的编程任务并非瞬间完成，而是需要一系列"导航动作"——重新打开文件、滚动到相关位置、重新阅读上下文、重建对问题的心智模型。只有约10%的会话能在中断后一分钟内重新开始编码，只有7%的会话在编辑前没有先导航到代码其他位置。这意味着恢复成本本质上是"上下文重建成本"，它与你离开该任务的时间长短、以及你对那段代码的熟悉程度高度相关。对多Agent场景而言，这个成本意味着每次切换都相当于重新"冷启动"你的工作记忆。

限制Agent数量，然后先服务等最久的

只跑你能review的数量。 不是你的机器、你的套餐或你的工具允许的数量。如果你一次只能review一个有意义的变更——正如Willison对自己的描述——那么对你打算合并的代码而言，一到两个Agent就是你的数字，再加上你能忽略一小时的调研任务。其他都进队列，某个槽位空出时下一个任务才开始。这也节省配额。Claude Code的agent view文档指出"并行运行十个Agent消耗配额的速度大约是运行一个的十倍"。

先解阻塞，再review，且先解锁等最久的。 一个已完成的Agent，工作已经在磁盘上。再等十分钟毫无损失。一个被阻塞的Agent，这十分钟全丢了。所以先解阻塞：回答问题，批准或拒绝命令，然后在被解锁的Agent继续运行时review已完成的工作。在被阻塞的Agent中，先处理等得最久的。这能把最坏等待时间压到最低。

通知推送同时违反这两条规则。它们为刚刚发生的事触发，所以最后ping你的Agent获得你的注意力，半小时前提问的那个则不会。

研究者Gloria Mark、Daniela Gudith和Ulrich Klocke的研究发表于2008年CHI会议（人机交互领域顶会），他们通过实验对比了被打断和未被打断的办公室工作者在任务完成时间、质量和情绪上的差异。结论是：被打断的人确实用更短时间完成了任务，输出质量没有显著下降，但他们报告了更高的压力、挫败感、时间压力和努力程度。也就是说，人们用"加速"补偿了中断带来的时间损失，代价是心理负荷上升。这一发现对Agent场景的启示在于：你passing review的速度变快，并不代表你判断得更准，可能只是你在用更高的认知压力换取更短的队列。

这在Hermes IDE中是什么样

我开发Hermes IDE，所以请带着这个前提读这一节。Hermes让Claude Code、Codex和其他CLI Agent并排运行，每个在自己的终端和worktree里。上限由你决定。Hermes帮助第二条规则：看清谁在等待，以及等了多久。

每个会话显示一个状态：工作中、需要批准、问了你、完成、错误或闲置。当Hermes只是猜测状态时，它会明说。一个错误的"工作中"会让被阻塞的Agent看起来在忙，于是那个Agent在无人察觉的情况下掉出你的队列。

一个attention inbox统计被阻塞在你这里的Agent数量。⌘I（Windows和Linux上是Ctrl+Shift+I）跳转到等待最久的Agent。你在那个Agent自己的终端里回答。Hermes从不替你回答权限提示，也从不自己在终端里打字。通知在Agent被阻塞或完成时触发，并跳过你正在看的会话。

Hermes不是唯一追踪谁在等待的工具。Claude Code的agent view有"Needs input"状态，顶部一行统计等待输入的会话数，以及像"2 awaiting input"这样的终端标签标题。如果你所有Agent都是Claude Code，那可能就够了，尽管它的文档把agent view标为研究预览。

Cursor的八Agent模式把一个prompt跑在多个Agent上，所以你是在比较同一个任务的多次尝试，这是不同的工作。Hermes适用于你的Agent来自不同厂商、你想要一个统一inbox的情况。

这是一个macOS、Windows和Linux的桌面应用，可免费下载，源代码在BSL 1.1下可见，与Nous Research、Anthropic、OpenAI或任何Agent厂商均无关联。

你到底能review多少？

回头看上周。数一数有多少Agent被阻塞的时间比工作的时间还长。这个数字比任何工具的最大值都更能指引你的上限。你的上限是多少，是什么让你停止增加Agent？

队列既是工具问题也是习惯问题。在你构建的系统中，队列是软件：拉取任务的worker、跑两次的重试、需要幂等的consumer，以及跨服务工作的saga和outbox。