Agent 工作流，問題唔只係「識唔識分工」

當 AI Agent 被安排成分析、設計、編碼同審查幾種角色，表面上似有一隊專業團隊；但角色分得細，唔代表交接自然可靠。AutoSwarm 論文摘要指出，多 Agent 的專門分工未必自動帶來互補，而 Agent 之間的依賴亦可能令局部錯誤拖垮整項工作。1

一份名為 BMAD-Solo 的工程規範草案，嘗試將焦點由「再加多幾個 Agent」轉去任務契約、證據同放行規則。佢提出以一條 Plan-Act 業務流，由同一個任務單位貫穿分析、設計、實作及審查；角色代表工序責任，唔係四個各自運作的 Agent。

要留意，呢份內容係目標設計草案，唔係已落地的系統說明。草案亦指出，現有材料未能核實 AutoSwarm 論文中指定的詳細公式，亦未取得徐直軍相關講話的官方完整原文，因此只將相關原則視為設計要求，唔當成已驗證的工程效果。

一個任務單位，四段工序

草案將工作流程拆成四個責任：

• Analyst：釐清業務目標、驗收條件、限制同未知事項。
• Architect：將目標變成明確交付清單、接口、依賴、檢查項目同審查要求。
• Coder：只按獲批範圍實作，提交候選成果及真實測試證據。
• Supervisor：對照交付要求反向審查，指出風險、缺口及局限。

每次交接都要講清楚任務編號、契約版本、目前工序、操作授權、必須完成的工作，以及下一工序的提交條件。焦點唔係令提示詞寫得更長，而係避免模型將「我以為做完」當成「已符合放行條件」。

機器測試過關，唔等於可以放行

草案提出雙重門禁：一方面，所有必需的機器檢查都要通過，證據亦要對得上當前任務、契約同候選版本；另一方面，必須有未參與該候選實作的授權審查者，針對同一版本獨立簽章。

換句話講，模型由 Coder 切換成 Supervisor、換一個提示詞，甚至清空對話，都唔足以證明審查真正獨立。草案要求獨立審查者可以退回候選，而且唔可以由編碼者透過一般寫檔工具自行補上簽章。

同樣地，提示詞本身亦唔係硬性安全閘。要真正阻止未驗證成果被放行，還要有受控的執行、驗證及釋出入口。如果部署環境只提供提示詞提醒，草案建議如實標示為「行為引導，硬門禁未覆蓋」。

保留證據，比留低一句「測試通過」可靠

每次檢查都應留下可核對的回執，例如檢查命令、退出狀態、測試收集數量、跳過項目、錯誤輸出、清理情況，以及候選和契約的識別資料。超時、未執行、必需項目被跳過、結果無法解析，或者清理狀態未知，都唔應該當成通過。

草案亦主張每次執行保留不可覆寫的原始證據，並為候選成果、任務契約同執行環境計算摘要。若候選內容改動，舊審查簽章就要失效；機器測試證據亦只有在受控執行器確認仍然適用時，先可以考慮沿用。

單一任務契約，避免多份紀錄互相打架

建議的文件設計以一份任務契約作為當前工作的權威入口，再用一個焦點指標記錄目前處理哪項任務。機器回執、原始執行證據同審查報告各有用途，任務契約只引用佢哋，避免把同一個狀態複製到幾份文件，最後出現「邊份先算數」的問題。

草案亦強調，獲接受的成果先適合沉澱到長期領域規範；調試過程、未證實的假設同逐輪執行記錄，唔應該直接變成長期事實。若審查後仍要改動程式或規範，就要形成新候選，再重新核對受影響的證據。

由草案到落地，仲差實際驗收

建議的落地次序包括：先建立契約格式和焦點管理，再接入能產生真實回執的受控執行器，然後加入獨立審查同受保護的放行入口，最後先驗證 Roo Code 或 Cline 等宿主的實際規則載入、權限限制同錯誤處理。

測試唔可以只證明「正確情況會通過」，亦要證明零測試、超時、缺少簽章、候選被改動、任務焦點爭用等情況會被拒絕，同時確保合法任務仍然可以完成。

**最重要的結論：Agent 工程化唔係將角色標籤貼得更齊，而係令每項工作都有明確契約、可核查證據同可信的獨立放行機制。**呢份草案提出咗一套目標規則，但相關控制器、審查服務、宿主整合同遷移工作，仍須逐項實作及驗收，未可以當成已經生效。

Agent 工作流，問題唔只係「識唔識分工」

當 AI Agent 被安排成分析、設計、編碼同審查幾種角色，表面上似有一隊專業團隊；但角色分得細，唔代表交接自然可靠。AutoSwarm 論文摘要指出，多 Agent 的專門分工未必自動帶來互補，而 Agent 之間的依賴亦可能令局部錯誤拖垮整項工作。1

一份名為 BMAD-Solo 的工程規範草案，嘗試將焦點由「再加多幾個 Agent」轉去任務契約、證據同放行規則。佢提出以一條 Plan-Act 業務流，由同一個任務單位貫穿分析、設計、實作及審查；角色代表工序責任，唔係四個各自運作的 Agent。

要留意，呢份內容係目標設計草案，唔係已落地的系統說明。草案亦指出，現有材料未能核實 AutoSwarm 論文中指定的詳細公式，亦未取得徐直軍相關講話的官方完整原文，因此只將相關原則視為設計要求，唔當成已驗證的工程效果。

一個任務單位，四段工序

草案將工作流程拆成四個責任：

• Analyst：釐清業務目標、驗收條件、限制同未知事項。
• Architect：將目標變成明確交付清單、接口、依賴、檢查項目同審查要求。
• Coder：只按獲批範圍實作，提交候選成果及真實測試證據。
• Supervisor：對照交付要求反向審查，指出風險、缺口及局限。

每次交接都要講清楚任務編號、契約版本、目前工序、操作授權、必須完成的工作，以及下一工序的提交條件。焦點唔係令提示詞寫得更長，而係避免模型將「我以為做完」當成「已符合放行條件」。

機器測試過關，唔等於可以放行

草案提出雙重門禁：一方面，所有必需的機器檢查都要通過，證據亦要對得上當前任務、契約同候選版本；另一方面，必須有未參與該候選實作的授權審查者，針對同一版本獨立簽章。

換句話講，模型由 Coder 切換成 Supervisor、換一個提示詞，甚至清空對話，都唔足以證明審查真正獨立。草案要求獨立審查者可以退回候選，而且唔可以由編碼者透過一般寫檔工具自行補上簽章。

同樣地，提示詞本身亦唔係硬性安全閘。要真正阻止未驗證成果被放行，還要有受控的執行、驗證及釋出入口。如果部署環境只提供提示詞提醒，草案建議如實標示為「行為引導，硬門禁未覆蓋」。

保留證據，比留低一句「測試通過」可靠

每次檢查都應留下可核對的回執，例如檢查命令、退出狀態、測試收集數量、跳過項目、錯誤輸出、清理情況，以及候選和契約的識別資料。超時、未執行、必需項目被跳過、結果無法解析，或者清理狀態未知，都唔應該當成通過。

草案亦主張每次執行保留不可覆寫的原始證據，並為候選成果、任務契約同執行環境計算摘要。若候選內容改動，舊審查簽章就要失效；機器測試證據亦只有在受控執行器確認仍然適用時，先可以考慮沿用。

單一任務契約，避免多份紀錄互相打架

建議的文件設計以一份任務契約作為當前工作的權威入口，再用一個焦點指標記錄目前處理哪項任務。機器回執、原始執行證據同審查報告各有用途，任務契約只引用佢哋，避免把同一個狀態複製到幾份文件，最後出現「邊份先算數」的問題。

草案亦強調，獲接受的成果先適合沉澱到長期領域規範；調試過程、未證實的假設同逐輪執行記錄，唔應該直接變成長期事實。若審查後仍要改動程式或規範，就要形成新候選，再重新核對受影響的證據。

由草案到落地，仲差實際驗收

建議的落地次序包括：先建立契約格式和焦點管理，再接入能產生真實回執的受控執行器，然後加入獨立審查同受保護的放行入口，最後先驗證 Roo Code 或 Cline 等宿主的實際規則載入、權限限制同錯誤處理。

測試唔可以只證明「正確情況會通過」，亦要證明零測試、超時、缺少簽章、候選被改動、任務焦點爭用等情況會被拒絕，同時確保合法任務仍然可以完成。

**最重要的結論：Agent 工程化唔係將角色標籤貼得更齊，而係令每項工作都有明確契約、可核查證據同可信的獨立放行機制。**呢份草案提出咗一套目標規則，但相關控制器、審查服務、宿主整合同遷移工作，仍須逐項實作及驗收，未可以當成已經生效。