課堂活動：模擬多 Agent 協作與自動化驗收閘道

本頁是一次課堂模擬演練：讓多個 Agent 圍繞同一開發任務分工協作，把各自產生的候選修改統一送入自動化測試與驗收閘道；只有滿足可執行驗收標準的修改才能進入歷史基線，不合格修改會被攔截並返回可重現的回饋。這樣做的目標不是讓 Agent 互相「討論出正確」，而是把「協作開發—自動驗收—歷史繼承」的工程閉環跑通。

演練目標

• 理解多 Agent 協作開發中的任務分工、候選修改匯合，以及驗收閘道對不合格修改的攔截作用。
• 體驗用可執行測試和驗收條件替代主觀審批，觀察哪些候選能進入基線、哪些需要重試。
• 比較高階問題：驗收規則是否可重現、回饋是否可行動、誤攔截與漏攔截風險、拆解粒度與協作成本。

角色分工與基本流程

可以把課堂小組分成規劃/拆解 Agent、實作 Agent、測試生成 Agent、審查/協調 Agent。同一任務允許產生多個候選修改，再由閘道統一裁決。

1. 任務拆解：把目標拆成可獨立驗證的子任務，例如「介面校驗—演算法修復—回歸測試」。
2. 並行實作：多個實作 Agent 提交候選補丁，測試 Agent 生成邊界用例。
3. 自動驗收：執行自動化測試、靜態檢查與契約檢查，由驗收閘道按可執行標準判定。
4. 歷史繼承：通過的修改合入歷史基線，成為後續 Agent 繼續工作的基礎；被拒修改保留失敗原因與重現資訊，用於重試。

驗收閘道標準

閘道的判據必須可執行，不能停留在「看起來正確」。重點攔截不滿足介面約定、引入回歸、未覆蓋邊界條件或違反品質約束的修改。一個可用的回饋至少應包含：失敗用例、日誌、重現步驟、期望行為與相關約束。

歷史繼承與高階觀察

通過的修改進入基線後，後續 Agent 不必從零開始；被拒修改則成為可檢索的負例，避免重複犯錯。評估這類協作系統時，要特別關注驗收規則是否可重現、回饋是否可行動，以及誤攔截與漏攔截帶來的不同風險。拆解粒度過細會抬高合併與驗收成本，過粗又會讓候選修改互相覆蓋；更穩的做法是按「可獨立驗證」的邊界拆分。