莫等闲，白了少年头，空悲切。——岳飞

Orca：把一支 AI 编程代理舰队带进同一个工作台

当 AI 编程代理开始真正参与开发流程，开发者面对的问题已经不只是“该选哪一个助手”。

更常见的场景是：一个任务交给 Claude Code 探索，另一个任务交给 Codex 实现，再让 OpenCode、Pi 或其他命令行代理处理不同方向。它们各自拥有能力，也各自占据独立的终端、上下文和代码状态。任务一多，窗口一多，分支一多，真正难管理的便不再只是代码，而是整支代理队伍。

Orca 希望把这件事重新组织起来。

它是一款面向 AI 编程代理的编排工具，支持在同一个工作空间中运行 Codex、Claude Code、OpenCode、Pi 以及其他可在终端中运行的代理。每个代理可以位于独立的 Git 工作树中，多项任务可以并行推进，开发者则能在一个地方观察、管理、审阅和继续推动它们。

Orca 的目标很明确：让开发者不必在一堆终端、编辑器、分支和对话之间来回切换，而是把代理协作带入一个更集中、更可见的工作环境。

当一个代理变成一支代理舰队

单个 AI 编程代理已经能够完成不少工作。

它可以阅读代码、修改文件、执行命令、解释错误、运行测试，也能围绕一个任务持续推进。但当项目开始同时处理多个需求时，单代理的使用方式很快会遇到现实问题。

一个代理正在修复问题。

另一个代理正在研究新的实现方向。

第三个代理可能负责整理文档、检查差异或处理另一个分支上的任务。

如果所有工作都发生在同一个目录中，文件变更会相互干扰，分支状态会变得复杂，开发者也难以比较不同方案。Orca 用独立工作树来承载这种并行关系。

同一个提示可以被分发给多个代理。

每个代理都在自己的隔离 Git 工作树中完成任务。

开发者可以比较不同结果，并选择其中更合适的一份进行合并。

这使“让多个代理同时工作”不再只是打开多个终端那么简单。每个代理有自己的代码空间，每条尝试有自己的运行轨迹，而人则能够站在更高处组织这些并行任务。

并行工作树，让不同方案同时发生

Orca 的 Parallel Worktrees 功能，直接面向多代理并行开发。

开发者可以将同一个提示交给五个代理，并让它们各自在独立的 Git 工作树中处理。不同代理可以给出不同实现，不同工作树可以保留不同修改，而最终的选择权仍然回到开发者手中。

这种方式很适合那些并不存在唯一显而易见答案的问题。

一个功能可以有不同的实现方向。

一个错误可以有不同的排查路径。

一个界面可以有不同的调整方案。

一个复杂任务也可以由不同代理从不同角度尝试完成。

过去，这种比较往往意味着反复切换分支、保存临时修改、记住每次尝试做了什么。Orca 则将每个并行任务放在独立工作树中，使代理之间的工作保持隔离，也使结果更容易被并排观察。

它并不要求开发者一开始就知道最佳路线。

相反，它让多条路线可以同时展开。

任何终端代理，都可以进入 Orca

Orca 的兼容理念很直接：只要一个代理可以在终端中运行，它就可以在 Orca 中运行。

README 中列出了广泛的代理支持范围，包括 Claude Code、Codex、Grok、Cursor、GitHub Copilot、Muse、DeepSeek Harness、ZCode、OpenCode、MiMo Code、Amp、OpenClaude、Antigravity、Pi、oh-my-pi、Hermes、Devin、Goose、Auggie、Autohand Code、Charm、Cline、CodeBuddy、Codebuff、Freebuff、Command Code、Continue、Droid、Kilo、Kimi Code、Kiro、Mistral Vibe、Qwen Code 与 Rovo Dev 等。

这意味着 Orca 并不试图将开发者绑定到某一种模型或某一种代理产品。

它更像一个能够容纳不同终端代理的工作台。

今天可以使用 Claude Code 进行架构探索。

明天可以使用 Codex 编写实现。

之后也可以在同一套工作树与终端环境中使用另一个 CLI 代理继续任务。

代理不同，任务不同，订阅不同，但工作空间可以保持一致。

这种开放性让 Orca 的角色更清晰：它不是另一个取代代理的代理，而是让代理能够被组织、并行运行和持续管理的编排层。

终端不该只是黑色窗口

终端仍然是 AI 编程代理最自然的栖身之处。

命令执行、日志输出、交互过程、测试结果与代理回复，常常都发生在终端里。Orca 为此提供 Terminal Splits 功能，带来支持 WebGL 渲染的终端体验、无限分屏能力，以及在重启后仍可保留的滚动历史。

这让终端不再只是一次性打开又关闭的黑色窗口。

它可以被拆分。

可以同时承载多个代理。

可以保留之前的输出。

也可以成为持续追踪任务状态的地方。

当多个工作树、多个代理与多个命令同时运行时，终端分屏尤其重要。开发者不必频繁离开当前视线，也不必在系统窗口之间寻找某个任务。不同会话可以被放在同一个工作区中，彼此独立，却又同时可见。

终端因此不只是执行命令的地方。

它也是代理协作的现场。

从手机观察代理，也能从手机继续指挥

开发并不总是在桌面前发生。

一个长时间运行的任务可能在等待测试结束，一次代理执行可能需要确认后续方向，一项修改可能已经完成但还需要进一步指令。Orca 提供移动端伴侣应用，让开发者可以通过手机查看和引导代理。

移动端可以监控工作树。

可以查看终端输出。

可以向代理发送命令。

当代理完成任务时，应用还能够发送通知。

这让代理运行不再完全被限制在桌面设备前。即使暂时离开电脑，开发者仍然可以知道某个任务是否已经结束，是否需要下一步指令，是否应当继续推进。

移动端并不取代桌面环境。

它更像桌面 Orca 的延伸。桌面负责承载完整的代码、终端、工作树与编辑环境，手机则让开发者在不在桌面旁时仍然能保持对代理工作的感知与控制。

手机与桌面之间，由 Relay 负责连接

Orca 的移动端与桌面端之间使用 Relay 进行连接。

手机和桌面不会彼此直接通信。它们都会建立到 Relay 单元的出站 WebSocket 连接，由 Relay 将两个会话配对，并在它们之间转发帧数据。

Relay 系统中，director 负责将主机分配到不同单元，并协调迁移；cell 则承载实际用户连接。

这种架构让移动端伴侣可以与桌面主机保持连接关系，也让桌面与手机之间的交互拥有明确的中间层。

移动推送网关则作为独立 Cloud Run 服务运行。桌面主机使用与 Relay 相同的 X25519 密钥完成认证，并为已配对手机注册原生推送 Token。网关会对事件进行排队，执行每台主机的配额与请求限制，并在 Apple 或 Google 报告 Token 失效时移除相关注册。

README 还明确说明，日志只记录聚合计数，不会将 Token、通知标题、通知正文或完整主机指纹写入日志。

在移动协作场景中，通知意味着“代理有新进展”，而不是把所有细节暴露在不必要的位置。

远程工作树，让代理去更强的机器上工作

并不是每个项目都适合只在本地机器上运行。

有些任务可能需要更强的硬件、更适合的环境，或者一台专门用于持续执行代理任务的远程主机。Orca 提供 SSH Worktrees，让代理可以在远程机器上运行，同时保留文件编辑、Git 操作与终端能力。

远程连接包含自动重连与端口转发。

这使工作树不一定要局限于本机目录。开发者可以将代理任务交给远程环境处理，同时仍然通过 Orca 观察与管理代码、终端与工作状态。

本地设备不必承担所有计算与执行工作。

远程主机也不必成为脱离视野的黑箱。

Orca 试图让两者保持在同一个工作流中。

Design Mode：把真实界面直接交给代理

开发界面时，最难传达的往往不是“这里有个按钮”，而是具体的问题究竟发生在哪里。

颜色不对。

间距不对。

布局不对。

某个控件在特定位置表现异常。

如果只是用文字描述，AI 代理需要不断猜测实际界面是什么样子。Orca 的 Design Mode 提供了另一种路径。

开发者可以在真实 Chromium 窗口中点击任意 UI 元素。

被选中的元素对应的 HTML、CSS 与裁剪后的截图，会直接进入代理提示词。

这让界面问题不再只能通过模糊描述传递。

代理可以得到页面中实际元素的结构、样式与局部视觉信息。开发者也不必手动复制大量 DOM 片段、截图或样式内容，再试图解释它们之间的关系。

从点击真实界面，到把上下文送入代理，Design Mode 缩短了设计问题与代码修改之间的距离。

原生查看 GitHub 与 Linear，不必跳出工作流

开发任务并不只发生在代码文件中。

Pull Request、Issue、项目看板和任务卡同样构成开发流程的重要部分。Orca 提供 GitHub 与 Linear 的原生浏览能力，让使用者可以在应用内查看 PR、问题与项目看板。

从某个任务出发，可以直接打开对应工作树。

在审阅任务时，也不必因为查看外部信息而离开当前工作环境。

这种整合并不是为了把所有工具都塞进一个界面，而是为了减少不必要的上下文切换。任务信息、代码变更、代理执行与审阅流程本来就彼此相关，Orca 将它们放得更近一些，使开发者能够更连续地推进工作。

在 AI 生成的差异上直接留言

代理提交修改之后，真正重要的工作并没有结束。

代码仍然需要审阅。

实现细节仍然需要确认。

某些地方可能需要修改，某些地方可能应该保持原样。Orca 提供 Annotate AI Diffs 功能，让开发者可以直接在差异的任意行添加评论，并将这些评论发送回代理。

这让审阅不再是“看完以后重新写一段提示词”。

开发者可以针对具体一行变更指出问题。

可以要求代理处理某个细节。

可以在 Orca 内完成审阅、编辑与提交。

差异因此不只是最终结果的展示区域。

它也成为人与代理继续沟通的界面。

代码审阅不必脱离代理工作流，而能够成为下一轮修改的输入。

编辑器、文件与图片，也能直接进入提示词

Orca 提供接近 VS Code 的编辑器体验，并支持自动保存。

文件与图片可以被直接拖入代理提示词中。

这一能力让上下文传递更自然。

需要让代理查看某个文件时，不必反复复制文件路径或整段内容。

需要让代理理解某张设计图或截图时，也不必先在别处上传，再回到终端中描述。

文件本身可以直接成为提示的一部分。

图像也可以直接成为代理需要理解的上下文。

当代理处理的是实际项目内容时，越少绕路，工作流就越连贯。

Orca CLI：不只让人使用 Orca，也让代理使用 Orca

Orca 不只是一个可视化桌面应用。

它还提供 Orca CLI，让代理可以驱动 Orca 的工作流。README 中列出的命令包括工作树创建、快照、点击与填充。

例如，代理可以通过以下类型的命令参与操作：

orca worktree create
orca snapshot
orca click
orca fill

这意味着 Orca 的能力不只停留在用户手动点击的界面中。

代理也可以通过命令行参与工作树创建、界面快照与交互操作。对于需要真实交互的流程，Orca 还提供 Computer Use 能力，让代理能够操作桌面应用与可见界面。

当工作流需要打开程序、点击元素、填写内容或与实际 UI 交互时，代理不再只能停留在文件和终端层面。

它可以进一步进入可见的软件界面。

快速打开，让工作树、文件、代理与命令都在手边

多工作树、多代理与多文件环境最容易出现的一个问题，就是“知道东西存在，却找不到它在哪里”。

Orca 提供 Quick Open，用于搜索工作树、文件、代理、命令和仓库上下文。

这种能力看起来很轻，却很适合复杂工作空间。

当一个项目同时运行多个任务时，开发者不希望把时间消耗在寻找入口上。某个代理在哪个工作树里，某个文件属于哪次修改，某个命令该从哪里执行，都可以通过更集中的搜索入口被快速找到。

工作流越复杂，快速回到正确位置就越重要。

查看使用情况，并在不同账号之间切换

不同代理工具通常对应不同账号、不同订阅与不同使用额度。

Orca 提供账号切换与使用情况跟踪能力，能够显示 Claude 与 Codex 的使用情况与速率限制重置时间，并支持在不重新登录的情况下切换账号。

这让代理管理不只局限于任务和代码。

使用状态也可以进入同一个工作界面。

当多个工具共同参与开发时，额度、账号与可用性本身也会影响任务分配。某个代理此刻适合继续运行，还是应当切换到另一个工具，这类判断可以建立在更直接的可见信息上。

Markdown、图片、PDF 与仓库文档都可以在工作区预览

代码仓库里并不只有源代码。

README、设计说明、图片、PDF、架构文档和其他项目资料，往往也是理解任务的重要部分。Orca 支持在工作区中预览 Markdown、图像、PDF 与仓库文档。

这使文档不再是需要单独打开的外部附件。

它们可以留在当前工作空间中，与代理、终端、工作树和代码一起被查看。

当开发者正在审阅一个任务，或正在向代理解释某项修改时，相关文档可以更自然地留在视线范围内。

通知与未读状态，让多任务不会悄悄淹没

代理可以持续工作，而人不可能持续盯着每一个终端。

Orca 提供通知与未读状态能力，用于提示代理已经完成任务或需要注意。开发者也可以把线程标记为未读，在之后合适的时间重新回到它们。

这看似是一个普通的消息管理功能，但在多代理环境中，它承担着更实际的作用。

当多个任务并行时，最怕的不是代理不工作，而是任务完成之后没有被及时发现。

通知告诉你某件事发生了。

未读状态让你可以承认“现在还不能处理”，但不会因此丢掉它。

在代理不断产出结果的环境里，这种节奏控制同样重要。

桌面、手机与远程运行时，共同组成一个工作空间

Orca 可运行在 macOS、Windows 与 Linux 上。

桌面端是最完整的工作台，承载代理、工作树、终端、编辑器、代码审阅与任务浏览。

移动端是随身的伴侣，用于查看工作树、终端输出与向代理发送命令。

SSH 工作树则让任务可以扩展到远程主机，在更强的机器上持续运行。

这三种位置共同构成 Orca 的使用形态。

桌面负责深度操作。

手机负责观察与继续指挥。

远程机器负责承载需要离开本机的执行环境。

开发者不必只在一种设备或一种运行位置中工作，而可以在不同场景之间保持工作流连贯。

面向移动端开发的实际工作路径

Orca 的移动端使用 React Native 构建，作为桌面应用的伴侣。

本地开发时，需要分别运行桌面端与移动端进程。桌面 Orca 在仓库根目录启动后，会在端口 6768 承载移动端 WebSocket RPC 服务。移动应用则从 mobile/ 目录启动 Expo Metro 服务，默认使用端口 8081。

桌面端可以这样启动：

1 2	pnpm install pnpm dev

移动端可以这样启动：

1
2
3

cd mobile
pnpm install
pnpm start

使用手机测试时，手机与桌面设备需要位于同一个局域网中。移动应用通过扫描配对二维码与桌面 Orca 建立连接。

如果需要原生开发客户端构建，可以使用：

1
2
3

pnpm exec expo run:android
pnpm exec expo run:ios
pnpm start --dev-client

这种开发路径体现出 Orca 移动端的定位并不是独立产品，而是与桌面代理工作台紧密协作的延伸。

版本化协议，让移动端与桌面端保持兼容

移动应用的更新速度与桌面应用并不总是同步。

移动端可能受到应用商店审核与发布节奏影响，因此 Orca 在手机与桌面之间使用版本化协议。双方会在 status.get 过程中交换版本号，并在出现真正不兼容的情况时给出阻止使用的判断。

目前 README 说明，相关版本常量处于不会阻止连接的状态，但协议层已经为未来的不兼容变更准备好了处理路径。

如果桌面端移除了移动端依赖的 RPC 方法，或者改变了移动端读取字段的含义、认证握手方式或消息帧格式，就需要提升协议版本。

对于新增可选字段、新增 RPC 方法或新增终端订阅事件类型，则不需要升级协议版本。

这一机制让桌面与移动端之间的连接不只是“能连上就行”，而是为后续演进预留了明确边界。

一个适合代理时代的开发桌面

Orca 所面对的，不是“如何再做一个编辑器”。

它面对的是一个已经发生变化的开发现场。

终端里运行的不再只有编译命令和测试命令，还有能够独立执行任务的编程代理。

Git 工作树不再只是高级用户偶尔使用的工具，而可能成为让多个代理隔离工作的基础。

代码审阅不再只发生在人与人之间，也发生在人审阅代理生成的差异，并将具体反馈送回代理的过程中。

手机不再只是离开桌面后的通知终端，也可以成为继续观察与引导代理的控制入口。

远程机器不再只是一个独立服务器，也可以成为 Orca 工作树的延伸。

Orca 将这些元素放在一起，试图给出一种新的工作方式：不是围绕一个代理展开工作，而是围绕一组代理组织工作。

让人重新回到编排者的位置

AI 编程代理越强，开发者越不需要亲手完成每一个重复动作。

但这并不意味着人的角色变得更轻。

相反，当多个代理可以并行推进任务时，人需要做的事情会逐渐转向更高层次：拆分任务、比较结果、确认方向、审阅变更、选择合并方案，并在适当的时候让不同代理接力。

Orca 将开发者放回这个位置。

它不试图把人从流程中移除。

它提供的是一个可以观察代理、调度代理、比较代理成果、审阅代理修改并持续推进工作的场所。

当代理从单个助手变成一支可并行协作的队伍，真正需要的就不只是更多终端。

而是一个能够把这支队伍带到同一张工作台上的编排者。