重新回來聊Agent，前四章的LLM Agent，不論是和數據庫和模型還是和搜索引擎交互，更多還是大模型和人之間的交互。這一章我們來嘮嘮只有大模型智能體的世界！分別介紹斯坦福小鎮和Chatdev兩篇論文。它們的共同特點是使用多個大模型智能體協同完成任務。
多智能相比單一智能體可能有以下的應用場景
- 協同任務完成/創意生成：通過多智能體間的溝通，反思，校驗，完成複雜任務，激發創意的小火花
- 模擬世界：多智能體模擬社會環境，現實應用是遊戲NPC，腦洞再大一點是不是可以用於社會學研究，因果推斷，平行世界模擬？？
生活番：Generative Agents
- Generative Agents: Interactive Simulacra of Human Behavior
- https://github.com/joonspk-research/generative_agents
斯坦福小鎮算是這幾個月來看到的最有意思的大模型應用了，作者設計了虛擬的小鎮環境，並在其中設計衆多不同性格的虛擬智能體，完全基於LLM的生成能力，讓衆多AI們在小鎮中開始了生活，思考和互動。
生活環境和經歷塑造了每一個個體，AI也不例外，所以後面的介紹我們會圍繞以下三個核心組件相關代碼來展開
- 沙盒環境: 描述AI們的生存環境，並讓AI感知當前所處環境，並隨AI行動更新環境狀態
- 智能體框架
- 行爲規劃：智能體每一步行爲的生成
- 記憶流: 智能體歷史記憶的存儲
在以上組件的加持下，小鎮中的智能體們會發生以下基礎行爲
- 智能體行爲：智能體根據當前狀態和歷史經歷，決定下一步是喫飯睡覺還是打豆豆
- 智能體互動：智能體間的互動通過交流或指令進行，當智能體處於同一環境中時可能會觸發交流對話
- 智能體和環境交互：智能體行爲會改變環境狀態，例如智能體睡覺時，環境中牀的狀態就會變成“Occupied”。當然我們也可以直接修改環境狀態
- 智能體規劃：想要觸發以上1和2的行爲和互動，智能體肯定不能在小鎮裏隨機遊走。論文的實現是讓智能每天都生成一天的Todo List，根據計劃行動，並在行動中不斷更新當日計劃。
- 智能體自我思考：通過對歷史經歷的不斷總結和反思得到更高級層次的自我思考，從而影響日常智能體的行爲
- 其他衍生能力：信息在智能體之間傳播，多智能體合作，etc
沙盒環境
這裏我們把沙盒環境放到第一個部分，因爲個人感覺如何定義環境，決定了
- Perceive：智能體能接收到哪些環境信息
- Action：智能體可以做出哪些行爲，包括在當前位置行爲，和位置移動
- Influence: 行爲可以對環境產生哪些影響
- 地圖(maze.py)
環境本身被抽象成一個二維矩陣，這類二維遊戲地圖也叫瓦片地圖(Tiled Map）。地圖上每一個瓦片，都是一個字典存儲了該瓦片內的所有信息，以下信息中的events字段都是智能體可以感知，並影響的環境信息。
self.tiles[9][58] = {'world': 'double studio',
'sector': 'double studio', 'arena': 'bedroom 2',
'game_object': 'bed',
'spawning_location': 'bedroom-2-a',
'collision': False,
'events': {('double studio:double studio:bedroom 2:bed', None, None)}}
同時Maze還存儲了一份倒排索引，也就是給定當前智能體當前的地址，需要返回在地圖中對應的二維座標，這樣就可以規劃智能體從當前位置到某個地點的行動路徑。
self.address_tiles['<spawn_loc>bedroom-2-a'] == {(58, 9)}
- 環境感知(perceive.py)
有了環境，再說下智能體如何感知環境。給定智能體當前在地圖中的位置，智能體可以感知周圍設定範圍內所有瓦片中最新的事件。如果周圍發生的事件太多，會先按照和智能體之間的距離排序，選擇最近的N個。同時對於智能體之前未感知的事件，會加入到智能體的記憶流中。
記憶流
記憶流的設計算是論文的一大核心，分成以下兩個部分
- 記憶提取：其一是傳統的RAG，也就是智能體的每一步行爲都需要依賴智能體的歷史記憶，如何抽取相關記憶是核心
- 記憶存儲：其二是智能體的記憶除了感知的環境，還包含哪些信息？
記憶提取(retrieve.py)
話接上面的環境感知部分，智能體感知到了周邊的環境是第一步，第二步就是用感知到的信息，去召回智能體相關的歷史記憶。這裏被召回的記憶，除了之前感知的環境和事件，還有思考記憶，思考後面會講到。召回除了使用embedding相似度召回之外， 記憶召回加入了另外兩個打分維度時效性和重要性。
其中時效性打分是一個指數時間衰減模塊，給久遠的記憶降權，哈哈時效性打分是個寶，在很多場景下都是相似度的好伴侶，實際應用場景中RAG真的不止是一個Embedding模型就夠用的。
重要性打分是基於大模型對每個記憶的重要程度進行打分。打分指令如下
最後在召回打分時，相似度，時效性，重要性進行等權加和。
記憶存儲 (reflect.py)
智能體記憶流中存儲的除了感知到的環境之外，論文還增加了一類很有趣的思考記憶。哈哈不由讓我想起了工作中聽到的一個梗"老闆說不能只幹活，你要多思考！！"
觸發機制也很有insight，就是每個智能體會有一個重要性Counter，當近期智能體新觀察到的各類事件的重要性打分之和超過某個閾值，就觸發思考任務。哈哈今天你思考了麼？沒有的話來學習下智能是如何思考的，對打工人很有啓發喲
- 第一步定位問題？？論文取了智能體近100條的記憶，通過指令讓模型從中提N個問題。指令如下
Given only the information above, what are !<INPUT 1>! most salient high-level questions we can answer about the subjects grounded in the statements?
1)
- 第二步反思問題？？針對以上N個問題進行相關記憶的抽取，然後基於抽取記憶進行思考。這裏允許召回的記憶本身是之前生成的思考，也就是基於思考再思考，基於反思再反思。從這裏我真的看好智能體成爲天選打工人......
What !<INPUT 1>! high-level insights can you infer from the above statements? (example format: insight (because of 1, 5, 3))
1.
最後生成的思考會存儲入記憶流中，用於之後的行爲規劃或者再進一步的思考。
行爲和規劃
最後一個模塊是行爲規劃（plan.py），也是最主要的模塊，決定了智能體在每一個時間點要做什麼，也是之智能體記憶流中的第三種記憶類型。
除了基於當前狀態去生成下一步行爲之外，論文比較有意思的是先規劃了智能體每一天的待辦事項，然後在執行事項的過程中，進行隨機應變。從而保證了智能體在更長時間軸上連續行爲的連貫性，一致性，和邏輯關聯。
長期規劃：每日待辦
智能體每日待辦事項是通過自上而下的多步拆解，使用大模型指令生成的(plan.py)
第一步，冷啓動，根據任務特點，生成智能體的作息時間，如下
第二步，生成小時級別的事項規劃。這裏並非一次生成所有事項，而是每次只基於智能體的所有靜態描述，包括以上生成的生活作息，個人特點等等（下圖），和上一個生成事項，來規劃下一個事項。模型指令是1-shot，輸出事項和事項持續的事件
第三步，是把小時級的事項規劃進行事項拆解，拆分成5-分鐘級別的待辦事項。模型指令同樣是1-shot，模板給出一個小時級別任務的拆分方式，讓模型去依次對每個小時的事項進行拆解，模型指令中1-shot的部分格式如下：
Today is Saturday May 10. From 08:00am ~09:00am, Kelly is planning on having breakfast, from 09:00am ~ 12:00pm, Kelly is planning on working on the next day's kindergarten lesson plan, and from 12:00 ~ 13pm, Kelly is planning on taking a break.
In 5 min increments, list the subtasks Kelly does when Kelly is working on the next day's kindergarten lesson plan from 09:00am ~ 12:00pm (total duration in minutes: 180):
1) Kelly is reviewing the kindergarten curriculum standards. (duration in minutes: 15, minutes left: 165)
2) Kelly is brainstorming ideas for the lesson. (duration in minutes: 30, minutes left: 135)
3) Kelly is creating the lesson plan. (duration in minutes: 30, minutes left: 105)
4) Kelly is creating materials for the lesson. (duration in minutes: 30, minutes left: 75)
5) Kelly is taking a break. (duration in minutes: 15, minutes left: 60)
6) Kelly is reviewing the lesson plan. (duration in minutes: 30, minutes left: 30)
7) Kelly is making final changes to the lesson plan. (duration in minutes: 15, minutes left: 15)
8) Kelly is printing the lesson plan. (duration in minutes: 10, minutes left: 5)
9) Kelly is putting the lesson plan in her bag. (duration in minutes: 5, minutes left: 0)
最終分鐘級別的待辦事項會作爲智能體當日的主線行爲，寫入以上的記憶流中，在之後的每一次行爲規劃中，提醒智能體，當前時間要乾點啥。
短期規劃：隨機應變
以當日長期行爲規劃爲基礎，智能體在按計劃完成當日事項的過程中，會不時的感知周圍環境。當出現新的觀測事件時，智能體需要判斷是否需要觸發臨時行爲，並調整計劃。這裏主要分成兩種臨時行爲：交流和行動。這兩種行爲的觸發會基於智能體當前的狀態，和大模型基於上文的指令輸出，例如對於是否產生對話行爲的判斷
當智能體A，出現在當前智能體可以感知的環境範圍內時，通過以上的環境感知模塊，智能體的記憶流中會出現智能體A的當前行爲。這時智能體會在記憶流中檢索和智能體A相關的記憶，合併當前狀態作爲上文，使用大模型指令判斷是否要發起和A的對話
如果判斷需要發起對話，則觸發對話模塊進行交流，而交流是所有社會性行爲產生的根本。
效果
主要模塊基本就說這麼多，技術評估就不多說了，在智能體行爲上論文驗證了當前框架會產生一定的社會效應，包括信息會在智能體之間傳播，智能體之間會形成新的關係，以及智能體間會合作完成任務等等。
論文也討論了當前框架的一些不足，包括如何在更長時間週期上泛化，如何避免智能體犯一些低級錯誤，例如躺上有人的牀哈哈哈哈~
個人感覺還需要討論的是如何在當前的記憶流中衍生成更高級的，抽象的思考，以及對世界的認知。這些認知是否有更高效，結構化的存儲和召回方式。只依賴反思和記憶流的線性存儲可能是不夠的。
職場番：ChatDev
- Communicative Agents for Software Development
- https://github.com/OpenBMB/ChatDev
哈哈如果說斯坦福小鎮對標綜藝桃花塢，那ChatDev就是對標令人心動的Offer。論文參考了斯坦福小鎮的記憶流，CAMEL的任務導向型對話方案，通過智能體間對話協同完成特定軟件開發任務。
論文把軟件開發流程，抽象成多個智能體的對話型任務。整個開發流程分成設計，編程，測試，文檔編寫四個大環節，每個環節又可以拆分成多個執行步驟，其中每個步驟都由兩個角色的智能體通過對話合作來完成，如下
在進入主要流程前，讓我們先完成準備工作。開發流程的準備工作需要定義三類配置文件，源碼提供了默認的配置文件，用戶可以根據自己的需求，選擇覆蓋部分配置。配置文件從Top to Bottom分別是
- ChatChainConfig：定義了整個任務鏈的所有步驟和執行順序(phrase)，以及所有參與的智能體角色。
以默認配置爲例，任務鏈包含以下步驟：DemandAnalysis -> LanguageChoose -> Coding -> CodeCompleteAll -> CodeReview -> Test -> EnvironmentDoc -> Manual
參與智能體角色包括：CEO，CFO， CPO， CCO， CTO， programmer，Reviewer，Tester等
-
PhaseConfig：下鑽到每個步驟，分別定義了每個步驟的prompt指令，以及參與的兩個Agent角色。
-
RoleConfig：下鑽到每個角色，分別定義了每個角色的prompt指令
初始化配置文件後我們進入軟件開發的四個主要流程~
Design
產品設計環節，負責把用戶需求轉化成項目方案，包括兩個原子步驟：CEO和CPO進行需求分析和產品設計，CEO和CTO選擇編程語言。考慮每個phase的實現其實是相似的，只不過參與智能體不同，以及phase對應的指令和多輪對話形式不同，這裏我們只說CEO和CPO之間關於需求分析對話實現（role_play.py）～
這裏融合了CAMEL的Inception Prompting和斯坦福小鎮的記憶流和自我反思來完成任務導向的對話。
- Role Assignment
首先初始化參與phase的兩個智能體角色，並生成初始prompt(Inception Prompt)。包括用戶需求(task_prompt)，本階段的任務描述（phase_prompt）和兩個智能體的角色描述(role_prompt)。
基於初始指令，之後兩個智能體會通過對話相互爲對方生成指令，而人工參與的部分只有最初的角色描述和任務描述，所以叫初始指令。產品涉及環節的具體指令如下，需求分析階段的任務指令使用了few-shot，給出不同的產品形態例如圖片，文檔，應用等實現方式，並明確了對話的兩個智能體的討論主題，以及終止討論的條件，即確定產品形態
以下是論文附錄給出的一個需求分析階段的具體對話示例，不過對話終止符似乎變成了<END>
- Memory Stream
老實說感覺這裏的memoery stream和上面小鎮中實現的memory stream關聯似乎並不是很大。看代碼實現，對話是直接使用上文對話history作爲輸入，只有當輸入上文長度超長的時候，會保留Inception prompt和最近的N輪對話......難道是我漏看了代碼，如果是請評論指出 >.<
- Self-Reflection
小鎮中自我反思是爲了產生更抽象，更高級的個人思考。而在這篇論文self-Reflection其實更像是會議總結模塊，當多輪對話完成，但是並未出現對話停止<END>符號，這時可以觸發總結模塊，把前面的多輪對話作爲上文，來總結對話得到的結論，用於後續步驟的進行，如下
Coding
編程環節包括兩個基本步驟：後端寫代碼，和前端設計交互界面。編程環節最大的難點就是如何避免模型幻覺，最大正度保證代碼的正確性，以及在多輪對話中如何進行復雜長代碼的編寫和修改。這裏同樣我們只說下後端編寫代碼這一個步驟。
代碼編寫步驟的核心指令如下，CTO智能體給程序員智能體的指令是：以面向對象的編程語言python爲基礎，先給出核心類和方法。程序員智能體會按照指令以markdown爲語法進行代碼和註釋的編寫。之後代碼編寫環節會循環執行N次多輪對話，不斷對代碼進行更新優化。
在指令的基礎上，爲了優化複雜代碼的編寫效果，論文在代碼編寫環節引入了version control環節。在每一步代碼編寫完成後，會使用difflib對兩版代碼進行比對，並從記憶流中刪除舊版本的代碼，這樣對話會永遠基於最新的代碼版本進行，對最新代碼進行不斷更新。
Testing
測試環節包括兩個基本步驟：代碼評審和測試環節。
評審環節，程序員智能體會給評審智能體指令，讓其對代碼進行檢查，例如是否有未實現的類或方法，以及整個項目是否符合用戶需求等等(角色指令如下圖），並給出評審建議。其次程序員之智能體會基於以上建議對代碼進行調整。
測試環節是基於代碼執行後出現的bug進行修復。論文在這裏引入了Thought Instruction，有點類似Decomposed Prompt的任務拆分。因爲如果直接基於代碼執行bug讓大模型進行修復，問題可能過於複雜導致模型無法直接修復，或者產生幻覺。因此通過多輪對話引入一步任務拆分，先經過TestErrorSummary步驟對測試bug的位置和產生原因進行總結，再基於以上總結進行代碼調整。
Documentation
文檔生成環節就比較簡單了，包括多個phase步驟，一個phase對應一類文檔說明。這裏使用了few-shot指令來引導智能體生成requirements.txt, README.MD等用戶文檔，以下是生成requirements.txt的指令示例
效果
效果上ChatDev從CAMEL編程相關的任務中隨機抽了70個任務進行測試，任務平均代碼量是131行代碼，4個文件，3個上游依賴庫，說明ChatDev整體生成的軟件還是偏簡單，小型，不涉及複雜的設計。具體效果大家可以直接去Chatdev的代碼庫裏給的生成案例感受下。在這樣的代碼複雜度下，ChatDev最終代碼的執行成功率在86% ，平均任務完成時間在7分鐘左右，且調用成本相對較低。
除了以上提到了兩個比較火爆的多智能體協同應用，還有很多相關應用和開源實現，這裏就不一一介紹了，感興趣的同學可以去自己試試看
- AgentSims：國內開源的類似斯坦福小鎮
- AgentVerse：多模型交互環境
- MetaGPT:覆蓋軟件公司全生命流程，例如產品經理等各個職業的AutoGPT
- CAMEL：任務導向型，溝通式多智能體協同框架，Chatdev的基礎
想看更全的大模型相關論文梳理·微調及預訓練數據和框架·AIGC應用，移步Github >> DecryPrompt