李鸣野 王若冰

(中国航天系统科学与工程研究院 北京 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框架作为智能体的开发手段，搭建了协同研讨场景的原型系统，并以一次模拟的协同研讨以及一个样例工具作为验证，验证结果证明了本文所述技术的可行性与有效性。后续工作中，需要将更多的文档编辑、建模及仿真软件的代码改造为面向智能体的形式并集成到研讨厅中，使这些软件成为协同研讨工具。