15 个开源编排器，2026-09-22 当天的数字摆在一处
把散在 15 个仓库里的当天数字摆在一处：不用挨个开 README，就能看出谁还在推东西、许可属于哪一类、形态是桌面还是命令行。star 与 fork 每天在动，所以每个数都钉在抓取日 2026-09-22 上；隔天再看请以当天的 API 为准。Orca 自己那一行也照同一把尺量，写在最前面。2026-10-19 从 GitHub 又重取了这 15 家：头部位次没换，第一名已到 ★97,847，第二名的 README 顶部写着 sunsetting。
更新于 2026-10-20
把这个工具接到 QCode 端点：一把 key 调 Claude、GPT 与国产模型。
- 按 token 计费，实时单价见 /models
- 支付宝、微信支付、信用卡、加密货币均可付款
- 充值后自助开通、立刻生效
四个当天数得出来的维度
star 与活跃度
按 2026-09-22 的 star 排，第一名 Orca ★75,454，第二名 vibe-kanban ★28,168，第三名 cmux ★27,335；末位 sculptor ★232，terragon-oss ★259 就在它前面。15 家里只有 1 家过 50,000。活跃度看最近推送：3 家的推送日期早于 2026-06-01，其中 crystal（2026-02-26）、uzi（2025-06-04）、terragon-oss（2026-02-10）。star 是存量信号，推送日期才是「今天还有没有人管」的信号，两个都要看。核于 2026-10-19。
许可不是「开源/不开源」两类
7 家是 MIT（含 Orca），5 家是 Apache-2.0，1 家是 AGPL-3.0（claude-squad），Worktrunk 是 MIT OR Apache-2.0 二选一。另有 3 家 GitHub API 报 NOASSERTION —— 含义是自动识别没认出来，不是没有许可：cmux 的 README 写 GPL-3.0-or-later，Superset 写 Elastic License 2.0（ELv2），Worktrunk 写 MIT OR Apache-2.0，三处都是逐字可查。要商用或要闭源分发的话，AGPL 与 ELv2 这两类跟 MIT 不是一回事，这一栏值得单独看。核于 2026-10-19。
形态与模型来源只在 README 里能指到句子
形态、模型来源、收费这三栏，2026-09-22 那次核录取回并逐字对了 11 家 README；2026-10-19 这轮把原先没取回的 4 家（nimbalyst、parallel-code、uzi、terragon-oss）补上，那 4 行的三栏按 2026-10-19 抓到的 README 原句填，抓取日写在行里，其余 11 行仍是 2026-09-22 的锚句。桌面 App、终端原生、命令行、云端，各是一家 README 自己的说法。横评里最骗人的写法，是把「同类大多如此」写成「它也如此」。
并行与 git 的速度：只有使用者自述，没有厂商基准，而自述给出的因果已被本人改掉
并行度上去以后 git 会不会自己变慢，这件事在公开资料里只找得到使用者自述、找不到厂商基准，而自述给出的因果后来也被报告者本人改掉。Orca 仓库的一条 open issue（#10769，2026-07-26 提交、作者 AmethystLiang、2 条回复，抓于 2026-09-22）写的是：同一个仓库活到 297 个 worktree 时，Source Control 面板里的 git commit 中位数从约 1.5 秒涨到 8.9 秒、峰值 21.6 秒，.git 目录 1.1G，作者当时把原因指向共享对象库的自动维护退化。同一段正文顶部现在放着那位报告者自己的追记：后续实测推翻了这一因果，worktree 的数量不是实测出来的主因，按这些数据也不能拿它当 Git 成本的预测阈值；仍然成立的是慢的 Git 操作在 UI 里看不见。它是单仓库、单日的自述，不是可复现基准，也只代表 Orca 这一家；把它放上表是因为选编排器的人问的就是这个，但请按它正文顶部那段追记的定性读。复查于 2026-10-19。
怎么读这张表
表里 15 行，每行五段：star（2026-09-22 当天 GitHub API）、许可、最近推送日期、最新 release 与其发布日，最后三栏是形态、模型来源、收费。前四段全部来自 API 档案，机器读出来的，没有人抄；后三栏只在这家 README 已被逐字核过时才填 —— 2026-09-22 那次取回 11 家，复查那一轮又把剩下的 4 家（nimbalyst、parallel-code、uzi、terragon-oss）的 README 取回并按原句填上，两种抓取日都标在行里，同类的说法不拿来替谁补。许可那一栏特别注意：GitHub API 对 3 家报的是 NOASSERTION（它认不出许可证类型），这不等于没有许可 —— cmux、Superset、Worktrunk 三家的 README 都逐字写了自己的许可，这一栏按 README 写，并在括号里标依据是 README 而不是 API。核于 2026-10-19。
为什么必须带抓取日
一张不带抓取时刻的 star 榜，第二天就已经是错的：表里 15 家钉在 2026-09-22，而 2026-10-19 从 GitHub 重取时，第一名 Orca 已到 ★97,847，第二名 vibe-kanban ★28,395、第三名 cmux ★28,273，superset ★15,368、agent-orchestrator ★13,360；worktrunk 以 ★9,309 越过 claude-squad 的 ★8,627，中段头名换了家。release 一侧同样在动：Orca 当天发 v1.4.230，superset 当天发 desktop-v1.39.0，sculptor 的最新 release 是 sculptor-v0.49.0rc2；vibe-kanban 的最近推送停在 2026-09-19，README 顶部写着 sunsetting。上一轮核录记的是当天的对照：同一天里 15 家的 star 差最大的不是头部而是尾部：terragon-oss 只有 ★259，而第二名 vibe-kanban 是 ★28,168，差 108 倍。更关键的是变化速度：Orca 从 09-21 的 73,754 涨到 2026-09-22 的 75,454，一天 1,700。这一页的处理办法是把抓取日写进每个数后面（2026-09-22），并且把「最新 release 的发布日」也一并列出：release 日期比 star 更能看出一个项目这周还在不在动 —— orca 2026-09-22、vibe-kanban 2026-04-24、cmux 2026-09-17、superset 2026-09-21、agent-orchestrator 2026-09-12。核于 2026-09-23。
这一页的时间锚
2026-09-22：本页全部 star、fork、license、pushed_at、latest_release 取自当天的 GitHub API 档案，共 15 个仓库；同日抓回 10 份 README 全文，形态与模型来源那两栏的逐字锚都出自这些档案。这一天 Orca 的 star 是 75,454，比 09-21 的 73,754 多 1,700。
2026-07-26：Orca 仓库提交 issue #10769，报的是同一个仓库开到 297 个活 worktree 时 git commit 的延迟变化；截至抓取日仍是 open。写下来的是那位使用者自己机器上的当天记录，未经他人复现，只对那一个仓库、那一天成立，不构成可复现的基准。
2026-09-23：本页四语定稿。star 与 release 这类数会随版本动，所以每个数都锁在 2026-09-22 那个抓取日上；隔几天再看请以当天的 API 重取，不要沿用本页。2026-10-19：重取了 15 个仓库的 repo 数据与各仓库 releases 的最新一条、15 份默认分支 README，并回看了 issue #10769 的正文——那三段数字仍是 297 个活 worktree、commit 中位数约 1.5 秒到 8.9 秒、.git 1.1G。表里 2026-09-22 那一组数原样留着，新查到的位次写在「为什么必须带抓取日」那一节。
能自己比 vs 得等官方说
当天能逐字指到句子的
核于 2026-10-19，能在 GitHub API 档案里逐字对上的：1) 15 个仓库的 stargazers_count、forks_count、license.spdx_id、pushed_at、最新 release 的 tag 与 published_at；2) Orca 为 MIT、75,454 star、4,939 fork；3) 三处 README 许可原文（cmux 的 GPL-3.0-or-later、Superset 的 Elastic License 2.0、Worktrunk 的 MIT OR Apache-2.0）；4) issue #10769 的 297 个活 worktree、commit 中位数约 1.5 秒到 8.9 秒（峰值 21.6 秒）、.git 1.1G 三段原句，以及同一份档案正文顶部那段报告者追记的原句——301 个 worktree 不是实测出来的主因，约 35 秒的代价来自 --reflog 要枚举 7,330 个 reflog 文件，其中一个 fork 单独贡献 2,470 个 ref 与 reflog 文件，数据不支持拿 ~100 这样的数量门槛预测 Git 成本。复查那一份档案同样逐字可查：15 家的 repo 与 releases 列表、15 份 README、以及这三家 README 里的许可写法。这些只是「档案里有这句」的层面；这些数字说明谁更好，得由读者自己的约束条件定。
⚠️ 三个想当然
一，「star 高就是适合我」：star 是关注度存量，跟你的仓库大小、要不要 GUI、能不能接受 AGPL 都没关系；2026-10-19 重取这 15 家时，star 最高的那家与末段的 sculptor 都在当天有新 release，而 star 第二的那家最近推送停在 2026-09-19 —— 星多星少看不出一周后它还在不在动。二，「GitHub 显示 NOASSERTION 就是没许可 / 不能商用」：那只是自动识别没认出来，三家都在 README 里写明了条款，其中 Superset 的 ELv2 恰恰是带使用限制的条款 —— 方向正相反。三，「上了表就是还在维护」：crystal 的最近推送停在 2026-02-26，README 顶部还写着自己已被 Nimbalyst 取代，uzi 的最近推送停在 2025-06-04；维护还在不在，看的是这些日期，不是它有没有被写进表里。复查于 2026-10-19。
中段 5 家与末段 5 家
中段 5 家（claude-squad 起）
claude-squad：★8,522（GitHub API 2026-09-22） · 许可 AGPL-3.0（API） · 最近推送 2026-08-20 · 最新 release v1.0.20（2026-08-20） · 形态 终端 TUI，一窗管多会话 · 模型 调本地 agent CLI，Codex 自备 key · 收费 未提收费；源码 AGPL-3.0 worktrunk：★8,339（GitHub API 2026-09-22） · 许可 MIT OR Apache-2.0（README） · 最近推送 2026-09-22 · 最新 release v0.79.0（2026-09-21） · 形态 CLI（wt 命令 + shell 集成） · 模型 调外部 CLI agent（示例 claude） · 收费 开源 MIT OR Apache-2.0 emdash：★5,806（GitHub API 2026-09-22） · 许可 Apache-2.0（API） · 最近推送 2026-09-22 · 最新 release v1.2.6（2026-09-21） · 形态 桌面应用（三平台） · 模型 复用已装的 CLI agent · 收费 Apache-2.0 开源 container-use：★4,046（GitHub API 2026-09-22） · 许可 Apache-2.0（API） · 最近推送 2026-09-21 · 最新 release v0.4.2（2025-08-19） · 形态 CLI 工具 + stdio MCP 服务器 · 模型 模型来自宿主 agent，未提 key/订阅 · 收费 开源（Apache-2.0），未提收费 crystal：★3,120（GitHub API 2026-09-22） · 许可 MIT（API） · 最近推送 2026-02-26 · 最新 release v0.3.5（2026-02-26） · 形态 已停更（2026-02，形态未写） · 模型 README 未写模型来源 · 收费 README 未写收费
末段 5 家（star 232–1,762）
sculptor：★232（GitHub API 2026-09-22） · 许可 MIT（API） · 最近推送 2026-09-22 · 最新 release sculptor-v0.48.0（2026-09-21） · 形态 桌面App：并行跑编码代理 · 模型 经 Claude Code/Pi 等外部代理 · 收费 自称开源，未提收费；nimbalyst：★1,762（GitHub API 2026-09-22） · 许可 MIT（API） · 最近推送 2026-09-21 · 最新 release v0.77.5（2026-09-09） · 形态与模型与收费（README 抓于 2026-10-19）：桌面 App，覆盖 macOS、Windows、Linux，另有 iOS 配套应用；同时跑多个 agent，每个各占一个 git worktree；README 列 Codex 与 Claude Code 并排，OpenCode 与 GitHub Copilot 标为 alpha，另有一个 Gemini provider；README 自陈 MIT 开源；parallel-code：★1,018（GitHub API 2026-09-22） · 许可 MIT（API） · 最近推送 2026-09-22 · 最新 release v3.0.1（2026-09-19） · 形态与模型与收费（README 抓于 2026-10-19）：把编码 agent 并行派出去，每个各占一个 worktree；README 写可用 Claude Code、Codex、Gemini；README 写不需要额外订阅、按 MIT 许可；uzi：★583（GitHub API 2026-09-22） · 许可 MIT（API） · 最近推送 2025-06-04 · 最新 release v0.0.2（2025-06-03） · 形态与模型与收费（README 抓于 2026-10-19）：命令行工具，每个 agent 一个 tmux 会话，自动管 worktree；模型侧 README 写用你自己选的 AI 工具，举了 claude、codex；README 未标价；terragon-oss：★259（GitHub API 2026-09-22） · 许可 Apache-2.0（API） · 最近推送 2026-02-10 · GitHub API 未列 release · 形态与模型与收费（README 抓于 2026-10-19）：README 写把活儿派给云端的编码 agent，并说自己是一份关停时留下的开源快照；模型侧写自带订阅或 API key；README 未标价
最靠前的几行（含 Orca）
orca：★75,454（GitHub API 2026-09-22） · 许可 MIT（API） · 最近推送 2026-09-22 · 最新 release v1.4.207（2026-09-22） · 形态 桌面 App + 手机伴侣，并行 worktree 编排 · 模型 README 未写模型来源 · 收费 免费开源（MIT） vibe-kanban：★28,168（GitHub API 2026-09-22） · 许可 Apache-2.0（API） · 最近推送 2026-09-19 · 最新 release v0.1.44-20260424091429（2026-04-24） · 形态 本地桌面 App，浏览器网页界面 · 模型 模型来自你已认证的编码 Agent · 收费 README 未写收费 cmux：★27,335（GitHub API 2026-09-22） · 许可 GPL-3.0-or-later（README） · 最近推送 2026-09-22 · 最新 release v0.64.25（2026-09-17） · 形态 macOS 原生终端（非 Electron/Tauri） · 模型 模型来自你自己装的 agent CLI · 收费 免费开源 GPL，另有付费 Founders 档 superset：★14,501（GitHub API 2026-09-22） · 许可 Elastic License 2.0 (ELv2)（README） · 最近推送 2026-09-22 · 最新 release desktop-v1.30.1（2026-09-21） · 形态 桌面 App + CLI/SDK/MCP · 模型 跑任意 CLI agent；可自接 OpenRouter · 收费 桌面永久免费；收费项为可选服务 agent-orchestrator：★12,267（GitHub API 2026-09-22） · 许可 Apache-2.0（API） · 最近推送 2026-09-22 · 最新 release v0.13.0（2026-09-12） · 形态 桌面应用+本地daemon · 模型 外接你已有的编码agent · 收费 Apache-2.0开源，未标价 （以上 star 一律为 GitHub API 2026-09-22 的数）
这和 QCode 有什么关系
编排器解决的是「同时开几个 agent、各自的改动落在哪」，模型与计费在另一侧：这一页取回的 15 家 README（2026-09-22 核录 11 家，2026-10-19 补取 4 家）里，模型来源几乎全写成「用你自己已经装好或认证过的 agent」，Orca 自己也不含模型。所以决定成本的是那一侧的 token 单价与缓存命中，不是编排器的 star 数。QCode 在另一侧：一把 key 按 token 计费，各模型单价见 /models，上面这些 CLI 配好自有端点后由编排器并行起。要常驻或并行跑 Agent，Orca 的 README 也把远程机器写成一条常规用法；这种情况下可以用 QCode 的云服务器：服务器放在海外，在服务器上装好 Claude Code 或 Codex，用你的 QCode Key 走 QCode 的接入端点调用模型；AI 服务和云服务器共用一个余额，起价见 qcode.cc/cloud 的线路对照表。
常见问题
这张表的 star 数是什么时候的？还能用吗？
全部是 2026-09-22 当天 GitHub API 的数，抓取日写死在每个数后面。能不能用取决于你要它干什么：当量级和相对位置看，一天的差别不影响结论（Orca 75,454 对第二名 28,168）；当精确值看就不行，同一天里 Orca 就比前一天多了 1,700。真要引用请回 2026-09-22 的档案，或自己当天重取一次再比。核于 2026-10-19。
GitHub 的 license 显示 NOASSERTION，是这项目没许可证吗？
不是。NOASSERTION 只表示 GitHub 的自动识别没能把 LICENSE 文件对上某个已知条款，15 家里有 3 家带这一标记。2026-10-19 重看这三家的 README：cmux 那一节写它按 GPL-3.0-or-later 开源，同一段另写它的 server 软件用 BSL 1.1；Superset 写整个 app 都在仓库里、用 Elastic License 2.0，它排除的只有一件事，就是把 Superset 本身打包成对外出售的服务；Worktrunk 的徽章写 MIT OR Apache-2.0。所以这一栏要么按 README 读、要么去仓库的 LICENSE 文件里读，识别失败不等于没有许可。
15 家里哪些是 GPL/AGPL/ELv2？商用要单独看吗？
7 家 MIT、5 家 Apache-2.0、1 家 AGPL-3.0（claude-squad），Worktrunk 是 MIT 或 Apache-2.0 二选一，cmux 按其 README 是 GPL-3.0-or-later，Superset 是 Elastic License 2.0。条款名之外，各家 README 还写了条款本身放行与禁止什么：Superset 说 ELv2 之下可以用、可以 fork、可以改、可以给团队自建；cmux 说它那份 server 软件按 Business Source License 1.1 —— 读、改、在非生产环境下运行都可以，生产使用或自建需要商业授权，同一节另写没法遵守 GPL 的组织可能有商业条款可谈；MIT 与 Apache-2.0 那一头，README 给的就是一行授权声明，条款正文在各自链到的 LICENSE 文件里（emdash 与 agent-orchestrator 都是这样）。AGPL 关注点对网络分发时的源码提供义务，ELv2 明确不允许把产品本身打包成服务出售，GPL 看传染性条款 —— 这三类跟 MIT 的「随便用」不是一回事，内部自用与对外提供服务的结论也不同。条款全文以各仓库的 LICENSE 与 README 为准。许可分布那组数核于 2026-10-19，引用的几处 README 原句抓于 2026-10-19。
并行几十个 agent 会不会把 git 拖慢？有数据吗？
公开资料里找得到的是使用者自述，不是基准。Orca 仓库 issue #10769（2026-07-26 提交，抓取日仍为 open）当时说：同一仓库 297 个活 worktree 时 git commit 中位数从约 1.5 秒涨到 8.9 秒、峰值 21.6 秒，.git 1.1G，并把原因指向共享对象库的自动维护退化。这条因果后来被报告者本人改掉：同一份正文顶部现在是他的追记，写后续实测推翻了原来的因果判断，301 个 worktree 不是实测出来的主因，加 --indexed-objects 对枚举代价几乎没有影响，约 35 秒的代价出在 --reflog 要枚举 7,330 个 reflog 文件上，多数由 Orca 托管的 fork remote 拉全部分支产生，其中一个 fork 单独贡献 2,470 个 ref 与 reflog 文件；追记另写 worktree 的数量仍是有用的上下文，但数据不支持拿 ~100 这样的数量门槛去预测 Git 成本，原报告作为调查经过保留。仍然成立的产品问题是慢的 Git 操作在 UI 里看不见，工作区与共享库的健康也没有从症状出发的路径；给出的实现方向是把托管 fork 的拉取用 --no-tags 收到那一个分支，并让符合条件的、由 Orca 发起的 commit 与 fetch 不在关键路径上触发自动维护。这是单仓库、单日的记录，换仓库大小、换 worktree 数量都会不一样，也只代表被报告的那一家。真要判断自己会不会撞上，看的是自己仓库里 ref 与 reflog 的规模、托管的 fork 拉多少个分支，而不是数 worktree 的个数。复查于 2026-10-19。
star 少的就一定不如 star 多的？
表里就有反例方向：3 家的最近推送早于 2026-06-01，其中 crystal ★3,120 但最新 release 2026-02-26；而末段的 sculptor ★232，最新 release 是 2026-09-21，比一些 star 更多的还近。2026-10-19 重取时，sculptor 到了 ★240，并在当天发了 sculptor-v0.49.0rc2；同批补取的 crystal 的 README 已写明自己被 Nimbalyst 取代，★1,935 的 nimbalyst 的 README 也是这一轮取回的。选工具看的是约束匹配（许可、形态、你的仓库大小）与维护活跃度，star 只是搜索热度的副产品。
表里「形态」「收费」这几栏是怎么填出来的？为什么行里会出现两个抓取日？
2026-09-22 那次核录取回并逐字对了 11 家 README，另外 4 家（nimbalyst、parallel-code、uzi、terragon-oss）当时只有 API 元数据，所以那三栏留了「未取回」。2026-10-19 这轮把这 4 家的 README 全部取回，按当天原文填上，抓取日写在行里；其余 11 家的三栏仍是 2026-09-22 的锚句。这三栏回答的是「这家 README 里有没有这句话」：有原文才有内容，一家的说法不挪给另一家 —— 横评里最贵的错误，就是替被评的对象补一句它没说过的话。
信息来源
当天仓库元数据：GitHub REST 的 repo 与 releases/latest 端点，15 个仓库，抓于 2026-09-22 并存本地档案（按响应 sha16 命名，不可变）。README 原文：各仓库默认分支的 README（README 全文逐字核过的 10 家 + Orca），同日抓回。issue：github.com/stablyai/orca/issues/10769 的正文原句，同日抓回。2026-10-19 又抓了一次同一批：15 个仓库的 repo 数据与各仓库 releases 的最新一条、15 份默认分支 README、以及那条 issue 的正文。二手榜单、测评与聚合站的数据在引用范围之外；凡「未写」均指核录取到的原文里没有该句。
可组合 AI 编码栈
2026 年的显性共识：编排层 + 执行层 + review 层各选一件，多数人同时用 2-3 个工具。组合栈的底座，是能通吃各家的模型访问层。
不再押注单一工具通吃，而是按层选型：编排层负责把任务拆小、派给合适的执行者（Claude Code 的 subagent、自定义工作流）；执行层负责真正写码（Cursor、Cline、Claude Code、agy 等）；review 层用与执行层不同的模型做独立把关，避免「自己批自己的作业」。每层的模型按任务难度与价格路由。
工具盘点类内容从「最佳单一工具」转向「最佳组合」：Claude Code Builders 七月刊直接写「选栈 = 同时选模型层和工具层」；codeculture 的标题是「为什么资深开发者用三个工具而不是一个」。驱动因素有两个：工具能力出现明显分工（编辑器内补全 vs 终端长任务 vs 异步 review），以及多模型价格差拉开后「按任务路由模型」能省出一个量级。
相关阅读
Orca 智能体开发环境指南
它是什么、并行省了什么、要还什么，那一页按 Orca 自己的机制讲：多个 CLI 智能体各自占一个 git worktree 同时跑，一条提示发给多个 agent 再比结果、合赢家；各家 CLI 的权限 flag 在 Orca 里被预填成什么样，macOS 与 Linux 怎么装才不撞同名，也在那一页。这一页做的事，是把它放进 15 家的对照里比数字。
并行 agent 的额度与成本账
编排器不替你出模型钱；并行 N 份上下文与缓存价差那笔账在这页。
Claude Code Worktree 并行开发实战：让多个 Agent 同时工作不冲突
不用编排器、自己拿 git worktree 管并行的那条路，字段与命令在这页。
加密货币充值指南
9 种币、56 条网络，0 平台手续费购买 AI 编程 API 额度。
本页转述 15 个开源仓库在 2026-09-22 当天的公开元数据与 README 内容，2026-10-19 又重取了一次；与各仓库无隶属关系，也没拿到它们的授权或内部信息。star、fork、release、推送日期都会随版本变；「未写」表示核录时取到的 README 里没有这句话，不表示官方否认。issue 数字为使用者自述，未经复现。选型请以下载当天的官方页面为准。