點解 Agent 分工，仲要管好交接？

將工作拆畀多個 Agent，唔代表每個 Agent 自然會互相補位。AutoSwarm 論文摘要提到，多 Agent 協作未必自動帶來互補成果，Agent 之間嘅依賴亦可能令局部錯誤擴大成任務失敗。1

所以，治理重點唔只係「邊個做邊部分」，仲要講清楚每個階段消費咩資料、交出咩成果、由邊個驗證，以及出錯時點樣退返去。呢份工程草案用一個任務工件貫穿整條工作流，唔按角色各自開一套文件。

要先講清楚：以下係設計提案，唔係已落地嘅系統。草案列出嘅路徑、模板同門禁接口，唔代表相關資產已建立或通過測試。

四種工作視角，放入 Plan-Act 兩個階段

草案將四種職責放進同一條 Plan-Act 流程：

階段	工作視角	主要責任
Plan 前段	Analyst（分析）	釐清業務目標、限制、驗收要求，以及仍未解決嘅問題。
Plan 後段	Architect（架構）	定義介面、交付範圍、依賴、檢查項目同失敗後點樣處理。
Act 前段	Coder（實作）	按已批准嘅契約實作，並提供候選版本同自測證據。
Act 後段	Supervisor（監督）	核對交付、安排驗證同反向審查，確認可否進入下一步。

關鍵唔係一定要有四個獨立 Agent，而係要令工作有清楚嘅先後次序同出口條件。細小任務可以縮短分析同設計，但仍要交代目標、範圍、適用檢查同審查安排，唔可以單靠「好簡單」跳過門禁。

華為公開資料亦提到，質量要求應融入業務流程；相關文章則將業務流視為流程、IT、數據、質量管理同營運嘅基礎。78 呢個觀點喺草案入面化成一項設計原則：質量檢查唔應只係最後先加上去，而要跟住工作流一併設計。

同一個 Agent 可以換視角，但唔可以自己批自己

Agent 可以先做實作者，再用 Supervisor 嘅角度檢查自己嘅候選版本，做反向推演、核對證據、整理問題。不過，呢啲仍然係同一個執行主體嘅分析，唔等於獨立審查。

草案建議嘅預設安排係：Agent 負責按流程工作、受信驗證入口負責產生機器結果，最後由一位未參與實作嘅人類審查員獨立核對並簽章。新開一個對話、換一個模型，或者將角色名稱改成「Supervisor」，都唔足以證明審查獨立。

如果改用自動審查服務，就要另外界定佢嘅身份、權限、審查資料同失效處理，並實際驗收。否則，最多只能稱為另一項檢查，唔應當作已建立職責分離。

一份任務契約，保存目標、狀態同證據位置

草案建議將任務契約同生命週期集中放喺 specs/tasks/。每個任務有一份權威工件，記錄目標、依賴、輸入、交付清單、驗收條件、必需檢查、授權引用同目前階段；機器回執同審查報告則由任務工件引用，而唔係再複製一套狀態。

另一個擬議檔案 _active.md 只用嚟指向目前焦點任務。佢唔應另外記錄任務階段、角色或者驗收結果，否則同一件事就可能喺兩個地方出現唔同版本。

呢個安排亦有一個重要分別：任務工件係管理工作嘅主線，但唔代表所有程式碼、測試或者大型日誌都要搬入任務目錄。工作輸出、測試資產、原始證據同已發布嘅領域規範，各自仍要有清楚用途同位置。

草案亦建議只載入完成當前工序所需嘅資料：任務契約、相關輸入、必要嘅領域規則，以及當前候選同證據定位。階段轉換、恢復工作或者候選有變時，就重新核對任務身份、契約版本、授權同未完成事項；唔好單靠聊天摘要延續之前嘅「已通過」結論。

驗收唔係一句「測試全綠」

草案將放行條件寫成兩部分同時成立：機器檢查通過，並且獨立審查有效。機器檢查負責按預先定義嘅命令、斷言同測試清單收集結果；獨立審查則核對業務意思、邊界條件、副作用同機器檢查未覆蓋嘅風險。

實際回執需要連結到特定任務、契約版本、候選版本、嘗試編號同執行環境。必需檢查缺失、結果過期、測試無法確認有冇執行，或者候選版本已改變，都唔應視為通過。草案將結果分成 PASS、FAIL 同 UNKNOWN：只有 PASS 可以滿足機器門禁，FAIL 同 UNKNOWN 都唔放行。

審查簽章亦要綁定同一份契約、候選版本、機器回執同審查報告。如果實作、測試或關鍵環境有變，舊簽章未必仍然適用，受影響部分要重新驗證。合併、發布同歸檔亦係不同操作，各自需要對應授權同實際回執；唔可以用一句「已完成」將幾件事混為一談。

失敗時保留現場，唔好為咗過關改低標準

驗收失敗後，草案建議保留當時嘅候選版本、失敗回執、審查報告同授權範圍，唔好自動清理或者覆蓋。一般實作問題可以喺授權範圍內交返實作者修正，再建立新一輪嘗試；如果目標、介面或驗收條件改變，就要返回設計階段，更新契約並重新批准。

缺少環境、權限或必需證據時，應該標記為受阻，而唔係臨時跳過檢查。草案亦明確反對透過刪除測試、降低斷言或者將失敗改名，令候選「睇落」通過。

仍然要實際驗收宿主同執行環境

文件規則可以講清楚應該點做，但唔能夠單靠文字證明 Roo Code、Cline 或其他宿主真係載入咗規則，亦唔能夠證明工具權限、審批入口同驗證回執已經受控。草案要求逐項確認規則有冇載入、模式有冇生效、權限有冇按預期限制，以及失敗時系統會唔會拒絕推進。

同樣，將輸出放喺某個目錄，唔等於已經有執行層面嘅沙盒隔離；需要按實際環境核實檔案、網絡、憑證同程序權限。草案提出嘅驗證時限亦只係可調整嘅工程預設，唔係普遍適用嘅保證。

總括嚟講，呢套做法嘅核心係令任務目標、工作交接、驗證結果同獨立審查互相對得上。佢提供咗一個可以實作嘅治理方向，但要成為真正嘅門禁，仍要由受控工具同實際審批流程落實，並逐項驗收。

點解 Agent 分工，仲要管好交接？

將工作拆畀多個 Agent，唔代表每個 Agent 自然會互相補位。AutoSwarm 論文摘要提到，多 Agent 協作未必自動帶來互補成果，Agent 之間嘅依賴亦可能令局部錯誤擴大成任務失敗。1

所以，治理重點唔只係「邊個做邊部分」，仲要講清楚每個階段消費咩資料、交出咩成果、由邊個驗證，以及出錯時點樣退返去。呢份工程草案用一個任務工件貫穿整條工作流，唔按角色各自開一套文件。

要先講清楚：以下係設計提案，唔係已落地嘅系統。草案列出嘅路徑、模板同門禁接口，唔代表相關資產已建立或通過測試。

四種工作視角，放入 Plan-Act 兩個階段

草案將四種職責放進同一條 Plan-Act 流程：

階段	工作視角	主要責任
Plan 前段	Analyst（分析）	釐清業務目標、限制、驗收要求，以及仍未解決嘅問題。
Plan 後段	Architect（架構）	定義介面、交付範圍、依賴、檢查項目同失敗後點樣處理。
Act 前段	Coder（實作）	按已批准嘅契約實作，並提供候選版本同自測證據。
Act 後段	Supervisor（監督）	核對交付、安排驗證同反向審查，確認可否進入下一步。

關鍵唔係一定要有四個獨立 Agent，而係要令工作有清楚嘅先後次序同出口條件。細小任務可以縮短分析同設計，但仍要交代目標、範圍、適用檢查同審查安排，唔可以單靠「好簡單」跳過門禁。

華為公開資料亦提到，質量要求應融入業務流程；相關文章則將業務流視為流程、IT、數據、質量管理同營運嘅基礎。78 呢個觀點喺草案入面化成一項設計原則：質量檢查唔應只係最後先加上去，而要跟住工作流一併設計。

同一個 Agent 可以換視角，但唔可以自己批自己

Agent 可以先做實作者，再用 Supervisor 嘅角度檢查自己嘅候選版本，做反向推演、核對證據、整理問題。不過，呢啲仍然係同一個執行主體嘅分析，唔等於獨立審查。

草案建議嘅預設安排係：Agent 負責按流程工作、受信驗證入口負責產生機器結果，最後由一位未參與實作嘅人類審查員獨立核對並簽章。新開一個對話、換一個模型，或者將角色名稱改成「Supervisor」，都唔足以證明審查獨立。

如果改用自動審查服務，就要另外界定佢嘅身份、權限、審查資料同失效處理，並實際驗收。否則，最多只能稱為另一項檢查，唔應當作已建立職責分離。

一份任務契約，保存目標、狀態同證據位置

草案建議將任務契約同生命週期集中放喺 specs/tasks/。每個任務有一份權威工件，記錄目標、依賴、輸入、交付清單、驗收條件、必需檢查、授權引用同目前階段；機器回執同審查報告則由任務工件引用，而唔係再複製一套狀態。

另一個擬議檔案 _active.md 只用嚟指向目前焦點任務。佢唔應另外記錄任務階段、角色或者驗收結果，否則同一件事就可能喺兩個地方出現唔同版本。

呢個安排亦有一個重要分別：任務工件係管理工作嘅主線，但唔代表所有程式碼、測試或者大型日誌都要搬入任務目錄。工作輸出、測試資產、原始證據同已發布嘅領域規範，各自仍要有清楚用途同位置。

草案亦建議只載入完成當前工序所需嘅資料：任務契約、相關輸入、必要嘅領域規則，以及當前候選同證據定位。階段轉換、恢復工作或者候選有變時，就重新核對任務身份、契約版本、授權同未完成事項；唔好單靠聊天摘要延續之前嘅「已通過」結論。

驗收唔係一句「測試全綠」

草案將放行條件寫成兩部分同時成立：機器檢查通過，並且獨立審查有效。機器檢查負責按預先定義嘅命令、斷言同測試清單收集結果；獨立審查則核對業務意思、邊界條件、副作用同機器檢查未覆蓋嘅風險。

實際回執需要連結到特定任務、契約版本、候選版本、嘗試編號同執行環境。必需檢查缺失、結果過期、測試無法確認有冇執行，或者候選版本已改變，都唔應視為通過。草案將結果分成 PASS、FAIL 同 UNKNOWN：只有 PASS 可以滿足機器門禁，FAIL 同 UNKNOWN 都唔放行。

審查簽章亦要綁定同一份契約、候選版本、機器回執同審查報告。如果實作、測試或關鍵環境有變，舊簽章未必仍然適用，受影響部分要重新驗證。合併、發布同歸檔亦係不同操作，各自需要對應授權同實際回執；唔可以用一句「已完成」將幾件事混為一談。

失敗時保留現場，唔好為咗過關改低標準

驗收失敗後，草案建議保留當時嘅候選版本、失敗回執、審查報告同授權範圍，唔好自動清理或者覆蓋。一般實作問題可以喺授權範圍內交返實作者修正，再建立新一輪嘗試；如果目標、介面或驗收條件改變，就要返回設計階段，更新契約並重新批准。

缺少環境、權限或必需證據時，應該標記為受阻，而唔係臨時跳過檢查。草案亦明確反對透過刪除測試、降低斷言或者將失敗改名，令候選「睇落」通過。

仍然要實際驗收宿主同執行環境

文件規則可以講清楚應該點做，但唔能夠單靠文字證明 Roo Code、Cline 或其他宿主真係載入咗規則，亦唔能夠證明工具權限、審批入口同驗證回執已經受控。草案要求逐項確認規則有冇載入、模式有冇生效、權限有冇按預期限制，以及失敗時系統會唔會拒絕推進。

同樣，將輸出放喺某個目錄，唔等於已經有執行層面嘅沙盒隔離；需要按實際環境核實檔案、網絡、憑證同程序權限。草案提出嘅驗證時限亦只係可調整嘅工程預設，唔係普遍適用嘅保證。

總括嚟講，呢套做法嘅核心係令任務目標、工作交接、驗證結果同獨立審查互相對得上。佢提供咗一個可以實作嘅治理方向，但要成為真正嘅門禁，仍要由受控工具同實際審批流程落實，並逐項驗收。