Orca：给多 Agent 时代的开发者重新造一个 IDE

如果你用过 Cursor 或 Claude Code，你一定碰到过这个问题：同一个功能想让两个 Agent 各写一版比一下，结果第二个 Agent 跑起来就把第一个的文件覆盖了。不是 Agent 不行，是 IDE 压根没给”多 Agent 同时干活”准备基础设施。

Orca 做的事就是这个。它不跟 Cursor、Windsurf、Copilot 争”谁的 AI 写代码更厉害”，而是把问题往上提了一层。你手里已经有 Claude Code、Codex、OpenCode、Grok CLI 这些 Agent 的订阅了，Orca 负责让它们在同一时间、同一仓库、互不冲突地并行跑。相当于你已经买了好几辆跑车，Orca 给你的是一个能同时管理它们的赛道。

stablyai/orca，YC W26 孵化，MIT 协议，TypeScript + Electron 写的，2026 年 3 月 17 日开仓。截至 2026 年 7 月，项目约 7k Stars，6,126 次 commits，保持每日发布的节奏。5 个月内做到这个规模，在 AI 工具类项目里不多见。

官方给它的定位是 ADE（Agent Development Environment），不是 IDE。这个命名不是文字游戏。IDE 是”人写代码、AI 辅助”，ADE 是”AI 写代码、人监督编排”。翻完它的架构设计之后，我觉得这个项目值得聊的点不止 Star 数。

为什么值得关注

Orca 跟市面上所有 AI 编程工具最大的区别，在于它不卖模型推理。它卖的是编排。

Cursor、Copilot、Windsurf 的商业模式都是”我提供推理，你付订阅费”。重度用户用多了平台亏钱，于是搞 Fair Use、限速、降质。模型一涨价，订阅费跟着涨。Orca 绕开了这层：你用自己的 Claude Pro、ChatGPT Plus、Codex 订阅，Orca 只负责把多个 Agent 组织起来协同工作。

这套定位有个很聪明的潜台词。模型层未来一定会持续降价，订阅会越来越便宜，但编排层的价值是稳定增长的。Anthropic 推 Claude Code，OpenAI 推 Codex，Google 推 Gemini CLI，所有大厂都在把 CLI Agent 做成标配。你手里的 CLI Agent 越多，越需要一个编排层。Orca 押的就是这个趋势。

更关键的是技术实现思路。Orca 没有给每个 Agent 写专用适配器，而是做了一层协议抽象：只要能跑在终端里的二进制，就是支持的 Agent。Claude Code、Codex、Grok、Cursor CLI、OpenCode、Pi、Devin、Amp、Cline、Continue，至少 27 个 CLI Agent 全部兼容。

Agent 内部怎么思考、怎么调用工具，Orca 不管。它管的是”给每个 Agent 一个独立的工作空间”和”把结果汇总给我看”。Agent 升级了不影响 Orca，新 Agent 出来只要能跑终端就支持。做协议层不做实现层，这是 Orca 最耐用的设计。

这个编排逻辑落到工程上，核心机制是每个 Agent 跑在独立的 git worktree 里：你把一个 prompt 同时扇出给多个 Agent，每个跑在物理隔离的工作目录中，共享同一个 .git 仓库但互相看不见对方的改动。全部跑完后用 git diff 逐份对比，挑最好的合并，其余归档。

这种 fan-out/fan-in 模式不是 Orca 发明的，但它是第一个把这个模式做成 IDE 原生交互的产品。git worktree 本身是 Git 的冷门功能，Orca 把它从命令行角落拉出来，变成了 IDE 的第一公民。整套设计背后是一个完整的分层系统，每一层解决一个独立问题。

从底层的 Worktree 引擎负责物理隔离，到 Agent 调度层管理 27+ 个 Agent 的生命周期，再到 Ghostty-class 终端提供 WebGL 硬件渲染，最上层是移动伴侣、Design Mode、SSH 远程执行这些跨设备能力。六层不是独立卖点，它们共同服务于一个心智模型：每个任务是一个 worktree，worktree 里跑任意 Agent，产出用 git 对比，从头到尾不离开 Orca。

拆完了架构，说点接地气的。实际的安装和上手体验怎么样？

上手什么感觉

Orca 是 Electron 桌面应用，macOS、Windows、Linux 全平台支持。跟 Cursor 和 VS Code 一样需要本地安装，但启动后的界面逻辑完全不同。安装很简单，macOS 直接 Homebrew：

brew install --cask stablyai/orca/orca

Windows 和 Linux 去 GitHub Releases 页面下载安装包。装完打开，第一件事是导入 git 仓库。Orca 自动识别仓库结构，多仓库项目还能按 project group 组织。

接下来建第一个 worktree。点 New Worktree，填任务名，选基准分支，提交。对话框立刻关闭，git fetch 和 git worktree add 在后台跑。你可以在 Orca 里继续做其他事，不用盯进度。

在终端里直接敲你常用的 CLI Agent 命令：claude 或 codex

Agent 跑在独立 worktree 里，改的文件不会影响主分支。跑完了切到 Review 视图，Orca 自动显示 diff。在任意一行写注释，注释会被发回给 Agent 当反馈，Agent 继续改。这套流程相当于把 GitHub PR review 的体验搬到了 AI Agent 输出上。

有几个地方容易踩坑：

• 如果你只用 1 个 Agent。Orca 是为同时跑多个 Agent 设计的，单 Agent 场景下 Cursor 或 VS Code + Copilot 反而更顺手
• 需要理解 git worktree 概念，不然看到多个目录会懵
• 移动伴侣依赖桌面端持续在线。电脑休眠或断网，手机就收不到推送了

这个问题目前没有好解法，因为本地 Agent 跑的就是你本机的环境。

体验上的坑说清楚了。但更关键的问题是，到底什么人该用、什么人不该用？

什么时候用，什么时候别用

一张表看清 Orca 和 Cursor、VS Code 这类传统 AI 编程工具的定位差异：

Orca 的独特位置不在”谁的 AI 写得好”，而在”让所有 AI 一起写，你来挑”。如果你只用一个 AI 编程工具，Cursor 或 Claude Code 单独用已经足够。Orca 的价值在你同时订阅了多个工具之后才真正体现出来。

适用场景很明确：你同时在用至少 3 个 CLI Agent，经常需要在同一仓库做并行实验，或者需要离开电脑时保持 Agent 运行并远程介入。不适用的情况也很清楚：偶尔用 AI 补全代码的用 VS Code 够了，团队没有 Code Review 兜底的别上 Agent 批量改文件，不接受 Electron 应用的也别勉强。作为 Cursor 和 Claude Code 的同类工具，Orca 真正的差异不在代码生成能力上，而在编排层。不过功能再强，社区健康度才是决定能不能长期用的关键。

社区怎么样了

“we ship daily”不是口号，Release 页面看得见。v1.4.127-rc.0（2026 年 7 月 7 日）的版本号本身就说明了迭代密度。提交历史里还有一个有趣的细节：Orca 的 AI Agent 自己也参与开发，多次提交中出现了 Co-authored-by: Orca <help@stably.ai>。Agent 开发 Agent 工具，这个递归本身就很 Orca。

中文技术社区对这个项目的关注度不低。王若风的博客把 Orca 拆成了 6 个非平凡产品决策，txtmix 的深度拆解从工程角度分析了 Worktree 模型的完整生命周期。两篇文章的共同判断是：Orca 不是又一个 VS Code 套壳，它的 worktree-native 心智模型是在重新定义 IDE 这个品类。

需要留意的一个点是，Orca 的移动伴侣后端和账号体系这些云服务部分，在开源仓库里看不到。这是 YC 项目的常见策略：开源吸开发者，闭源锁商业用户。目前对普通用户影响不大，但如果未来关键功能闭源，社区分叉的能力会受限。好在核心的 worktree 引擎和 Agent 调度都是本地运行，云服务只涉及推送和配对。社区数据看完了，但判断一个项目不能只看数字。

值不值得跟

说一个我自己的判断变化。一开始看到 Orca 的时候，我的想法很简单：这不就是 Electron 套个终端再配个 git worktree 快捷菜单吗？翻完架构设计和提交历史之后，我的判断收窄了。

Orca 真正有价值的设计不是任何一个单独功能，而是 worktree 被提升为 IDE 一等公民这件事。在传统 IDE 里，打开项目就是打开一个文件夹。在 Orca 里，打开一个任务就是一个 worktree。这个心智模型的转换，把”并行 Agent 协同”从一个口头概念变成了一阶操作。它不是加了个 feature，是换了个底盘。

举个例子，Orca 给 worktree 定义了完整的生命周期：Create、Work、Review、Ship、Archive。创建 worktree 时对话框提交即关闭，git fetch 和 checkout 在后台跑，你继续做别的事。多个 worktree 可以同时创建，互不阻塞。删 worktree 时目录和分支一并清理。这套交互在命令行里要写好几条 git 命令，在 Orca 里就是点几下鼠标。

但 Orca 的问题也很明确。它的价值完全依赖 CLI Agent 生态的多样性。如果未来 Anthropic 或 OpenAI 把 CLI Agent 关掉只保留云 API，Orca 整个产品逻辑就要重做。目前看这个风险不大，CLI Agent 多元化的趋势在加速，但这是生态押注风险，不是技术风险。

另一个值得长期观察的点是商业可持续性。Stably AI 是 YC 孵化的初创公司，Enterprise 商业版刚起步。能不能靠”编排层”的定位赚到钱，是 Orca 下一个阶段的关键考验。YC 的背书降低了突然停更的概率，但不等于商业模式已经验证。

Mobile Companion 这个功能我单独提一句。它做的事说起来很简单：Agent 跑完了给你手机发推送，你在地铁上点 Approve，回家分支已经合到 main。但这件事的意义被低估了。它改变了”跑 Agent 必须盯屏幕”的工作节奏，让 Agent 从同步协作变成了异步协作。十年前微信推送改变了 IM 习惯，Agent 状态推送大概率会改变开发者的工作节奏。

资源地址

聊到这里，该做个了断了。值不值得花时间？

先装一个试试

该说的都说了。如果你已经在用 Claude Code 或 Codex，给 Orca 一个下午。建两个 worktree，各跑一个 Agent 解同一个问题，用 git diff 对比结果。跑通一次你就会明白，worktree 不是锦上添花，是基础设施。这套流程用顺手之后，你会开始主动给每个 feature 建 worktree，Agent 变成你手下的并行流水线。

观望的话，关注两个指标：CLI Agent 生态的多样性是否继续增长（目前趋势很明确），以及 Enterprise 版的定价和功能边界（这直接决定商业可持续性）。

Orca 做对了一件事：在所有人都在卷”谁的 AI 写代码更好”的时候，它选了”让所有 AI 一起写，你当裁判”。三年后回头看，这个思路大概率会被当成理所当然。但在 2026 年夏天，它刚好处在那个”少数人先看懂”的窗口里。