用 Orca 編排多個 AI coding agent：隔離工位、平行派工、看板監看、diff 審查到 PR

1. Orca 是什麼 0:00–0:24

作者介紹 Orca：一個「agent orchestratori」（他玩了 Orca / orchestrator 的諧音梗），由 Y Combinator 支持的公司 Stably 開發。它能做的比一支影片能展示的多得多，這支影片只挑幾個有趣的功能來看。

推理因為觀眾可能從沒聽過 Orca，所以作者先用一句話定位它：它不是又一個 coding agent，而是「agent orchestrator」——管理多個 agent 的指揮台（他還玩了 Orca ≈ orchestrator 的諧音）。接著補上可信度（Stably 公司、Y Combinator 支持），並事先聲明「功能多到一支影片講不完，只挑幾個有趣的示範」，把觀眾的期待設在「看幾個亮點」而不是完整教學。

• COrca是agent orchestrator：不寫程式，只負責開工位、派任務、看進度、收成果→ 畫地圖
• AOrca像工地的工頭，自己不動手，只負責派工、巡視、驗收→ 批判類比
• RAgent與orchestrator的分工→ 存＋回想

AI 補充作者沒說清楚「orchestrator」和「agent」差在哪，但這是整支影片的前提：agent 是真正動手改程式碼的工人（OpenCode、Claude、Codex…），orchestrator 是不寫程式、只負責「開工位、派任務、看進度、收成果」的工頭。Orca 本身不帶模型，它把你電腦上已經裝好的各種 agent 接進同一個介面。理解這個分工，後面每一個功能（開 worktree、內建瀏覽器、board、diff 審查）都可以歸到「工頭的工作」這條線上。

術語:AI coding agenti

2. Design Mode：一鍵開 worktree 0:24–1:00

進到 Orca 看 design modei。作者先說明專案裡有 setup scripti，每次建立新 work tree 都會自動跑 pnpm install。按 Cmd+N 建新 work tree，agent 預設是 OpenCode，但可以換成任何已安裝的 agent。建好後它先跑 setup，跑完 OpenCode 就載入了。

推理因為上一段把 Orca 定位成工頭，所以作者接著示範工頭的第一個動作：開工位。他先繞去專案設定給觀眾看一眼 setup script（每次建新 work tree 就跑 pnpm install），再回到 app 按 Cmd+N。這個順序是刻意的：先讓你知道「新工位不是空殼、依賴會自動裝好」，你才不會疑惑為什麼 agent 一載入就能直接跑。對話框裡 agent 預設是 OpenCode，但作者特別強調「可以選任何已安裝的」，為之後一個工位配一個不同 agent 埋伏筆。

• C按Cmd+N開新worktree=開新資料夾+新分支+啟動一個agent，setup script自動裝依賴→ 畫地圖
• E開新worktree的agent選單列了13種可選，含Manage agents與Create more→ 存＋演練
• P幫你的專案寫一個worktree用的setup script→ 練習
• RCmd+N開新worktree實際做了什麼→ 存＋回想

AI 補充作者沒有解釋什麼是 work tree，但這是整支影片的基礎。Git 的 worktree 功能讓同一個 repo 同時 checkout 多個分支到不同資料夾，共享同一份 .git 歷史；每個資料夾可以獨立編輯、獨立 commit。Orca 的「建 work tree」= 開一個新資料夾 + 新分支 + 在裡面啟動一個 agent。因為是新資料夾，node_modules 不會自動存在，所以才需要 setup script 跑 pnpm install——這就是作者一開始繞去看設定的原因。截圖裡的 agent 選單很值得看：Blank Terminal、Claude、Claude Agent Teams、Codex、OpenCode（勾選中）、Pi、OMP、Gemini、Antigravity、Kiro、Cline、Cursor、Hermes，底下還有「Manage agents」和一個「Create more」開關（可一次連開多個）。這張清單直接說明 Orca 是 agent-agnostic 的：它不綁任何一家模型。

術語:git worktreei

3. 內建瀏覽器 + 抓 DOM 元素 1:00–2:02

在 work tree 裡跑 nxi dev website 啟動網站，再開一個「new browser tab」直接在 Orca 內開那個網站，分割到右邊，左邊留 OpenCode。瀏覽器分頁有「grab page elementi」功能：滑過去會高亮 DOMi 元素，點下去就把該元素的 markup 複製到剪貼簿。作者貼進 OpenCode 並加一句「讓 description 撐滿卡片寬度」，agent 在自己的 work tree 裡調查專案然後改好。

推理因為上一段 worktree 已經裝好依賴、OpenCode 也載入了，所以作者直接在 worktree 裡跑 `nx dev website`，然後開一個「new browser tab」在 Orca 裡面打開 localhost，把它分割到右邊、OpenCode 留在左邊。這個並排版面就是 design mode 的樣子。接著他點瀏覽器工具列的 grab page element，滑過去會高亮 DOM 元素，點下 card container 就把它的 markup 複製到剪貼簿；貼進 OpenCode 再加一句「make the description extend the width of the card」按 Enter。作者刻意讓整個流程一氣呵成，用行為證明「指著畫面上的東西叫 agent 改」真的只有三個動作。

• C點瀏覽器裡的元素，把它的markup複製給agent，指著畫面說要改哪裡→ 畫地圖
• E貼進OpenCode後顯示「Pasted ~25 lines」，是渲染出的HTML片段不是原始碼位置→ 存＋演練
• R抓元素時除了複製markup還能做什麼→ 存＋回想

AI 補充幾個作者沒說、但截圖看得到的細節：(1) 左邊終端機的路徑是 `~/orca/workspaces/prowfish`，分支名也叫 prowfish——Orca 幫每個 worktree 隨機取名，資料夾與分支同名，這就是上一段 worktree 的實體。(2) 網站是 Astro 專案跑在 localhost:4321，`nx dev website` 是 Nx monorepo 的指令，代表這是 monorepo 裡的其中一個 app；上一段的 setup script 沒跑過就不會有這個指令可用。(3) 抓元素時瀏覽器上方有一行提示「Click or hover an element, then press C to copy or S to screenshot」——所以除了複製 markup，也能直接截圖給 agent 看。(4) 貼進 OpenCode 後顯示「Pasted ~25 lines」，也就是複製的是該元素的 HTML 片段，而不是原始碼檔案位置；agent 收到的是「渲染出來的 DOM」，它得自己在專案裡找到產生這段 HTML 的元件——這就是作者說「它會去 investigate the project」的原因。這裡也點出 grab element 的限制：DOM 和原始碼不一定一一對應（框架會加 class、hash），agent 需要一點推理才能對上。

4. 側邊面板：編輯器、歷史、Git 狀態 2:02–2:43

打開側邊面板：有檔案瀏覽器，點開檔案是內建的 Monaco 編輯器i，可以自己改；有 agent 做過什麼的歷史紀錄；還有 git statusi 顯示剛才改了一個檔案。作者接著跳到另一頁，用同樣方式抓一個區塊貼進去說「這裡也一樣」，agent 也改好了。

推理因為上一段的改動是 agent 在自己的 worktree 裡完成的、人沒有介入，所以作者接著要證明「人隨時可以介入」：打開側邊面板，點開 .gitignore 示範內建 Monaco 編輯器「我們可以自己改」；再往下是 agent 做過什麼的歷史；最後是 git status 顯示剛才只改了一個檔案。看完狀態他沒有停下來，而是立刻跳到另一頁，用同一套「抓元素 → 貼上 → 說 do the same here」再做一次，證明這個迴圈是可重複的，不是一次性的巧合。

• C側邊面板隨時能人工介入：內建Monaco編輯器自己改檔、看git status確認agent動了哪裡→ 畫地圖
• Ragent做完後worktree名字的變化→ 存＋回想

AI 補充截圖補上作者沒講的兩個重點。第一，git status 面板（右側）的資訊比他說的多：分支叫 `feat-card-component`、上游是 `origin/main`、Changes 1：`apps/website/src/pages/index.astro` +2 −2。左側 OpenCode 的輸出也列出具體改了什麼：在內層 `<div>` 加 `flex-1 min-w-0`、把 `<p>` 的 `max-w-xl` 拿掉——這就是「讓 description 撐滿卡片寬度」在 Tailwind 裡的實作。更值得注意的是 agent 的中間思考：它 grep 到同樣 pattern 有兩處，但判斷「使用者只要求他選的那張卡片，所以只改這裡」——這正好解釋為什麼作者下一步要手動跳到另一頁再抓一次：agent 刻意沒有擴大範圍。第二，側邊欄的 worktree 名稱從上一段的 `prowfish` 變成了 `Feat card component`，而終端路徑仍是 `~/orca/workspaces/prowfish`——代表 Orca 在 agent 開始做事後依任務內容自動幫 worktree／分支取了有意義的名字，資料夾名不變。另外面板上方已經有「Create PR」按鈕和「Stage All」，這是下一段流程的入口。

5. Git 工作流：AI 寫 commit、開 PR 2:43–3:28

在 changes 面板按 stagei all，commit messagei 可以自己寫也可以按 generate 讓 AI 生成。作者對生成的訊息滿意，commit 後直接按 create a PR。到 GitHub 看到 PR 已建立（有 commit message、沒有 PR 描述，作者說沒關係），按 create the merge commit 合併。這就是 design mode 的完整迴圈；作者刪掉這個 workspace 進入下一個主題。

推理因為上一段已經看到 git status 列出兩個改動的檔案，所以作者接著在 changes 面板按 stage all，然後面對「commit message 要自己寫還是讓 AI 寫」的選擇——他選了 generate 來測試品質。生成的訊息他覺得可以，就 commit，接著直接按 create a PR。跳到 GitHub 確認 PR 真的存在後，他還順手按了 create the merge commit 把它合進 main。整段的邏輯是「把 design mode 的迴圈走到底」：從指著畫面上的一個元素，到改動進 main，全程沒離開 Orca（除了最後去 GitHub 看一眼）。走完後他刪掉這個 workspace，代表 design mode 示範結束。

• CStage all→AI生成commit message→commit→Create PR，全程沒離開Orca→ 畫地圖
• RAI生成的commit message怎麼來的→ 存＋回想

AI 補充看截圖可以評估 AI 生成的 commit message 到底好不好：它寫的是「Fix course card text overflow in flex layouts」——注意它沒有照抄作者的 prompt（「讓 description 撐滿寬度」），而是從 diff（加 `flex-1 min-w-0`、拿掉 `max-w-2xl`）反推出「這其實是在修 flex 版面的文字溢出問題」，這比作者自己的說法更接近技術本質，難怪他說 happy with that。Staged changes 是 2 個檔案（`pages/index.astro` 與 `pages/courses/index.astro`），對應上一段做的兩次修改。GitHub 那張圖也有幾個值得注意的地方：PR 標題「Feat card component #2」直接拿分支名（上一段 Orca 自動取的 `feat-card-component`）轉成的；內文「No description provided」——作者說「沒有 PR message 但沒關係」，這對個人專案 OK，但團隊協作時 PR 描述通常是必要的，這是 Orca 這個流程目前的一個小缺口（或作者沒設定）。最後「create the merge commit」是 GitHub 三種合併方式之一（merge commit / squash / rebase），保留完整歷史。

術語:pull requesti

6. 平行編排：三個 worktree、三個 agent 3:28–4:29

接著建一堆 work tree 並分派給不同 agent：第一個用 OpenCode，第二個用 Antigravityi（作者很久沒用了），第三個用 Pii。每個都在自己的 work tree 裡，可以切換。作者事先讓一個工具（Improve）找出專案裡幾個小問題，現在把任務分派：Pi 做 001、Antigravity 做 005、OpenCode 做 007，然後依序按下執行。

推理因為上一段已經證明一個 worktree 可以獨立走完「改 → commit → PR」，所以作者接著把同一個動作乘以三：連按三次「建 worktree」，分別選 OpenCode、Antigravity（他說很久沒用了）、Pi，每個都在自己的 worktree 裡跑 setup。這裡的推理很直接：既然工位彼此隔離，那同時開三個就不會互相干擾。任務來源他事先準備好了——用一個叫 Improve 的工具掃出專案裡幾個小問題並編號，現在只要把 001 給 Pi、005 給 Antigravity、007 給 OpenCode，再依序按下執行。作者刻意選三個不同的 agent，是為了展示 Orca 不綁任何一家、也順便比較它們的表現。

• C工位彼此隔離，就能同時開多個worktree各派不同agent做不同任務→ 畫地圖
• ROrca怎麼確保依賴裝好才啟動agent→ 存＋回想
• R『Improve』這個工具的角色→ 存＋回想

AI 補充截圖裡三個 worktree 的名字是 `mojarra`（Pi）、`opaleye`（Antigravity）、`barnacle`（OpenCode）——Orca 隨機取海洋生物名，和第 3 段的 prowfish 一樣，等 agent 開始做事後才會改成有意義的名字（見第 4 段）。中間終端機正在顯示 Antigravity 的啟動畫面，有兩個作者沒點出來、但後面會很重要的細節：一是最上面那行 `Waiting for setup to finish before starting agent...`，證實 Orca 是「setup script 跑完才啟動 agent」的序列（透過環境變數 `ORCA_SEQUENCED_STARTUP_SCRIPT`），和第 2 段看到的行為一致；二是 Antigravity 顯示 `Antigravity Starter Quota`、模型 `Gemini 3.5 Flash (High)`——「Starter Quota」就是免費額度，這是一個伏筆。右側 git 面板顯示「No changes on this branch」，因為任務還沒開始跑。另外要補充「Improve」是什麼：作者沒解釋，從上下文看它是一個另外跑的 agent／工具，先把專案掃一遍、產出一份編號的小問題清單（001、005、007…），讓後續分派有現成的任務單。這一步其實是平行編排的前提——沒有先把工作切成互不重疊的小任務，三個 agent 同時跑就沒意義。

術語:parallel agent orchestrationi

7. Workspace Board：一眼看全部進度 4:29–5:08

切到 workspace boardi，可以看到每個 agent 各自在跑，做完會浮上來等審查。OpenCode 先宣稱完成；Antigravity 因為免費額度用完沒做完，作者直接把它刪掉；Pi 的任務比較大（大約九個步驟）還在收尾。作者說趁這段時間可以先去審 OpenCode 的成果。

推理因為上一段三個任務已經派出去，所以作者不再逐個切終端機，而是切到 workspace board 看整體。他的說法是「每個都在做自己的事，做完會浮上來、我們再審」——這是把監看從「主動輪詢」變成「被動等通知」。接著三個 agent 的結果剛好構成三種情境：OpenCode 宣稱完成（可以去審了）；Antigravity 免費額度用完、任務沒做完（直接刪掉 worktree，不糾結）；Pi 的任務比較大、約九個步驟、還在收尾（等它）。作者的處理方式本身就是在示範平行編排的心法：不是所有 agent 都會成功，失敗的就砍掉，不要讓它擋住其他人。

• C不逐個切終端機看進度，做完的agent自動浮上board，人再審→ 畫地圖
• C每個agent的用量額度各自獨立，用完就卡住，orchestrator幫不上忙→ 畫地圖
• Aworkspace board像看板管理，掃一眼就知道誰做完不用逐個問→ 批判類比
• EAntigravity做到一半卡在「Individual quota reached...Resets in 68h6m28s」→ 存＋演練
• RAntigravity任務失敗時作者的處理方式→ 存＋回想

AI 補充看板截圖補上了任務內容：Todo 0 / In progress 5 / In review 0 / Done 0 四欄，In progress 裡三張卡片分別是「Fix typescript errors and…」（Pi，prompt 是 `implement @plans/001-fix-typescript…`）、「Fix seo metadata warnings」（Antigravity）、以及還叫 `barnacle` 的 OpenCode。這解開了上一段的兩個謎：(1) 001 / 005 / 007 是 `plans/` 資料夾裡的 markdown 檔（第 4 段的檔案樹裡就有 `plans` 目錄），Improve 產出的是一份份計畫檔，agent 用 `@plans/001-…` 引用；(2) 卡片標題是 agent 開始做事後自動從任務改名的，還沒開工的 barnacle 就維持隨機名。卡片除了三個 agent 還有兩張 `main primary`，是兩個專案各自的主分支。第二張截圖是 Antigravity 的失敗現場：往上看它其實已經做了不少事——讀了 CoursePost.astro、列出課程目錄、編輯了兩個 .mdx 的 metadata、正要改 tags 頁——然後底下一行紅字 `Individual quotai reached. Please upgrade your subscription to increase your limits. Resets in 68h6m28s`。第 6 段啟動畫面上的「Starter Quota」在這裡兌現了。值得注意的是它做到一半的改動並沒有消失（仍在 opaleye worktree 裡），作者選擇刪掉是因為任務沒完成、審半成品不划算；如果那是關鍵任務，另一個做法是換一個 agent 接手同一個 worktree。這一段的 lesson 是：平行跑多個 agent 時，額度／費用是每個 agent 各自的限制，orchestrator 幫不上忙。

8. Diff 審查：加註解丟回 agent 5:08–5:53

審查 OpenCode 做的所有工作：可以直接在 diffi 上加註解，把註解送回給 agent 修改。滿意就 stage all、建 PR。回到 board 看 Pi，也收尾完成了，同樣 stage、生成 commit message、commit、開 PR。跳到 GitHub 看到兩個 PR 都在。

推理因為上一段的看板只告訴你「誰做完了」、不告訴你「做得對不對」，所以作者接著打開 OpenCode 的 diff 逐行看。他強調的重點是：可以在 diff 上直接加註解，然後把註解送回給 agent——這比自己動手改（第 4 段的 Monaco 編輯器）更省力，也比重新打一段 prompt 更精準，因為註解本身就帶著行號與上下文。審過滿意就 stage all、建 PR。接著回看板，Pi 也做完了，同樣的四步（stage、generate commit message、commit、create PR）再走一次。最後到 GitHub 看到兩個 PR 並排——這是平行編排的收成畫面：三個 agent 出發、兩個成功、兩個獨立的 PR。

• C逐檔看agent的diff，在行上加註解比自己動手改或重打prompt更省力精準→ 畫地圖
• A在diff上加註解送回agent，像GitHub PR review在某行加comment→ 批判類比
• Ebarnacle worktree的diff顯示Changes 8，比design mode那次的兩個檔案多很多→ 存＋演練
• Preview AI agent的diff時用行內註解取代重寫prompt→ 練習

AI 補充截圖顯示的是 `Card.astro` 的 diff（路徑在 barnacle worktree 下，分支已改名為 `feat-cleanup-lint-and…`），變更是把 props 解構裡沒用到的 `variant = "h2"` 拿掉——OpenCode 的分頁標題「Remove unused impo…」也印證 007 這個任務是「清理 lint 警告／未使用的 import 與變數」。右側顯示 Changes 8，也就是這次改了八個檔案，比 design mode 那次的兩個檔案多得多，這正是需要逐檔審查的原因。左側行號旁邊有一個「+」圖示，那就是加註解的入口（和 GitHub PR review 的體驗一樣）。作者沒說但值得補的一步：「把註解送回 agent」的實際效果是 Orca 把你的註解（含檔案與行號）組成一段 prompt 塞回該 worktree 裡的 agent 對話，agent 再改一次、你再看一次 diff——這是一個人機來回的閉環，工頭不寫 code，只批改。另外注意三個任務的性質：TypeScript 錯誤、SEO metadata、lint 清理——都是「小、獨立、不會碰同一批檔案」的任務，所以兩個 PR 可以分別合併而不衝突；如果任務會改到同一個檔案，平行跑的收成階段就會在 merge 時打架，這是選任務時要先想到的。

術語:annotationi

9. 還能做更多：比稿、handoff、sub agents 5:53–6:36

影片只涵蓋 Orca 的一小部分功能。剛才是讓不同 agent 平行做不同任務；也可以叫所有 agent 做同一個任務，比較 diff 後挑最好的。還有 agent handoffi：一連串任務由一個 agent 交棒給下一個，或用 sub agentsi。作者建議去試試 Orca，最後自我介紹：做短而實用、尊重觀眾智商與時間的影片。

推理因為前面示範的是「不同 agent 做不同任務」，所以作者接著把同一套機制換個用法：也可以「所有 agent 做同一個任務」，然後比較各家的 diff、挑最喜歡的——這把 Orca 從生產工具變成評測工具，正好回應第 6 段刻意選三個不同 agent 的動機。第二種是 agent handoff：任務有先後依賴時，一個做完交給下一個；或用 sub agents 把大任務拆開。他沒有示範這兩種，只是點名，然後收尾建議觀眾去試 Orca，並自我介紹：做短而實用、尊重觀眾智商與時間的影片。

• C任務有先後依賴時，一個agent做完交給下一個；或用sub agents把大任務拆開→ 畫地圖
• P同一任務派給兩個以上agent，比較diff只合併一個→ 練習
• R平行分工、比稿、agent handoff三種用法的差別→ 存＋回想

AI 補充把三種用法對回前面建立的概念，就能看出它們共用同一套基礎設施（worktree 隔離 + board 監看 + diff 審查），差別只在任務怎麼分配：(1) 平行分工——N 個 agent × N 個不同任務，成果是 N 個獨立 PR（第 6–8 段示範的）；(2) 比稿——N 個 agent × 同一個任務，成果是 N 個 diff，只留一個合併、其餘 worktree 刪掉，本質上是用實際產出來選 agent／模型；(3) handoff——1 個任務鏈，agent A 的產出是 agent B 的輸入，需要的是順序而非隔離，Orca 要處理的是「A 做完自動啟動 B」。sub agents 則是第三種的變體：由一個主 agent 自己拆任務、派給子 agent，這在 Claude Agent Teams 這類工具裡是內建能力（第 2 段的選單裡就有）。要注意 (2) 和 (3) 影片都沒有實際示範，作者只是口頭提到，實際操作方式與限制需要自己查文件。最後的自我介紹看似與內容無關，但它解釋了整支影片的風格：六分鐘、不講原理、每個功能只做一次示範——這也是為什麼很多背景（worktree 是什麼、Improve 是什麼、quota 怎麼算）需要由這份筆記補上。