AI Agent 愈來愈常被安排分工：一個角色釐清需求，另一個規劃技術方案，再交給實作與審查。但多個 Agent 分工，不代表工作自然互補；交接與依賴也可能讓局部錯誤一路傳到下游。AutoSwarm 論文摘要提出的正是這類協作挑戰。1

一份 BMAD-Solo 工程規格草案，試圖把問題落到更具體的治理設計：工作按業務流程往前走，角色負責不同工序；任務是否能放行，則要看證據，而不是看 Agent 自稱完成。

角色可以輪替，權限不能跟著提示詞改變

草案把工作拆成 Plan 與 Act 兩個基本動作，再依序安排四種工作視角：Analyst 負責釐清業務目標與驗收條件，Architect 把需求整理成可執行的任務契約，Coder 在授權範圍內實作與自測，Supervisor 則負責獨立審查。

重點不是要架起四個獨立 Agent。草案允許同一通用引擎依序切換工作視角，但也畫出清楚的界線：**角色名稱或提示詞不會自動授予權限。**尤其是實作候選的 Agent，不能再替同一候選簽下「獨立審查通過」。新開會話或改稱 Supervisor，也不能證明審查者獨立。

這個流程觀念也呼應徐直軍對業務流與流程的論述：業務流是工作的出發點，流程則是呈現和固化業務流的方式。9 在這份草案裡，角色是流程中的工作分工，不是文件分類的依據。

放行需要兩道門：機器檢查加獨立審查

草案以兩項條件描述任務驗收：機器檢查結果 C 與獨立審查 R 必須同時成立，才算通過。換句話說，測試全綠但沒有有效審查，不足以放行；審查者認為設計合理，但必需檢查失敗，也不能放行。

而且，「通過」必須綁定同一個候選版本。如果程式碼、測試、任務契約或相關環境在審查後改變，舊回執就不能直接替新候選背書。下游也不能只看任務檔裡寫著 ACCEPTED；它還得確認機器回執、審查簽章、依賴與目前候選彼此吻合。

草案因此把可信執行、回執收集與釋出入口視為不同治理責任。可由實作者修改的本機檔案、內容摘要或提示詞，不能單獨證明證據未被竄改，也不能取代獨立簽章。

任務文件管契約，證據文件管驗證

提案指定 specs/tasks/ 作為任務契約與生命週期的權威位置；specs/ 儲存長期有效的領域規範；verification/ 則存放機器回執與審查記錄。三者各司其職，不再由多份檔案同時記錄進度與完成狀態。

一份任務契約需要交代目標、輸入、交付清單、驗收條件、依賴、授權範圍、必需檢查、審查政策，以及失敗後如何恢復。像是檢查尚未建立、執行環境未知，或簽章缺失，都要明確標為未完成或阻塞，不能把「計畫要做」寫成「已經通過」。

任務遇到失敗時，草案要求保留差異、原始輸出與失敗回執；修復後另開新嘗試，不覆蓋舊證據。若修復改變了候選，舊審查也要重新確認。這項設計要避免一種常見風險：為了讓狀態看起來轉綠，刪掉必要測試，或把過去的成功結果套到新版本上。

Roo 與 Cline 的接入，仍是待驗證工作

草案也提出 Roo Code 與 Cline 的提示詞和流程映射，但將提示詞定位為行為指引，而不是硬性安全邊界。宿主是否真的載入規則、能否攔截不同工具入口、是否能拒絕未通過的釋出，都必須按實際版本與權限逐一驗證。

這裡的狀態尤其重要：文件標示自己是待審定的工程規格草案，並明確交代本次交付沒有建立生產檔案、執行測試、部署宿主或遷移舊任務。因此，這是一套治理設計與驗收方向，不是已經上線的 Agent 門禁系統。

它真正要處理的，不是替 Agent 多取幾個角色名稱，而是把三件事說清楚：誰能修改候選、誰能獨立審查，以及什麼證據足以讓成果往下游流動。當 Agent 能做的事愈多，這些界線愈不能只留在提示詞裡。

AI Agent 愈來愈常被安排分工：一個角色釐清需求，另一個規劃技術方案，再交給實作與審查。但多個 Agent 分工，不代表工作自然互補；交接與依賴也可能讓局部錯誤一路傳到下游。AutoSwarm 論文摘要提出的正是這類協作挑戰。1

一份 BMAD-Solo 工程規格草案，試圖把問題落到更具體的治理設計：工作按業務流程往前走，角色負責不同工序；任務是否能放行，則要看證據，而不是看 Agent 自稱完成。

角色可以輪替，權限不能跟著提示詞改變

草案把工作拆成 Plan 與 Act 兩個基本動作，再依序安排四種工作視角：Analyst 負責釐清業務目標與驗收條件，Architect 把需求整理成可執行的任務契約，Coder 在授權範圍內實作與自測，Supervisor 則負責獨立審查。

重點不是要架起四個獨立 Agent。草案允許同一通用引擎依序切換工作視角，但也畫出清楚的界線：**角色名稱或提示詞不會自動授予權限。**尤其是實作候選的 Agent，不能再替同一候選簽下「獨立審查通過」。新開會話或改稱 Supervisor，也不能證明審查者獨立。

這個流程觀念也呼應徐直軍對業務流與流程的論述：業務流是工作的出發點，流程則是呈現和固化業務流的方式。9 在這份草案裡，角色是流程中的工作分工，不是文件分類的依據。

放行需要兩道門：機器檢查加獨立審查

草案以兩項條件描述任務驗收：機器檢查結果 C 與獨立審查 R 必須同時成立，才算通過。換句話說，測試全綠但沒有有效審查，不足以放行；審查者認為設計合理，但必需檢查失敗，也不能放行。

而且，「通過」必須綁定同一個候選版本。如果程式碼、測試、任務契約或相關環境在審查後改變，舊回執就不能直接替新候選背書。下游也不能只看任務檔裡寫著 ACCEPTED；它還得確認機器回執、審查簽章、依賴與目前候選彼此吻合。

草案因此把可信執行、回執收集與釋出入口視為不同治理責任。可由實作者修改的本機檔案、內容摘要或提示詞，不能單獨證明證據未被竄改，也不能取代獨立簽章。

任務文件管契約，證據文件管驗證

提案指定 specs/tasks/ 作為任務契約與生命週期的權威位置；specs/ 儲存長期有效的領域規範；verification/ 則存放機器回執與審查記錄。三者各司其職，不再由多份檔案同時記錄進度與完成狀態。

一份任務契約需要交代目標、輸入、交付清單、驗收條件、依賴、授權範圍、必需檢查、審查政策，以及失敗後如何恢復。像是檢查尚未建立、執行環境未知，或簽章缺失，都要明確標為未完成或阻塞，不能把「計畫要做」寫成「已經通過」。

任務遇到失敗時，草案要求保留差異、原始輸出與失敗回執；修復後另開新嘗試，不覆蓋舊證據。若修復改變了候選，舊審查也要重新確認。這項設計要避免一種常見風險：為了讓狀態看起來轉綠，刪掉必要測試，或把過去的成功結果套到新版本上。

Roo 與 Cline 的接入，仍是待驗證工作

草案也提出 Roo Code 與 Cline 的提示詞和流程映射，但將提示詞定位為行為指引，而不是硬性安全邊界。宿主是否真的載入規則、能否攔截不同工具入口、是否能拒絕未通過的釋出，都必須按實際版本與權限逐一驗證。

這裡的狀態尤其重要：文件標示自己是待審定的工程規格草案，並明確交代本次交付沒有建立生產檔案、執行測試、部署宿主或遷移舊任務。因此，這是一套治理設計與驗收方向，不是已經上線的 Agent 門禁系統。

它真正要處理的，不是替 Agent 多取幾個角色名稱，而是把三件事說清楚：誰能修改候選、誰能獨立審查，以及什麼證據足以讓成果往下游流動。當 Agent 能做的事愈多，這些界線愈不能只留在提示詞裡。