AI Agent 的工作流程常把 Analyst、Architect、Coder、Reviewer 分成不同角色，彷彿只要換一個模式或提示詞，品質風險就能自然下降。但 BMAD-Solo 一份日期標示為 2026 年 10 月 27 日的工程草案，將問題拉回更基本的一點：角色名稱不是權限，提示詞也不是物理門禁。

這份提案並不打算建立四個 Agent 互相派工，而是以一個任務單元串起 Plan–Act 流程，再要求交付同時具備可核對的機器證據與真正獨立的審查。草案目前是規範設計，不代表程式、宿主設定或發布門禁已經實作。

從角色清單，回到完整業務流程

提案把工作順序整理為：目標進入、Plan 分析、Plan 架構、Act 實施、Act 審查，最後才是受控交付。Analyst 負責釐清目標、驗收條件與未知；Architect 固定介面、依賴、檢查方式和交付範圍；Coder 按核准契約實施；Supervisor 則重新檢視候選成果與證據。

這種設計採用「先看端到端業務流，再安排流程與資訊」的思路。徐直軍談業務、流程與 IT 關係的文章，將業務流描述為從客戶需求出發、經過產品或服務交付並回到客戶的端到端過程；流程與 IT 則圍繞業務流發揮作用。6 在這份草案裡，對應的做法是讓任務從目標一路連到交付，而不是替每個角色另建一套彼此脫節的文件。

研究多 Agent 協作的論文紀錄也提醒，分散工作不會自動帶來互補貢獻；Agent 之間的依賴可能讓局部錯誤擴大成任務失敗。1 這不等於單一 Agent 一定更可靠，而是說明了為什麼任務依賴、驗收責任和交接證據不能只靠角色分工帶過。

一個任務單元，幾種不同的權威證據

草案建議以單一任務文件承載交付契約，內容包括目標、輸入、依賴、交付清單、驗收條件、檢查命令、授權範圍與失敗恢復方式。任務狀態也放在這個權威來源，不再另維護一份可以互相矛盾的角色進度表。

但「單一權威源」不代表把所有資訊塞進同一份文件。任務契約說明要交付什麼；可信執行器產生的回執記錄檢查實際結果；獨立審查簽章記錄審查結論；公共領域規範則保存已接受、可供後續任務使用的長期知識。摘要可以幫助接手，卻不能取代原始證據。

這個分工也處理了常見的狀態混淆：任務已經開始，不代表它已獲核准；自測通過，不等於任務已被接受；完成一個階段，也不代表可以直接發布或部署。

「機器通過」和「獨立審查」要同時成立

草案將接受條件寫成兩道門：機器檢查 C 與獨立審查 R 必須同時通過。實際釋出成果還要確認權限、依賴、候選版本身分和交付完整性。因此，即使檢查結果是 PASS，也不能單靠它宣告任務可發布。

機器檢查不能只看命令是否回傳零。還要確認它是否真的執行、測試是否有收集到案例、必需案例是否被跳過、是否超時，以及執行回執是否對應目前這一版程式與契約。缺少證據、證據過期或清理狀態不明，都不能當成通過。

獨立審查的門檻更容易被誤解：同一個模型從 Coder 切換成 Supervisor，並不會因此成為獨立審查者。換提示詞、開新對話，甚至改用另一個角色名稱，都無法單獨證明審查身分獨立。草案要求由實作方無法代持憑證的人類審查者，或具備獨立身分與受保護憑證的審查服務，針對特定契約、候選成果和檢查結果簽章。

如果這個信任邊界不存在，系統可以把審查當作輔助建議，卻不能宣稱已完成獨立驗收。

配置片段不是已運作的安全機制

草案也提供 Roo Code 與 Cline 的配置映射例子，例如在 Plan 模式限制實作行為、在 Act 模式安排實施與審查輔助。不過，這些片段只是待實作、待驗收的設計資產；提示詞寫著「不可執行」並不等於宿主真的能阻擋執行，設定檔能解析也不代表審查者沒有修改候選的權限。

要證明門禁有效，仍須在目標版本實測規則是否載入、工具呼叫是否受限、逾時是否能停止、缺少簽章是否會被拒絕，以及合理任務是否仍能順利通過。草案特別區分「工作流程中的行為規範」與「由受保護入口強制執行的權限控制」，避免把前者包裝成後者。

重點不是多加一個角色，而是讓證據接得起來

這份 BMAD-Solo 提案的核心，並非證明單一 Agent 能取代所有協作，而是把交付責任拆成可檢查的契約、可追溯的執行證據，以及不能由實作者自批的審查結論。它仍是一份工程規範草案；是否能成為真正的治理機制，要看後續是否落實執行器、身分隔離、受保護簽章與宿主驗收。

對正在設計 Agent 工作流的團隊來說，值得先問的不是「要不要再加一個 Agent」，而是：當檢查缺失、候選改變或審查者不獨立時，系統是否真的會停止交付？

AI Agent 的工作流程常把 Analyst、Architect、Coder、Reviewer 分成不同角色，彷彿只要換一個模式或提示詞，品質風險就能自然下降。但 BMAD-Solo 一份日期標示為 2026 年 10 月 27 日的工程草案，將問題拉回更基本的一點：角色名稱不是權限，提示詞也不是物理門禁。

這份提案並不打算建立四個 Agent 互相派工，而是以一個任務單元串起 Plan–Act 流程，再要求交付同時具備可核對的機器證據與真正獨立的審查。草案目前是規範設計，不代表程式、宿主設定或發布門禁已經實作。

從角色清單，回到完整業務流程

提案把工作順序整理為：目標進入、Plan 分析、Plan 架構、Act 實施、Act 審查，最後才是受控交付。Analyst 負責釐清目標、驗收條件與未知；Architect 固定介面、依賴、檢查方式和交付範圍；Coder 按核准契約實施；Supervisor 則重新檢視候選成果與證據。

這種設計採用「先看端到端業務流，再安排流程與資訊」的思路。徐直軍談業務、流程與 IT 關係的文章，將業務流描述為從客戶需求出發、經過產品或服務交付並回到客戶的端到端過程；流程與 IT 則圍繞業務流發揮作用。6 在這份草案裡，對應的做法是讓任務從目標一路連到交付，而不是替每個角色另建一套彼此脫節的文件。

研究多 Agent 協作的論文紀錄也提醒，分散工作不會自動帶來互補貢獻；Agent 之間的依賴可能讓局部錯誤擴大成任務失敗。1 這不等於單一 Agent 一定更可靠，而是說明了為什麼任務依賴、驗收責任和交接證據不能只靠角色分工帶過。

一個任務單元，幾種不同的權威證據

草案建議以單一任務文件承載交付契約，內容包括目標、輸入、依賴、交付清單、驗收條件、檢查命令、授權範圍與失敗恢復方式。任務狀態也放在這個權威來源，不再另維護一份可以互相矛盾的角色進度表。

但「單一權威源」不代表把所有資訊塞進同一份文件。任務契約說明要交付什麼；可信執行器產生的回執記錄檢查實際結果；獨立審查簽章記錄審查結論；公共領域規範則保存已接受、可供後續任務使用的長期知識。摘要可以幫助接手，卻不能取代原始證據。

這個分工也處理了常見的狀態混淆：任務已經開始，不代表它已獲核准；自測通過，不等於任務已被接受；完成一個階段，也不代表可以直接發布或部署。

「機器通過」和「獨立審查」要同時成立

草案將接受條件寫成兩道門：機器檢查 C 與獨立審查 R 必須同時通過。實際釋出成果還要確認權限、依賴、候選版本身分和交付完整性。因此，即使檢查結果是 PASS，也不能單靠它宣告任務可發布。

機器檢查不能只看命令是否回傳零。還要確認它是否真的執行、測試是否有收集到案例、必需案例是否被跳過、是否超時，以及執行回執是否對應目前這一版程式與契約。缺少證據、證據過期或清理狀態不明，都不能當成通過。

獨立審查的門檻更容易被誤解：同一個模型從 Coder 切換成 Supervisor，並不會因此成為獨立審查者。換提示詞、開新對話，甚至改用另一個角色名稱，都無法單獨證明審查身分獨立。草案要求由實作方無法代持憑證的人類審查者，或具備獨立身分與受保護憑證的審查服務，針對特定契約、候選成果和檢查結果簽章。

如果這個信任邊界不存在，系統可以把審查當作輔助建議，卻不能宣稱已完成獨立驗收。

配置片段不是已運作的安全機制

草案也提供 Roo Code 與 Cline 的配置映射例子，例如在 Plan 模式限制實作行為、在 Act 模式安排實施與審查輔助。不過，這些片段只是待實作、待驗收的設計資產；提示詞寫著「不可執行」並不等於宿主真的能阻擋執行，設定檔能解析也不代表審查者沒有修改候選的權限。

要證明門禁有效，仍須在目標版本實測規則是否載入、工具呼叫是否受限、逾時是否能停止、缺少簽章是否會被拒絕，以及合理任務是否仍能順利通過。草案特別區分「工作流程中的行為規範」與「由受保護入口強制執行的權限控制」，避免把前者包裝成後者。

重點不是多加一個角色，而是讓證據接得起來

這份 BMAD-Solo 提案的核心，並非證明單一 Agent 能取代所有協作，而是把交付責任拆成可檢查的契約、可追溯的執行證據，以及不能由實作者自批的審查結論。它仍是一份工程規範草案；是否能成為真正的治理機制，要看後續是否落實執行器、身分隔離、受保護簽章與宿主驗收。

對正在設計 Agent 工作流的團隊來說，值得先問的不是「要不要再加一個 Agent」，而是：當檢查缺失、候選改變或審查者不獨立時，系統是否真的會停止交付？