AI Agent 一旦要處理多步驟工作，問題往往唔止係「邊個角色負責咩」，仲包括：下一步依據乜嘢接手？測試結果係咪對應最新改動？做實作嗰個 Agent，可唔可以同時批准自己？

一份 BMAD-Solo 工程規範草案，嘗試用「任務」而唔係「角色」做管理主線：由業務分析、技術設計，行到實施、驗證同獨立審查，每個工序都要交代清楚輸入、輸出同放行條件。

由業務流程出發，而唔係先分 Agent

草案將 Analyst、Architect、Coder 同 Supervisor 視為同一個通用引擎喺不同工序使用嘅工作視角，唔要求一定要有四個獨立 Agent。Plan 階段先釐清目標、限制同驗收要求，再由 Architect 固定任務契約；Act 階段先實施同自測，之後交畀獨立審查。

呢種「先睇業務流程，再安排工作方式」嘅取向，同徐直軍談到業務流係工作基礎嘅觀點相呼應；華為亦曾提到，AI 應用要同企業流程、組織、數據同業務場景結合，先較有條件落地。9 8 不過，呢度講嘅 Agent 工程規範係一個具體設計提案，唔係上述資料已經驗證過嘅標準做法。

一份任務契約做主線，證據各自有家

草案建議每項工作用一份任務檔記錄目標、交付物、驗收條件、依賴、獲准修改範圍同必需檢查。specs/tasks/ 會係任務契約同狀態嘅主要位置；領域規範留低長期有效嘅業務約束；verification/ 則存放機器檢查回執同審查證據。

重點係分清楚「記錄狀態」同「證明通過」：任務檔寫住 ACCEPTED，唔代表門禁已經通過。下游放行仍然要核對證據係咪屬於目前嗰個候選版本，亦要確認相關依賴同授權無問題。

呢個考慮亦回應多 Agent 系統常見嘅協作風險。AutoSwarm 論文摘要指出，將工作分派畀多個 Agent，唔會自動帶來互補貢獻；Agent 之間嘅依賴亦可能令局部錯誤擴大成任務失敗。1 換言之，增加角色或者 Agent 數量，唔等於自然有更好嘅協作治理。

放行要過兩關：機器檢查 C，加獨立審查 R

草案將驗收概括為「C ∧ R」：C 係機器檢查結果，R 係獨立審查簽章。兩者都有效，候選先可以交畀依賴佢嘅下游。

機器檢查唔可以只睇退出碼係咪零，仲要確認必需項目有冇實際執行、測試有冇被跳過、結果係咪對應目前候選，以及超時同清理狀態有冇交代。審查一方則要核對邊界情況、例外處理、呼叫方同資料所有權，並留下清楚嘅批准或返工決定。

最重要嘅防線係職責分離：實施候選嘅主體唔可以批准自己嘅改動。同一個模型即使開新對話、改用 Supervisor 名稱，亦唔會因此變成獨立審查者。模型可以協助做反向檢查，但如果冇經認證、符合政策嘅獨立簽章，R 就仍然未成立。

提示詞有用，但唔等於硬門禁

規範亦建議 Roo Code 同 Cline 等工具按 Plan、Act 工序載入相應規則，並明確指出目前角色視角唔會增加使用者授權或工具權限。Coder 可以交付候選同證據，但唔可以改寫可信回執或使用審查簽章憑據。

不過，提示詞只係行為指引，唔係安全隔離。要真正阻止自批自放，仍然要有可信嘅執行、回執收集同釋出入口，並確保實作者無法改寫審查記錄。若工具本身冇可靠嘅攔截機制，就要由受保護嘅外部流程把關，而唔應聲稱單靠提示詞已經完成硬性控制。

目前係草案，唔係已完成嘅系統

呢份設計提出任務模板、狀態轉換、證據欄位、宿主工具接入指引同驗收情境，亦明確列出舊任務遷移、宿主部署同生產門禁實作唔屬於今次交付範圍。未有實作嘅檢查亦必須標示為計劃中，唔可以當成已通過。

所以，呢份草案最有用嘅地方，未必係再加多幾個 Agent，而係將接力規則寫清楚：邊個依據乜嘢做事、證據屬於邊個候選、邊個有權批准，以及未通過時點樣保留現場再修復。最終能否成為有效門禁，仍要靠實際工具、權限隔離同測試驗收證明。

AI Agent 一旦要處理多步驟工作，問題往往唔止係「邊個角色負責咩」，仲包括：下一步依據乜嘢接手？測試結果係咪對應最新改動？做實作嗰個 Agent，可唔可以同時批准自己？

一份 BMAD-Solo 工程規範草案，嘗試用「任務」而唔係「角色」做管理主線：由業務分析、技術設計，行到實施、驗證同獨立審查，每個工序都要交代清楚輸入、輸出同放行條件。

由業務流程出發，而唔係先分 Agent

草案將 Analyst、Architect、Coder 同 Supervisor 視為同一個通用引擎喺不同工序使用嘅工作視角，唔要求一定要有四個獨立 Agent。Plan 階段先釐清目標、限制同驗收要求，再由 Architect 固定任務契約；Act 階段先實施同自測，之後交畀獨立審查。

呢種「先睇業務流程，再安排工作方式」嘅取向，同徐直軍談到業務流係工作基礎嘅觀點相呼應；華為亦曾提到，AI 應用要同企業流程、組織、數據同業務場景結合，先較有條件落地。9 8 不過，呢度講嘅 Agent 工程規範係一個具體設計提案，唔係上述資料已經驗證過嘅標準做法。

一份任務契約做主線，證據各自有家

草案建議每項工作用一份任務檔記錄目標、交付物、驗收條件、依賴、獲准修改範圍同必需檢查。specs/tasks/ 會係任務契約同狀態嘅主要位置；領域規範留低長期有效嘅業務約束；verification/ 則存放機器檢查回執同審查證據。

重點係分清楚「記錄狀態」同「證明通過」：任務檔寫住 ACCEPTED，唔代表門禁已經通過。下游放行仍然要核對證據係咪屬於目前嗰個候選版本，亦要確認相關依賴同授權無問題。

呢個考慮亦回應多 Agent 系統常見嘅協作風險。AutoSwarm 論文摘要指出，將工作分派畀多個 Agent，唔會自動帶來互補貢獻；Agent 之間嘅依賴亦可能令局部錯誤擴大成任務失敗。1 換言之，增加角色或者 Agent 數量，唔等於自然有更好嘅協作治理。

放行要過兩關：機器檢查 C，加獨立審查 R

草案將驗收概括為「C ∧ R」：C 係機器檢查結果，R 係獨立審查簽章。兩者都有效，候選先可以交畀依賴佢嘅下游。

機器檢查唔可以只睇退出碼係咪零，仲要確認必需項目有冇實際執行、測試有冇被跳過、結果係咪對應目前候選，以及超時同清理狀態有冇交代。審查一方則要核對邊界情況、例外處理、呼叫方同資料所有權，並留下清楚嘅批准或返工決定。

最重要嘅防線係職責分離：實施候選嘅主體唔可以批准自己嘅改動。同一個模型即使開新對話、改用 Supervisor 名稱，亦唔會因此變成獨立審查者。模型可以協助做反向檢查，但如果冇經認證、符合政策嘅獨立簽章，R 就仍然未成立。

提示詞有用，但唔等於硬門禁

規範亦建議 Roo Code 同 Cline 等工具按 Plan、Act 工序載入相應規則，並明確指出目前角色視角唔會增加使用者授權或工具權限。Coder 可以交付候選同證據，但唔可以改寫可信回執或使用審查簽章憑據。

不過，提示詞只係行為指引，唔係安全隔離。要真正阻止自批自放，仍然要有可信嘅執行、回執收集同釋出入口，並確保實作者無法改寫審查記錄。若工具本身冇可靠嘅攔截機制，就要由受保護嘅外部流程把關，而唔應聲稱單靠提示詞已經完成硬性控制。

目前係草案，唔係已完成嘅系統

呢份設計提出任務模板、狀態轉換、證據欄位、宿主工具接入指引同驗收情境，亦明確列出舊任務遷移、宿主部署同生產門禁實作唔屬於今次交付範圍。未有實作嘅檢查亦必須標示為計劃中，唔可以當成已通過。

所以，呢份草案最有用嘅地方，未必係再加多幾個 Agent，而係將接力規則寫清楚：邊個依據乜嘢做事、證據屬於邊個候選、邊個有權批准，以及未通過時點樣保留現場再修復。最終能否成為有效門禁，仍要靠實際工具、權限隔離同測試驗收證明。