吳恩達：多智能體協作是新關鍵，軟件開發等任務將更高效

作者：機器之心 2024-04-26 12:37:57

在軟件開發領域，這些智能體展示了其獨特的能力，能夠高效協作，處理編程中的復雜問題，甚至進行代碼自動生成。最新的技術動態顯示，AI 智能通在軟件開發中顯示出巨大的潛力。

前不久，斯坦福大學教授吳恩達在演講中提到了智能體的巨大潛力，這也引起了眾多討論。其中，吳恩達談到基于 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），但我們采用多智能體的編程抽象方法，這看似違反直覺，但卻有幾個理由支持：

它有效！許多團隊使用這種方法取得了良好的效果，沒有什么比結果更有說服力的了。此外，消融研究（例如在 AutoGen 論文中）表明，多智能體的表現優于單一智能體。
雖然現今的一些 LLM 能接受非常長的輸入上下文（例如，Gemini 1.5 Pro 可以接受 100 萬個 token），但它們真正理解長而復雜輸入的能力是參差不齊的。采用智能體工作流，讓 LLM 一次專注于一件事，可以獲得更好的表現。
最重要的是，多智能體設計模式為開發者提供了一個框架，用以將復雜任務分解成子任務。當在單個 CPU 上運行代碼時，我們經常將程序分解成不同的進程或線程。這種抽象有助于我們將任務分解成更易于編碼的子任務。使用多智能體角色進行思考同樣是一個有用的抽象。

在許多公司中，管理者通常會決定招聘哪些角色，然后如何將復雜項目 —— 如編寫一大塊軟件或準備研究報告 —— 分解為更小的任務分配給具有不同專長的員工。使用多個智能體的做法與此類似。每個智能體實施自己的工作流程，擁有自己的記憶（這本身是智能體技術中一個迅速發展的領域：一個智能體如何記住足夠多的過去互動以在未來的任務中表現得更好），并可能請求其他智能體的幫助。智能體還可以進行規劃和使用工具。這會產生了大量的 LLM 調用和智能體間的信息傳遞，可能形成非常復雜的工作流程。

雖然管理人員困難，但這是我們非常熟悉的，它為我們如何「雇傭」和分配任務給我們的 AI 智能體提供了一個心理框架。幸運的是，管理不善 AI 智能體的損害遠低于管理不善人類！

像 AutoGen、Crew AI 和 LangGraph 這樣的新興框架為解決問題提供了豐富的多智能體解決方案。如果你對玩樂趣十足的多智能體系統感興趣，不妨看看 ChatDev，這是一個運行虛擬軟件公司的智能體集合的開源實現。你可以查看他們的 GitHub repo，也許克隆 repo 并親自運行系統。雖然它可能不總是產生你想要的結果，但你可能會對它的表現感到驚訝。

就像規劃這一設計模式一樣，我發現多智能體協作的輸出質量很難預測，特別是當允許智能體自由交互并為它們提供多種工具時。更成熟的反思和工具使用模式更為可靠。希望你能享受這些智能體設計模式的樂趣，并且它們能為你帶來驚人的結果！如果你有興趣了解更多，可以閱讀以下文章：