基于多智能體的協同研討關鍵技術研究

李鳴野 王若冰

(中國航天系統科學與工程研究院 北京 100048)

0 引 言

本世紀初，操龍兵和戴汝為提出將具有自主與反應能力、分布計算與移動計算能力的智能體作為綜合集成研討廳的技術基礎，研究表明基于智能體的分布式系統的設計模式相比通常的C/S模式以及B/S模式具有靈活、響應快、對網絡性能需求較低等特點[1]，但其對于如何實現實時、同步的專家協同研討并未作出詳細論述。在綜合集成研討廳中，專家協同研討是專家交流觀點、協同工作、共享資源并最終涌現群體智慧的重要環節，這就需要研討廳軟件集成多種支持協同工作的研討工具，如文檔協同工具、協同建模工具、協同仿真工具等，即研討廳軟件本身也是一個CSCW系統。

國內外學者和研究機構從不同的角度對基于多智能體的CSCW系統進行了研究。Barthes等[2]設計的ONTOCODESIGN平臺采用本體管理智能體以及個人助手智能體來輔助人們進行協同設計系統的本體構建工作。Talib等[3]將多智能體用于實現遠程教育系統的管理、調度、分布化與考試評分。Kaeri等[4]提出RAC并將其用作遠程會議系統中終端設備程序與智能體的中介，而RAC本身也屬于智能體。Jones等[5]設計的TATIN-PIC是一個用于協同設計的軟件系統，其使用多智能體來解決多種終端設備間的通信、軟件的可擴展性、智能化的個人助手等問題。張永建等[6]將多智能體用于飛機協同設計系統的協同通信，其遵循的是FIPA所提的通信模型,并采用Gateway Agent對Web服務和多智能體平臺進行銜接。王凱等[7]提出的雙總線架構協同設計系統采用B/S模式實現異步功能，并采用C/S模式及智能體實現實時同步功能。結合本文的應用場景，文獻[2-5]中的方式需要在客戶端集成全部的功能，存在靈活性、擴展性不足的問題，而文獻[6]中采用的Web方式難以開發出較復雜的建模工具或仿真工具，文獻[7]一定程度上避免了上述問題，但仍舊需要定期更新客戶端軟件。

針對專家研討在多協同研討工具的集成、擴展及個性化用戶界面方面的需求，本文考慮利用移動智能體技術來設計一個靈活、易擴展、自適應的協同研討客戶端。移動智能體實質是一個代碼、數據和程序運行狀態的集合，具有可移動、自主決策、自適應、異步執行等特性，被廣泛應用于信息檢索、電子商務、分布式數據挖掘等領域[8]。目前已有許多利用移動智能體提升系統靈活性、自適應性和可擴展性的相關研究，比如Chen等[9]設計的ABRTTDMS利用移動智能體來提升分布式交通流量監測與管理系統的靈活性和自適應性。Aversa等[10]在云計算框架中利用移動智能體來動態添加和配置虛擬服務器集群的服務。

在對多智能體技術以及CSCW系統進行研究的基礎上，本文設計了一套協同研討系統的多智能體架構，提出一種基于移動智能體的協同研討場景自適應構建技術，在此基礎上通過智能體間的通信來實現研討工具的協同化。最后使用JADE框架作為智能體開發手段，搭建了協同研討的原型系統，并以模擬的協同研討場景進行了實例驗證。

1 多智能體架構

在協同研討系統中，對于每個研討主題需要為用戶提供一個協同研討場景，場景中包含基本的研討功能和各種協同研討工具。本文將協同研討系統中的每個用戶化身、場景和工具設計為智能體。

圖1為協同研討系統的多智能體基本架構示意圖。在服務端，研討場景智能體控制整個協同研討場景的構建和運行，而工具智能體控制工具UI智能體的創建和協同；在客戶端，研討場景UI智能體和工具UI智能體為移動智能體，負責界面的繪制、交互。ACL(agent communication language)是一種用于支持多個智能體之間協商、合作和消息傳遞等活動的高級語言，此架構中服務端的智能體通過ACL與客戶端的智能體進行通信，而同在服務端或客戶端的智能體之間則以接口調用的方式進行通信。

圖1 協同研討系統的多智能體基本架構

本文定義了11種智能體行為，各類智能體與這些行為的主要關系如圖2所示。各智能體通過添加并執行各種行為的方式來完成各種任務，比如圖1中研討場景UI智能體和工具UI智能體的“創建并移動”過程在圖2中的RegisterParticipant和ProjectToClient行為中完成，而圖1中智能體間的“ACL通信”過程則在圖2中的NotifyDeparting、ServeIncomingMsg、AttendScene、RegisterParticipant等行為中完成。

圖2 智能體與行為間主要關系圖

各種智能體行為的具體描述如下：

1) 研討場景智能體初始化行為Initialize。在一個研討場景被創建時，根據研討所需的工具集合多次調用RegisterTool行為。

2) 用戶離開通知行為NotifyDeparting。當某用戶離開研討場景時，研討場景智能體通知其他用戶客戶端的研討場景UI智能體。

3) 注冊參與者行為RegisterParticipant。當用戶注冊到某研討場景時，分別將研討場景UI智能體和工具UI智能體創建并移動到客戶端容器，并將新用戶加入的消息通知其他客戶端的研討場景UI智能體。

4) 研討場景注冊工具行為RegisterTool。創建某個工具的工具智能體并組裝到研討場景智能體。

5) 通知數據同步行為NotifyDataSync。工具智能體和工具UI智能體通知對方進行界面中數據的同步。

6) 通知界面狀態行為NotifyUIStatus。工具智能體和工具UI智能體通知對方進行界面窗口的狀態更新。

7) 向客戶端投影行為ProjectToClient。工具智能體為某個客戶端創建一個工具UI智能體，并將其移動到客戶端容器中，以實現工具智能體向客戶端的投影。

8) 用戶加入場景行為AttendScene。用戶化身智能體向研討場景智能體發出加入該場景的請求。

9) 用戶離開場景行為DepartingScene。用戶化身智能體向研討場景智能體發出離開該場景的請求。

10) 搜索研討場景行為SearchScene。用戶化身智能體通過JADE框架提供的目錄服務搜索某個研討場景智能體。

11) 處理消息行為ServeIncomingMsg。研討場景智能體、研討場景UI智能體、工具智能體以及工具UI智能體均具有此種行為，各智能體根據消息內容的不同有著不同的處理方式。

2 關鍵技術

2.1 基于移動智能體的協同研討場景自適應構建技術

由于研討問題的復雜、開放和跨領域等特性，在協同研討場景中，除提供研討主持、深度研討、意見共識、群體決策、電子白板等基本研討交互工具外，需要為專家提供不同領域的協同建模、協同分析、協同設計、協同編輯、協同仿真等多種協同研討工具，研討場景的界面需要隨研討主題、用戶信息的不同而變化，而且隨著研討平臺的應用領域和業務的擴展，將不斷有新的協同研討工具加入研討場景，這就要求協同研討場景和工具具有自適應能力。B/S模式難以滿足較為復雜的協同建模工具和協同仿真工具在前端的需求，而若采用傳統的C/S模式，需要在客戶端集成全部的協同研討工具，客戶端程序FE可形式化表示為：

FE=

(1)

式中:T表示全體協同研討工具的集合，Scene表示研討場景UI智能體，Avatar表示用戶化身智能體，MAE表示智能體運行環境。可見這樣一來客戶端不但體積龐大，而且當工具集合T一旦發生變化時，整個客戶端FE都需要隨之進行更新，客戶端存在著靈活性、可擴展性不足的問題。

本文提出一種基于移動智能體的協同研討場景自適應構建技術，客戶端軟件中內嵌智能體運行環境，研討場景UI智能體和各工具UI智能體可以在研討開始后再移動到客戶端上運行，避免了上述傳統C/S模式和B/S模式各自的缺點[11]。基于移動智能體的協同研討場景自適應構建流程如圖3所示，其具體過程為:

1) 某次專家協同研討開始時，根據研討主題創建一個研討場景智能體。

2) 研討場景智能體被創建后根據研討所需的工具將各種工具智能體創建并組裝到到研討場景智能體中。

3) 用戶在客戶端要求進入一個研討場景時，研討客戶端創建一個用戶化身智能體，向相應的研討場景智能體發出請求。

4) 研討場景智能體處理用戶的請求，驗證通過后研討場景智能體根據研討主題信息和用戶信息一方面為該用戶創建專屬的研討場景UI智能體，移動到請求用戶的客戶端智能體運行容器中。另一方面則通知研討場景中已創建的相關工具智能體，各工具智能體分別為該用戶創建各自的工具UI智能體，將這些工具UI智能體移動到該用戶的客戶端智能體運行容器中。

5) 研討場景UI智能體到達后，檢查是否有工具UI智能體已經到達，將已到達的工具UI智能體組裝到研討場景UI智能體。

6) 各工具UI智能體到達客戶端容器后，若研討場景UI智能體已經到達，則將這些工具UI智能體組裝到研討場景UI智能體。若研討場景UI智能體還未到達，則進行等待。

7) 到達客戶端容器后，研討場景UI智能體首先在研討客戶端顯示設備的指定區域上，繪制研討背景及其基本操作界面，然后按照工具UI智能體的疊放次序，依次通知各工具UI智能體在指定坐標繪制其顯示界面。

圖3 協同研討場景自適應構建過程

上述協同研討場景構建過程的自適應性主要體現在兩點：研討主題自適應和用戶自適應。某個研討主題s的主題界面配置文件SCF可形式化表示為：

SCF=

(2)

式中：MC表示菜單配置信息，LC表示界面布局配置信息，TC表示工具配置信息。根據TC可知研討主題s所需的研討工具集合，表示為Ts，有Ts?T，對應的工具UI智能體集合可表示為TAs。

某個用戶u的用戶界面配置文件UCF可形式化表示為：

UCF=

(3)

式中：SC表示界面風格配置信息，DI表示設備信息。研討場景智能體由SCF和UCF創建研討場景UI智能體Scenes，則研討主題s下需要移動的智能體集合MA可形式化表示為：

MA=

(4)

這樣客戶端程序就可形式化表示為：

FE′=

(5)

式中：Base表示移動智能體MA運行所依賴的基類，當對研討工具進行升級或擴展時Base無需隨之改動。而研討進行時的客戶端則可形式化表示為：

(6)

相比式(1)中的客戶端FE，本文所采用的方法根據研討主題信息和用戶信息由服務器向客戶端移動相應的研討場景UI智能體和工具UI智能體，無需在客戶端集成全部的功能，實現了對于研討主題和用戶的自適應。

2.2 基于ACL通信的工具協同化技術

ACL指用于為多個智能體間的協商、合作和消息傳遞提供支持的高級通信語言，工具協同化指讓處于不同地點的多位專家可以使用研討工具對同一份文檔或文件進行同步的編輯操作，本文采用智能體間通過ACL消息交互的方式來實現研討工具的協同化。

FIPA組織對智能體之間的通信模型進行了規定，其中包括FIPA ACL、內容語言(content language)和本體(ontology)等內容[12]。FIPA ACL是FIPA提出的一種標準化ACL語言，一條FIPA ACL消息通常包含performative、sender、receiver、language、content、ontology等參數，其中的language參數用于規定內容語言而不是通信語言。本文的智能體通信語言均采用FIPA ACL，而FIPA ACL的內容語言則采用FIPA SL。

在多智能體系統中，智能體之間的協商與協作需要建立在共同的知識體系之上，否則智能體將誤解或是無法理解對方的意圖[13]。為了實現智能體間知識的共享，本文利用了FIPA標準中的本體。在FIPA ACL消息中，通常內容是與本體相關的，本體決定了智能體如何理解消息的內容。

圖4為協同研討場景的本體結構示意圖，其中的每個矩形框代表一個本體概念。協同研討場景的本體結構主要有三個分支，分別是研討參與者(participant)、數據同步(dataSync)和工具(tool)。研討參與者的本體中包括了出席場景(Attendance)、離開場景(Departing)和參與者信息(ParticipantInfo)三種概念。數據同步的本體中包含數據同步通知(DataSyncNotification)一種概念。工具的本體中包含工具注冊(ToolRegister)、工具注銷(ToolDeregister)、工具UI投影(ToolUIProject)、工具UI邊界(ToolUIBound)和工具UI狀態(ToolUIStatus)五種概念。這些本體中的概念確定了接收到ACL消息的智能體應該以何數據執行何種任務。

圖4 協同研討場景的本體結構示意圖

本文通過ACL通信來同步各客戶端工具UI智能體的數據和狀態，以實現工具的協同。在研討的進行過程中，工具UI智能體監聽用戶對研討工具的操作。當其編輯內容發生變更時，將該變更以DataSyncNotification本體概念類進行封裝并發送給工具智能體；當工具界面窗口的尺寸、位置發生變更時，將該變更以ToolUIStatus本體概念類進行封裝并發送給工具智能體。以編輯內容發生變更為例，得到基于ACL通信的工具協同化過程如下：

1) 假設有用戶A、B和C，對于某個研討工具，服務器容器運行有該工具的工具智能體，每個服務端容器運行有該工具的工具UI智能體。

2) 當用戶A在此工具中進行修改操作時，用戶A的工具UI智能體向工具智能體發送一個內容為DataSyncNotification的ACL消息。

3) DataSyncNotification中帶有對象序列化后生成的字符串，用來傳遞用戶做出的修改。

4) 工具智能體接收到ACL消息后首先根據本體SceneOntology判斷此消息內容為DataSyncNotification類型，然后將DataSyncNotification通過ACL消息轉發給用戶B和C的工具UI智能體，最后將其中的字符串payload反序列化成對象并更新到工具智能體自身。

5) 用戶B和C各自的工具UI智能體接收到ACL消息后根據本體SceneOntology判斷消息內容為DataSyncNotification類型，然后將其中的字符串payload反序列化成對象，最后根據這些對象更新界面內容。

結合各智能體進行響應的時序關系，得到上述工具協同化過程的順序圖如圖5所示。

3 原型系統

本文基于Java語言，利用JADE框架開發協同研討所需的各類智能體、各種智能體行為和協同研討場景本體，并使用Swing工具包實現協同研討系統的圖形界面。圖6為JADE框架提供的遠程智能體管理界面，可以看到當前研討場景中有Smith和Bob兩位用戶，他們各自的終端上分別有名為Client#smith和Client#bob的智能體運行容器，而Server和Main-Container這兩個容器則位于服務器上。

圖6 遠程智能體管理界面

用戶Smith和Bob的協同研討界面如圖7和圖8所示，Smith在樣例工具中依次做出直線、矩形和橢圓圖形，同時Bob的樣例工具依次收到這三個圖形的數據同步消息，每收到一個消息時根據消息內容立即更新界面圖像，并且Bob可以點擊查看每一個圖形的類型和創建者，可見實現了研討工具的協同化。

圖7 用戶Smith的協同研討界面

圖8 用戶Bob的協同研討界面

4 結 語

本文針對傳統C/S模式面對自適應研討場景、研討工具擴展和研討工具協同化的不足，設計出協同研討系統的多智能體架構，并提出基于移動智能體的協同研討場景自適應構建技術和基于ACL通信的工具協同化技術。在此基礎上利用JADE框架作為智能體的開發手段，搭建了協同研討場景的原型系統，并以一次模擬的協同研討以及一個樣例工具作為驗證，驗證結果證明了本文所述技術的可行性與有效性。后續工作中，需要將更多的文檔編輯、建模及仿真軟件的代碼改造為面向智能體的形式并集成到研討廳中，使這些軟件成為協同研討工具。