Orchestration

Orchestration（編排）是什麼，跟單純叫 Claude 做一件事有什麼不同？

單純叫 Claude 做一件事，是模型直接推理、直接生成回覆，整個過程只有一層——你的請求進去，答案出來。Orchestration 則是在這一層之上,額外加了一層協調機制,負責決定「這個大任務該拆成哪幾塊」「哪一塊先做、哪一塊可以同時做」「每一塊做完的結果該怎麼傳給下一塊」「哪一步失敗了該怎麼處理」。

用比喻來說,如果模型生成內容是「演奏樂器」,Orchestration 就是「指揮」——指揮本身不演奏任何一種樂器,但決定了誰在什麼時候進場、音量怎麼搭配、整首曲子的節奏跟結構。在 Claude Code 的情境裡,無論是單一 Agent、多個 Subagent 平行處理,還是更大型的 Dynamic Workflows,只要牽涉到「協調多個步驟或多個執行單位怎麼配合」,就是 Orchestration 在起作用。

為什麼需要獨立的 Orchestration 機制，讓單一個 Agent 自己邊做邊決定不行嗎？

單一個 Agent 自己臨場決定,在任務簡單、線性、範圍還不確定的情境下確實是可行、甚至更靈活的做法——它可以隨探索過程中發現的新資訊動態調整方向,不需要事先固定好分工。但當任務規模變大、需要真正的平行執行(例如同時稽核多個獨立模組),或是流程本身需要保證每次都用同一套固定順序執行(不希望每次都讓模型臨場重新決定順序),獨立的 Orchestration 機制就變得必要。

它解決的核心問題是「控制流程要不要是確定性的」——如果控制流程本身是預先寫好的固定腳本,而不是每次由模型臨場判斷,你就能得到可重複、可預期的執行結果,這對需要穩定性、需要在大量步驟間管理狀態與失敗處理的複雜任務來說,是單一 Agent 臨場決定很難提供的保證。

在 Claude Code 的實際場景裡，Orchestration 具體長什麼樣子？

最基本的形式是 Subagent 的動態派生——你不需要自己寫腳本,是 Claude 即時判斷要不要派生子任務、派生幾個、各自負責什麼,這個判斷過程本身就是輕量級的 Orchestration,只是控制流程不是預先寫死的,是模型臨場決定的。

再往上一層是 Dynamic Workflows——這是一份由 Claude 寫成的固定 JavaScript 腳本,明確定義好整個協調流程(誰先跑、誰平行跑、結果怎麼合併),再由這份腳本去指揮一大批 Subagent 執行,控制流程本身變成確定性的、可重複的,不是每次臨場決定。這種模式下 Claude 可以協調到數十甚至上百個平行的執行單位,適合真正大規模、需要嚴謹狀態管理的場景,例如把一整套跨檔案的大型重構,拆成上百個平行驗證的子任務去執行。兩種模式的核心差別在於「誰掌握計畫」——是模型每次即時判斷,還是預先寫成固定腳本。

身為使用者，我什麼時候該主動去想到 Orchestration 這一層，而不是讓 Claude 自己決定？

多數日常任務不需要你主動介入這一層——線性、範圍明確、不需要平行處理的工作,讓單一 Agent 直接處理最直接,你不需要理解或設計任何 Orchestration 邏輯。

真正該開始思考這一層的時機,是當你發現任務本身天生具備「可以拆成幾個互不依賴的部分」,而且這些部分的過程雜訊你完全不想看到,或是你需要同一套協調流程被重複執行、每次都要求一致的順序與品質——這時候才值得研究是要用輕量的 Subagent 動態派生,還是需要寫成更嚴謹的固定腳本。對新手而言,最實用的態度是先讓單一 Agent 處理過幾次類似任務,親眼觀察有沒有天然可以拆開的獨立段落,再決定要不要往 Orchestration 這個方向設計,而不是一開始就假設任務需要複雜的協調機制。