LLM 代理實驗，結合專門構建的 RPG 和工具呼叫。（進行中）

免責宣告：嘗試透過影片捕捉和解釋隨機響應、隨機生成以及獨立客戶端的行為，比我原先想象的要困難得多。我在這裡保留了一些影片片段以打斷文字，但它們可能除了我自己之外對任何人都沒有太多啟示。

引言

大約兩年前，我啟動了 LlamaTale 專案，它是基於現有 MUD / 互動小說框架的一個分支。其想法是嘗試使用 LLM（大型語言模型）建立一個具有程式生成內容（主要開始時是對話）的遊戲，但以真實規則集為基礎。例如，我嘗試過 AIDungeon 和純粹的講故事角色扮演，但發現它們缺乏結構。隨著時間的推移，專案不斷發展，首先是包含完全由使用者提示生成的的世界，然後是自主 NPC，它們可以執行一系列動作。前者執行得相當好，但後者則不然。它們會陷入迴圈，不遵循提示，並嘗試以各種可能的方式破壞我的 JSON 解析。這在 LLM 方面也屬於“遠古時期”，當時 Llama2 微調和 4k 令牌是標準。

快進到最近，我又想再次探索這個概念。但在 LlamaTale 中這樣做並不有趣。它從一開始就有些倉促，沒有明確的計劃。我想從頭開始，構建一個從一開始就為代理設計的系統。

我著手構建一個新遊戲，或者說是一個框架，目前還沒有遊戲，代理可以在本地執行並連線到伺服器。本質上，它是一個 MMO，或者至少是一個多人 RPG，其中代理可以取代所有玩家。至少，這是理論上的。

框架

我從一開始就做出了一些決定

• 代理將作為客戶端執行，而不是在伺服器上。
• 我希望超越單純的對話生成。
• 它們將使用類似於玩家使用的訊息系統，但帶有一定的限制；沒有 WASD 輸入，而是具有具體命令，帶有要移動到的位置或座標，要互動的實體。
• 除了 LLM 的決策之外，還將有一個狀態機，其中包含確定性狀態，這些狀態根據 LLM 的命令啟用和停用。
• 代理沒有視覺效果。它們將收到其周圍環境的文字表示。
• 我將使用工具呼叫作為動作。不再需要繁瑣的 JSON 解析。

關於遊戲本身的一些基本資訊

• 遊戲框架是一個伺服器權威的多人系統。
• 我決定採用 Tab 目標戰鬥系統，因為它對延遲更友好，而且 LLM 的反應速度不佳。
• 伺服器是 Java，使用 Zay-ES ECS（實體元件系統），沒有場景圖。
• 遊戲客戶端執行 jMonkeyEngine3 (Java)。
• 代理執行 Java。
• 伺服器由 SQL 資料庫和倉庫支援。
• 代理有自己的 SQLite 資料庫來儲存記憶。

雖然 LLM 伺服器可以在本地執行，但我選擇使用 Mistral 的 API。它更快，而且由於每個動作主要只有數百個輸入和輸出令牌（除非您不小心將最大數量設定為埠號，導致 LLM 進入重複模式），所以它非常便宜。我嘗試了 Mistral Small，但它無法識別工具呼叫，所以我最終使用了 Medium。它能很好地處理工具呼叫，但不是最有創意的模型。

由於我總是擔心令牌使用量，目前我將主要決策呼叫限制為每 15 秒一次。

感知系統

出於頻寬和複雜性考慮，我不想傳送影像讓 LLM 解釋。取而代之的是，伺服器上有一個系統，收集相關資訊，例如附近有什麼，前面有什麼，位置資訊，狀態等等，並將所有這些作為元件傳送給客戶端。這樣做的好處是適用於多種基礎設施模式。我選擇了功能齊全的網路客戶端，因為我已將所有東西都設定好了。但這也可以透過 REST 提供服務，例如，效果也一樣好。

客戶端從感知狀態（PerceptionState）獲取資料，並用所給的資訊替換基本提示模板。這意味著如果本地執行，使用者可以控制所使用的具體提示，並根據自己的偏好進行調整。

狀態機

為了增加愉悅體驗的機會，我不想讓 LLM 自己做每一個小決定。有一些“經典”AI 狀態可以根據 LLM 想要做的事情開啟和關閉。例如，一旦進入戰鬥，就會有一個戰鬥系統來幫助攻擊和定位。如果它決定跟隨某物，一個“跟隨者”狀態就會接管。一個“旅行”狀態將處理較長行程中的事情。

但與此同時，客戶端會定期與 LLM 核對，並且還有一些反應性狀態會在某些事件發生時提示 LLM。

進展順利之處

它奏效了！這本身就是一場勝利。LLM 代理根據收到的提示做出相關決策。如果它有一個任務，它更有可能選擇一個能推進任務的行動。例如：

訊息：“我注意到附近有一片三葉草，這是我收集草藥任務的一部分。我將把它撿起來以完成我的目標。”行動：函式[名稱=pick_up, 描述=null, 引數原始={"entity": "9"}], 索引=0]]]

具有良好的空間意識。可以根據座標移動得更近，最終停留在物體的正確一側等。

它可以同時正確執行多個工具呼叫。例如，它可以發出移動呼叫和互動呼叫。

可改進之處

它會重複自己，並陷入迴圈。如果某事物顯示在“最近記憶”中，它就會一遍又一遍地做同樣的事情，沒有變化。我在 LlamaTale 中也注意到了這一點，我懷疑它需要一個規劃階段來保持自身的方向。

它也感覺相當枯燥，缺乏個性。這可能是一個提示問題。它需要在提示中加入更深層次的角色描述，並佔更大比例（目前只有幾行）。

它有陷入“助手模式”的傾向。談論這或那可能需要“幫助”。這可能是一個微調問題，但也可能與提示有關。

下一步

這個專案仍處於早期階段。我想在假期結束前完成一些工作，但我會繼續，能力各有不同。我很快就會新增規劃功能。這將首先能夠設定一個在提示中持久存在的目標，然後能夠逐步實現該目標。也許可以使用任務框架。

我想探索使用本地模型。歡迎任何關於具有良好工具呼叫能力的中型模型的建議。