Orca 隔离并行编程会话并追踪用量

同时开 5 个 Claude Code 或 Codex 会话，麻烦往往先出在协作上：文件互相覆盖、终端状态难追踪、额度消耗来不及看。Orca 给出的方案，是让每个 agent 拥有独立的 git worktree，再把状态、差异审阅和用量集中到一个桌面应用里。

这套思路值得了解，但证据需要分清：原文依据项目 README 整理，没有端到端跑过。它展示的是一套并行工作流程，还不能证明开更多 agent 就能更快交付。

并行跑 5 个 agent，先把代码目录隔开

Orca 的核心单位是 git worktree，也就是同一仓库下的独立工作目录。按原文流程，每项任务各有分支和文件夹，Claude Code、Codex、OpenCode 或 Pi 在对应目录的终端里运行。

这样，一个 agent 修改文件时，不会直接覆盖另一个 agent 工作目录里的文件。多个工作目录仍共享 Git 历史，不必把整个仓库的历史重复复制。

原文给出两种用法：把同一个提示词交给 5 个 agent，比较不同结果；或者针对同一个 bug，让不同 worktree 分别尝试一种修复思路。最后查看 diff，挑选合适的实现合并。

worktree 解决的是工作目录隔离，最终合并仍需要人判断。

它并不保证不同实现都正确，也不自动消除分支合并时的冲突。原文还提醒，依赖通常需要在每个 worktree 中单独安装。对前端和 Node 项目来说，Git 历史可以共享，node_modules 却可能重复占用磁盘和安装时间。

把用量、完成状态和审阅放进同一个入口

并行之后，第二个问题是管理成本。

根据 README，Orca 能显示 Claude 和 Codex 的用量及限额重置时间，还支持无需重新登录就切换账号。原文没有交代具体统计口径，也没验证刷新延迟和切换过程，因此暂时不能把它理解为经过验证的精确计费面板。账号切换也应限于自己拥有的账号，并遵守服务条款。

多个 agent 同时工作，会增加 token 消耗。用量视图的作用，是让这些消耗更容易被看见，而不是降低调用成本。

任务状态则靠通知和未读标记管理：agent 完成或需要处理时提醒，暂时顾不上的线程可以标记未读。审阅时，可以直接在 diff 的某一行添加评论，再把反馈发回 agent。

这几个功能连起来，才形成完整流程：创建 worktree、启动 agent、等待通知、审阅差异、逐行反馈、合并结果。终端分屏、WebGL 渲染，以及重启后保留滚动历史，服务的也是这条工作链。

前端调试能获得哪些额外上下文

Orca 的 Design mode 与前端工作关系最直接：在真实 Chromium 窗口中点击页面元素，就能把它的 HTML、CSS 和局部截图送进 agent 的提示词。

它试图减少描述页面问题时的信息损失。例如处理某个组件的样式问题，agent 可以同时拿到结构、样式和视觉结果。不过，原文没有展示修复案例，也没有比较它与手动提供截图、DOM 信息的效果差异。

其他能力更多是在连接任务入口和运行环境：在应用里浏览 GitHub PR、issue 和 Linear 看板，并从任务创建 worktree；通过 SSH worktrees 在远程机器运行 agent，配合文件编辑、Git、终端及端口转发；通过 README 列出的 iOS、Android 配套应用接收通知、发送后续指令。

Orca 还提供 CLI，原文列举了 orca worktree create，以及 snapshot、click、fill。这些表明 agent 也能操作 Orca，但原文没有给出后几个命令的完整语法或参数，不能直接拼成可执行教程。

我的判断

我认可先隔离目录、再集中审阅的顺序。并行编程最先需要解决的是修改归属和结果收敛，worktree 对这两个问题提供了清楚的组织边界。

不过，原文连经验验证也比较有限：作者明确没有端到端运行，只是在转述 README。没有完成时间、成功率、token 成本或合并冲突的对照数据，无法判断 Orca 比手动管理 worktree 和多个终端节省多少工作。

开 5 个 agent 是一种工作方式，不是效率结论。

对于任务少、很少触及额度限制的个人开发者，手动 worktree 加终端可能已经够用。Orca 更有吸引力的地方，是把频繁切换的状态、用量和审阅集中起来。团队是否需要它，取决于这些管理动作已经占用了多少精力。

另外，原文称团队每天发布更新，并提醒以 changelog 为准。具体功能是否可用，应按实际安装版本核对。

能拿来做什么

• 遇到有两种明确修复思路的前端或 Node bug，可以先用两个 worktree 分别尝试，再比较 diff 和验证结果，控制首次并行的规模。
• 并行运行 Claude Code、Codex 前，先确认用量及重置时间是否可见，并观察多开会话后的消耗，决定是否继续增加 agent。
• 审阅 AI 修改时，把反馈落到具体 diff 行，明确指出需要改动的位置，再让 agent 继续处理。
• 评估 Design mode 时，选一个已有的页面样式问题，比较自动提供 HTML、CSS、截图与手动提供上下文的操作成本和修复结果。