Boss 說了算：straw-boss，我的多智慧體派工協調系統

專案 GitHub：稻草老闆（straw-boss）

假設你要進行一項跨資料庫、API 與前端的功能，但三個團隊在各個專案都設定好了自己的智慧體（agent）工作流程，怎麼進行這項任務？

假設我有三個工作空間，分別進行知識蒐集、文章編輯和書目管理，如果從三個入口分別進場工作，又要如何確保三個空間的工作能順利交接？

困難處境是：

• 如果讓一個智慧體做三份獨立工作，三個工作都需要自己的工作流，這會讓智慧體無所適從。更別說，如果要讓單一智慧體載入三個專案的規則、AGENTS.md 或技能文件，要如何避免脈絡退化問題？
• 如果讓智慧體分發給子智慧體（subagent）去做，我們又要如何追蹤每個子智慧體的工作成果，並且確保有辦法即時介入和驗證關鍵流程？
• 如果從三個專案分頭進去，開三個智慧體來工作，又要如何確保它們之間的交接和協調能順利進行？

本來，我已經定義好了數個迴圈自駕體（loop harness），它們在自己的工作中都運作良好。我現在需要指揮它們，但我實在不想再定義一個特大自駕體來完成協調工作，還希望能自由決定人類要何時切入，那要怎麼做？

為了解決我自己工作上的問題，我開發了稻草老闆（straw-boss）：用一個具圖協調能力的框架，讓所有迴圈自駕體在更大的框架下良好運作的 Codex/Claude 外掛。

以下我先說明我的設計概念，再說明如何使用。

智慧體 AI 的圖工程

如果我們用節點代表工作者或工作步驟，用邊表示資訊傳遞與控制流程，以狀態記錄工作的進展，我們就有了一張圖（graph）。每個節點裡，可以有自己的工作迴圈：一位工人持續實作、驗證與修正，完成後再把結果交給下一位。

本文所說的「圖工程」，是在設計這些節點如何共同完成工作：誰先開始、誰等待誰、結果交給誰、失敗後回到哪裡，以及哪些轉換需要人的決定。

對 Straw Boss 而言，這設計建立在各工作空間既有的智慧體系統上，核心如下：

協調者選圖

協調者先依工作的形狀選擇協作圖。Straw Boss 支援三種圖：

• 單一迴圈（single-loop）：由一位智慧體從頭處理到完成。這是工人預設使用的圖，即節點模式。
• 子智慧體分工與整合（sub-agent fan-out/fan-in）：把邊界明確、可以獨立處理的分支交給子智慧體，再由原智慧體整合結果。
• 協調者—工人（orchestrator-worker）：由一位協調者管理多位從各自專案啟動的工人，依回報安排工作。

這個選擇，取決於工作如何分工與交接。

在協調者—工人模式下，協調者會先建立派工計畫，按照派工計畫進行派工；而各節點內的工作仍沿用原有的迴圈自駕體。

協調者派工

協調者會依據圖以及派工計畫（協調者—工人模式的話），把要求交給負責該範圍的工人，帶上已知條件、前置依賴與完成時需要的證據。這個派工甚至可以是平行的，由協調者來決定每個工作的依賴關係。

工人在自己的 workspace 使用原有的 harness，與使用者處理具體需求、設計與驗證方法。

更棒的是，協調者可以依據你的模型和力度偏好，發配不同等級的工人來完成任務。

例如我定義過一個 claude-drive-codex profile，讓 Claude 擔任主協調，依工作需要把任務分給 Claude 或 Codex：

這個策略把主協調、輕量工作與深入處理分開。Sonnet 遇到需要進一步實作或推理的問題，就帶著已有證據交給 Astra；Astra low 遇到具體難題時，再提高到 medium。模型與力度依工作調整，使用者當次明確指定的組合優先。

協調者與工人的溝通

工人回報進度、等待事項與完成結果，協調者依回報安排下一步，傳遞其他任務已確認的資訊。

交接材料保留具體的欄位、行為與驗證結果，讓下游能據以工作；詳細調查留在原工人的脈絡裡。

Straw Boss 透過腳本保存狀態與傳送通知。需要人回答時，工人留下等待狀態，人直接進入對話；工作完成後，協調者處理交接與收尾。這讓溝通的結果能持續被看到，也讓授權沿著明確的工作關係傳遞。

協調者對機器資源的自我調度

不同工人即使有各自的工作樹（straw-boss 會看情況幫你開工作樹，避免平行工作之間互相干擾），仍可能使用同一個資料庫，或同時啟動相同 port 的服務。這些資源需要跨任務、甚至跨協調者安排。

這時，Straw Boss 的腳本會記錄資源由誰持有，並支援申請、等待與釋放，讓同一台機器、同一使用者下的協調者與工人共用調度紀錄。協調者安排共享資源，工人依專案設定使用它們；資料庫內部的遷移依賴仍由負責的工人確認，再交回協調者安排順序。

讓人類全面掌控的多智慧體框架

Straw Boss 透過 Herdr 的 API 建立可觀看、可加入的工作窗格。每位工人在自己的 workspace 執行，人可以看見它正在做什麼，也可以直接進入對話。

這張團隊邀請功能的示範畫面，呈現主協調者、前端、資料庫與 API 工作者。示範停在呈現分工與等待的階段。

沿用這個情境，資料庫工人可能提出：「同一個信箱再次受邀，舊邀請要怎麼處理？」我可以直接在它的窗格回答：「撤銷舊邀請，保留歷史紀錄。」它接著與我確認資料需求，依專案慣例完成設計與驗證。

工人留下確定的欄位與行為，回報給協調者，再由協調者把相關結果交給 API 與前端。等前端有了可操作的畫面，我可以加入驗證，檢查使用者是否看得懂邀請狀態。需要調整時，就在負責這項工作的對話裡繼續。

使用者就是 boss，而 straw boss 是美國農場的俚語，代表會下場和工人一起幹的老闆。這是這個專案預設的人類位置。

用法與示範

使用只需要三步：安裝 plugin、執行 init，接著透過 boss-say 交代工作。以下依你使用的工具擇一安裝；指令與環境需求以 Straw Boss 文件為準。

Claude Code 在互動介面輸入：

/plugin marketplace add https://github.com/wayne930242/straw-boss
/plugin install straw-boss@straw-boss

Codex CLI 在終端執行：

codex plugin marketplace add wayne930242/straw-boss --ref main
codex plugin add straw-boss@straw-boss

安裝後重新啟動工作階段，在專案內執行 init。Claude Code 使用：

/straw-boss:init

Codex 使用：

$straw-boss:init

依引導設定工作空間與派工方式。要使用前述可直接加入的工作現場，需準備好 Herdr，並在設定時啟用。接著就可以交代工作：

boss-say 在 web、api 與 db 實作團隊邀請功能。
先確認資料模型與 API 契約，再完成前端。
邀請過期、重複邀請與權限語意，由我和負責的工人討論確認。
前端可操作後，讓我進入驗證；發布前取得我的授權。

協調者安排分工與依賴，各工人使用自己專案的工作流執行。你可以留在協調者這裡掌握進度，也可以隨時走進需要討論、授權或驗證的窗格。

就這樣，祝你工作順利！