Orca on KnightLiブログ

Orca は Codex と Claude Code をどのように並行して実行しますか: ワークツリー、タスクの比較、モバイル承認

Wed, 15 Jul 2026 22:05:00 +0800

同じバグや機能が Codex と Claude Code にそれぞれ与えられた場合、多くの場合、エージェントに無限に再試行させるよりも早く盲点が発見されます。しかし、本当に難しいのは、プロセスを制御することです。2 つの変更は相互にカバーできず、結果は比較できる必要があり、タスクがいつ完了するか、コンピュータから離れたときに続行すべきかどうかをユーザーが認識できなければなりません。 Orca は、独立した Git ワークツリーで複数のターミナルエージェントを実行し、同じ場所でセッション、差分、タスクのステータスを追跡します。【オルカ公式倉庫】(https://github.com/stablyai/orca)

この記事は「承認前の比較」に焦点を当てています。並列実行は自動マージではありません。モバイル版はコードレビューの代わりにはなりませんが、時間内に進行状況を確認し、フォローアップの質問を送信し、どの結果が慎重なレビューのためにコンピュータに返す価値があるかを判断することができます。

最初に正しい境界を確立します: 並列実行は自動採用を意味しません

Orca は、Codex、Claude Code、およびその他のターミナルエージェントを並行して実行でき、各エージェントは独自の Git ワークツリーを使用します。公式 README は、同じプロンプトを複数のエージェントに割り当て、分離されたワークツリーで完了後の結果を比較し、勝ったソリューションをマージすることによって機能します。

したがって、プロセス全体を次の 3 つの層に分割する必要があります。

ステージ	完了者	製品
実行	コーデックス / クロードコード	独立したブランチ、差分、テスト出力、説明
比較	Orca + マニュアルのレビュー	計画の違い、リスクポイント、結論候補
承認とマージ	マニュアル	受け入れられたコミット、必要な追加の変更

「両方のエージェントが完了したと言っている」を承認と受け取らないでください。実際の差分をマージする前に、特に権限、データベースの移行、依存関係のアップグレード、削除されたファイルを確認する必要があります。

比較に意味があるようにタスクを分割する方法

2 人のエージェントが完全に曖昧な「ログイン問題の修正」を受け取った場合、多くの場合、横に並べて比較できない 2 つの大きな変更が発生することになります。統一された受け入れベースラインを各タスクに与える必要があり、戦略は異なる必要があります。

共同条件：复现登录 token 过期后的重试失败；必须通过现有登录测试；不改 API 协议。

Codex：从请求重试链路定位根因，提交最小修复，并说明为何不会影响刷新逻辑。
Claude Code：先写失败复现与回归测试，再提出最小修复；不改无关认证模块。

比較する場合は、次の 4 つの質問のみに注目してください。

実際に問題を再現し、カバーするソリューションはどれですか?
どちらの差分が小さく、境界が明確ですか?
どのテストコマンドが実際に実行され、出力は再現可能でしたか?
依存関係、権限、またはリグレッションのリスクが低いソリューションはどれですか?

このようにして、Codex と Claude Code の違いは、どちらがより説得力のある指示を書いたかの比較ではなく、測定可能なエンジニアリング上の選択になります。

Worktree は 2 つの候補変更が互いに混入するのを防ぎます

Git ワークツリーを使用すると、同じリポジトリの異なるブランチに異なる作業ディレクトリを持たせることができます。 Orca は分離された各ワークツリーでエージェントを実行するため、A のフォーマット、依存関係のインストール、またはファイルの削除が B のディレクトリに直接変更されたり、ホームディレクトリを直接汚染したりすることはありません。

開始する前にメインワークスペースを整理しておくことをお勧めします。

git status
git fetch --all --prune
git switch main
git pull --ff-only

次に、人間が判読できるブランチ名を候補に使用します。

1
2
3

agent/login-fix-codex
agent/login-fix-claude
agent/login-tests

分離してもマージ競合は排除されません。2 つのスキームが同じ証明書ファイルを変更することになった場合でも、マージでは 1 つのマスタースキームを選択するか、もう 1 つのスキームから独立したテストコミットを選択する必要があります。複数の候補ブランチを一度に main にマージしないでください。

Orca で 2 つのエージェントを開始するための実際的な手順

特定のボタンはバージョンによって異なりますが、次の順序は変わりません。

Orca で Git リポジトリを開き、ベースラインブランチと現在のコミットされていない変更を確認します。
Codex と Claude Code の独立したワークツリーを作成/選択します。
共通の受け入れ条件をコピーし、さまざまなサブタスクと禁止範囲を書き出します。
エージェントに、変更されたファイル、実行されたテスト、未検証の仮定、および推奨されるコミット手順をリストして結論を得るように依頼します。
終了したら、最初に diff とテスト出力を読み取り、どちらかの出力を修正し続けるかどうかを決定します。

Orca は、GitHub およびリニアタスクからワークツリーを開くこと、および差分行にコメントをエージェントに残すこともサポートしています。「テストのみを保持し、依存関係のアップグレードを撤回する」または「ここでキャッシュの無効化シーケンスを説明する」など、実用的なフィードバックの形でコメントを書くことは、単に「改善してください」と言うよりも効果的です。

携帯電話で「承認」を行う方法

Orca のモバイルコンパニオンは、携帯電話でエージェントを監視およびガイドするために使用されます。完了時に通知を受信し、どこからでもフォローアップを送信します。 iOS および Android のコンパニオンアプリをサポートしており、デスクトップバージョンとペアリングする必要があります。

ここでの「モバイル承認」は、タスクレベルの意思決定として理解されるべきであり、携帯電話上で盲目的に Git マージを完了するものではありません。

通知到达
  → 查看 Agent 的完成摘要、测试状态和风险提示
  → 决定：追问 / 让它补测试 / 停止另一个候选 / 标记为待电脑审阅
  → 回到桌面端查看完整 diff、运行关键测试、再合并

携帯電話での適切な操作には、失敗したテストの説明をエージェントに求めること、変更の範囲を狭めることを要求すること、回帰ケースを追加すること、または明らかに主題から外れたタスクを停止することが含まれます。通知の概要のみに基づいて、データベースの移行、運用構成、権限の変更、または広範なリファクタリングを承認するのには適していません。

再利用可能な比較および承認チェックリスト

両方のエージェントが完了したら、次の順序で続行します。

[ ] 两个方案是否都基于同一基线分支？
[ ] 是否都列出了修改文件和运行过的测试？
[ ] 是否有一个方案引入了无关依赖或大范围格式化？
[ ] 是否存在同一文件的竞争修改？
[ ] 主方案能否独立通过测试？
[ ] 次方案中是否有可单独挑选的测试、注释或修复？
[ ] 是否已在桌面端审查完整 diff，再执行 merge？

候補は、マージ前にメインの作業ツリーで比較できます。

1
2
3

git diff main...agent/login-fix-codex
git diff main...agent/login-fix-claude
git log --oneline main..agent/login-fix-codex

確認後、採用されたブランチのみをマージするか、git cherry-pick を使用して個別にコミットすることを選択します。採用されなかったワークツリーは検証が完了するまで保管し、戻ったときに別のアイデアを見つけやすくするためにクリーンアップしてください。

よくある質問

Codex と Claude Code は同じファイルを同時に変更できますか?

はい、それらは異なるワークツリーにあるためです。ただし、これは実行時に相互の上書きを回避するだけであり、マージ中に論理的な競合が自動的に解決されるわけではありません。 1 人のマスター実装エージェントと、テスト、レビュー、または代替案を担当する別のエージェントを指定するのが最善です。

携帯電話に「完了」と表示されるだけで結合できますか?

そんなはずはありません。携帯電話は、通知を受信したり、フォローアップの質問を送信したりするのに適しています。完全な差分、ライブテスト、機密性の高い構成、およびマージの決定は、依然として信頼できるデスクトップ環境で行う必要があります。

両方のエージェントの結果が満足のいくものではないのはなぜですか?

多くの場合、タスクの境界や受け入れ基準は十分に具体的ではありません。まず、エージェントの 1 人にコードの読み取りのみを行わせ、根本原因の想定と最小限の影響ファイルをリストします。方向性を確認してから並列実装を開始するとコストが安くなります。

概要

Orca を使用すると、Codex と Claude Code を分離されたワークツリーで並行して実行できるようになり、その後の比較可能な差分、テスト、リスクノートから実際の利益が得られます。モバイルコンパニオンアプリケーションは、「通知の受信 - 質問 - 次のステップの決定」を事前に完了するのに適していますが、手動による完全なレビューと Git とのマージに代わるものではありません。実行、比較、承認を分離することで、マルチエージェントの並列処理によってコードのリスクが増幅されることはありません。

Orca Parallel Agent ワークフローチュートリアル: Git Worktree を使用して Codex と Claude Code を同時に実行する

Wed, 15 Jul 2026 21:58:00 +0800

多个 Agent 同时改一个仓库，最怕的不是速度不够，而是它们相互覆盖文件、污染未提交改动，最后很难判断哪一份结果可合并。Orca 的做法是为每个 Agent 分配独立的 Git worktree：同一个仓库可以并行运行 Codex、Claude Code 或其他终端 Agent，完成后再比较 diff、选择并合并结果。Orca 官方仓库

它不是另一个模型，也不会替代 Codex 或 Claude Code；更准确地说，它是给多个 CLI Agent 加上一层工作区、任务和结果管理界面。适合需要并行探索方案、但又希望保留 Git 隔离边界的开发者。

Orca 适合什么任务

Orca 最适合“目标相同、实现路径可比较”的任务，例如：

让两个 Agent 分别实现同一个接口，再比较测试、可读性和改动范围。
一边排查 bug，另一边补测试或阅读相关模块。
同时尝试保守修复与重构方案，最后只合并其中一个。
把前端、后端、文档拆成互不重叠的子任务并行推进。

不适合直接拆开的情况也很常见：多个 Agent 同时改同一个核心文件、需要共享未提交状态的调试过程，或需求本身还没有明确。这时先用一个 Agent 梳理计划，通常比并行启动五个窗口更省时间。

工作原理：每个 Agent 一棵独立工作树

Git worktree 允许一个仓库同时检出多个分支到不同目录。Orca 在此基础上为 Agent 创建和管理这些独立目录：每个 Agent 都有自己的文件改动、终端会话和分支上下文，不会直接覆盖主工作目录。

官方 README 描述的典型流程是：把同一个提示分发给多个 Agent，每个 Agent 在隔离 worktree 中完成任务，然后比较结果并合并胜出的实现。Parallel Worktrees 说明

可以把关系理解为：

层级	负责什么
Codex / Claude Code	理解任务、修改代码、执行测试
Git worktree	隔离每个方案的文件和分支改动
Orca	创建工作树、启动 Agent、集中查看会话与 diff
你	拆分任务、审查结果、决定合并哪个方案

开始前的仓库准备

并行之前先把主目录收拾干净。worktree 能隔离新分支的文件改动，却不能替你判断主目录里哪些未提交变更应该保留。

git status
git fetch --all --prune
git switch main
git pull --ff-only

如果 git status 不是干净状态，先提交、暂存或明确保留当前改动。随后为不同方案建立清晰的分支命名，例如：

1
2
3

agent/fix-login-codex
agent/fix-login-claude
agent/add-login-tests

Orca 支持 Windows、macOS 和 Linux 桌面端；安装包和当前版本以官方发布页为准。它可以运行任何能在终端执行的 Agent，因此还要确认本机已经完成 Codex、Claude Code 或你计划使用的 CLI 的登录和基础配置。

一个可复用的并行拆分方式

以“登录偶发失败”为例，不要给三个 Agent 都发送“修复登录 bug”。更好的拆分是把交付物写清楚：

1
2
3

Agent A：定位请求重试与 token 刷新路径；只提交最小修复，并补充复现步骤。
Agent B：不改业务逻辑；为登录失败、过期 token、网络超时补自动化测试。
Agent C：审查最近登录相关改动，给出根因假设、风险文件和建议，不直接修改代码。

这样三条工作树的输出可以直接比较：A 提供候选修复，B 提供回归保护，C 提供独立审查。即使最终只采用 A 的修改，B 和 C 的结果仍能帮助验证方向。

对于同一个功能的多方案竞赛，也应限制范围：要求每个 Agent 只改指定模块、运行相同测试命令、在最终说明中列出修改文件和未解决问题。没有共同的验收标准，多个 Agent 的“完成”很难横向比较。

在 Orca 中启动并行 worktree

具体界面会随版本变化，但操作顺序通常如下：

打开一个已初始化 Git 的仓库，确认基线分支和主目录没有意外改动。
为每个子任务创建独立 worktree 或让 Orca 从任务创建工作树。
分别选择 Codex、Claude Code 等本机可用 Agent，给出不重叠的任务说明和验收命令。
让 Agent 在自己的 worktree 中执行；不要在主目录同时手动修改同一批文件。
完成后查看每棵工作树的 diff、测试输出和提交记录，再决定保留、修改或丢弃。

Orca 还提供终端分屏、diff 行内评论、文件拖放给 Agent，以及通过 CLI 管理工作树的能力；例如其文档列出了 orca worktree create、snapshot 等工作流命令。功能入口以当前版本文档为准。Orca CLI 介绍

如何合并结果，避免把三个方案混在一起

最安全的顺序是先审查、后合并：

# 在主工作树中查看某个候选分支
git diff main...agent/fix-login-codex
git log --oneline main..agent/fix-login-codex

# 确认测试和改动范围后再合并
git switch main
git merge --no-ff agent/fix-login-codex

如果测试工作树和修复工作树都值得保留，先合并测试，再合并修复，或用 git cherry-pick 挑选单独提交。不要因为它们都由 Agent 生成，就直接把全部 worktree 一次性 merge；重复的依赖升级、格式化改动和同文件重构最容易在这里引入冲突。

合并前至少检查四项：

改动是否只覆盖了任务范围内的文件。
测试命令是否实际运行且结果可复现。
是否包含密钥、生成文件、大型锁文件或无关格式化。
两个候选方案是否改了同一段业务逻辑；若是，保留一个作为主方案，另一个只作为参考。

常见问题

Orca 会替我购买或共享 Codex、Claude Code 的额度吗？

不会。Orca 的定位是编排终端 Agent；你仍使用自己已有的 Agent 订阅、账号和本机登录状态。多开 Agent 也可能更快消耗对应产品的用量额度。

多个 Agent 可以修改同一个文件吗？

可以，因为它们位于不同 worktree；但后续合并会产生竞争。若同一个文件不可避免地要改，最好指定一个主实现 Agent，其他 Agent 只做审查、测试或提出补丁建议。

没有 Git 仓库能用吗？

Orca 能运行终端 Agent，但并行 worktree 的隔离和可控合并依赖 Git。对重要项目，先初始化仓库并建立可回滚的基线，再开始并行任务。

Orca 与直接开多个终端有什么区别？

手动开多个终端也能并行，但你需要自己创建工作树、记住分支、追踪会话和对比结果。Orca 把这些步骤放到同一界面，重点是降低并行 Agent 的管理成本，而不是改变 Agent 本身的能力。

小结

Orca 的实用之处在于把“并行试错”变成可审查的 Git 工作流：每个 Agent 在独立 worktree 中工作，结果用 diff、测试和分支提交来比较。先把任务拆到互不干扰，再只合并经过审查的候选分支，才能让 Codex、Claude Code 的并行能力真正服务于交付，而不是制造更多冲突。