最近，「多智能體系統」是人工智能領域最熱門的流行詞之一，也是開源框架 MetaGPT 、 Autogen 等研究的焦點。

但是，多智能體系統就一定是完美的嗎

近日，來自卡內基梅隆大學的副教授 Graham Neubig 在文章《Don't Sleep on Single-agent Systems》中強調了單智能體系統也不可忽視。

Graham Neubig 從以下幾個方面展開：

• 當代 AI 智能體發展的元素，包括大語言模型、提示以及動作空間；
• 多智能體系統示例；
• 多智能體系統存在的問題；
• 如何從使用多個專門的智能體過渡到一個強大的智能體，以及一些需要解決的問題。

CMU 機器學習和計算機系助理教授陳天奇對這項研究進行了轉發并評論：「這是一篇關于如何讓單智能體系統更強大的深刻見解，對機器學習系統也有很好的啟示。提示前綴緩存將成為與其他一般推理優化技術相互作用的一項關鍵技術」。

基于 LLM 的智能體

大多數智能體都是基于大語言模型構建的，如 Anthropic 的 Claude 或 OpenAI 的語言模型。但語言模型不足以構建一個出色的智能體，構建一個智能體至少需要三個組件：

• 大語言模型 LLM；
• 提示：可以是用于指定模型一般行為的系統提示，或者從智能體周圍環境中提取的信息類型；
• 動作空間：上述兩項是研究者提供給 LLM 的輔助工具，以便智能體在真實世界中產生動作。

一般來說，當涉及多智能體系統時，至少要改變這三個組成部分中的其中一個。

多智能體示例

假設你正在構建一名 AI 軟件開發助手，這里作者以 CodeR 為例，這是一個用于 AI 軟件開發的多智能體框架。它包括多個智能體，所有智能體都使用相同的底層 LM，但提示和動作空間各不相同：

• 管理器（Manager）：該智能體的提示指定它應該為其他智能體編寫一個規劃來執行，以及輸出規劃的動作空間；
• 復現器（reproducer）：該智能體有一個提示，告訴它重現該問題，以及一個將代碼寫入重現錯誤文件 reduce.py 的動作空間；
• 故障定位器（Fault Localizer）：該智能體有一個提示，告訴它找到導致錯誤的文件，以及一個使用軟件工程工具進行故障定位和列出文件以供以后使用的動作空間；
• 編輯器（Editor）：該智能體有一個提示，用于接收復現器和故障定位器的結果，并有一個動作空間，允許它對文件進行編輯；
• 驗證器（Verifier）：此智能體具有提示，可接收其他智能體的結果，以及輸出問題是否已解決的動作空間。

這是構建一個系統時所需要的結構，但是在構建這樣的系統時存在一些困難。

多智能體系統存在的一些問題

在構建多智能體系統時，你可能會遇到許多問題，比如：

獲得正確的結構：多智能體系統通過添加結構來解決問題。當智能體面臨的問題與指定的結構完全匹配時，效果會很好，但問題是如果不匹配怎么辦？

上下文信息的傳遞：多智能體系統通常在多個智能體之間傳遞信息，但這可能是信息丟失的原因。例如，如果故障定位器僅將其摘要信息傳遞給其他智能體，則通常會導致重要的上下文信息丟失，而這些信息可能對下游智能體有用。

可維護性：最后，這些智能體通常都有自己獨立的代碼庫，或者至少有獨立的提示。因此，多智能體系統可能擁有更大、更復雜的代碼庫。

有趣的是，很多這些挑戰也適用于人類組織！我們都有過這樣的經歷：團隊組織混亂，溝通不暢，或者當某個成員離開時，無法維持必要的技能。

如何打造出色的單智能體系統

人們為什么要打造多智能體系統？一個需要說明的重要原因是：專用于特定任務的智能體的表現通常很好，只要有合適的結構和工具，它們就能很好地完成相應的任務。

單智能體有能力競爭嗎？

可能比我們預想的還更容易一些，作者表示這里已經有一個很好的原型：https://github.com/All-Hands-AI/OpenHands/tree/main/agenthub/codeact_agent

下面我們就來看看，要打造出優秀的單 LLM、單動作空間和單提示工程技術，需要些什么。

單 LLM：這是相對比較容易的部分。近段時間已經出現了一些表現出色的通用 LLM，包括 Claude 和 GPT-4o 等閉源模型以及 Llama 和 Qwen 等開源模型。雖說這些模型也不是萬能的，但它們也確實能完成多種多樣的任務。就算它們缺乏某個功能，也可以通過持續訓練來增添，同時不會對其它功能產生太大影響。

單動作空間：這也不難。如果我們有多個使用不同工具的智能體，那么我們可以 (1) 為模型提供相對通用的工具，以幫助它們解決問題；(2) 如果不同的智能體有不同的工具組合，則可以將他們連接起來。比如，在 OpenHands 中，可以向智能體提供寫代碼、運行代碼和執行網絡瀏覽的工具。這樣的通用方法可讓模型使用為人類開發者開發的軟件工具，從而增多它們的功能，做到其它多智能體能做到的事。

單提示工程技術：這是比較困難的地方！我們需要確保智能體在如何解決任務上獲得正確的指示，同時從其環境中獲得正確的信息。

下面給出了兩個選擇：

• 將所有提示詞連接起來使用：如果我們有一個多智能體系統，要使用 10 個不同的提示詞，那么為什么不將它們連接組合到一起呢？近期的長下文模型已經有能力處理多達幾十萬 token 了，比如 Cluade 能處理 20 萬 token，而 Llama 是 12.8 萬。OpenHands 也使用了此方法。但這種方法也有一些缺點。首先是成本，更長的提示詞需要更多金錢和時間，不過現在有一些技術（比如 Anthropic 的提示詞緩存技術）可以降低其成本。這種方法的另一個缺點是，如果提示詞太多，則 LLM 可能無法關注到重點，但隨著模型能力提升，LLM 在確定長上下文中的重要信息方面越來越強了。
• 檢索增強式提示：另一種可能的選擇是使用檢索。如同檢索增強式生成（RAG）系統一樣，可以出于效率或準確度的目的對長上下文進行裁剪。在選擇提供 LLM 的示例方面，這里有一些研究進展：https://arxiv.org/abs/2209.11755

總結

本文并不是說多智能體就沒有用武之地了。比如在一個智能體可以訪問專有信息，而另一個智能體則代表了另一個人的情況下，多智能體系統肯定大有作為！

本文的目的是批判性地思考讓系統更加復雜這一趨勢。有時候簡單就是最好的 —— 有強大的模型、強大的工具和多種多樣的提示詞就足夠了。