Orca 为什么敢让几十个代理同时跑：独立工作树隔离机制深扒

Orca 为什么敢让几十个代理同时跑独立工作树隔离机制深扒【免费下载链接】orcaOrca is the ADE for working with a fleet of parallel agents. Run any coding agent with your own subscription. Available on desktop, mobile and remote runtime.项目地址: https://gitcode.com/GitHub_Trending/orca48/orca让五六个编码 Agent 在同一个仓库里并行跑是近两年多代理编排叙事里最诱人、也最容易翻车的场景。几乎所有团队的第一反应都是它们会不会互相踩掉改动、提交互相污染、甚至把别人的分支给 push 了这确实是多数方案的死穴——共享一份 checkout 的并发本质上是在赌运气。Orca 的思路则完全不同。它的做法是从根上消灭共享每个任务拿到一份独立的git worktree各占一块磁盘、各挂一条分支、各开一组终端。从 docs/site/content/docs/model/worktrees.mdx 的官方表述看Orca 是 worktree-native——不切分支、不 stash一次任务就是一次 on-disk 的完整副本。本文不打算复述营销话术而是直接翻开它的源码看这套隔离机制到底怎么实现的资源怎么分配、目录边界怎么建、为了并发它付出了哪些工程代价以及哪些场景其实不适合硬上并行。一、并发模型任务即工作树工作树即沙箱Orca 的并发单元不是线程也不是进程而是一个仓库的多份工作树。核心模型在 worktree 文档里有明确的三条每个仓库有一个base ref通常是origin/main作为所有工作树的分叉起点每个工作树有自己的start-from ref决定它从哪条提交长出分支每个工作树拥有独立的分支、独立的磁盘文件、独立的代理终端。这带来一个直接推论两个代理之间不存在任何共享的可写状态。代理 A 改src/main.ts影响的是工作树 A 的磁盘副本代理 B 在同一路径上写文件落在工作树 B 的副本里。两者在同一仓库下工作却像在两个互不相干的沙箱里工作。这正是 Run Codex, ClaudeCode, OpenCode or Pi side-by-side 这条产品主线能够成立的技术前提——README.md 里那句 each in its own worktree, tracked in one place 不是宣传语而是架构决定。但隔离不等于无限资源。要支撑几十个工作树同时存在、还要随时切来切去git 元数据的读写会成为新的瓶颈。Orca 为此在 git 命令执行层加了准入调度admission机制所有 git 命令都带一个admissionTier参数区分interactive与background两种等级。从 src/main/git/admission-tier-plumbing.test.ts 的测试可以看到创建工作树这类用户主动操作走interactive档而后台刷新的 git 操作被压到background档让出准入名额。配合WORKTREE_LIST_TIMEOUT_MS 30_000见 src/main/git/worktree-operation-options.ts单个卡死的 scan 不会拖垮所有后续列表——源码注释写得很直白one wedged shared scan otherwise hangs every later list。二、目录层级与进程边界工作树到底独在哪2.1 每一份都是货真价实的 git worktreeOrca 没有发明私有的目录格式而是直接调用git worktree add。核心入口在 src/main/git/worktree-add.tsconst args [...windowsLongPathGitArgs(repoPath), worktree, add] args.push(--no-track, -b, branch, worktreePath) if (baseBranch) { const baseContext await resolveWorktreeAddBaseContext(...) effectiveBase baseContext.effectiveBase args.push(effectiveBase) }关键细节藏在参数里--no-track避免新分支继承 base 的上游防止git status在首次推送前误报 behind by N-b保证每个工作树都长在自己的分支上。随后configurePushAutoSetupRemotesrc/main/git/worktree-add.ts会给仓库写入push.autoSetupRemotetrue让代理在提交后执行一次普通git push就能自动创建远端分支——这是代理自己提 PR链路的关键一环。创建完成后Orca 还会把 base ref 持久化到 git 配置branch.branch.basesrc/main/git/worktree-add.ts 中的persistWorktreeCreationBase。这就是后续 diff review对比 start-from ref与 Attribution 追溯的依据。更严格的一点是进程与路径的锁定。Orca 为每次创建维护了一个preparation lock在 src/main/git/worktree-create-preparation.ts 里从解析 base ref、reset --hard物化文件、到worktree move -f -f与checkout --no-track -b每一步都要verifyWorktreePreparationLockAtPath重新校验锁归属——防止两个并发的创建动作互相覆盖对方正在物化的目录。任何一步失败都会走performDiscardPreparedWorktree把半成品清掉绝不留下脏目录。2.2 删除侧的并发防线先注册、后执行创建要防并发删除更要防。Orca 维护了一张持久化的待删除注册表src/main/worktree-removal-table.ts删除操作先登记worktreePath与branch镜像到磁盘后再真正执行git worktree remove。这张表的直接效果是创建与删除的互斥。addWorktree一进来就调用assertNoPendingWorktreeRemovalConflict如果同一路径或同一分支还在删除流程中创建直接抛错因为Git still owns that path and branch until the background delete finishes。反向同理删除工作树时如果发现 git 因存在未合并提交而拒绝删分支Orca 会保留这些分支并提示 Review N Branchesdocs/site/content/docs/model/worktrees.mdx 的 Preserved branches 一节避免代理辛苦写的提交被无声销毁。磁盘 IO 同样被限流WORKTREE_DELETE_CONCURRENCY 2src/main/git/worktree-delete-limit.ts。注释给了非常实在的理由——一次大规模删除会独占子进程 20–35 秒两个并发删除就能饱和一块磁盘再多只是互相拖慢。2.3 终端与 UI 的隔离agent 的所有权边界工作树的隔离不止于 git。Orca 中每个工作树承载自己的 agent 终端、编辑器标签与浏览器标签代理的启动经由 src/main/agent-launch/startup-agent-worktree-create.ts 的 executor 完成——代理是工作树的启动终端而非全局聊天。代理的用量归属usage attribution也按工作树记账src/main/claude-usage/worktree-attribution.ts查找用量记录时先按工作树路径精确匹配再按包含关系兜底匹配保证每个代理消耗的 token 都能算到正确的任务头上。三、隔离的成本账共享什么、复制什么3.1 gitignored 文件是隔离的漏洞也是成本大头一个全新的 worktree 是干净的 checkout——依赖、缓存、本地密钥这类 gitignored 路径统统缺失。几十个代理并行若每个工作树都各装一份node_modules磁盘会瞬间爆炸安装时间也完全不可接受。Orca 用三层机制堵这个洞docs/site/content/docs/model/worktrees.mdx 的 Shared directories gitignored files 一节Worktree Shared Paths每仓库配置从主 checkout 物化到新工作树——macOS 上优先用 APFS clone-copy否则退化为符号链接orca.yaml的worktree.sharedDirectories仓库内提交的、必须共享的 gitignored 目录清单专门对付node_modules、.cache这类大目录全部按链接共享# orca.yaml仓库根目录 worktree: sharedDirectories: - node_modules - .cache仓库根目录的.worktreeinclude需要复制而非链接的 gitignored 文件比如.env、.vscode/settings.json让每个工作树拥有自己的副本。实现上这两条规则都有硬约束。resolveWorktreeSharedDirectoriessrc/main/git/worktree-shared-directories.ts只接受在主 checkout 中存在且被 gitignore的目录——把被跟踪目录或未忽略路径共享出去会在每个工作树上制造虚假 diff。.worktreeinclude的解析src/main/git/worktree-include-file.ts更保守只支持字面路径通配符与!取反直接跳过并告警文件大小上限 256KB、条目数上限 1000、路径禁止..逃逸、禁止.git——safe for now 的契约写得很清楚。这里能看到隔离与成本的精确平衡源码和提交历史是完全隔离的每人一份而可再生的重型目录是共享的一份真身 N 个链接不可再生的密钥类文件是复制的每人一份小副本。三种粒度三种成本策略。3.2 等待与超时为慢设下的工程防线并行场景里最隐蔽的杀手是意外的慢。一个卡在 OneDrive 云占位符上的 checkout、一个被 content filter 拖住的worktree add足以让整个创建链路挂死。Orca 把超时做成了一套可调、带钳制的机制src/main/git/worktree-operation-options.tsexport const WORKTREE_ADD_TIMEOUT_MS 180_000 // 默认 3 分钟 export const WORKTREE_ADD_TIMEOUT_MAX_MS 30 * 60_000 // 上限 30 分钟环境变量ORCA_WORKTREE_ADD_TIMEOUT_MS可以把默认值调到上限但不能低于 180 秒——lowering it to fail faster also lowers the minimum any override can request下限即默认防止误操作把创建弄成必超时。而300这种想写成秒的误用会被钳制而不是直接采纳测试 src/main/git/worktree-add-timeout-override.test.ts 覆盖了这些边界。连 base 分支漂移的判定都带预算RETARGET_DIVERGENCE_BUDGET_MS与RETARGET_MAX_COMMIT_DIVERGENCE 100src/main/git/worktree-base-divergence.ts用来判断准备中的 checkout 是否还值得重新对基。源码注释里给了一组真实测量一个 21715 文件的仓库本地main与origin/main只差 5 个提交、74 个文件——重对基很便宜而一个废弃 fork 的main与origin/main差了 8173 个提交、21708 个文件——那几乎等于重新 checkout 整棵树直接放弃重对基。用提交数做树差异的廉价代理把并发创建的开销限制在可预期范围内。四、哪些场景其实不适合并行隔离机制再扎实也不等于并行永远划算。从代码与文档里能清楚读出几条边界1. 强串行依赖的任务不要并行。工作树隔离解决的是写冲突不解决顺序依赖。代理 A 的改动是代理 B 的前置两者并行只会让 B 基于过期 base 工作最后在 review 阶段打成一团。Orca 的模型更鼓励评审后合并的接力一个代理完成 → 合并 → 下一个代理从新 base 再开工作树。2. 共享目录集中、写密集的仓库要三思。node_modules走符号链接共享后多个代理同时跑构建、写缓存是在同一份文件系统状态上竞争。链接避免的是磁盘重复避免不了IO 争用。大仓库的git worktree add本身就有 3 分钟默认超时、最坏 30 分钟的上限——创建几十个工作树的时间里资源是被占满的。3. 物理资源是硬约束。工作树隔离的是 git 状态不是 CPU 和内存。每个代理一个终端 一个模型上下文几十个并行意味着几十份 token 窗口、几十个进程。隔离让它们不互相破坏但不让它们不需要资源。文档里甚至给了最直白的卫生建议合并完就删别留几十个僵尸工作树——Leaving dozens of merged worktrees around just slows down the palettedocs/site/content/docs/recipes/jump-worktrees.mdx。4. 单机做不了的事交给远端。隔离机制在 SSH 目标上同样成立——Orca 在远端执行git worktree add代理跑在远端、文件流式同步docs/site/content/docs/recipes/remote-worktrees.mdx。把计算密度从一台笔记本摊到多台机器是几十个代理同时跑在资源维度上的最终答案。结语Orca 的答案其实朴素得近乎复古用 git 自带的工作树机制做隔离再用工程手段把并发的副作用管住——准入调度管 git 命令、注册表管创建/删除互斥、超时钳制管慢操作、三层路径策略管磁盘成本。它没有发明新的隔离原语而是把一个成熟的版本控制原语用到了极致。几十个代理同时跑的真正前提不是某个魔法调度器而是每个代理从磁盘到分支到进程都彼此独立——以及工程上对它们终究要共享的只有 CPU、内存和磁盘带宽这件事的清醒认识。隔离让并行成为可能资源预算让并行变得可持续而任务本身的结构才最终决定并行是不是值得。【免费下载链接】orcaOrca is the ADE for working with a fleet of parallel agents. Run any coding agent with your own subscription. Available on desktop, mobile and remote runtime.项目地址: https://gitcode.com/GitHub_Trending/orca48/orca创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考