AI 代理開始分工後，下一個問題不是「還能再加幾個角色」，而是：誰有權改動成果、誰負責驗證，又由誰獨立判斷成果能否放行？

一個 Agent 可以先扮演分析者，再切換成工程師或審查者；但角色名稱變了，不代表執行者變了。若同一個 Agent 寫出成果，再以「Supervisor」身分替自己簽核，這仍不是獨立審查。

一份以 BMAD-Solo 為背景的工程規範草案，據此提出一種較清楚的做法：讓一份任務契約貫穿整個業務流程，把四種職責安排在 Plan、Act 兩段作業中，最後由機器檢查與真正獨立的審查共同把關。這是設計提案，不是已部署的系統。

多角色不等於多一層保障

多代理研究關注專業分工與協作，但代理數量增加，不必然代表貢獻互補；代理之間的依賴也可能讓局部錯誤擴大成整體失敗。這正是 AutoSwarm 論文摘要提出的問題之一。1

因此，治理的起點不應只是替每個角色建立一份說明文件，而是先定義一項工作如何從需求走到驗收、由誰提供證據，以及什麼條件下成果才能交給下游使用。

把角色放回同一條工作流

這份草案將工作分成 Plan 與 Act 兩個階段，並在其中安排四種職責：

• Analyst：整理業務目標、不變條件、驗收方式，以及仍未釐清的問題。
• Architect：把需求整理成介面、交付範圍、依賴關係與驗證條件。
• Coder：依核准的契約實作，並提交候選成果與自我檢查證據。
• Supervisor：核對成果與契約是否一致，組織機器驗證及反向審查。

這不是四個彼此隔離的 Agent，也不是每個角色各有一套任務清單。角色切換只代表工作責任改變；不能因此推定權限改變，更不能把同一個執行者的自我檢查當成獨立簽核。

這種以業務流為中心的設計，也呼應了流程管理中「流程承載業務作業、資料隨業務流動」的觀點。8 華為公開演講亦提出，應把品質要求納入各業務流程，而非只在流程末端處理品質問題。7

一份任務契約，避免多頭維護

草案建議把每項任務的目標、交付清單、依賴、驗收標準、當前階段與證據位置，集中在一份權威任務工件中。角色目錄、宿主待辦和聊天摘要可以提供入口或提示，但不應各自維護一套不同的任務狀態。

關鍵不在文件要多長，而在每項工作都能回答幾個實際問題：

1. 要交付什麼？ 列清楚會新增、修改或刪除哪些資產。
2. 怎樣算完成？ 每項驗收條件都要對應可執行的檢查，或明確的人工判斷問題。
3. 證據屬於哪個版本？ 驗證結果必須綁定任務、契約版本和候選成果，不能拿舊版本的通過紀錄替新版本背書。
4. 出了問題怎麼辦？ 區分一般實作缺陷、需求或介面變更，以及缺權限、缺環境等阻塞狀況；不要用跳過檢查來假裝完成。

同理，活動任務指標最好只負責指出目前焦點，階段和驗收狀態則從任務工件讀取。這樣能減少不同文件各自更新、最後卻彼此矛盾的風險。

放行要有兩道門，而且都要對準同一個成果

草案的核心門檻是：機器驗證通過，並且獨立審查有效，兩者缺一不可。

機器檢查負責確認任務明確列出的條件，例如測試結果、必需檢查是否實際執行，以及驗證回執是否對應目前候選。若結果缺漏、逾時、無法確認測試有被執行，或候選在驗證後又有變動，就不能把狀態當成通過。

獨立審查則應由未參與該候選實作的人進行，並核對同一份契約、候選版本和機器回執。由 Agent 草擬的反向審查報告可以協助整理問題，但如果最後仍由同一個執行者自我批准，就不構成獨立簽章。

兩道門各自處理不同問題：機器檢查不等於業務判斷，人工審查也不能讓失敗的必需測試變成通過。至於合併、發布和歸檔，仍須另行確認相應授權與實際操作結果，不能用一句「已完成」把不同狀態混為一談。

提案不等於已經落地

這份規範中的資料夾路徑、模板、門禁介面和宿主設定，都是擬議設計，不能據此推斷它們已建立、載入或驗收。靜態規則也無法單獨證明 Cline 或 Roo Code 的實際權限、工具行為及審查流程已受到強制控制。

草案同時指出，目前可取得的 AutoSwarm 論文資料是預印本條目與摘要；其中 CS 和驗收公式的定義是否與原文逐字一致，證據不足。因此，本文所述治理模型應視為工程設計建議，而不是已由該研究驗證的系統或效果。1

對正在導入 AI 工作流的團隊而言，值得先問的或許不是「要不要更多代理」，而是：任務只有沒有一份大家都認得的契約？驗收證據能不能對上實際版本？負責審查的人，是否真的沒有參與實作？這些問題釐清後，角色分工才有機會成為流程的一部分，而不是多一層看似正式的標籤。

AI 代理開始分工後，下一個問題不是「還能再加幾個角色」，而是：誰有權改動成果、誰負責驗證，又由誰獨立判斷成果能否放行？

一個 Agent 可以先扮演分析者，再切換成工程師或審查者；但角色名稱變了，不代表執行者變了。若同一個 Agent 寫出成果，再以「Supervisor」身分替自己簽核，這仍不是獨立審查。

一份以 BMAD-Solo 為背景的工程規範草案，據此提出一種較清楚的做法：讓一份任務契約貫穿整個業務流程，把四種職責安排在 Plan、Act 兩段作業中，最後由機器檢查與真正獨立的審查共同把關。這是設計提案，不是已部署的系統。

多角色不等於多一層保障

多代理研究關注專業分工與協作，但代理數量增加，不必然代表貢獻互補；代理之間的依賴也可能讓局部錯誤擴大成整體失敗。這正是 AutoSwarm 論文摘要提出的問題之一。1

因此，治理的起點不應只是替每個角色建立一份說明文件，而是先定義一項工作如何從需求走到驗收、由誰提供證據，以及什麼條件下成果才能交給下游使用。

把角色放回同一條工作流

這份草案將工作分成 Plan 與 Act 兩個階段，並在其中安排四種職責：

• Analyst：整理業務目標、不變條件、驗收方式，以及仍未釐清的問題。
• Architect：把需求整理成介面、交付範圍、依賴關係與驗證條件。
• Coder：依核准的契約實作，並提交候選成果與自我檢查證據。
• Supervisor：核對成果與契約是否一致，組織機器驗證及反向審查。

這不是四個彼此隔離的 Agent，也不是每個角色各有一套任務清單。角色切換只代表工作責任改變；不能因此推定權限改變，更不能把同一個執行者的自我檢查當成獨立簽核。

這種以業務流為中心的設計，也呼應了流程管理中「流程承載業務作業、資料隨業務流動」的觀點。8 華為公開演講亦提出，應把品質要求納入各業務流程，而非只在流程末端處理品質問題。7

一份任務契約，避免多頭維護

草案建議把每項任務的目標、交付清單、依賴、驗收標準、當前階段與證據位置，集中在一份權威任務工件中。角色目錄、宿主待辦和聊天摘要可以提供入口或提示，但不應各自維護一套不同的任務狀態。

關鍵不在文件要多長，而在每項工作都能回答幾個實際問題：

1. 要交付什麼？ 列清楚會新增、修改或刪除哪些資產。
2. 怎樣算完成？ 每項驗收條件都要對應可執行的檢查，或明確的人工判斷問題。
3. 證據屬於哪個版本？ 驗證結果必須綁定任務、契約版本和候選成果，不能拿舊版本的通過紀錄替新版本背書。
4. 出了問題怎麼辦？ 區分一般實作缺陷、需求或介面變更，以及缺權限、缺環境等阻塞狀況；不要用跳過檢查來假裝完成。

同理，活動任務指標最好只負責指出目前焦點，階段和驗收狀態則從任務工件讀取。這樣能減少不同文件各自更新、最後卻彼此矛盾的風險。

放行要有兩道門，而且都要對準同一個成果

草案的核心門檻是：機器驗證通過，並且獨立審查有效，兩者缺一不可。

機器檢查負責確認任務明確列出的條件，例如測試結果、必需檢查是否實際執行，以及驗證回執是否對應目前候選。若結果缺漏、逾時、無法確認測試有被執行，或候選在驗證後又有變動，就不能把狀態當成通過。

獨立審查則應由未參與該候選實作的人進行，並核對同一份契約、候選版本和機器回執。由 Agent 草擬的反向審查報告可以協助整理問題，但如果最後仍由同一個執行者自我批准，就不構成獨立簽章。

兩道門各自處理不同問題：機器檢查不等於業務判斷，人工審查也不能讓失敗的必需測試變成通過。至於合併、發布和歸檔，仍須另行確認相應授權與實際操作結果，不能用一句「已完成」把不同狀態混為一談。

提案不等於已經落地

這份規範中的資料夾路徑、模板、門禁介面和宿主設定，都是擬議設計，不能據此推斷它們已建立、載入或驗收。靜態規則也無法單獨證明 Cline 或 Roo Code 的實際權限、工具行為及審查流程已受到強制控制。

草案同時指出，目前可取得的 AutoSwarm 論文資料是預印本條目與摘要；其中 CS 和驗收公式的定義是否與原文逐字一致，證據不足。因此，本文所述治理模型應視為工程設計建議，而不是已由該研究驗證的系統或效果。1

對正在導入 AI 工作流的團隊而言，值得先問的或許不是「要不要更多代理」，而是：任務只有沒有一份大家都認得的契約？驗收證據能不能對上實際版本？負責審查的人，是否真的沒有參與實作？這些問題釐清後，角色分工才有機會成為流程的一部分，而不是多一層看似正式的標籤。