前不久，史丹佛大學教授吳恩達在演講中提到了智能體的巨大潛力，也引起了許多討論。其中，吳恩達談到基於 GPT-3.5 建構的智能體工作流程在應用上表現比 GPT-4 更好。這表明，將目光局限於大模型不一定可取，智能體或許會比其所使用的基礎模型更加優秀。
在軟體開發領域，這些智能體展現了其獨特的能力，能夠高效協作，處理程式設計中的複雜問題，甚至進行程式碼自動產生。最新的技術動態顯示，AI 智能通在軟體開發中顯示出巨大的潛力。還記得 Devin 嗎？號稱世界第一個 AI 軟體工程師的它出場就驚艷到了我們，一個智能體就能帶給我們如此體驗，如果是多個智能體合作，是不是能夠直接把體驗值直接拉滿呢？
想像一下，一個由多個智能體組成的團隊，每個成員都擅長於特定的任務，如程式碼審查、錯誤偵測或新功能實作。這些智能體體可以互補彼此的能力，共同推動軟體專案的進度。這豈不是解放了碼農的雙手，再也不用擔心腱鞘炎了。
吳恩達撰寫一篇帶我們深入這一領域，探索智慧體系的最新動態。文章中提及的 AutoGen 和 LangGraph 等工具，正是在這一大背景下應運而生。這些工具旨在幫助開發者更容易部署和管理 AI 智能體，從而充分發揮其潛力。借助它們的力量，即使是沒有深厚程式設計背景的人也能夠利用 AI 智能體來優化和自動化軟體開發流程。以下是機器之心不改變原義的整理與翻譯。
原文連結：https://www.deeplearning.ai/the-batch/issue-245/
智能體協作是我最近幾封信中描述的四種關鍵AI 智能體設計模式中的最後一種。對於像編寫軟體這樣的複雜任務，多智能體方法會將任務分解成由不同角色（如軟體工程師、產品經理、設計師、QA 工程師等）執行的子任務，並讓不同的智能體完成不同的子任務。
不同的智能體可以透過提供一個LLM（或多個LLM）執行不同的任務來建構。例如，要建立一個軟體工程師智能體，我們可以提供LLM：「你是編寫清晰、高效程式碼的專家。請寫程式碼來執行任務…」。
我們多次呼叫相同的大型語言模型（LLM），但我們採用多智能體的程式設計抽象方法，這看似違反直覺，但卻有幾個理由支持：
在許多公司中，管理者通常會決定招募哪些角色，然後如何將複雜專案— 如寫一大塊軟體或準備研究報告－ 分解為較小的任務分配給不同專長的員工。使用多個智能體的做法與此類似。每個智能體實施自己的工作流程，擁有自己的記憶（這本身是智能體技術中一個迅速發展的領域：一個智能體如何記住足夠多的過去互動以在未來的任務中表現得更好） ，並可能請求其他智能體的幫助。智能體還可以進行規劃和使用工具。這會產生了大量的 LLM 呼叫和智慧體間的訊息傳遞，可能形成非常複雜的工作流程。
雖然管理人員很困難，但這是我們非常熟悉的，它為我們如何「僱用」和分配任務給我們的 AI 智能體提供了一個心理框架。幸運的是，管理不善 AI 智能體的傷害遠低於管理不善人類！
像 AutoGen、Crew AI 和 LangGraph 這樣的新興框架為解決問題提供了豐富的多智能體解決方案。如果你對玩樂趣十足的多智能體系統感興趣，不妨看看 ChatDev，這是一個運行虛擬軟體公司的智能體集合的開源實作。你可以查看他們的 GitHub repo，也許複製 repo 並親自運行系統。雖然它可能不會總是產生你想要的結果，但你可能會對它的表現感到驚訝。
就像規劃這個設計模式一樣，我發現多智能體協作的輸出品質很難預測，特別是當允許智能體自由互動並為它們提供多種工具時。更成熟的反思和工具使用模式更為可靠。希望你能享受這些智能體設計模式的樂趣，並且它們能為你帶來驚人的結果！如果你有興趣了解更多，可以閱讀以下文章：
更多詳細內容，請閱讀原文。
看了本篇文章，網友們大受啟發，不過也有網友提出，多智能體系統在執行相同或類似任務時表現出的穩定性和可預測性還有待考慮。你覺得多智能體協作的益弊何在呢？
以上是吳恩達：多智能體協作是新關鍵，軟體開發等任務將更有效率的詳細內容。更多資訊請關注PHP中文網其他相關文章！
