- 下午两点，五份 diff 同时到齐
- 这类环境真正在卖的东西不是模型
- 隔离这一部分，今天光靠 git 就能试
- 瓶颈不会消失，只会换个位置
- 所以要看的不是生成功能，而是筛选功能
- 如果五个都差不多，那就是读了五倍、只得到一份
- 把这个项目的现状照实写下来
- 装工具之前，这周可以做的实验
- 小结与出处
下午两点，五份 diff 同时到齐
针对同一个 issue，同时跑了五个智能体。二十分钟后出现了五个分支，每个都带着 300 到 900 行不等的改动。思路上三个相近、两个不同。测试四个通过、一个失败。
接下来通常会发生这些事。把五份都读完要两个小时。两小时后你挑出一份，可挑完之后又觉得另外四份里的好东西丢掉可惜。于是你一点一点往里搬，最后干脆手写出了第六个版本。生成上省下的二十分钟确实省了，而后面接上的两个半小时，是原本不存在的时间。
这篇文章讲的就是那两个半小时是从哪来的。
这类环境真正在卖的东西不是模型
Orca 是一款正面瞄准这股潮流的工具。仓库简介把自己介绍成一个用来驾驭并行智能体群的 ADE，并声明无论哪种 CLI 智能体都用用户自己的订阅来跑。也就是说，它不是一款卖模型的产品。
README 摆在最前面的功能是并行 worktree。它写着：把一条提示词撒给多个智能体，把每个放进隔离的 git worktree，比较结果后合并胜出的那个。其余功能也都指向同一个方向：在 diff 的每一行上写评论并回传给智能体，在应用内打开 GitHub 和 Linear 的 issue 并直接建出 worktree，通过 SSH 挂载远程服务器上的 worktree，在浏览器里点击 UI 元素并把它的 HTML、CSS 和裁切好的截图塞进提示词。
把这份清单摊开来看，共同点就出来了。这个产品卖的不是生成代码的能力，而是让人能够消化已生成之物的那个表面。隔离、比较、评论、合并 —— 正正是评审与集成的工具。
隔离这一部分，今天光靠 git 就能试
并行智能体最先痛起来的地方，是多个执行者去动同一个目录。这一点用 git 的基本功能就能解决。下面是我实际执行并确认过的命令。
# 在仓库内，一边新建分支一边挂上一个独立目录
git worktree add -b try/a ../wt-a
git worktree add -b try/b ../wt-b
git worktree list
# /path/main-repo 2072b5c [main]
# /path/wt-a 2072b5c [try/a]
# /path/wt-b 2072b5c [try/b]
每个目录的文件树和构建产物是完全分离的，而 .git 的对象库共用一份。效果和把仓库克隆五次差不多，但磁盘占用和拉取时间要少得多。
清理的时候有一个地方会绊住你。
git worktree remove ../wt-a
git branch --list
# * main
# try/a <- worktree 删掉了，但分支还在
# + try/b <- 加号表示另一个 worktree 正占着它
删掉 worktree，分支还会原样留下。实验分支越积越多，原因大多在这里。而带加号的分支正被另一个 worktree 检出着，所以在这边没法再检出一次。并行跑起来必然会碰上这个约束，提前知道会更好。
瓶颈不会消失，只会换个位置
解决了隔离之后，下一堵墙就来了。生成快了五倍，读的人还是一个。
这层关系用排队论的一行就能说清。把系统里平均滞留的作业数记作 L，到达率记作 lambda，平均滞留时间记作 W，那么 L 等于 lambda 与 W 的乘积。反过来，W 就是 L 除以 lambda。
把智能体加到五个，就是把 lambda 提高到五倍。如果评审的处理能力不变，系统内的 L —— 也就是等待评审的 diff 库存 —— 就会堆起来。库存一堆起来，每份 diff 的滞留时间 W 就变长。滞留时间变长的 diff，会因为这期间基线分支动过而产生冲突，得再改一遍，然后再去排一次队。
不用数字，结论也很清楚：不同步提升评审能力，并行化增加的不是完成速度，而是库存。下午两点的那两个半小时，就是从这里来的。
所以要看的不是生成功能，而是筛选功能
换成这个视角再看，挑选并行智能体工具时该问的问题就变了。不是「能同时跑几个」，而是「五个里扔掉四个能有多便宜」。
降低丢弃成本的办法有三个。第一，让机器在人读之前先把候选刷掉。在每个 worktree 里自动跑测试和 lint，把失败的从评审对象里剔除 —— 这件事不用工具，写个脚本就行。第二，把比较并排摆开。五份按顺序读，前面的会忘掉；把同一个文件的五个版本并排看，剩下的就只有差异。第三，别让人再去把改好的地方手工搬来搬去。这正是为什么需要「在 diff 上写评论、原样回传给智能体」这个功能。前面看到的 Orca 功能清单，恰恰就集中在这三件事上。
换句话说，这类工具的价值不在于能跑多个智能体 —— 那开五个终端也能做到。价值在于把「扔掉四个」的成本降下来。
如果五个都差不多，那就是读了五倍、只得到一份
这里还得再往下挖一层。扇出要能带来信息，候选之间必须彼此不同。同一条提示词、同一份上下文、同一个模型，扔五次，通常会得到五个大同小异的答案。那么阅读成本老老实实是五倍，得到的信息却只有一份。前面下午两点那一幕里之所以有三个相近，原因通常就在这儿。
制造多样性的轴有三条。第一条是提示词。与其抛出同一个要求，不如把思路钉死了分开：一个让它复用现有抽象，一个让它新建模块，一个让它只做最小改动。这样一来，比较的就不是实现口味，而是设计选择。第二条是上下文范围。有的候选只给相关文件，有的候选连测试和 issue 一起给。第三条是执行主体。
Orca 明确表示自己不绑定特定模型、只要是能在终端里跑的 CLI 智能体都能接上，这一点在第三条轴上是有意义的。不同的智能体，默认提示词和使用工具的习惯都不一样，所以面对同一个要求会给出形状不同的答案。不过这只是产品替你打开的一条轴，真正去设计多样性，依然是人的活儿。
把这个项目的现状照实写下来
为了不夸大，只写我确认过的事实。仓库创建于 2026 年 3 月 17 日，许可证是 MIT，主语言是 TypeScript。桌面端标注支持 macOS、Windows、Linux，并提供了 Homebrew cask 与 AUR 包。移动端伴侣应用，iOS 通过 App Store 和 TestFlight 分发，Android 则通过仓库 release 上的 APK 分发。
README 自称每天都在发布，因此提示功能清单永远滞后、release notes 才是真正的清单。我把这句话既读作优点，也读作警告。一个诞生还不到半年的桌面应用每天发布，同时也意味着昨天能用的东西今天可能表现不同。在我查看的时点，未关闭的 issue 超过三千件。在一个热门仓库里，这个数字本身并不代表有缺陷，但它同样也不能替代成熟度来说话。
归纳起来，这个工具还没到可以由别人替你判断值不值得用的阶段。它是团队代码要经过的环境，所以真要引入，这个判断得自己做。
装工具之前，这周可以做的实验
有一种办法可以不装任何东西、先把工作流试一遍。真正花钱的不是工具而是评审，所以从评审这一侧开始量就好。
# 1) 就同一个 issue 切三个分支（跑三个智能体，或者人自己试三次都行）
for n in a b c; do git worktree add -b try/$n ../wt-$n; done
# 2) 在人去读之前，让机器先刷掉一批
for n in a b c; do
( cd ../wt-$n && npm test >/dev/null 2>&1 && echo "PASS $n" || echo "DROP $n" )
done
# 3) 只看活下来的，按文件并排比对
git diff try/a try/b -- src/
然后记录两件事：从活下来的候选里挑出一个，实际花了几分钟；以及挑完之后，有没有从别的候选那里手工搬过代码。如果有，那么在这个团队里扇出还不算划算 —— 因为一开始搬，做五份的理由就没了。
这个测量只要做一周，你能用数字说出来的就不再是「买不买工具」，而是「撒到几个才适合我们团队」。通常那个数字比五要小。
小结与出处
并行智能体环境看上去卖的是生成吞吐，实际卖的却是筛选与集成的工具。而之所以需要这些工具，是因为生成越便宜，瓶颈就越往评审那边挪。在挑工具之前先量一量自己团队的评审处理能力，顺序上才对。
- stablyai/orca 仓库 —— 功能清单、支持的智能体、安装途径、许可证。本文关于 Orca 的所有说法，都是直接从仓库 README 与仓库元数据确认的。
- git worktree 官方文档 —— worktree 添加、列出、移除的准确行为
- 正文中的 git 命令在 git 2.50.1 上实际执行并核对过输出。带
npm test的最后那个示例因项目而异，没有原样跑过。
현재 단락 (1/40)
针对同一个 issue，同时跑了五个智能体。二十分钟后出现了五个分支，每个都带着 300 到 900 行不等的改动。思路上三个相近、两个不同。测试四个通过、一个失败。