基于多智能體的協(xié)同研討關(guān)鍵技術(shù)研究

李鳴野 王若冰

(中國航天系統(tǒng)科學(xué)與工程研究院 北京 100048)

0 引 言

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

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

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

在對多智能體技術(shù)以及CSCW系統(tǒng)進行研究的基礎(chǔ)上，本文設(shè)計了一套協(xié)同研討系統(tǒng)的多智能體架構(gòu)，提出一種基于移動智能體的協(xié)同研討場景自適應(yīng)構(gòu)建技術(shù)，在此基礎(chǔ)上通過智能體間的通信來實現(xiàn)研討工具的協(xié)同化。最后使用JADE框架作為智能體開發(fā)手段，搭建了協(xié)同研討的原型系統(tǒng)，并以模擬的協(xié)同研討場景進行了實例驗證。

1 多智能體架構(gòu)

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

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

圖1 協(xié)同研討系統(tǒng)的多智能體基本架構(gòu)

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

圖2 智能體與行為間主要關(guān)系圖

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

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

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

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

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

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

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

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

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

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

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

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

2 關(guān)鍵技術(shù)

2.1 基于移動智能體的協(xié)同研討場景自適應(yīng)構(gòu)建技術(shù)

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

FE=

(1)

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

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

1) 某次專家協(xié)同研討開始時，根據(jù)研討主題創(chuàng)建一個研討場景智能體。

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

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

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

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

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

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

圖3 協(xié)同研討場景自適應(yīng)構(gòu)建過程

上述協(xié)同研討場景構(gòu)建過程的自適應(yīng)性主要體現(xiàn)在兩點：研討主題自適應(yīng)和用戶自適應(yīng)。某個研討主題s的主題界面配置文件SCF可形式化表示為：

SCF=

(2)

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

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

UCF=

(3)

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

MA=

(4)

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

FE′=

(5)

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

(6)

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

2.2 基于ACL通信的工具協(xié)同化技術(shù)

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

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

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

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

圖4 協(xié)同研討場景的本體結(jié)構(gòu)示意圖

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

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

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

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

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

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

結(jié)合各智能體進行響應(yīng)的時序關(guān)系，得到上述工具協(xié)同化過程的順序圖如圖5所示。

3 原型系統(tǒng)

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

圖6 遠程智能體管理界面

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

圖7 用戶Smith的協(xié)同研討界面

圖8 用戶Bob的協(xié)同研討界面

4 結(jié) 語

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