速览：Orca 是 Stably 推出的桌面应用，用于同时运行一组编码 Agent，并让每个 Agent 使用独立的 git worktree。它通过你现有的订阅驱动各种 CLI Agent，并提供终端分屏、diff 标注、SSH worktree、Chromium Design Mode、GitHub 和 Linear 浏览，以及移动端 companion app。截至 2026 年 9 月 1 日，它拥有 58,464 个 Star，采用 MIT 许可证，支持 macOS、Windows 和 Linux。它解决了你成为吞吐量瓶颈的问题，但不会告诉你五份 diff 中哪一份正确，也不会留下其他人可以阅读的记录。
本文深入介绍我们在 2026 年值得安装的五个开源 AI Agent 工具清单中的一个工具。
一个终端中的一个 Agent 就是一单位工作：你发送 prompt，等待，审阅，再次发送 prompt。Agent 很快，而你变成了慢的一环。工具进步了两年后，最终却卡在这里，这是一个奇怪的结果。
显而易见的解决办法是同时运行多个 Agent，显而易见的问题是多个 Agent 编辑同一个工作树会互相破坏。Orca 同时解决了这两个问题，并继续加入一组主要用于减少上下文切换的功能。
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。
核心思路：每个 Agent 一个 worktree
Git worktree 允许一个仓库同时拥有多个工作目录，并分别检出不同分支。Orca 把它作为基本原语。每个 Agent 都有自己的 worktree，因此五个 Agent 可以同时处理同一个仓库而不触碰彼此的文件。
让它不只是便利功能的模式是 fan-out：将一个 prompt 同时发送给多个 Agent，然后比较结果：
把一个 prompt 分发给五个 Agent，让每个 Agent 使用独立 worktree，再比较结果并合并胜出者。
对于定义清晰的任务，这样做是浪费；对于确实困难、无法预判哪种方案会成功的任务，这是清单中最有价值的能力。三个模型对棘手迁移的三次尝试不会以相同方式失败，三选一也比围绕第一个方案不断迭代更有效。
手动完成这一流程意味着五个终端标签、五次 git worktree add，还要在脑中记住每个标签对应什么。一周后，大多数人都会停止做这种记账。
它能运行什么
任何能在终端运行的工具都可以。支持列表很长，包括 Claude Code、Codex、Cursor CLI、GitHub Copilot CLI、OpenCode、Grok、Amp、Antigravity、Pi、oh-my-pi、Hermes Agent、Devin、Goose、Auggie、Charm、Cline、Codebuff、Command Code、Continue、Droid、Kilocode、Kimi、Kiro、Mistral Vibe、Qwen Code、Rovo Dev 和 MiMo Code，另外还有可用于其他 CLI Agent 的通用入口。
关键在于它使用你自己的订阅和 API key。Orca 不转售 Token，也不代理请求。如果你用 Claude Code 配合 Opus 5，再用 Codex 调用开放模型，Orca 会通过你已经付费的账号运行它们。
这也让多模型比较变得便宜而且容易尝试。把一个 prompt 分发给 Claude Code、Codex 和 OpenCode，只需消耗三个已有订阅的调用，不需要建立新的供应商关系。
安装
# macOS
brew install --cask stablyai/orca/orca
# Arch Linux
yay -S stably-orca-bin
macOS Apple Silicon 和 Intel 的直接下载包、Windows 安装程序以及 Linux AppImage 都位于 releases page。对于无头 Linux 服务器，可以使用 orca serve 以及仓库中的专门指南。
移动端 companion app 与桌面应用配对，已经上架 iOS App Store，Android APK 位于 releases。
一周后仍然重要的功能
并行 worktree 是标题功能，下面这些功能才会改变日常使用。
账号切换和使用量跟踪。在应用中查看 Claude 和 Codex 的使用量与限流重置时间，无需退出再登录即可切换账号。同时运行五个 Agent 时你很快会遇到限额，知道何时恢复，决定了你能否提前规划，而不是在任务中途才发现。
标注 AI diff。可以在任意 diff 行上写评论并发回 Agent，在不离开应用的情况下审阅、编辑和提交。这是处理 Agent 输出的正确交互模型，因为有用的反馈几乎总是针对具体行；把“重试 helper 中的 backoff 应该使用指数退避”写进聊天框，会丢失对应位置。
SSH worktree。在更强的远程机器上运行 Agent，使用完整的文件编辑、git 和终端能力，并支持自动重连及端口转发。当笔记本无法承载五个并行构建时，这很实用，而笔记本通常确实做不到。
Design Mode。在真实 Chromium 窗口中点击任意元素，Orca 会把它的 HTML、CSS 和裁剪截图放进 Agent 的 prompt。它消除了前端 Agent 工作中最糟糕的部分：用语言描述究竟哪个元素出了问题。
终端分屏。提供 Ghostty 级别的终端、WebGL 渲染、无限分屏，以及重启后仍然保留的滚动记录。记住最后一点，稍后还会回到它。
应用内 GitHub 和 Linear。浏览 PR、issue 和看板，并直接从任务打开 worktree。
Orca CLI。Agent 可以通过 orca worktree create、snapshot、click 和 fill 驱动 Orca 本身，因此工作流可以脚本化，而不必只能点击操作。
此外还有将文件和图片拖入 prompt、基于 VS Code 的自动保存编辑器、跨 worktree 和 Agent 的快速打开、Markdown 与 PDF 预览、需要真实 UI 交互时的 computer use，以及通知和未读状态，让你知道 Agent 是完成了还是卡住了。维护者每天发布更新，并称 changelog 才是真正的功能列表，这既是提醒，也是好迹象。
Fan-out 什么时候值得，什么时候只是在烧 Token
并行并不是免费的，常见失败模式是花五倍 Token 得到同一个答案的五个版本。使用这种模式可以遵循一个粗略规则：有歧义时 fan-out，有明确规范时单独运行。
任务存在多种合理方案时 fan-out。状态管理重构、棘手的数据迁移、尚未找到瓶颈的性能问题，以及不熟悉的库集成，都适合这种方式。此时模型确实会分叉，差异本身就是价值。三个 Agent 会生成三种结构，其中一个可能比你原本会写的更好。
任务已被明确规定时只运行一个 Agent。为接口增加字段、编写与现有四个 handler 一致的 handler，以及为行为已有文档说明的函数编写测试，都属于这种情况。五个 Agent 只会产生五份几乎相同的 diff，你却支付五倍成本。
跨模型 fan-out，而不只是跨运行实例。三个 Claude Code 实例处理同一 prompt，结果通常很接近；Claude Code、Codex 和 OpenCode 处理同一 prompt，差异会大得多，因为差异来自训练而不只是采样。Orca 把这种比较变成一键操作，这是一个容易被低估的功能，也正是账号切换和使用量跟踪与 worktree 同样重要的原因。
Fan-out 前先写验收标准。如果 Agent 开始前你说不清什么是正确答案，最后就会依据审美选出胜者。先写三条标准只需一分钟，就能把评审从主观判断变成检查，也能把标准交给 Agent，通常会让全部候选方案更好。
经济账很简单：fan-out 用 Token 换取更广的解空间搜索。解空间宽时这是好交易，只有一个合理答案时则不是。
Orca 带来的问题
运行五个 Agent，你得到五份 diff。接下来怎么办？
这是工具没有回答的问题，而且工具越好，问题越严重。Fan-out 放大了产出，但你区分正确与貌似正确的能力完全没有变化。仔细阅读五份 diff 所需时间可能比写代码还长，因此实际使用中人们会快速浏览，挑看起来最干净的一份，然后合并。
看起来干净不等于正确。这正是 Agent 输出的问题，在涉及 API 时尤其明显，因为 Agent 此时是在猜，而不是推理。五个 Agent 各自臆测接口返回什么，针对想象出来的结构写代码，再针对自己的假设写出能通过的测试。diff 互不一致，但靠阅读无法核验其中任何一个。
你需要一个不是自己的裁判，也就是一份 Agent 没有自行编造的契约，以及遇到差异就失败的测试套件：
- OpenAPI 规范是共享事实。每个 worktree 中的每个 Agent 读取相同的数据模型、状态码和错误封装，而不是产生五套猜测。
- mock 从规范生成。错误分支也要包含在内，这样只处理 happy path 的 Agent 会立即失败，而不是到了 staging 才失败。
- 契约测试决定胜者。对五个 worktree 运行同一套测试。两个通过，三个失败，这个合并决定建立在证据上，而不是哪份 diff 在晚上六点读起来最舒服。
- 结构变化要明确暴露。上游契约移动时测试应该失败，而不是行为悄悄漂移。
这就是 Apifox 与 Orca 的互补关系。Orca 让你低成本得到五个候选答案；规范加确定性测试套件，则让你低成本选择其中一个。在开启 fan-out 前就接入规范，而不是等到问题出现后再接入。随着 Agent 编写更多代码，验证需求只会增长。
终端滚动记录不是档案
现在说第二个缺口。这与其说是 Orca 的缺陷，不如说是它的边界。
Orca 是单个操作者的优秀驾驶舱。一切都位于你的机器上：worktree、终端会话、diff，以及会在重启后保留的滚动记录。个人工作正需要这些；但第二个人需要了解任何信息时，它就会变成问题。
你周四运行五个 Agent。周一同事问支付客户端中的重试逻辑为何改变。只要 worktree 没被关闭，答案也许还在笔记本的终端窗格里。生成它的 prompt 没了，推理过程没了，唯一持久的产物是模型写的一条 commit message。
Prompt 不是档案，驾驶舱也不是组织。
HiFox 正是构建在这条边界的另一侧，两者的理念其实比分类名称更接近。两者都按工作单元隔离工作，也都允许你提供自己的执行环境和订阅。区别在于工作单元是什么：Orca 的单元是你正在查看的 worktree，HiFox 的单元则是会跨越会话持续存在的任务。
- 共享记录是任务，而不是 prompt。进度、工具调用和结果会流回任务，Agent 输出作为可以回复的评论保存。周一的问题有一个不是屏幕录制的答案。
- Agent 是保存下来的配置。它包含 instructions、runtime、skills、repositories 和 environment。为支付服务调好的设置可以重复使用，不必每天早晨在新的窗格中重新输入。
- Crew 是 leader Agent 加上其他 Agent 和人员，采用 leader-first。leader 读取任务上下文，决定拉入哪些成员，并在一个地方合并结果，这相当于增加综合步骤的 fan-out，而不是让你自己阅读五份 diff。
- 执行环境由你提供。你连接一个 Computer，可以是笔记本、服务器或容器；HiFox 使用其中已经安装的 Runtime。这与 Orca 使用个人订阅的模式相同。
- 每个任务的仓库工作都位于独立 worktree。同一隔离技巧从窗格层面应用到了任务层面。
- Backlog 不会运行。任务停留在 Backlog 中不会启动运行，因此工作会在消耗 Token 前先完成准备和审阅，这是大多数并行 Agent 设置缺少的检查点。
- 使用团队已经理解的结构。空间、项目、迭代和任务，并支持 Jira 同步。
诚实地说，如果你独自工作，Orca 可能已经足够，而且非常好用。第二个人需要了解 Agent 做了什么时，你就需要持久任务记录，终端滚动记录无论如何都无法提供。
一种可行的配置顺序
如果要采用它，可以按以下顺序避免常见混乱：
- 先安装 Orca，用一个 Agent 运行一周。在尝试并行前，终端、编辑器和 diff 标注本身就值得使用。
- 先接入规范和契约测试。没有裁判就 fan-out 只会让问题变糟，这是最容易被跳过的一步。
- 只在困难问题上 fan-out。模糊重构用三个 Agent，清晰 ticket 用一个。凡事 fan-out 会浪费 Token 和注意力。
- 先降低每个 Agent 的 Token 成本。五个 Agent 搜索同一个仓库意味着五倍浪费，因此可以配合 codebase-memory-mcp。
- 使用标注，而不是重新发送 prompt。把行级评论发回 Agent，比重写整条指令更有效。
- 笔记本应付不来后切换到 SSH worktree。在真实构建中，通常第三或第四个 Agent 就会到达这个节点。
- 第二个人参与后再添加任务层。个人工作可以跳过；团队工作中记录不是可选项。
FAQ
Orca 能取代我的 IDE 吗？对于 Agent 驱动的工作，大体可以。它有基于 VS Code 的编辑器、自动保存、文件浏览器、终端和 diff 审阅。深度调试时，人们仍会保留完整 IDE。
每个并行 Agent 都需要单独订阅吗？不需要。Orca 使用你已有的账号，内置使用量跟踪会显示 Claude 和 Codex 的限额及重置时间。同时运行多个 Agent 会触发限流，这是计划限额问题，不是 Orca 的问题。
五个 Agent 处理一个仓库真的安全吗？安全，因为每个 Agent 都有自己的 git worktree，不能覆盖其他 Agent 的文件。仓库外的共享状态，例如数据库、运行中的开发服务器和端口，仍然需要你管理。应让它们指向不同环境，否则会出现看起来像 Agent 错误的混乱失败。
怎样选择 diff？对所有候选运行同一套测试，让测试来决定。如果测试无法区分候选方案，那么扩展 fan-out 前应先修测试。追踪每个 Agent 实际调用的内容也有帮助。
Orca 还是 HiFox 这样的工作管理工具？它们处于不同层次，可以组合使用。Orca 是你此刻驱动 Agent 的地方；任务系统负责让工作存在、被分配，并在之后保持可审阅。个人使用可能只需要前者。
它真的采用 MIT 许可证吗？是的，与这个类别中的一些工具不同。Stably 是一家商业公司，桌面应用采用 MIT 开源许可证。
总结
Orca 是解决吞吐量问题的有力方案。并行 worktree、真正的终端、diff 标注、远程执行和移动端 companion app 组合成了一个严肃的工具；使用自己的订阅而不是转售 Token，也是正确的商业模式。
它交付的是每小时更多候选答案，但只有在你能选择答案并记住发生过什么时，这才算进步。选择需要契约和测试套件，也就是 Apifox；记忆需要一个跨会话存在的任务，也就是 HiFox 。
没有裁判的五个 Agent，不是五倍产出，而是五倍审阅队列。
开发必备：API 全流程管理神器 Apifox
介绍完上文的内容，我想额外介绍一个对开发者同样重要的效率工具 —— Apifox。作为一个集 API 文档、调试、设计、测试、Mock、自动化测试于一体的工具，Apifox 是目前提升研发效率的首选。
如果你正在开发项目，不妨试试其极其友好的界面设计，它完全兼容 Postman 和 Swagger 数据格式，导入数据非常方便，，即使是新手也能很快上手，点击这里即可注册使用。
值得一提的是，除了个人和常规团队使用，针对有高安全合规要求、或需要在内网环境协作的企业，Apifox 还提供了深度定制的私有化部署方案。
获取专属报价与部署方案
详细的私有化部署系统架构与安全白皮书
针对您公司规模的专属报价单
免费的 1v1 专属产品演示 (Demo) 机会
