中央 repo 派工給多個子 repo，這架構叫什麼？工程界叫 Orchestrator–Worker
我拉了一個專案，它是「主支線目標規劃中心」，底下管著三個執行用的 repo。我請 Claude 解讀派工腳本的機制，順便教我這套結構在工程界的真實說法——結果一路從 hub-and-spoke 講到 orchestrator–worker、control plane，還發現它跟物流業的軸輻網路是同一個道理。
Jacques Louis David,《Étienne-Maurice Gérard 將軍（1773–1852）》, 1816 年。油彩、畫布。畫中是一位拿破崙時代的法國將軍——將軍的職責不是親自衝鋒，而是站在中央調度全局、把命令分派給各部隊執行，正是 orchestrator（協調者）的縮影。典藏於大都會藝術博物館。
起因：拉了一個專案，它管著另外三個 repo
我拉了一個叫 a 的 repo。它的定位很特別——它是「主支線目標規劃中心」，本身幾乎不放業務程式碼，而是用一堆 YAML 工單、dispatch.sh 腳本、GitHub Action 去管理底下三個執行用的 repo：a-a、a-b、a-c。
我看得懂它在做什麼，但我講不出「這種架構在工程界叫什麼」。所以我請 Claude 先解讀派工腳本，再教我圈內人的真實說法。
Claude 的白話解釋：dispatch.sh 在做什麼
Claude 把 dispatch.sh 拆成一句話：讀一張 YAML 工單 → 翻譯成目標 repo 的 GitHub Issue。
流程是六步：
工單 YAML ──► 防重複檢查 ──► 查註冊表 ──► 合併標籤/負責人 ──► 開 Issue ──► 回寫紀錄
(WO-0001) (dispatched?) (repos.yml) (labels merge) (gh issue) (蓋戳章)裡面有兩個我覺得很漂亮的設計：
- 註冊表（repos.yml）是唯一真相來源：工單只寫代號
a-a，真正的 repo 路徑cameocyc/a-a集中在一個檔案管理。要改 repo 名，只改一個地方。 - 冪等（idempotent）：派工後會在工單尾端蓋一個
dispatched:戳章；已蓋章的工單再跑會被跳過，除非加--force。所以同一張工單跑一百次，也只會開一個 Issue。
我的提問：這個「中央規劃、分派到多個 repo 執行」的架構，工程界怎麼說？
我跟 Claude 說：這個 repo 是主支線目標規劃中心，它有從屬關係的 repo 分別在 a-a、a-b、a-c。你可以教我說一次嗎？我希望學會 AI 界的工程和真實說法。
Claude 的回答：同一件事，有三層由淺到深的說法
Claude 給了我三層說法，從最直覺到最高階：
第一層：Hub-and-Spoke（軸輻式）。 a 是 hub（軸心），三個子 repo 是 spoke（輻條）。最好懂。
第二層：Orchestrator–Worker（協調者–執行者）。 這是 AI 圈最愛用的講法。a 是 orchestrator，負責拆解任務、分派、追蹤，本身不做事；a-a/a-b/a-c 是 worker，各領一塊專心做完。Claude 特別點出：這套結構跟多 Agent 系統的拓墣一模一樣——把 worker 換成 AI agent、把 dispatch.sh 換成 LLM 的 tool call，就是一套 multi-agent orchestration。
第三層：Control Plane（控制平面）。 借自 Kubernetes。a 是 control plane——只決策、下指令的大腦；三個子 repo 是 data plane——真正幹活的地方；repos.yml 就是 service registry（服務註冊表）。
我學到的一個關鍵詞是 idempotent（冪等）：一個操作不管執行幾次，結果都跟執行一次相同。
我又追問：能不能引用一篇文章，補軸輻網路的概念？
我想把「軸輻」這個詞紮得更實，所以請 Claude 幫我引用一篇講軸輻網路模型的文章來補充。
Claude 的回答：軸輻其實是物流業省成本的老智慧
Claude 幫我讀了行銷資料科學專欄、由台科大羅凱揚與蘇宇暉撰寫的〈有效節省成本的軸輻網路模型〉。重點是這個——軸輻網路真正的價值在省連線數：
「點對點」要連所有點，成本是 N × M 條線；「軸輻網路」讓所有點先集中到樞紐再輻射出去，成本只要 N + M 條線。當 N 與 M 越大，兩者的差距就越大。（觀點與數據出自羅凱揚、蘇宇暉，行銷資料科學 Medium 專欄）
文中舉的例子是聯邦快遞：創辦人史密斯 1962 年在耶魯提出構想，1971 年成立公司，以孟菲斯為單一樞紐轉運全美包裹——這正是軸輻模型的經典實作。
這讓我把點連起來了：我那個 a repo 之所以不讓三個子 repo 互相直接派工、而是全部經過中樞，省的就是同一筆「連線數」成本。三個 repo 點對點要管 3 條關係，加到十個 repo 就要管 45 條；但走軸輻，十個 repo 也只要十條「中樞 ↔ 子 repo」的線。repos.yml 當註冊表、dispatch.sh 當唯一派工口，本質上就是軟體版的孟菲斯轉運中心。
我學到的
- 我手上這個 repo 的正式名稱是 orchestrator / control plane，子 repo 是 worker / data plane——以後我能講得出口了。
- 軸輻網路不是航空和物流的專利，它是一個跨領域的省成本拓墣：用「N + M」取代「N × M」。軟體的派工中樞、物流的轉運中心，是同一個數學。
- 最讓我有感的是 Claude 那句：把 worker 換成 AI agent，這套人類派工流程就無痛變成 multi-agent system。我現在管的是 repo，未來管的可能就是一群 agent，但架構的腦是同一個。
致謝與延伸閱讀
本文「軸輻網路」一段的概念、N×M 對 N+M 的成本論點、以及聯邦快遞的例子，都來自下面這篇文章。特別感謝兩位作者把一個原本抽象的物流概念講得這麼清楚，也感謝文中製圖者畫出的軸輻 vs. 點對點對照圖——那張圖讓我一眼就看懂了差別，這篇學習筆記才接得起來。謝謝你們讓我學會：
- 羅凱揚、蘇宇暉，〈有效節省成本的軸輻網路模型〉，行銷資料科學 Medium 專欄。
本文是我在 Claude 協助下，邊讀派工腳本邊整理的學習筆記。軟體架構的解讀由我與 Claude 對話產生，軸輻網路的概念與數據則歸功於上述原文作者，特此分流標註，不敢掠美。