Orca：让多个 AI 编码 Agent 并行干活的 ADE，单订阅时代的终结
Orca：让 5 个 AI 编码 Agent 并行干活的 ADE，单订阅时代的终结
一个场景
你有一个功能要做。传统做法是：打开 Cursor，让 Claude Code 写，等它跑完，看看结果，不满意再改。一个 agent，一条路，串行等待。
但如果你能同时开 5 个 agent——每个都在独立的 git worktree 里，用不同的策略实现同一个功能——然后你只需要挑那个最好的合并呢？
这就是 Orca 做的事。2026 年 3 月上线，8 月已经 4.2 万 star，YC 背书。它不是又一个 coding agent，而是让多个 coding agent 并行工作的编排环境——官方叫法是 ADE（Agent Development Environment）。
从 IDE 到 ADE：颗粒度的跃迁
过去二十年，开发工具的演进路线是：编辑器 → IDE → AI IDE。
- 编辑器（Vim、Emacs）：管文本
- IDE（VS Code、IntelliJ）：管项目
- AI IDE（Cursor、Windsurf）：管单次 AI 交互
在 ADE 里，基本单位不再是"一次 prompt"或"一个文件"，而是"一个 agent 在一个 worktree 里的一次完整工作会话"。你可以同时跑 Codex、Claude Code、OpenCode、Pi，每个都在自己的隔离 worktree 里，互不干扰。
这和"多开几个 VS Code 窗口"有本质区别。多开窗口时，你仍然是串行地切换注意力——看一个 agent 的输出，切到另一个，再切回来。Orca 做的是统一追踪：所有 agent 的状态、diff、终端输出都在一个界面里，你可以并排比较结果。
核心机制：Worktree 隔离 + 移动端监控
Orca 最关键的设计是 Parallel Worktrees。Git worktree 本身不是新东西——它让同一个仓库的多个工作目录共存，每个可以 checkout 到不同的分支或 commit。Orca 把这个机制用在了 agent 编排上：
1. 你给一个 prompt 2. Orca 把它扇出到 N 个 agent 3. 每个 agent 在自己的 worktree 里独立工作 4. 你比较结果，合并赢家
这个设计的精妙之处在于：隔离是免费的。你不需要为每个 agent 复制整个仓库，git worktree 共享 .git 目录，只创建工作文件。5 个 agent 跑同一个仓库，磁盘开销几乎没增加。
第二个杀手特性是 Mobile Companion。你的 agent 跑完了，手机收到通知；你在地铁上看到 agent 卡住了，直接从手机发个 follow-up。这把"人盯着 agent"从桌面解放出来了——agent 变成了可以异步管理的后台进程。
和已有工具的对比
| 维度 | Cursor / Windsurf | Claude Code (CLI) | Orca |
|---|---|---|---|
| Agent 数量 | 1 | 1 | N（并行） |
| 隔离机制 | 无 | 无 | Git worktree |
| 移动端 | 无 | 无 | iOS/Android |
| Agent 选择 | 锁定厂商 API | 锁定 Anthropic | 任意 agent，自有订阅 |
| 远程能力 | 无 | 无 | SSH worktree |
Orca 不锁定 agent 厂商。你用自己的 Codex 订阅、自己的 Claude 订阅，Orca 只负责编排。这在 2026 年的 agent 生态里是个重要选择——厂商锁定的风险太高了。
为什么现在？
ADE 的出现不是偶然。2026 年中，coding agent 市场完成了第一阶段的洗牌：Claude Code、Codex、OpenCode、Cursor Agent 各自站稳了脚跟。单 agent 的能力已经够强了——Claude Code 能独立完成中型 PR，Codex 擅长系统级重构。
但单 agent 有个硬上限：它是串行的。一个 agent 跑完一个任务，你才能开始下一个。如果你有 5 个独立的 bug 要修，或者 3 种实现方案想比较，串行等就是浪费时间。
并行编排的价值就在这里。不是让 agent 更聪明，而是让多个够聪明的 agent 同时干活。这和 CPU 从单核到多核的跃迁一样——单核性能遇到物理墙后，多核成了唯一出路。
Orca 的增长数据印证了这一点：4.2 万 star，4 个月内从 0 到 GitHub Trending 常客。它切中的不是某个具体功能需求，而是 agent 时代的生产力范式转移。
还有什么问题？
Orca 不是银弹。几个值得关注的点：
1. 合并冲突：5 个 agent 各改各的 worktree，合并时冲突怎么办？Orca 的文档说"compare the results and merge the winner"，但实际操作中，如果两个 agent 改了同一个文件的不同部分，合并仍然需要人工介入。
2. 注意力分配：5 个 agent 同时跑，你真的能同时 review 5 个 diff 吗？移动端通知解决了"知道它跑完了"的问题，但没解决"理解它做了什么"的问题。
3. 成本：每个 agent 都在消耗你的 API 配额。5 个 agent 并行跑 10 分钟，等于 50 分钟的 API 消耗。对于按 token 计费的用户，这不是小数目。
4. 厂商依赖：虽然 Orca 不锁定 agent，但它依赖 agent 生态的稳定性。如果 Anthropic 改了 Claude Code 的接口，Orca 需要跟进。
一个更大的图景
Orca 代表的趋势比它本身更重要：开发工具正在从"辅助人类写代码"转向"编排 agent 写代码"。
这个转变的终局不是 Orca 本身，而是一个问题：当 agent 能力强到可以独立完成大部分编码任务时，人类的角色是什么？
Orca 给出的答案是：人类变成指挥官——不写代码，而是决定让哪些 agent 做什么、比较结果、合并赢家。移动端 companion 强化了这个隐喻：你不需要坐在电脑前，agent 会通知你它干完了。
这个模型和软件工程的传统形象差距很大。传统软件工程师是"键盘上的工匠"，ADE 时代的工程师更像"项目经理"——管理多个 agent 的工作流，而不是自己动手。
这不是坏事。它意味着工程效率的杠杆变大了——一个人能完成的工作量，从"自己写多少行代码"变成了"能编排多少个 agent"。但这也意味着，编排能力正在成为新的核心技能。
Orca 是第一个把这种编排能力做成产品的工具。它不会是最后一个。
---
项目地址：https://github.com/stablyai/orca 官网：https://onorca.dev 协议：MIT 平台：macOS / Windows / Linux / iOS / Android