智能體竟能自行組建通信網絡，還能自創協議提升通信效率
機器之心報道
編輯：Panda
Hugging Face 上的模型數量已經超過了 100 萬。但是幾乎每個模型都是孤立的，難以與其它模型溝通。儘管有些研究者甚至娛樂播主試過讓 LLM 互相交流，但所用的方法大都比較簡單。
近日，牛津大學一個研究團隊提出了一個用於 LLM 通信的元協議：Agora，並宣稱可以解決「智能體通信三難困境」，進而構建「世界級的 LLM 智能體網絡」。
智能體通信三難困境
智能體（agent）是指能在環境中自主行動以實現其設計目標的計算機系統。
和人類一樣，爲了實現共同的目標，智能體也需要相互協作。實際上，如此構建的多智能體系統正是當前 AI 領域的一大重要研究方向，比如 OpenAI 就正在網羅多智能體人才。
OpenAI 著名研究科學家 Noam Brown 發帖爲多智能體研究團隊招募機器學習工程師
但是，由於智能體千差萬別（包括架構、功能和約束條件等），要爲它們組成的異構網絡設計通信協議並不容易。牛津大學的這個團隊將這些難題歸因到了三個方面：
該團隊將這些屬性之間的權衡稱爲智能體通信三難困境（Agent Communication Trilemma），如圖 1 所示，具體討論請參閱原論文。
Agora：LLM 的通信協議層
要解決這個智能體通信三難困境，關鍵是要接受這一點：並不存在一種能同時實現最佳效率、可移植性和多功能性的協議。
牛津大學的這個團隊提出的 Agora 是一種元協議（meta protocol），其利用了 LLM 的特殊能力來解決這個三難問題，具體來說就是爲不同的場景採用不同的通信方法。
我們知道，最強大的 LLM 具有三大關鍵屬性：
究其核心，Agora 會根據不同的情況使用不同的通信格式。
智能體可以支持廣泛的通信（高通用性），同時也能通過高效的例程處理總請求量中的大部分（高效率）。此外，整個協商和實現工作流程都由 LLM 處理，無需人類干預（高可移植性）。
Agora 功能的核心是協議文檔（PD）這一概念，圖 3 給出了其圖示。
下面將介紹 Agora 原生支持的通信層級，然後會展示一些示例。
Agora 中的通信
Agora 引入了一種機器可讀的方式來傳輸和引用協議，即協議文檔（PD）。PD 就是通信協議的純文本描述。
PD 是獨立的、與實現無關的，並且包含智能體在支持協議方面所需的一切：這就意味着現有協議的大多數描述（如 RFC）也都是合適的 PD。但是 PD 並不依靠某個中央實體來分配標識符，而是通過其哈希值（用於多路複用）進行唯一標識。
在 Agora 中，最常見的通信具有專用的高效例程，而最罕見的通信則使用低效但靈活的 LLM 和自然語言。具體來說：
在處理一個查詢時，到底選擇使用人工編寫的例程、LLM 編寫的例程還是 LLM（或三者中的某種組合），則完全由智能體自行決定。這能爲智能體在處理查詢方面提供最大的靈活性。
這種分層通信支持任意形式的通信（最大通用性），但在實踐中，僅在非常少的情況下會調用 LLM（最大效率）。此外，因爲 LLM 可以自行實現例程（因爲 PD 完全描述了協議的語法和語義），人類程序員只需要提供智能體可以訪問的工具的概述，這意味着人類方面所需的實現工作量很小（最大可移植性）。
也就是說，Agora 通過使用例程來處理常見請求，並在智能體需要協商解決方案或發生錯誤時使用自然語言，從而避開了通信三難困境。
將 Agora 用作一個零層協議
圖 2 表明，使用 Agora 無需在乎具體的實現和技術
智能體本身的實現（例如 LLM）、用於存儲數據的數據庫（例如 VectorDB、SQL、MongoDB 等）、編寫實現的語言（Python、Java 等）以及工具的性質都是抽象的。
同時，PD 可以引用其它協議文檔，並且由於例程可以調用其它例程，因此智能體可以基於先前的協商來解決更復雜的任務。
最後，基於強大的多功能性和可移植性，Agora 可以非常簡單地處理節點的添加或刪除、節點功能的更改或網絡目標的更改。所有這些因素都有助於使 Agora 成爲自然的零層協議，即 LLM 之間高階通信和協作的基礎層。
將 Agora 投入實際應用
爲了演示 Agora 的效果，該團隊在兩個場景中實現了 Agora：
實現細節
在演示中，Agora 的設計遵循三個關鍵原則：最小化、去中心化、完全向後兼容。從實踐角度看，Agora 使用 HTTPS 作爲基礎通信層，並使用 JSON 作爲交換元數據的格式。
演示：檢索天氣數據
該團隊首先演示了包含兩個智能體的情況。他們將這兩個智能體命名爲 Alice 和 Bob。其中 Alice 是一個 Llama-3-405B 驅動的智能體，它管理着一個倫敦導遊服務的預訂程序。Bob 則是一個 GPT-4o 智能體，其可提供給定日期和地點的天氣預報服務。在用戶交互之中，如果用戶預訂的日期預計有雨，則 Alice 會通知用戶。
爲了檢查天氣，Alice 首先會使用自然語言向 Bob 發送請求（A1 階段）：
Bob 則會使用其 Toolformer LLM 查詢自己的數據庫（B1 階段）並用自然語言給出答覆（B2 階段）：
隨着時間的推移，A1 和 B2 階段調用 LLM 的成本會顯著超越其它成本，於是 Alice 和 Bob 決定開發一個協議。
Alice 首先會檢查 Bob 是否已經支持合適的協議，但沒有找到。因此，她決定與 Bob 協商協議。
經過幾輪協商，Alice 和 Bob 就以下協議達成一致：Alice 發送一個包含兩個字段（位置和日期）的 JSON 文檔，然後 Bob 回覆一個包含三個字段的 JSON 文檔，即溫度（以攝氏度爲單位）、降水量（以毫米爲單位）和天氣情況（晴、陰、雨或雪）。
基於此，Alice 在執行查詢時只需指定該協議的哈希。下面給出了一個示例：
Alice 和 Bob 都可獨立決定編寫一個例程來處理自己這邊的通信。
從現在開始，Alice 和 Bob 無需使用 LLM 來傳輸流量數據：現在有一個例程可以自動執行階段 A1、B1 和 B2，從而免除了調用相應 LLM 的成本。
在該演示中，協商協議和實施例程的 API 調用成本爲 0.043 美元，而一次自然語言交換的平均成本爲 0.020 美元。這意味着，只要 Alice 和 Bob 使用商定的協議超過兩次，Agora 就能降低總體成本。
最後，該團隊也指出，整個通信過程都是在無人類干預的情況下進行的。此外，如果 Bob 變得不可用，Alice 可以簡單地將 PD 重新用於一個新節點，即便這個新節點可能使用了不同的 LLM / 數據庫 / 技術堆棧。
演示：100 個智能體構成的網絡
爲了展示 Agora 的擴展能力和涌現行爲，該團隊研究了一個由 100 個 LLM 智能體構成的網絡。
在這個網絡中，其中 85 個是助理智能體，15 個是服務智能體。它們全都有 LLM 支持。
服務智能體可提供各種服務，例如預訂酒店房間、叫出租車、訂餐等。圖 4 左給出了一個用於送餐的子網絡示例。
在工作過程中，服務智能體必須與多個工具和數據庫互動。此外，某些服務智能體還必須與其它服務智能體交互才能完成助理的請求（例如，出租車服務需要使用交通數據智能體來調整行程的預估車費）。
一開始，該團隊使用了圖 2 所示的底層通信層來啓動該網絡並提供哪些 URL 對應哪個節點的信息，同時也人工創建了智能體之間的連接鏈接（例如，出租車服務知道端口 5007 上的是交通服務，但它不知道如何與之通信以及需要什麼信息）。
爲了展示 Agora 的可移植性，該團隊使用了不同的數據庫技術（SQL 和 MongoDB）和不同的 LLM，包括開源和閉源模型（GPT-4o、Llama-3-405B 和 Gemini 1.5 Pro）。
然後，它們生成了 1000 個隨機查詢，其中既有簡單查詢（例如請求今天的天氣），也有更復雜的查詢（例如預訂滑雪勝地的房間、購買電影票、從菜單中訂購每種菜餚等）。
對於每個查詢，助理都會收到一個 JSON 文檔（代表任務數據），並負責完成請求並返回遵循給定模式的解析響應。
查詢按照帕累託分佈在助理之間分配，以模擬某些助理髮送的請求明顯多於其它助理的情況。
每個節點還可以讀取 PD 並將其共享到三個協議數據庫之一。
總體而言，這些設計決策下得到的網絡是一個非常異構的網絡，可以測試 Agora 的極限。
連接建立並且網絡可以發送和接收消息後，該團隊觀察到了幾個值得注意的行爲。
隨着 PD 在智能體之間逐漸共享（參見圖 5b），針對給定任務的適當協議涌現出了去中心化的共識。
舉個例子，在訂餐任務中，一個智能體會通過查詢請求另一個智能體將食物送到某個地址。這個餐廳智能體會向一個送餐服務請求送貨司機，接下來送餐服務又會向交通數據智能體查詢交通是否順暢，看能否完成送貨。除了直接通信觸及的範圍，所有智能體都不知道彼此的角色和所涉及的協議。儘管如此，各種智能體之間的交互仍然創造了一個能應付這所有事情的自動化工作流程。如圖 4 右所示。
該團隊觀察到，如果有適當的激勵（即效率激勵），Agora 中的智能體可以擺脫在大規模通信中常見的更長消息的低效陷阱。
該團隊同樣分析了這個更大網絡的成本，並與使用自然語言完成所有通信的網絡進行了比較。
結果如圖 5a 所示，一開始，Agora 的成本效益僅略優於僅依賴自然語言的網絡；隨着時間的推移，這種差距越來越大，越來越多的 Agora 驅動的節點依賴於 LLM 編寫的例程。
在自然語言網絡中運行 1000 次查詢的 API 查詢總成本爲 36.23 美元，而 Agora 的成本僅有 7.67 美元：也就是說，使用 Agora 執行此演示比使用常規自然語言便宜約五倍。而如果查詢更多，成本差距還會更大。