Orca：用 Git worktree 把平行 coding agents 变成可比较的开发流程

当 coding agent 从「一次只改一个工作目录」进入同时执行多个任务的阶段，真正困难的往往不是再接一个模型，而是管理并行工作的边界：每个 agent 要在哪里修改？如何避免互相覆盖？结果要怎么比较？完成后又如何合并回主线？

Orca 是一个以开发工作台为核心的开源 AI orchestrator。它把 Codex、Claude Code、OpenCode 或 Pi 等 CLI agent 放在同一个介面中，让每个 agent 使用独立的 Git worktree，再透过桌面、终端机、浏览器与行动端功能集中追踪。这个设计的重点不是替开发者选模型，而是把「多个 agent 同时工作」变成一个可观察、可比较、可收敛的工程流程。

本文根据 Orca 官方 README、repository metadata 与官方文件，拆解它如何处理平行 worktree、终端机、浏览器操作、远端 SSH、差异审查与 CLI 自动化，也说明哪些能力适合导入既有团队，哪些地方仍需要保留人工判断。

先看清楚 Orca 解决的是哪一层问题

Orca 不是新的 LLM，也不是只包装单一 coding agent 的聊天介面。它处理的是 agent runtime 之上的协作层：

工作隔离：每个 agent 在自己的 Git worktree 中执行，降低平行修改同一份档案的冲突风险。
工作可见性：多个 agent 的终端机、状态与结果集中在一个工作区，不必在多个视窗之间来回切换。
结果比较：同一个 prompt 可以分派给多个 agent，分别产生方案，再由开发者比较差异并选择要合并的结果。
后续操作：除了文字输入，也能从差异档案加注、传回 agent，或在浏览器介面中把元素资讯送进 prompt。
远端执行：透过 SSH worktree 把 agent 放到较强的远端机器上，仍保留档案、Git 与终端机工作流。

因此，Orca 的价值比较接近「多 agent 开发控制面板」，而不是另一个模型入口。导入时应该先问团队是否有平行探索、长时间执行、跨环境协作的需求，而不是只看它能否启动某个特定模型。

核心设计：一个 prompt，五个隔离 worktree

Git worktree 是 Orca 工作模型的地基。官方 README 的示例是把一个 prompt 分派给最多五个 agent，每个 agent 使用独立 worktree；开发者可以同时观察结果，最后选择要合并的版本。

这个流程和传统「开一个分支、叫 agent 修改、等待结果」不同。它把探索阶段拆成几个互不干扰的候选解：

1. 先从同一个 repository 建立多个 worktree。

1. 将相同或略有差异的任务交给不同 agent。

1. 让每个 agent 在自己的目录中读取、修改与测试。

1. 从集中介面检查每个 agent 的输出与 Git diff。

1. 选择一个方向，将它合并回主要分支，或淘汰其他 worktree。

隔离并不等于自动正确。测试仍可能漏掉需求，两个方案也可能都不符合产品限制；但 worktree 将「同时探索」与「最后整合」分成明确阶段，使审查者可以在合并前保留决策权。

为什么 worktree 比复制多份 repository 更适合

复制多份 repository 也能让 agent 平行工作，但会带来额外的同步成本：分支关系不明、修改差异难以追踪、最后合并容易变成手动搬档。Git worktree 让多个工作目录共享同一个 Git repository 的物件资料，同时保留各自的工作树与分支语意。

Orca 没有因此消除 Git 的复杂度，却把常见的建立、切换与观察操作放到同一个工作台。这对需要同时比较重构方案、测试修复方案或 UI 实作方向的工作特别实用。

终端机不只是附属视窗

Orca 的另一个重要组成是终端机工作区。官方 README 列出 WebGL rendering、无限分割，以及重新启动后仍能保留 scrollback 等能力。对 coding agent 而言，终端机不是单纯的输入框，而是执行指令、查看测试、追踪长任务与检查环境状态的主要介面。

集中终端机有三个工程上的好处：

降低上下文切换：agent 的工作目录、终端输出与 Git diff 可以放在相同的工作区中查看。
保留执行证据：长时间测试或建置的输出不必依赖聊天讯息转述，开发者可以直接回看 terminal scrollback。
支援人工接管：当 agent 卡在权限、依赖或测试失败时，开发者可以直接进入相同环境处理，不必重建工作目录。

这也提醒我们，好的 agent 介面不应只呈现「完成」或「失败」两种状态。对实际开发而言，命令、输出、变更与环境状态都属于可审查的工作上下文。

从浏览器取得更精准的 UI 上下文

在前端开发中，单靠自然语言描述「把这个按钮往右移」通常不够。Orca 的 Design Mode 让使用者在真实 Chromium 视窗中点选 UI 元素，把该元素的 HTML、CSS 与裁切画面直接送进 agent prompt。

这个功能的重点不是让 agent 自动操控所有浏览器，而是缩短「人看到的画面」与「agent 收到的上下文」之间的距离。它可以用在：

指定某个元件的实际 DOM 结构。
让 agent 知道目前套用的 CSS 与版面层级。
以局部 screenshot 补充文字描述无法表达的视觉问题。
让修正任务从「猜是哪个元素」变成「对这个元素提出变更」。

不过，HTML、CSS 与 screenshot 仍然是输入资料，不是产品需求本身。设计规范、无障碍要求、浏览器相容性与测试结果仍需由团队验证。

GitHub、Linear 与 diff review 被放回同一个流程

Orca README 也列出 GitHub 与 Linear 的原生工作流：可以在应用程式内浏览 PR、issue 与 project board，从任务开启 worktree，并在不离开工作区的情况下进行 review。

对团队来说，这种整合的价值不只是少开几个分页，而是让任务识别与程式码修改有更清楚的对应关系：

Issue / Project task
        ↓
建立隔离 worktree
        ↓
分派一个或多个 coding agent
        ↓
查看测试、终端输出与 diff
        ↓
加注、修正、重新执行
        ↓
人工审查后合并

其中「人工审查后合并」仍是必要节点。Orca 可以协助收集候选结果，不能替团队决定需求是否完成、变更是否安全，或某个 diff 是否符合架构规范。

Remote SSH：把 agent 放到真正适合它的机器

本机环境不一定适合长时间或高资源的 agent 工作。Orca 的 SSH worktree 功能，让 agent 可以在远端机器上使用完整档案编辑、Git 与终端机能力，并提供自动重新连线与 port forwarding。

这类设计适合以下情境：

本机是笔电，但建置或测试需要较多 CPU、RAM 或 GPU。
团队有共用的 development box 或隔离执行环境。
需要让多个 agent 在远端分支上长时间执行任务。
服务只在远端网路或内部环境可存取。

远端执行同时提高了治理要求。SSH key、repository 权限、port forwarding、agent 可执行的命令范围，以及工作完成后的清理策略，都应由团队明确定义。便利的连线不等于可以省略隔离与审计。

Annotate AI Diffs：把 review 意见送回工作回圈

Orca 支援在 diff 的行上加入注解，再把意见传回 agent，让 review 不必停留在「人看完之后另外写一段 prompt」。这个设计将修改循环具体化：

1. agent 先产生变更。

1. 开发者在 diff 上指出问题或补充限制。

1. agent 只针对这些上下文继续修改。

1. 重新执行测试并再次检查 diff。

对大型变更来说，行级注解比一段笼统的「请再改善」更容易定位。不过，注解仍应描述可验证的问题，例如行为、介面、测试或安全边界，而不是只给主观评语。

CLI 让 Orca 不只服务互动操作

除了桌面介面，Orca 也提供 CLI，可以用 orca worktree create、snapshot、click 与 fill 等命令脚本化工作流程。这让 Orca 可以被放进更自动化的开发流程中，例如：

为固定类型的 issue 建立标准化 worktree。
在 agent 执行前保存 snapshot，方便回溯。
以脚本操作介面，重现一组固定的人工流程。
在 CI 或内部工具中串接工作状态，而不完全依赖滑鼠操作。

但「可脚本化」应该搭配明确的权限边界。任何会修改 repository、执行部署、存取内部服务或传送外部请求的流程，都应先设计 dry-run、审批与回滚机制。

如何在团队中导入 Orca

建议不要一开始就把所有 coding agent 与所有 repository 都搬进去，可以采用三阶段：

第一阶段：只做隔离与观察

选一个不涉及生产部署的 repository，让两个 agent 分别处理同一个小型任务。比较它们的 diff、测试输出与人工审查时间，先确认 worktree 是否符合团队现有 Git 流程。

第二阶段：加入 review 回圈

把需求拆成「agent 产生初稿、开发者逐行注解、agent 修正、测试验证」的循环。这一阶段应记录哪些问题能透过精准上下文解决，哪些问题仍需要架构师或产品负责人决策。

第三阶段：再接远端与自动化

当隔离、审查与清理流程稳定后，再评估 SSH worktree、CLI 与任务系统整合。将可自动化的部分写成脚本，并保留高风险操作的人工核准点。

限制与风险

Orca 的 README 展示了完整的 agent 工作台，但导入时仍有几个限制需要实际验证：

agent 品质不会因介面集中而自动提升：平行执行可能只是更快产生更多不正确的候选。
Git merge 仍然存在：worktree 降低互相覆盖，并不保证不同方案可以无冲突合并。
资源成本会放大：五个 agent 同时执行，可能同时消耗模型额度、CPU、网路与建置资源。
远端权限需要治理：SSH 与 port forwarding 让能力更强，也让错误设定的影响范围更大。
产品功能变动快速：官方 README 明确表示功能持续更新，因此正式导入前应以当前 release 与官方文件再次确认行为。

这些限制不是 Orca 特有的缺陷，而是所有多 agent 开发系统都必须面对的工程问题。比较健康的评估方式，是以完成一项任务所需的总成本、审查时间、可回溯性与失败恢复能力来衡量，而不是只计算 agent 产生程式码的速度。

结语：把平行 agent 变成工程流程，而不是更多聊天视窗

Orca 最值得注意的地方，是它把 coding agent 的平行执行放回 Git、终端机、浏览器与 review 这些熟悉的工程概念中。Git worktree 提供隔离，集中工作区提供可见性，diff annotation 提供回馈回圈，SSH 与 CLI 则让流程延伸到远端与自动化环境。

如果团队目前最大的痛点是「agent 太多、结果难比、工作目录难管」，Orca 值得用一个低风险任务做实验。若问题其实是需求不清、测试不足或权限治理薄弱，那么先补齐工程流程，通常比再增加一个 agent 介面更重要。

本文资料来源：

- GitHub repository：[stablyai/orca](https://github.com/stablyai/orca)

- Orca 官方网站：[onorca.dev](https://www.onorca.dev/)

- GitHub API repository metadata（星数、授权、最近更新时间）：截至 2026-09-19 查询

本文未使用 repository README 中的图片作为文章封面；封面仅保留可供后续产图使用的英文 Prompt。