Orca（ADE）：圍繞 terminal AI coding agent 的工作空間——隔離 worktree、多 agent orchestration、瀏覽器標註

1. Orca 是什麼：ADE 與本片的問題 0:00–3:14

作者介紹 Orca 是一個 ADE（agent development environment）：專為 terminal 型 AI coding agent 打造的工作空間，不限特定 agent，用你既有的 AI 訂閱。它的價值不在「能跑 agent」，而在圍繞 agent 建的東西：隔離 Git worktreei 並行跑多個 agent、內建瀏覽器可點 UI 元素送進 prompt、手機 companion、多 agent orchestrationi。本片要回答：它會是 terminal／coding／Git／browsing 的 all-in-one 工具，還是只是又一個花俏的 AI 玩具？1:50–3:15 為贊助商 Morph（ModelCode.ai）的 legacy 專案現代化廣告。

推理因為作者已經天天在 terminal 裡跑 agent，所以他先替 Orca 下一個跟 IDE 區隔開的定義——ADE（agent development environment）——再刻意強調「重點不是能跑 agent，而是圍繞 agent 建了什麼」，然後把四個賣點（隔離 Git worktree 並行、內建瀏覽器點元素送 prompt、mobile companion、多 agent orchestration）一口氣列出來當作後面要逐一驗證的清單，最後把整支影片濃縮成一個可被否證的問題：all-in-one 工具，還是花俏玩具？

• CADE 不是給人寫程式的 IDE，而是圍繞正在寫程式的 agent 建的管理工作空間→ 畫地圖

AI 補充作者用「ADE」這個詞時沒有解釋它和 IDE 的差別在哪，但這個差別是整支影片的隱含前提：IDE 的使用者是人，工具幫人寫程式；ADE 的第一使用者是 agent，工具幫人「管理正在寫程式的 agent」。所以作者列的四個賣點其實都在解決「同時管好幾個 agent」會遇到的問題——它們會互相改到同一個檔（→ 隔離 worktree）、它們看不到瀏覽器裡的畫面（→ 點元素送 context）、你人不在電腦前（→ 手機 companion）、任務太大一個 agent 做不完（→ orchestration）。另外要注意 1:50–3:15 是贊助商 Morph（ModelCode.ai）的廣告，內容是 legacy 專案現代化，與 Orca 無關，可以直接跳過。字幕裡的「Py」其實是 Pii（pi.dev 的 Pi coding agent），不是 Python。

術語:ADE (agent development environment)iCLI agenti

2. 第一眼：官網與介面配置 3:14–5:54

orca.dev 官網可下載 Mac／Windows／Linux 版，原始碼在 GitHub；定位偏開發者，但能透過 SSHi 連遠端伺服器，所以也適合維運。進入 app：左側是 tasks、automations、mobile companion 與 project 管理（可分群，可放一般資料夾或 Git repo，後者能在隔離 worktree 管不同 branch）；中間是多 tab（terminal、browser、markdown、code editor、mobile emulator、各種 agent）；右上是 quick commands；右側是 file explorer 與 Git source control。

推理因為上一段只給了抽象的賣點清單，所以作者接著用空間來組織它們：左欄是「管理」（tasks、automations、Orca Mobile、project 群組），中欄是「工作」（多 tab：terminal、browser、markdown、code editor、mobile emulator、agent），右欄是「檢視」（file explorer、Git source control），右上是 quick commands。他順帶用官網文案「run a fleet of agents、review the AI output、Git integrations」加上「可透過 SSH 連遠端伺服器」來回應開頭的主張——雖然偏開發者，但維運也用得上。

• ROrca用量條顯示的是滾動時間視窗額度，不是月配額→ 存＋回想

AI 補充截圖（262 秒）能看出幾個作者沒細講但值得注意的細節。第一，左欄 Projects 底下有兩層：群組（Homelab、xcad、christianlempa、ObsidianChristianLempa）→ project（example-apps、tutorials、homelab、xcad）→ 展開後才是 workspace（xcad 底下那個帶綠點的 xcad），綠點代表這個 workspace 目前有東西在跑；這個「project → workspace」的兩層結構就是稍後隔離 worktree 的容器。第二，右側 explorer 此刻列的是作者家目錄的 dotfiles（.claude、.codex、.aider、.copilot、.continue…），因為這個 terminal 的 PWD 是 `~`——explorer 跟著目前 workspace 的路徑走，不是固定指向某個 repo。第三，左下角有兩條用量條「6% used 5h」「3% used wk」，就是他訂閱的 5 小時視窗與週視窗額度，下一段會解釋它從哪裡來。作者說 Orca 可跑在 Mac、「Intel Windows」與 Linux；「Intel Windows」是他的口語，實際是指 Windows 版（原始碼公開在 GitHub），不必糾結於 CPU 架構。另外，中欄的 mobile emulator 只是被點名而未示範，作者自己不是行動開發者，可以忽略。

術語:terminal emulatoriquick commandipull requesti

3. 設定：agents、用量、orchestration skill 5:54–7:48

開始前要設三件事。一、Agents：設預設 agent（或 auto），支援 Codex、Grok、Pi、Claude、OpenCode、Copilot、Gemini、Antigravity、Goose、Kilo Code 等十幾種，可安裝／啟用／停用。作者只把 Codex／Grok 的整合當成左下角「訂閱用量」顯示用（看 ChatGPT Pro 本週已用多少、可重設視窗、管理多帳號）。二、AI provider accounts：Claude、Codex、Gemini、OpenCode、MiniMax、Grok。三、安裝 orchestration skilli：它把「如何跟 Orca orchestration 溝通」的指令注入 agent，要定期更新。

推理因為版面已經看過、但沒有 agent 就什麼都示範不了，所以作者先處理 Agents 頁：設預設 agent 或 auto，並展示三十幾種可安裝的 CLI agent 清單，用它坐實第 1 段「不綁特定 agent」的主張。接著他把「安裝 agent」和「顯示用量」拆開：他不真的用 Codex／Grok agent，只是啟用整合以便左下角顯示 ChatGPT Pro 與 Grok 的額度；於是自然帶到 AI Provider Accounts 這一頁。最後他補上 orchestration skill——它是把「怎麼跟 Orca 的協調工具講話」的指令塞給 agent 的東西，而且要定期更新——為稍後的多 agent 示範鋪路。

• Corchestration skill 教 agent 怎麼跟 Orca 的協調工具講話、彼此傳訊→ 畫地圖
• E31種可安裝CLI agent，每個底下印著實際啟動指令→ 存＋演練

AI 補充截圖（374 秒）比作者口頭說的更有資訊量。第一，頁首寫「Available to install: 31 agents」，而且每個 agent 底下都印出 Orca 實際用來啟動它的命令列：`claude --dangerously-skip-permissions`、`copilot --yolo`、`gemini --yolo`、`aider --yes-always`、`goose GOOSE_MODE=auto`、`amp --dangerously-allow-all`。這說明兩件事：Orca 對每個 agent 的「整合」本質上就是一條啟動命令（所以新 agent 很容易加進清單），而且這些命令預設都帶了跳過人工確認的旗標——原因是 agent 在 Orca 裡常是無人看管地跑，之後示範時會看到這個選項的重要性。第二，左側設定樹在 AI CAPABILITIES 下有 Agents、AI Provider Accounts（標 OPTIONAL）、Orchestration（標 Installed）、Computer Use 與 Voice（Not installed），所以作者講的「三件事」剛好就是這一區的前三項；Computer Use 和 Voice 是影片沒碰的功能。第三，關於用量：ChatGPT Pro 這類訂閱的限制是「滾動時間視窗」而不是月配額，畫面左下的「6% used 5h／3% used wk」就是 5 小時視窗與週視窗；作者說「可以 reset the window」其實只是重設 Orca 端的統計起點，不會真的重設 OpenAI 那邊的額度。字幕裡的 agent 名字有幾個是誤聽（Ada → 畫面上的 Ante；Rover Dev → Atlassian 的 Rovo Dev），不影響理解。

術語:AI provider accountiusage windowi

4. 加入專案：掃描、匯入、分群 7:48–9:12

Orca 剛裝好是空的，要把現有 repo／資料夾加進左側 project manager。Add project → 選來源（本機、Docker contexti、遠端伺服器）、或 clone from URL、或建新專案。選一個父資料夾會自動掃描底下所有 repository，可勾選要匯入哪些並自動分群；分開匯入再手動分群很麻煩。作者依 Git 平台分群：self-hosted GitLabi 的 home lab repo 一群、個人資料夾／GitHub repo／Obsidian vault 另一群。

推理因為設定好了 agent 卻沒有工作對象，所以作者先解決最現實的問題：你的專案大多已經在磁碟上，不是要新建。於是 Add project 的路徑是「瀏覽資料夾」為主，而不是 clone；他再往前推一步——選一個父資料夾讓 Orca 自動掃描底下所有 repository、勾選要匯入的並自動分群——因為一個一個匯入再手動分群「工作量太大」。分群的邏輯他用的是 Git 平台：自家 GitLab 上的 home lab repo 一群，GitHub、本機資料夾、Obsidian vault 另一群。

• RAdd project時怎麼判斷資料夾是不是repository→ 存＋回想

AI 補充作者沒說清楚「掃描」的判斷依據：Orca 是找子目錄裡有沒有 `.git`，有的就當 repository 列出來、可勾選；沒有的只能整個當一般資料夾加入。這解釋了為什麼第 2 段截圖裡 Projects 底下的 Obsidian vault 只是一個資料夾節點、沒有 workspace 子層——它不是 Git repo，所以之後所有和 branch、worktree 有關的功能對它都不適用。來源選項裡的「Docker context」與「remote servers」對應第 2 段提到的 SSH 遠端能力：專案不一定在本機，可以住在另一台伺服器或容器環境裡，Orca 的 terminal 分頁就會在那裡開。至於分群，本質只是側欄的視覺整理，不影響 Git 行為；作者按平台分是因為他的 home lab repo 全在自架的 GitLab 上，權限與 URL 一致，方便一起管。

5. Git worktree：實體隔離的 branch 目錄 9:12–11:40

Orca 在 Git project 上才發揮全力。Project settings 可設 worktree 預設位置：Orca 會在 ~/orca workspaces 下建一個新目錄再連回 repo，所以磁碟上是實體分開的目錄、各自不同 Git checkouti。匯入 repo 時第一個 workspace 對應當前 branch；按 + 可新建 worktree（如 feature test app），以 agent 或空白 terminal 啟動，PWD 顯示它真的住在另一個路徑，explorer 裡檔案和來源 branch 一樣。新建檔案會自動開 markdown editor，也能編程式碼，但作者認為不如 VS Code／Zed、沒有外掛——因為 Orca 是 ADE 不是 IDEi：讓 agent 寫檔，人只負責審閱。

推理因為專案已經匯入、而 Orca 的價值要在 Git repo 上才顯現，所以作者先把 worktree 的物理事實講清楚：每個 worktree 是磁碟上實體分開的目錄、各自一個 Git checkout，匯入時的第一個 workspace 對應當下的 branch。接著他用最小示範驗證這個說法——建 worktree、跑 pwd 看路徑、看 explorer 檔案與來源 branch 一致、新增一個檔案。新增檔案時 markdown 編輯器自動打開，順勢把話題帶到「Orca 當編輯器好不好用」：不如 VS Code／Zed、沒有外掛；但他不把這當缺點，而是回到第 1 段的定位——這是 ADE 不是 IDE，檔案該由 agent 寫、人只審閱。

• C每個worktree是磁碟上實體分開的目錄、各自一個Git checkout，讓多個agent不互踩檔案→ 畫地圖
• A每個worktree實體隔離，像飯店讓每個房客住不同房間不共用一張床→ 批判類比
• P把要並行做的功能拆成獨立worktree，依賴的放同一個→ 練習

AI 補充截圖（618 秒）的 Create worktree 對話框補了作者沒講的細節。「Name or Create From」欄位有五個模式：Smart、GitHub、GitLab、Branch、Name，提示文字是「Type a name, #1234, branch, GitHub or GitLab URL」——也就是說你不只能給名字，還能貼一個 issue 編號或 PR／MR 的網址，Orca 會據此命名 branch 並帶入 context；這是「worktree 對應一個工作項目」的設計思路。「Agent」欄預選 Pi，代表建好 worktree 後就直接在裡面開一個 agent session；「Create more」開關則是連續建多個。背景終端的提示字元寫著 `~/example-apps via main`，右側面板顯示「No changes on this branch」，可見此刻是在第一個 workspace（main）上。Git 層面補一步：作者說「linking this back to the repository」，實際是 `git worktree add` 讓新目錄的 `.git` 只是一個指向原 repo 的檔案而非完整複本，所以兩邊共用歷史、commit 互相可見，但工作目錄的檔案各自獨立——這正是「同時跑多個 agent 不會互踩檔案」的技術基礎。關於編輯器的評語，作者說「不能加 plugin 或擴充套件 yet」，這是 2026 年 7 月當下的狀態，之後版本可能改變。

術語:workspace (Orca)i

6. 跑第一個 agent：live coding 一個 demo app 11:40–14:10

作者開新 terminal 選 Pi agent（預設走 Codex model），下 prompt：在 example app 目錄建一個管理 home lab 設備與 IP 的 SvelteKiti 全端 app，附 Dockerfile 與開發用 Docker Composei。Orca 立刻辨識到 agent sessioni，在側欄列出來。這時可以再開其他 agent（Claude Code、Codex）或 orchestrate 它們分工前後端；不同 feature 放不同 worktree 避免互改同一檔——若 feature 彼此依賴則要換流程。切回原 worktree 看不到這些檔、也沒有 agent session，證明隔離是真的。接著在第二個 agent 下指令「檢查另一個 agent 的進度並寫文件」。

推理因為上一段確立了「檔案由 agent 寫」，所以作者沒有事先寫任何規格，直接用口語 prompt 開工：目標（home lab 設備與 IP 管理）、技術堆疊（SvelteKit 全端、Docker 容器、開發用 Docker Compose）——而且承認「我不知道該用什麼 stack」，先做再迭代。agent 一跑起來，Orca 就在側欄多了一個 Pi 的 session 條目，作者用這個現象推到第二層：這時可以再開 Claude Code 或 Codex，甚至分工前後端；再推到第三層：要避免 agent 互踩同一個檔，就把不同 feature 放不同 worktree——但若 feature 彼此依賴就不能這樣切。最後他切回原本的 main worktree，看見沒有那些檔、也沒有 agent session，用反證確認隔離是真的，然後在另一個 agent 下第二個任務：檢查第一個 agent 的進度並寫文件。

• COrca監看每個terminal分頁的程序，認出是已註冊的agent命令就掛上session條目→ 畫地圖
• R作者說的「Pi agent用Codex model」是什麼意思→ 存＋回想

AI 補充有兩處作者沒說明但會影響理解。第一，「Pi agent with my default Codex model」不是指他用 Codex CLI 這個 agent，而是 Pi 透過 plugin 用他 ChatGPT Pro 訂閱底下的 GPT 模型（第 3 段他明確說不啟動 Codex agent）——所以整段只有一種 agent（Pi）、一種訂閱在跑。第二，「agent session」被 Orca 辨識並列在側欄，是因為 Orca 監看每個 terminal 分頁裡啟動的程序，認出是已註冊的 agent 命令（第 3 段截圖裡的那些啟動命令）就掛上條目；這是後面所有「看得到其他 agent 在做什麼」的基礎。關於分工的建議，作者說得對但跳了一步：把前端、後端放在不同 worktree 並行，前提是兩者的介面（API 路徑、資料格式）已經先講好，否則各自做完 merge 時會對不上——這就是他說「feature 彼此依賴要走不同流程」的具體意思。字幕中的「Cloud Code」是 Claude Code。另外注意第二個任務其實是下在 main worktree 的另一個 agent 裡，它看不到 feature test app 的檔案，所以它「檢查進度」只能靠問第一個 agent，這是下一段的關鍵。

7. agent 互相溝通：orchestration skill 實戰 14:10–16:53

第二個 agent 讀了 orchestration skill（要在設定裡啟用），就能看到另一個 agent 在做什麼、能 spawn sub agenti，並透過 Orca 傳訊給第一個 agent：「我在寫文件，請簡短回覆預定的功能範圍與尚未完成的檔案」；第一個 agent 回覆後，第二個就能寫出文件。一般流程是：merge 進 repo → 在隔離 worktree checkout → 做各自的 feature。畫面上檔案陸續生成（Dockerfile、compose、架構文件）。缺點：agent 工作時終端會不斷往上捲，難看到目前進度（可能與 agent 有關）。作者順手叫 agent 把 porti 從 5173 改掉以免和另一個 demo 衝突。

推理因為第二個 agent 看不到對方的檔案，所以它唯一的路徑是「問」：orchestration skill 讓它知道可以用 Orca 的指令對另一個 session 送訊息。作者等第一個 agent 寫完當下的檔案，畫面上就出現那則訊息——「我在寫文件，請簡短回覆預定的功能範圍與尚未完成的檔案，然後繼續你的實作」——第一個 agent 回覆後，第二個 agent 開始產出文件。作者由此概括一般流程：先 merge 進 repo，再在隔離 worktree checkout 各做各的 feature；並坦白自己只是 vibe codingi、不確定開發者是否真的這樣做。接著他觀察缺點（agent 工作時終端不斷上捲、看不到當前進度，可能和 agent 有關），順手叫 agent 改 port 避免和另一個 demo 衝突，最後把話題帶到「該怎麼啟動這個 app」。

• Corchestration skill讓一個agent能對另一個session送訊息，甚至spawn新的sub agent→ 畫地圖
• Aagent間傳訊像開會時有人插一句話，原本報告的人聽完接著講完→ 批判類比
• E訊息出現在第一個agent的終端裡，格式像使用者親自打的話→ 存＋演練

AI 補充截圖（866 秒）是理解 agent 間通訊機制的關鍵。那則訊息出現在**第一個** agent 的終端裡，格式就像使用者親自打的一段話，接著第一個 agent 進入「Listing pending tasks for project files… Working…」——也就是說 Orca 的做法不是什麼特殊協定，而是把第二個 agent 產生的文字當成一則新的使用者輸入，塞進第一個 agent 的對話回合。這解釋了為什麼任何 CLI agent 都能參與：只要它會回應使用者輸入，就能被「傳訊」。訊息最後那句「continue your implementation afterward」也很重要：它是 skill 教第二個 agent 加上的禮貌指令，避免第一個 agent 被打斷後忘記回去做原本的事。底部狀態列有幾個作者沒提的細節：路徑 `~/orca/workspaces/feature-testapp` 證實第 5 段講的 worktree 位置；`(openai-codex) gpt-5.6-sol • medium` 證實第 6 段的推論——Pi 透過 Codex 供應商用 GPT 模型；`↑42k ↓8.3k … 4.2%/372k` 是這個 session 的 token 用量與 context 佔比。右側 explorer 裡 example-app 底下所有檔案都標 `U`（untracked），代表 agent 已經生出整個 SvelteKit 專案骨架但一個都還沒 commit，這是之後 source control 要處理的東西。關於作者「一般流程」的描述可以補一步：他其實描述的是 trunk-based 的 feature branch 流程——每個 feature 從 main 開 worktree、做完併回 main、再從新的 main 開下一個——這也是為什麼他說「現在這裡沒有可迭代的檔案」：main 上還是空的，要等這個 feature 併回去。

8. Quick commands 與內建瀏覽器看成果 16:53–18:25

Quick commands 可以是固定的 terminal 指令，也可以是 agent prompt（如「start the dev serveri」）：後者會另起一個 agent 去搞清楚這個專案怎麼啟動。dev server 起來後 command+click 連結就在 Orca 內開瀏覽器 tab，且綁在這個 worktree。agent 建的 app 叫 Home Base：儀表板、總數、網路、實際抓到了作者真實的 Proxmoxi 節點（DNS 解析有誤），可新增 entry（Proxmox prod 2、IP、hostname、類型、狀態）。作者五分鐘做出 home lab 管理 app，強調只是 demo 不會上 production。

推理因為每個 agent 生出的專案啟動方式都不一樣（npm run dev？docker compose up？哪個 port？），所以作者不把啟動指令寫死，而是用「agent prompt」型的 quick command，把「怎麼啟動」這個問題也丟給 agent。dev server 起來後，他用 command+click 讓 Orca 在同一個 worktree 裡開瀏覽器分頁——強調瀏覽器也是隔離在這個 worktree 的——然後第一次看到成品 Home Base：儀表板、統計、設備表，還能新增一筆 Proxmox prod 2。他用「五分鐘做出 home lab 管理 app」回應第 1 段的問題，同時劃清界線：只是 demo，不會部署到 production。

• Cquick command不寫死啟動指令，而是丟給agent一句prompt去決定怎麼啟動→ 畫地圖
• Rdev server的port和Docker Compose的port不同→ 存＋回想
• R作者誤判了Proxmox示範資料的來源→ 存＋回想

AI 補充兩張截圖補了幾個作者沒說的細節。第一張（1014 秒）：quick command 選單裡「Start Devserver」底下小字寫「Pi: Start the dev server」，旁邊另有「Command」項——所以 agent prompt 型的 quick command 是綁定某個 agent 的，這裡是 Pi；同時終端裡是上一段改 port 的結果：agent 把 Vite 的開發 port 改成 5179、更新兩份 README，並註明「Docker Compose remains on port 3000」——也就是開發模式（npm run dev）與容器模式（compose）走不同 port，作者接下來看到的是開發模式。側欄 feature-testapp 底下顯示「2 agents」，到第二張截圖變成「3 agents」，多出來的就是「Start the dev server」那個 agent——每個 agent prompt 型 quick command 都會多一個 session，用完記得關。第二張（1062 秒）：網址列 `http://localhost:5179/`，瀏覽器工具列有 Import 與幾個檢視按鈕；頁面資料表列了 Proxmox Node 01（10.20.0.11、pve01.home.arpa）、Core DNS、Container Sandbox 三筆。這裡要指出作者一個誤判：他說「它居然加了我真實的 Proxmox 節點、DNS 解析不對」，但這三筆的網域是 `home.arpa`（RFC 8375 保留給家用網路的範例網域）、IP 是 10.20.x 這種教科書式私有位址，而作者自己隨後輸入的真實主機名稱格式是 `prox-prod-2.home.<他的網域>.de`——所以這些幾乎可以肯定是 agent 生成的種子資料，不是從他機器上讀到的真實節點，「DNS 不對」只是因為它本來就是假資料。這個誤判提醒一件事：agent 為了讓 demo 好看會自行編造貌似真實的資料，審閱時要分清「它查到的」和「它編的」。

術語:agent prompt (quick command)i

9. 瀏覽器標註：點 UI 元素直接送進 prompt 18:25–20:13

內建瀏覽器的控制列可以「抓」任何頁面元素：hover 複製 HTML、開 dev tools 看原始碼，但最好用的是 annotate page elementi——點一個元素，附一句話（解釋這些 class、或「刪掉這段太長的介紹改成一句話」），加進 annotation 清單；可繼續標其他元素（「這裡加 Lucide icon 管理」）。送出時可選任何正在跑的 agent，它會自動把 URL、瀏覽器 tab、元素本體與你的需求貼進 prompt，agent 立刻讀檔改碼。

推理因為上一段看成品時已經有想改的地方（介紹太長、想要 icon），所以作者用這些真實需求示範 annotation 的工作流：先展示低階能力（hover 複製 HTML、inspect source）當對照，再示範高階的 annotate——它不只是複製 HTML，而是把「哪個元素 + 你想怎麼改」配成一組，可以連續標多個元素累積成 annotation 清單，最後送出時 Orca 自動把 URL、瀏覽器 tab、元素本體與你的需求組成 prompt。作者的推論是：這消除了「用文字向 agent 描述我在說頁面上哪個東西」這個最麻煩的溝通成本，所以是「真正最好的功能」。

• Cannotate把「哪個元素＋你想怎麼改」配成一組，自動組成送給agent的prompt→ 畫地圖
• E每個標註元素打包了十幾項context，遠比URL、tab、元素本體多→ 存＋演練

AI 補充第二張截圖（1189 秒）揭露了 Orca 替每個標註元素打包了多少 context，遠比作者說的「URL、tab、元素」多：Intent（change）、CSS Selectori、Location、Bounds（座標與尺寸）、Classes、元素文字、Nearby text、Nearby elements、Computed styles（display、寬高、margin、padding、顏色、字型…）、Full DOM pathi、原始 HTML，最後才是你的 Feedback；第二個元素（那個 `span "PR"`）也用同樣格式列出，還附上 Nearby text「Proxmox Node 01 Primary virtualization host」讓 agent 知道它在表格哪一列。這解釋了為什麼 agent 能「立刻讀檔改碼」而不用先問你指的是哪裡：selector 與 class 名（`s-y_bCXRrkrYfP` 是 Svelte 編譯時加的 scoped class hash）足以讓它 grep 到對應的 `.svelte` 檔。這也是第 1 段賣點「把 context 直接送進 prompt」的具體內容。一個作者沒明說的細節：側欄 feature-testapp 底下從 3 agents 變成 4 agents，多了一個「## Design Feedback」session 標「now」——他嘴上說「送給任何正在跑的 agent」，但這次實際上是新開了一個 agent 來處理；兩種都可以，差別是新 agent 沒有前面的對話脈絡、但也不會打斷正在做事的 agent。第一張截圖（1132 秒）還順帶證實了第 8 段的判斷：表格第四列是作者剛加的 Proxmox Prod 2，主機名 `prx-prod-2.home.clcreative.de`，和前三筆的 `home.arpa` 明顯是兩個世界。

術語:Lucide iconsi

10. Mobile companion 與驗證修改結果 20:13–21:45

Orca mobilei 已配對作者的 iPhone：能連上裝置、看到所有 tab、帳號用量、跳進任何 worktree 與 session、輸入指令、讀終端輸出。缺點：需要重排 tab 版面，有時卡在 loading，「有時好用有時不行」。回到瀏覽器 tab：agent 改完後頁面報錯，作者請 agent 測試修正或重啟 dev server；重啟後就好了——標題已移除、有了 icon，點 icon 還能開 icon 切換器。作者停掉 agent 準備把成果部署出去。

推理因為 agent 要跑一陣子，所以作者用這段空檔補上 mobile companion，而且不迴避缺點：它得改 tab 的解析度與版面，有時卡在 loading，「有時能用有時不行」，他不確定是自己的問題還是新版已修。回到瀏覽器時頁面報錯，他給了兩條路——叫 agent 測試修正、或只是重啟 dev server——先試便宜的那條，重啟後就正常了：介紹段落沒了、表格有了 icon、點 icon 能開切換器。這一輪「改 → 錯 → 重啟 → 好」讓他確認 annotation 的修改確實落地，接著停掉 agent，準備把成果併回 repo。

• C手機端以worktree(branch)為單位列出Pinned/Active，能看到並回應agent的權限確認→ 畫地圖
• Rannotate改完後頁面報錯，重啟dev server就好的原因→ 存＋回想

AI 補充截圖（1216 秒）有個容易誤讀的地方：左邊「Your phone is paired.」與「Mobile 7/4/2026」是作者真實的配對狀態，但右邊那個手機介面是 Orca 內建的示意畫面而不是他的 iPhone 即時畫面——上面列的 `feat/mobile-page #2491`、`runtime/web-pairing #2487`、`infra/notifier` 等是 Orca 自家 repo 的 branch 名與 PR 編號。不過這個示意圖恰好說明了手機端的資訊架構：以 worktree（branch）為單位列出 Pinned／Active，每項顯示所屬 repo、最後一則 agent 訊息或指令，其中 `infra/notifier` 顯示「awaiting permission · sudo apt install」——代表手機端可以看到、也可以回應 agent 的權限確認，這是「從手機控制 agent」最實用的場景（agent 卡在確認等你，你在外面按一下）。作者實際上沒有把手機畫面錄進影片，所以他對「有時卡住」的評價是使用者回饋而非可重現的示範。關於頁面報錯又重啟就好，作者沒解釋原因，可以補一步：agent 為了做 icon 管理裝了新套件（lucide 的 Svelte 版），而 Vite dev server 在啟動時就決定好要預先打包哪些依賴，執行中新裝的套件會讓它的模組解析對不上，這種錯誤本來就要重啟才會消失——所以「大部分時候重啟就好」不是玄學，而是「新增依賴後要重啟 dev server」這條規則。若是程式邏輯錯，重啟不會有用，那時才需要叫 agent 修。

術語:device pairingihot module replacementi

11. Source control：commit 與 merge request 21:45–22:35

目前在 feature test app branch。用右側 GitOps source control：stagei all changes → commiti（「app initially created」）→ publish branchi → 建 merge request 併回主 branch → 刪掉整個 workspace（feature 完成）。回到主 worktree 跑 pull，檔案就出現在磁碟上的 main branch，可以繼續在上面開新 branch、新 worktree 做更多功能。

推理因為 worktree 的隔離是靠 branch 實現的，所以要讓成果變成「專案的一部分」就得走一遍 Git 的合併流程；作者刻意全程用 Orca 的 GUI 面板而不打 git 指令，證明第 2 段介面導覽時提到的 source control 能力足以取代終端裡的 Git 操作。順序是：stage 所有變更、寫 commit 訊息、commit 到 feature branch、publish（推到遠端）、開 merge request 併回 main、然後刪掉這個 workspace——因為 feature 做完了，worktree 就沒有存在的理由。最後回到 main worktree pull，驗證檔案真的到了 main，並宣告可以在這個基礎上繼續開更多 branch、更多 worktree。

• Cstage→commit→publish→開merge request→刪worktree，走完Git合併的生命週期→ 畫地圖
• E一次commit有19個檔案全部新增，含agent自己加的健康檢查端點→ 存＋演練
• Preview agent的commit前先列出diff裡的新增檔案清單→ 練習

AI 補充截圖（1319 秒）證實幾件事。終端提示字元 `~/feature-testapp via feature-testapp` 顯示目前在該 worktree 與同名 branch 上；右側面板頂端的按鈕是「Create MR」、比較基準寫 `vs refs/remotes/origin/main`——MR 是 GitLab 的用語（見第 2 段 pull request），可見這個 example-apps repo 放在作者自架的 GitLab（第 4 段），Orca 會依平台切換用語與 API。STAGED CHANGES 有 19 個檔案，全部標 `A`（新增），其中 `package-lock.json +1845` 行、`+page.svelte +300` 行、另有 `routes/health/+server.ts`（agent 自己加的健康檢查端點）與 `lib/entity-icons.ts`（上一段 icon 功能的產物）——這就是「五分鐘」內 agent 產出的實際規模，也是人審閱時該逐一看過的清單。側欄還多了「restart the dev server」與「Can oyu test and fix the…」兩個 session，說明作者上一段其實兩條路都試了。作者的流程漏講了一步：建了 merge request 之後，必須有人在 GitLab 上**接受**它（或設定自動合併），main 才會有這些 commit；影片直接跳到「pull 後檔案出現在 main」，中間的合併動作被剪掉了。另一個要注意的順序：他先刪 workspace 再 pull——這在這裡安全，因為 branch 已經 publish 到遠端、commit 不會隨 worktree 消失；若還沒 push 就刪 worktree，本機的 commit 仍在 `.git` 裡但 branch 若被一併刪除就要靠 reflog 找回。至於 commit 訊息「app initially created」與口誤「merge into the main feature branch」都不影響結果。

術語:git pulli

12. Orchestration：一個 agent 指揮多個 sub agent 22:35–25:05

新建 worktree「add documentation」，給 Pi agent 一個大任務：實作 markdown 式 home lab 簡報系統，並「orchestrate 多個 sub agent 並行、用較低 thinking modei 省 token」。這個 agent 就變成協調者，側欄出現多個 sub agent tasks。但它誤啟了 Codex——作者得手動停掉，打算在 Pi 的 prompt 加 guardraili「orchestration 一律用 Pi 不用 Codex CLI」；反過來你也可以指定「前端用 Claude、API 用 Pi + MiniMax」。重要設定：agent permissions 設成 Yolo（Orca 以全權限啟動 agent、不做人工確認），否則 Claude／Codex CLI 當 sub agent 時會一直問「真的要做嗎」；Pi 預設就不會問。sub agent 完成後把結果回報給控制 agent，它驗證、分析、再 spawn 新 sub agent 修問題。

推理因為第 7 段只證明了兩個同輩 agent 能互傳訊息，所以作者這次把 spawn sub agent（第 7 段提到但沒用的那個能力）推到極限：不指定怎麼拆，只在 prompt 裡要求「並行」與「低 thinking mode」，看協調 agent 自己怎麼分工。結果同時暴露成功與失敗：成功的是側欄與分頁真的長出多個 sub agent，完成後把結果回報給控制 agent，它驗證、分析、再 spawn 新 sub agent 修問題；失敗的是它誤啟了作者沒設定好的 Codex，得手動停掉——作者的對策不是改 Orca，而是在 Pi 的 prompt 加一條 guardrail「orchestration 一律用 Pi 不用 Codex CLI」，並反過來指出你也可以刻意混用（前端給 Claude、簡單的 API 給 Pi + MiniMax）。由 Codex 會一直要權限這件事，他帶出 agent permissions 的 Yolo 設定：Orca 以全權限啟動 agent、不做人工確認——若把 Claude／Codex CLI 當 sub agent 沒開這個，它們會不停問「真的要做嗎」把流程卡死；Pi 預設不問，這正是他選 Pi 的原因之一。

• CYolo模式讓Orca用全權限旗標啟動agent，不做人工確認→ 畫地圖
• AYolo模式像自動駕駛設到最高等級，油門煞車都交給系統→ 批判類比
• P幫你的CLI agent寫一條guardrail規則→ 練習
• R協調agent怎麼等sub agent做完→ 存＋回想
• RYolo模式的實際做法→ 存＋回想

AI 補充第一張截圖（1384 秒）讓 orchestration 從抽象變具體：協調 agent 的終端裡反覆執行 `orca terminal wait --terminal term_<id> --for tui-idle --timeout-ms 60000 --json`——也就是第 3 段那個 orchestration skill 教它的指令：`orca` 是一支命令列工具，`terminal wait … --for tui-idle` 意思是「等某個終端裡的 agent 進入閒置（做完）再回來」，每個 sub agent 對應一個 `term_` 開頭的 id。畫面上三次都「exited with code 1」，最可能是 60 秒 timeout 到了 sub agent 還沒做完，協調 agent 於是再等一輪；這是輪詢式的等待，不是事件推送，所以協調 agent 本身也在持續消耗 token（狀態列 `↑39k ↓1.9k … 9.0%/372k`）。上方分頁列有 docs-templates、docs-validator、docs-architecture 三個分頁，就是它拆出的三個 sub agent，而 Orca 依 prompt 自動幫分頁取了名（第二張截圖裡有「Auto-generate tab titles」設定）。第二張截圖（1448 秒）補足 Yolo 的實作：Agent Permissions 的說明是「Choose whether Orca launches agents with fewer permission prompts or with manual checks」，選項 Yolo／Manual；下方 Installed 區列出實際啟動命令——Codex 是 `codex --dangerously-bypass-approvals-and-sandbox`、Grok 是 `grok --permission-mode bypassPermissions`、Pi 就是 `pi`——這和第 3 段截圖裡每個 agent 都帶跳過確認旗標的現象對上了：Yolo 不是 Orca 攔截確認，而是換一組啟動旗標；Pi 沒有旗標，因為它本來就不問。同一頁還有「Keep computer awake while agents are working」與「Prompt Cache Timer」（Claude 的 prompt cache 閒置太久會失效、下一則訊息要重送整份 context，所以顯示倒數）——後者提醒 orchestration 的隱性成本：多個 agent 各自持有一份 context。作者說「低 thinking mode 省 token」是對的：sub agent 做的是拆好的小任務，不需要高推理強度。至於誤啟 Codex，根本原因是協調 agent 看到第 3 段清單裡 Codex 是可用的就選了，作者的 guardrail 是治標；治本是在 Orca 設定裡把不想用的 agent 停用，讓 orchestration 根本看不到它。

術語:Yolo modeiorca CLIi

13. 結論：Orca 讓不會寫程式的人也能做專案 25:05–26:03

作者認為 Orca 非常棒，甚至讓 coding 能力較弱的人也能開始做專案，考慮做一個 vibe coding 系列。它不只用於軟體開發：維運i也能在遠端伺服器上開 project 叫 agent 檢查 compose 部署、伺服器健康狀態，甚至跑 automations。這是值得繼續探索的專案。

推理因為整支影片的示範都是他這個自稱不太會寫程式的人，在半小時內從零做出一個能跑、有 icon、有健康檢查端點、已 merge 進 main 的 app，所以作者對開頭問題的回答不是逐項比較功能，而是用結果說話：它確實降低了做專案的門檻。接著他回頭兌現第 1 段的另一個承諾（「不只對 AI 開發者有趣，對任何 IT 人都有趣」）：維運可以在遠端伺服器上開 project（第 2、4 段的 SSH／remote 來源），叫 agent 檢查 compose 部署、伺服器健康狀態，甚至跑 automations。最後他把評價收在「值得繼續探索」而不是「必裝」，與前面誠實列出的毛邊一致。

• R作者對Orca的最終評價→ 存＋回想

AI 補充把整支影片對照第 1 段的四個賣點，可以整理出一份比作者結論更細的成績單：隔離 worktree（第 5、6、11 段）與瀏覽器 annotation（第 9 段）是最成熟的兩項，示範一次到位、沒出狀況；agent 間溝通與 orchestration（第 7、12 段）機制真的能動，但有誤啟錯誤 agent、需要 Yolo 全權限、輪詢耗 token 三個代價；mobile companion（第 10 段）作者自己都說有時卡住，且影片沒有實際手機畫面。所以「all-in-one 還是玩具」的答案更準確地說是：對「讓 agent 寫、人審閱」這種工作方式，Orca 目前是最完整的殼；對仍以手寫程式為主的人，它取代不了 IDE（第 5 段）。作者對維運場景的推論是合理的延伸但沒有示範：讓 agent 在遠端伺服器上「檢查 compose 部署與健康狀態」屬於唯讀操作，風險低、很適合 Yolo 模式；但若讓 automations 定時執行會改動系統的指令，就要記得第 12 段的提醒——Yolo 的 agent 沒有任何確認關卡，隔離手段（worktree、容器）在遠端伺服器上並不天然存在。最後一個實務提醒：整支影片的 demo 只用了一種 agent（Pi）與一個訂閱，作者對「不綁特定 agent」的驗證其實只到第 3 段的清單與第 12 段的 Yolo 旗標，多 agent 混用（前端 Claude、後端 Pi）是他建議的用法而非示範過的結果。

術語:Automations (Orca)i