我打造了一支會自我審查的 AI 開發團隊——關於多代理迴圈的學習心得

大多數多代理示範五分鐘內令人驚艷，但五小時後就毫無用處。在花了數個月打造 Task Hounds —— 一個開源、本地的多代理開發工作區 —— 之後，以下是真正關鍵的設計決策。

設定

Task Hounds 在單一專案周圍以迴圈方式運行三個代理：

• Manager（管理員）：理解上下文、維護計畫，並在每個週期分配一個具體任務
• Worker（工作員）：執行任務並提交結構化報告：變更的檔案、測試結果、已知問題
• Reviewer（審查員）：在 Manager 決定下一步之前，檢查結果是否有 bug、UX 問題及風險

人類會撰寫一份 Directive（指令）（任務使命），並可在執行期間插入想法或新任務。所有內容 —— 計畫、待辦事項、報告、回饋、即時代理串流 —— 都會持久保存於本地 SQLite，並在即時儀表板中呈現。

心得 1：一次一任務優於平行處理一切

我最初的直覺是採用平行工作員。示範效果很好，卻什麼都沒交付：代理們互相干擾對方的檔案，而 Manager 也無法歸因失敗。改為序列化成每個迴圈只處理一個任務，看似較慢，卻能完成更多工作。

心得 2：給人類一個寫入保護的錨點

目標漂移是長迴圈的隱形殺手。大約在第 10 個迴圈時，計畫會逐漸不再符合你原本的要求。我們的解決方案：Human Directive 會被複製到每個工作階段，且迴圈被禁止編輯它。只有人類才能變更任務使命。漂移現在會以與固定錨點的明顯差異呈現，而非悄無聲息地改變。

心得 3：結構化交接，而非聊天紀錄

在代理之間傳遞對話歷史有兩種失敗方式：它會超出上下文視窗，並讓下游代理受上游推理雜訊的影響。Task Hounds 中的每次交接都是固定文件：Manager 的記憶體是每個迴圈讀取一次的明確 JSON 交接；Worker 的輸出是固定的報告結構。如果機器可讀的待辦 JSON 無效，迴圈會在任何工作發布前修復它。

心得 4：審查員不得擁有權力

早期版本中，Reviewer 可以直接指派修復。結果：無限的審查迴圈，兩個代理無止境地協商。現在 Reviewer 只會將結構化回饋提交給 Manager，由 Manager 決定：修復、繼續或停止。將判斷與決策分開，穩定化了整個迴圈。

心得 5：信任是 UI 問題，而非模型問題

我給系統多少自主權的最大改變，不是來自更好的模型，而是能夠觀察。當每個決策都是 SQLite 中的一列，以及儀表板中的一個面板時，「我應該讓它運行一小時嗎？」就變成一個證據問題，而非信念問題。

仍待克服的難題

• 與 LLM 的文字合約仍然脆弱；結構化輸出／工具呼叫將取代我們修復層的一部分
• 成本：三種角色使用的 token 多於一次性提示。我們的賭注是，計畫→實作→審查比重新提示一個困惑的單一代理更省 token —— 對長任務成立，對小編輯則不一定
• 跨平台完善度（受管理的執行環境目前以 Windows 為主；Docker 則可在各處運行）

試用

Task Hounds 採用 MIT 授權：https://github.com/catowabisabi/task-hounds
3 分鐘示範：https://www.youtube.com/watch?v=pu-Rt8Ye4EQ

如果你也曾建置代理迴圈 —— 你的迴圈在哪個階段出問題：規劃、執行還是審查？歡迎在留言區分享心得。