如何以及何時構建多智慧體系統
本文分析了兩個看似對立的部落格文章——Cognition團隊的“不要構建多智慧體”和Anthropic團隊的“我們如何構建多智慧體研究系統”，指出它們實際上有很多共同點，並提供了關於何時以及如何構建多智慧體系統的見解。關鍵要點包括：上下文工程至關重要、以“讀”為主的多智慧體系統比以“寫”為主的更容易、以及生產可靠性和工程挑戰。文章還介紹了LangGraph和LangSmith等工具如何幫助解決這些挑戰。
最近，兩篇部落格文章引發了關於多智慧體系統的討論：Cognition團隊釋出的《不要構建多智慧體》和Anthropic團隊釋出的《我們如何構建多智慧體研究系統》。儘管標題看似對立，但它們實際上分享了許多共同的見解，尤其是在何時以及如何有效地使用多智慧體架構方面。
首先，上下文工程（Context Engineering）是成功的關鍵。Cognition的文章強調了這一概念，指出即使是最智慧的模型，如果沒有適當的上下文，也無法有效工作。傳統的“提示工程”已經演變為“上下文工程”，它要求工程師在動態系統中自動為每個子智慧體提供正確的背景資訊。Anthropic的文章雖然沒有直接使用這個術語，但同樣關注了長期對話管理、子任務描述和上下文壓縮等問題。例如，他們描述瞭如何在長時間執行的研究中，透過智慧摘要和外部儲存來保持上下文的連貫性。
其次，多智慧體系統在“讀”任務上比“寫”任務更易管理。Cognition的編碼系統涉及大量的寫操作，這導致子智慧體之間容易產生衝突，因為“動作帶有隱式決策，衝突的決策會帶來糟糕的結果”。而Anthropic的研究系統則更多地依賴於讀操作（如搜尋和收集資訊），最終報告由單個智慧體統一編寫。這表明，當寫操作需要並行化時，協調和合並的複雜性會急劇增加。
生產環境中，多智慧體系統還面臨一系列工程挑戰。Anthropic的文章列舉了持久執行、錯誤處理、除錯和可觀測性等問題。例如，智慧體長時間執行後，任何小錯誤都可能累積成嚴重問題，且無法簡單地從起點重啟。因此，需要框架支援耐用執行，確保在出錯時能從中斷處恢復。此外，智慧體的非確定性行為使得除錯變得困難，需要全面的跟蹤和可觀測性工具來診斷問題。
評估也是另一個重要方面。Anthropic建議從小規模評估開始（甚至20個資料點），使用LLM作為評判來自動評分，同時保留人工測試。這與LangSmith的評估方法論不謀而合，後者提供了資料集管理、LLM評判和人工註釋佇列等功能。
結論是，多智慧體系統並非萬能藥。它們最適合那些價值高、需要大量並行化、資訊超出單一上下文視窗、或涉及多個複雜工具的任務。對於像編碼這樣依賴性強的任務，當前的多智慧體技術可能並不理想。因此，框架應允許開發者在單智慧體和多智慧體之間靈活切換，而LangGraph正是為此設計。同時，像LangGraph和LangSmith這樣的工具可以提供耐用執行、除錯、可觀測性和評估等通用能力，讓開發者專注於業務邏輯。