AI Agent 一有複雜任務，直覺可能係再加幾個 Agent，分別做研究、寫程式同驗收。不過，分工本身唔保證大家真係互補；如果工作互相依賴，某一環出錯，亦有機會拖累成個任務。AutoSwarm 論文摘要正正提出呢類協作難題。1

一份標示為 2026 年 10 月 27 日嘅 BMAD-Solo 工程草案，就選擇由任務流程落手：唔先堆砌 Agent 數目，而係定清楚每個階段交乜、邊啲證據先算數，同埋幾時先可以將成果交畀下游使用。

四種職責，仍然可以係同一個 Agent

草案將工作串成一條流程：目標進入、Plan 分析、Plan 架構、Act 實施、Act 審查，最後先受控交付。Analyst 負責釐清目標同驗收要求；Architect 整理接口、依賴同檢查方法；Coder 按已批准嘅契約實施；Supervisor 則負責反向檢查成果。

重點係，呢四個名稱代表工序職責，唔代表一定要建立四個獨立 Agent。草案亦提醒，角色提示詞轉咗，唔等於權限邊界真係改變：同一個模型寫完程式，再換個角色審自己，唔可以當成獨立審查。

呢種由業務流程出發嘅思路，亦呼應徐直軍談流程時提到嘅觀點：流程係對業務流嘅呈現，IT 承載及支援業務流，質量要求亦應放喺流程之中。11 不過，呢度引用嘅係流程觀念；草案入面嘅任務欄位同門禁設計，係工程提案，唔係原文定義。

兩道門：機器檢查加獨立審查

草案最核心嘅門檻係 C ∧ R：機器檢查 C 同獨立審查 R 必須同時通過，先可以接受任務。真正釋出成果畀下游使用，仲要確認授權、依賴同候選版本都一致。

機器檢查唔係單睇「測試成功」四個字。方案要求檢查有明確命令、時限同工作目錄，保留真實執行回執，並核對測試有冇實際執行、必要項目有冇被略過，以及檢查後成果有冇改動。證據缺失、過期或者無法確認，都唔應該當作通過。

而獨立審查要針對一個明確嘅契約版本同候選成果，檢查驗收項目、邊界情況、錯誤處理同已知限制。草案亦提出，正式簽章應由實作者以外、經受保護機制核實嘅審查者完成；手寫姓名、角色標籤或者另一段提示詞，都唔足以證明身份獨立。

任務文件唔等於流水帳

方案建議，每個任務都有一份權威契約，寫清楚目標、授權範圍、輸入依據、交付物、驗收條件、檢查方式同失敗後點處理。原始測試回執、機器判定同審查結論各自有清楚位置，避免同一個狀態喺幾份文件入面各自更新。

交接亦唔係將上游對話成份搬過去。分析交畀架構設計，應提供可核對嘅目標、限制同未知；架構交畀實施，則要有凍結嘅交付契約同檢查方法。重點係保留下游做事必要嘅資料，而唔係保存所有過程。

最重要嘅限制：設計稿唔等於已經落地

草案對自身邊界講得幾清楚：文件模板同 Roo Code、Cline 配置片段只係目標設計，唔代表宿主已經載入規則、阻止越權操作，或者實際支援獨立簽章。相關運行時能力都要另行驗收。

所以，呢套方案目前適合當作治理設計去討論，唔應包裝成一個已經實測成功嘅產品。當 AI 開始處理跨多步驟工作，與其只問「要唔要多開幾個 Agent」，更實際嘅問題可能係：任務點樣交接、證據點樣保存，以及邊個有資格批准成果釋出。

AI Agent 一有複雜任務，直覺可能係再加幾個 Agent，分別做研究、寫程式同驗收。不過，分工本身唔保證大家真係互補；如果工作互相依賴，某一環出錯，亦有機會拖累成個任務。AutoSwarm 論文摘要正正提出呢類協作難題。1

一份標示為 2026 年 10 月 27 日嘅 BMAD-Solo 工程草案，就選擇由任務流程落手：唔先堆砌 Agent 數目，而係定清楚每個階段交乜、邊啲證據先算數，同埋幾時先可以將成果交畀下游使用。

四種職責，仍然可以係同一個 Agent

草案將工作串成一條流程：目標進入、Plan 分析、Plan 架構、Act 實施、Act 審查，最後先受控交付。Analyst 負責釐清目標同驗收要求；Architect 整理接口、依賴同檢查方法；Coder 按已批准嘅契約實施；Supervisor 則負責反向檢查成果。

重點係，呢四個名稱代表工序職責，唔代表一定要建立四個獨立 Agent。草案亦提醒，角色提示詞轉咗，唔等於權限邊界真係改變：同一個模型寫完程式，再換個角色審自己，唔可以當成獨立審查。

呢種由業務流程出發嘅思路，亦呼應徐直軍談流程時提到嘅觀點：流程係對業務流嘅呈現，IT 承載及支援業務流，質量要求亦應放喺流程之中。11 不過，呢度引用嘅係流程觀念；草案入面嘅任務欄位同門禁設計，係工程提案，唔係原文定義。

兩道門：機器檢查加獨立審查

草案最核心嘅門檻係 C ∧ R：機器檢查 C 同獨立審查 R 必須同時通過，先可以接受任務。真正釋出成果畀下游使用，仲要確認授權、依賴同候選版本都一致。

機器檢查唔係單睇「測試成功」四個字。方案要求檢查有明確命令、時限同工作目錄，保留真實執行回執，並核對測試有冇實際執行、必要項目有冇被略過，以及檢查後成果有冇改動。證據缺失、過期或者無法確認，都唔應該當作通過。

而獨立審查要針對一個明確嘅契約版本同候選成果，檢查驗收項目、邊界情況、錯誤處理同已知限制。草案亦提出，正式簽章應由實作者以外、經受保護機制核實嘅審查者完成；手寫姓名、角色標籤或者另一段提示詞，都唔足以證明身份獨立。

任務文件唔等於流水帳

方案建議，每個任務都有一份權威契約，寫清楚目標、授權範圍、輸入依據、交付物、驗收條件、檢查方式同失敗後點處理。原始測試回執、機器判定同審查結論各自有清楚位置，避免同一個狀態喺幾份文件入面各自更新。

交接亦唔係將上游對話成份搬過去。分析交畀架構設計，應提供可核對嘅目標、限制同未知；架構交畀實施，則要有凍結嘅交付契約同檢查方法。重點係保留下游做事必要嘅資料，而唔係保存所有過程。

最重要嘅限制：設計稿唔等於已經落地

草案對自身邊界講得幾清楚：文件模板同 Roo Code、Cline 配置片段只係目標設計，唔代表宿主已經載入規則、阻止越權操作，或者實際支援獨立簽章。相關運行時能力都要另行驗收。

所以，呢套方案目前適合當作治理設計去討論，唔應包裝成一個已經實測成功嘅產品。當 AI 開始處理跨多步驟工作，與其只問「要唔要多開幾個 Agent」，更實際嘅問題可能係：任務點樣交接、證據點樣保存，以及邊個有資格批准成果釋出。