李鳴野 王若冰

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

0 引 言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

FE=

(1)

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

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

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

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

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

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

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

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

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

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

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

SCF=

(2)

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

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

UCF=

(3)

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

MA=

(4)

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

FE′=

(5)

式中：Base表示移動(dòng)智能體MA運(yùn)行所依賴的基類，當(dāng)對研討工具進(jìn)行升級(jí)或擴(kuò)展時(shí)Base無需隨之改動(dòng)。而研討進(jìn)行時(shí)的客戶端則可形式化表示為：

(6)

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

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

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

FIPA組織對智能體之間的通信模型進(jìn)行了規(guī)定，其中包括FIPA ACL、內(nèi)容語言(content language)和本體(ontology)等內(nèi)容[12]。FIPA ACL是FIPA提出的一種標(biāo)準(zhǔn)化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é)作需要建立在共同的知識(shí)體系之上，否則智能體將誤解或是無法理解對方的意圖[13]。為了實(shí)現(xiàn)智能體間知識(shí)的共享，本文利用了FIPA標(biāo)準(zhǔn)中的本體。在FIPA ACL消息中，通常內(nèi)容是與本體相關(guān)的，本體決定了智能體如何理解消息的內(nèi)容。

圖4為協(xié)同研討場景的本體結(jié)構(gòu)示意圖，其中的每個(gè)矩形框代表一個(gè)本體概念。協(xié)同研討場景的本體結(jié)構(gòu)主要有三個(gè)分支，分別是研討參與者(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)，以實(shí)現(xiàn)工具的協(xié)同。在研討的進(jìn)行過程中，工具UI智能體監(jiān)聽用戶對研討工具的操作。當(dāng)其編輯內(nèi)容發(fā)生變更時(shí)，將該變更以DataSyncNotification本體概念類進(jìn)行封裝并發(fā)送給工具智能體；當(dāng)工具界面窗口的尺寸、位置發(fā)生變更時(shí)，將該變更以ToolUIStatus本體概念類進(jìn)行封裝并發(fā)送給工具智能體。以編輯內(nèi)容發(fā)生變更為例，得到基于ACL通信的工具協(xié)同化過程如下：

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

2) 當(dāng)用戶A在此工具中進(jìn)行修改操作時(shí)，用戶A的工具UI智能體向工具智能體發(fā)送一個(gè)內(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é)合各智能體進(jìn)行響應(yīng)的時(shí)序關(guān)系，得到上述工具協(xié)同化過程的順序圖如圖5所示。

3 原型系統(tǒng)

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

圖6 遠(yuǎn)程智能體管理界面

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

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

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

4 結(jié) 語

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