【2026 最新】Orca Graph Engineering 怎麼做？5 步打造可驗收的多 Agent 工作圖

最後更新：2026年7月30日 · Terry Chen

Orca Graph Engineering 教學：Task Graph、Evidence Gate 與改圖權

你把「盤點、實作、測試、整合」交給多個 AI Agent，看起來每個人都回報完成，最後一開真實瀏覽器，卻發現後端路由根本不存在。這正是 Orca Graph Engineering 想解決的問題：不是再多叫幾個 Agent，而是讓工作有依賴、有證據、失敗後也知道該往哪裡修。

2026 年 7 月，一篇 Orca 實作案例把這個概念講得很具體：原本的任務圖假設基礎設施已就緒，真實裝置驗收卻推翻前提，協調 Agent 因而補上新任務再重新驗證。這是很好的教材，但它是作者的單次案例，不是 Orca 的官方效能測試，也不代表 Orca 會自己修好所有工作。

這篇專為第一次接觸多 Agent 編排的讀者寫。我會先用白話說清楚 Graph、Gate 與 Replan，再帶你用目前 stable 版 Orca 跑一次可複製的五步流程；你不需要先懂圖論，也不用背一大串框架名詞。

Table of Contents

先說結論：Orca Graph Engineering 是什麼？

先記住這條式子：

可靠長任務＝ Task Graph（工作圖）＋ Evidence Gate（證據閘門）＋ Replan Authority（改圖權）

Task Graph 回答「誰先做、誰能平行、誰要等誰」。
Evidence Gate 回答「有什麼真實證據，足以讓下游放行」。
Replan Authority 回答「前提錯了時，誰可以補任務、停下游、要求重驗」。

Graph 主要改善路由、責任與可觀察性；它不會讓模型突然變聰明。測試寫錯、判準不完整，整張圖一樣可能得到假綠燈。若你還不熟悉 Agent 的執行層，可以先讀 AI Agent Harness 是什麼，再回來看這張工作圖。

Orca Graph Engineering 的 Task Graph、Evidence Gate 與 Replan 三層可靠性圖 — 工作圖安排交通，證據閘門決定能否放行；失敗則成為下一版計畫的輸入。

Graph 不是新模型：先看懂 3 個基本零件

LangGraph 官方文件把圖拆成 State、Nodes、Edges。套到日常工作，就是「大家共用什麼資訊、每一站做什麼、下一站去哪裡」。Graph Engineering 這個稱呼在 2026 年再次流行，但圖、狀態機與工作流並不是新發明；Loop 也沒有消失，它只是 Graph 裡的一個循環。

① Node：「一個有合約的工作包」

好 Node 不是「把登入做好」，而是「盤點登入相關檔案，輸出路由、API 契約、風險清單，不修改程式」。它要有輸入、輸出、檔案所有權與完成條件。工作包越清楚，平行 Agent 越不容易互踩。

② Edge：「真的依賴才畫線」

如果 B 必須讀到 A 的資料、通過 A 的控制門禁，或等待 A 完成不可逆操作，A → B 才是真依賴。只是習慣上先做 A、再做 B，不一定需要 Edge。找出真正依賴，才有機會把獨立工作平行化。

③ State：「接力棒裡帶著什麼」

State 可以是任務狀態、輸出、測試結果、決策與訊息。Orca 的 orchestration 層用 Task、Dispatch、Message 與 Decision Gate 保存協作狀態；Orca 本身不是模型，也不是替你判斷產品是否正確的 evaluator。白話說：它提供交通號誌與行車紀錄，目的地仍要由你定義。

想先掌握不含工具操作的完整方法，可以搭配既有的 Graph Engineering 基礎教學與 Loop Engineering 教學閱讀。

什麼時候值得用 Orca Graph Engineering？

適合的是有明確交接、可平行區塊、驗收門禁，而且失敗後需要保留現場的長任務，例如跨前後端功能、研究加原型、多人 code review、真實瀏覽器或裝置測試。這時 Orca 的 terminal、worktree 與 orchestration state 能讓責任更清楚。

先不要用的是修一個 typo、單一檔案小 bug、所有步驟都依賴同一份完整上下文，或多個 Agent 會同時改同一個資料庫與 production 環境的工作。成熟、固定的 SOP 也常由 script、CI 或狀態機做得更便宜、更可預測。多 Agent 不是免費加速；協調、審核與整合本身都有成本。

判斷口訣很簡單：沒有真正可分解的工作，就不要為了「看起來很 Agent」硬畫 Graph。

Orca Graph Engineering 實作前：先避開版本陷阱

Orca 是一個把多個 terminal CLI Agent 放在同一個桌面環境管理的開源工具。它可以搭配你原本使用的 Codex、Claude Code 等 Agent；模型訂閱、API token 與運算成本仍由各服務計算。官方畫面如下：

Orca 官方桌面介面：左側專案與工作樹、中央 Agent terminal、右側文件 — Orca 官方桌面介面示意。每個 Agent 可以在 terminal 中工作，是否使用獨立 worktree 則要由協調者明確選擇。圖片來源：Orca 官方 GitHub。

截至 2026 年 7 月 30 日，官方 latest stable 是 v1.4.161；同日的 v1.4.162 RC 已改用新的 Run／Delivery 模型，而官網 orchestration 頁面已顯示新版命令。這兩套命令不能混用。

所以第一條排錯指令不是上網抄範例，而是讀取安裝版隨附的契約：

orca skills get orchestration --full

下面主流程以 v1.4.161 stable 為準。若你的本機指南出現 run-create 與 worker-start，代表你走的是新版流程，請完整跟隨該份本機指南，不要把新版開頭接到 stable 的 dispatch --inject 範例後面。

Orca Graph Engineering：5 步建立第一張工作圖

Step 1：安裝 Orca、開啟 orchestration

macOS 可依 Orca 官方安裝文件使用 Homebrew：

brew install --cask stablyai/orca/orca
brew upgrade --cask orca

開啟 Orca 後，到 Settings → General 註冊 CLI，再到 Settings → Experimental 啟用 orchestration，最後驗證 runtime：

command -v orca
orca status --json
orca skills get orchestration --full

Windows 與 Linux 請用官方下載方式；Linux 若系統已有同名 GNOME 指令，官方建議改用 orca-ide。只要 status 能連到正在執行的 Orca runtime，才進下一步。

Step 2：先寫驗收，再建立 Task DAG

我們用「讓聯絡表單真的可用」當例子。不要先叫 Agent 寫碼，先把成功證據定義成三種情境：正常送出、欄位錯誤、API 失敗。然後建立四個任務：盤點 A、定義驗收 B、實作 C、真實瀏覽器驗收 D；C 依賴 A＋B，D 依賴 C。

orca orchestration task-create \
  --task-title "盤點現況" \
  --spec "盤點表單元件、送出 API 與錯誤處理；只輸出清單" \
  --json

orca orchestration task-create \
  --task-title "定義 Eval" \
  --spec "定義成功、欄位錯誤、API 失敗三種可觀察證據" \
  --json

orca orchestration task-create \
  --task-title "實作表單" \
  --spec "依盤點與驗收規格完成表單實作" \
  --deps '["<task_a>","<task_b>"]' \
  --json

orca orchestration task-create \
  --task-title "真實驗收" \
  --spec "用真瀏覽器送出表單，保存 network 與畫面結果" \
  --deps '["<task_c>"]' \
  --json

--deps 裡放的是前面回傳的 Task ID。Orca 公開 CLI 支援建立帶依賴的新 Task；本文不宣稱它能任意修改既有 Task 的所有 Edge。這個邊界很重要：能「新增下一個節點」，不等於 Agent 可以任意改寫整個系統。

Step 3：建立 worker，明確指定工作位置

先開一個 Agent terminal，等待它真的進入可接收指令的狀態：

orca terminal create \
  --worktree active \
  --title form-audit \
  --command "codex" \
  --json

orca terminal wait \
  --terminal <worker_handle> \
  --for tui-idle \
  --timeout-ms 60000 \
  --json

--worktree active 代表同一個 checkout，只是多一個 terminal，沒有檔案隔離。若真的要平行修改程式，才建立獨立 Git worktree，並替每個 worker 指定模組、port、test database 與裝置 session。Orca worktree 文件也提醒，共用依賴與忽略檔案要另外配置；worktree 不是作業系統安全沙箱。

Step 4：派工、等待，不把「完成回報」當成正確

把第一個 ready Task 派給 worker，再確認 Dispatch 確實存在：

orca orchestration dispatch \
  --task <task_a> \
  --to <worker_handle> \
  --inject \
  --json

orca orchestration dispatch-show \
  --task <task_a> \
  --json

orca orchestration check \
  --wait \
  --types worker_done,escalation,decision_gate \
  --timeout-ms 900000 \
  --json

--inject 會把任務與 lifecycle 說明送進 Orca 能辨識的 Agent CLI。有效的 worker_done 會結算這次 Task／Dispatch，但它只代表「worker 已回報完成」，不是「功能已被獨立證明正確」。接著用 orca orchestration task-list --ready --brief --json 找到解鎖的下一波。

Step 5：讓 Evidence Gate 阻擋下游，失敗就補 Task 再驗

最後的 D 不要只問模型「你覺得可以嗎」，而要取得真實瀏覽器的 network response、畫面成功訊息與錯誤狀態。Gate 是控制流：證據不足就不放行。若 D 發現 API route 不存在，正確做法不是把 D 原地重跑三次，而是保留失敗證據，新增「修復 API」與「重新驗證」兩個 Task：

orca orchestration task-create \
  --task-title "修復 API" \
  --spec "依真實驗收證據補上後端 route 與錯誤處理" \
  --deps '["<task_d>"]' \
  --json

orca orchestration task-create \
  --task-title "重新驗證" \
  --spec "重跑三種瀏覽器情境，保存 network 與畫面證據" \
  --deps '["<api_fix_task>"]' \
  --json

這就是最保守、也最容易稽核的「Graph 隨證據成長」：協調者根據新發現補節點，讓新驗收依賴真正的修復結果。需要人類判斷是否允許改 API contract、執行 migration 或部署時，再用 gate-create／gate-resolve 設正式決策門禁。

Orca Graph Engineering 驗收失敗後新增資料遷移與重新驗收節點的流程圖 — 驗收失敗不是終點：保留證據、診斷缺口、補任務，再建立一輪新的驗收。

4 個最容易踩的坑：Graph 有了，為什麼還會錯？

坑 1：三個 reviewer 都說 PASS，就當成真相

多個相似模型可能共享同一個盲點。至少混合 deterministic test、真實執行結果、模型 review 與必要的人類抽查。Eval 回答「判定如何」，Gate 才決定「能不能繼續」。即使使用真機或瀏覽器工具，selector、測試資料與判準仍可能寫錯。

坑 2：把 Git worktree 當安全沙箱

Worktree 能避免同一個 checkout 互踩，但不能隔離 credentials、網路、外部帳號、共用 cache 或 production database。高風險操作應改用手動權限、隔離 VM 與人類 Gate；合併後還要由唯一 merge owner 重跑整體測試。

坑 3：凡事平行，忽略協調稅

平行只適合真正獨立的工作。嚴格 sequential、共享上下文很多、工具操作密集的任務，增加 Agent 反而會增加 token、等待與整合成本。若你在選 coding Agent，可先看 Claude Code vs Codex 客觀比較；工具差異重要，但 Graph 的責任邊界更重要。

坑 4：把第三方視覺化工具當成 Orca 官方功能

原始案例畫面使用的 npx orca-viz@latest 是非官方、第三方、唯讀 viewer，不是 Orca 內建 DAG 介面。它讀取 Orca 的內部資料庫，其中可能包含 task spec、prompt 與 message；若要使用，先看版本相容與網路暴露設定，預設只在本機查看，不要把 archive 隨意分享。

怎麼選：單 Agent、固定流程，還是 Orca 工作圖？

一個明確小任務：用單一 Agent，加一個可靠 verifier。
成熟、固定、每天重跑的 SOP：優先用 script、CI 或 state machine。
有多人 ownership、平行工作、交接與 Gate 的長任務：使用 Orca Graph Engineering。
路徑高度不可預測的探索：先用簡單 Agent loop，讓結果逐步收斂，再把重複模式固化成 Graph。

如果你的目標是親手做出最小 Agent loop，下一篇可接著看 30 行概念碼打造 AI Agent Harness；想比較另一種「指揮官型」工具，也可延伸到 Hermes Agent 完整教學。

Orca Graph Engineering 常見問題

1. Graph Engineering 等於 DAG 嗎？

不等於。DAG 是沒有循環的有向圖；需要 retry、修訂、重新驗收或人類介入的 Agent 流程常會形成 cycle。Orca 的 Task dependency 可先畫成 DAG，但完整執行策略仍可能包含回頭修正。

2. Orca 會自動幫我拆任務、排程、修 Graph 嗎？

不應這樣假設。Orca 提供 Task、Dispatch、Message、Gate、terminal 與 worktree 等 primitives；由 coordinator 或使用者決定拓撲、concurrency、worker placement 與放行規則。不同版本另有不同程度的 coordinator automation，先讀本機 orchestration skill。

3. worker_done 代表測試通過嗎？

不是。它是有效 Dispatch 的 lifecycle 完成訊號。正確性仍要由測試、編譯、瀏覽器、真機、原始資料或人工審核等外部證據確認。

4. 每個 Agent 都應該放在獨立 worktree 嗎？

不一定。只讀研究可以共用 active worktree；會平行修改不同模組時才需要分離 checkout。即使不同 worktree，也要隔離 port、database、device 與 deploy target。

5. Orca 是免費的嗎？

Orca 專案採 MIT 授權，但 AI 不等於零成本。你仍要負擔所用 Agent 的訂閱、API、token、VM 與驗證成本；費用應以各 provider 帳單為準。

6. 我可以直接照官網的 run-create 嗎？

先看本機版本。2026 年 7 月 30 日官網已顯示 v1.4.162 RC 流程，而 latest stable v1.4.161 仍使用另一套命令。先執行 orca skills get orchestration --full，整段流程只跟一份版本契約。

7. 驗收一定要用 AI reviewer 嗎？

不用。能用 deterministic test、schema validation、編譯器或真實 API response 判斷的地方，先用它們；AI reviewer 適合處理語意、品質與開放式規範，但不該獨占放行權。

8. 新手第一張 Graph 應該多大？

四個 Node 就夠。拿一個現有三步驟 workflow，補上一個接到真實證據的 Gate；先證明「失敗能阻擋下游」，再考慮增加更多 Agent。

給新手的 5 個重點

先寫可觀察的驗收證據，再拆任務。
只有資料、控制、權限或真實先後關係才畫 Edge。
worker_done 是回報，不是品質證明。
失敗先診斷；缺前提就補 Task，再建立新的驗收。
命令變動快，永遠先讀本機 orca skills get orchestration --full。

📚 延伸閱讀

Graph Engineering 基礎教學：先建立 Node、Edge、State 與 verifier 的完整心智模型。
AI Agent Harness 是什麼：看懂模型外面的執行、工具、記憶與停止條件。
動手打造 AI Agent Harness：用概念碼把 loop、trace 與 gate 串起來。
AlphaLab AI 專區：追蹤 Agent 工具、方法與最新實作。

結語：先做一張會「拒絕放行」的小圖

Orca Graph Engineering 最值得學的，不是把畫面塞滿 Agent，而是把責任、證據與改圖權放到正確位置。回到開頭那條式子：Task Graph 安排行程，Evidence Gate 守住品質，Replan Authority 讓系統在前提錯誤時能轉彎。

現在就挑一個三步驟工作流，畫出四個 Node：盤點、實作、真實驗收、失敗後修正；為驗收寫一條能被機器或人看見的證據，再決定是否需要 Orca。想把這套方法真正變成自己的工作系統，也可以從 AlphaLab 課程繼續練習。