基于请求/服务协作模型的多Agent建模方法

宋昌统，王辉

0 引言

智能通信是人工智能领域中研究的一大热点，在多Agent系统中，不同Agent之间的通信是非常必要的，这是实现协作的重要途径。当有多个Agent同时向同一个服务主体提出服务请求，或者Agent向一个正在为其他Agent服务的服务主体提出请求时，被请求的服务主体就需要寻求其他服务主体的帮助，就需要通信和协作，以同时满足不同Agent的请求。因此，Agent具有自主性，反应性，社会性和推理能力等特点，能够用来解决传统的人工智能所不能解决的环境适应性、动态环境推理和规划、信息不完全等问题，使用Agent方法已经成为研究复杂系统的重要手段。

现实生活中大多数系统是属于多Agent 系统，因此研究多 Agent 系统是一件非常有实际意义的事情。本文在ConGolog中显式定义了通信动作，并提出一个请求/服务协作模型，这样，Agent就可以在动态环境下进行面向目标的自主协作行为规划。同时，在ConGolog中引入并发，解决了单个Agent所不能解决的问题。

1 情景的演算

情景的演算是人工智能大师McCarthy在1963年针对动态领域中的问题求解和逻辑程序设计首次提出的，是一个用一阶谓词逻辑描述世界的方法。情景演算方法可以在动态环境下进行面向目标的自主行为推理。直观上，一个情景就是世界的一个快照，在情景演算中使用情景(situation)类表示，而情景的变化是动作(action)的结果，在本体论中，动作是改变事物状态的基本手段，动作函数 do表示为：action×situation→situation。如果在情景s下实行动作a将得到另一个情景s’，那么情景s’可表示为do(a,s)。更多情景演算的概念和情景演算的公理系统参见文献[2]。

2 Golog与ConGolog

2.1 Golog

2.2 ConGolog

Golog语言是针对单个Agent的，其动作之间在时间上的关系只有顺序，在实际的运用中Golog语言受到很多的限制，例如没有感知只能离线规划，在规划的过程中不能再次接受其他的规划任务，尤其明显的是在多Agent系统的开发过程中遇到的并发动作的处理上。为了解决上述的问题，出现了很多新的情景演算语言[5]，其中较为有影响的是 De Giacomo和Yves Lesperance等人提出了并发程序设计语言ConGolog。ConGolog在Golog的基础上增加了并发处理，优先级的并发以及中断处理。在ConGolog中，初始情景可以不完全指定，而Agent可以根据情景演算的公理自己定义基本动作。

ConGolog被赋予了一种结构化的操作语义，称为计算语义。根据该语义的“单步变迁”的概念[6]，ConGolog引入了两个特殊的谓词 Final(δ,s)和 Trans(δ,s,δ’,s’)。其中 Final(δ,s)表示程序 δ可以合法的终止在情景 s。Trans(δ, s, δ’, s’)表示程序δ在情景s 下执行一步(即执行一个基本动作), 从而将情景s变化到情景s’, 并余下程序δ’未执行。实际上，程序δ和情景s是一个配置空间(configuration)<δ,s ＞，而trans的作用是通过执行一个可执行的基本动作，将这个配置空间改变成另一个配置空间<δ’, s’＞。

使用final和trans谓词的好处不仅在于可以描述Golog语言，更重要的是可以描述并发，带优先级的并发，中断等。在Congolog中并发动作表示为δ1||δ2, δ1和δ2表示两个并发执行的动作，δ1 ＞＞δ2表示δ1和δ2是带有优先级的两个并发动作，其中δ1的优先级高于δ2，当动作δ1执行完或者不能执行时才执行动作δ2。δ||表示多个该动作δ并发执行。Φ→δ表示中断，Φ表示触发条件，δ是中断的处理程序，当触发条件满足时就执行程序δ，否则δ将不会被执行。使用final和trans谓词可以将这四种复杂动作表述为[7]：

(1)并发

(2)优先级并发

(3)多个相同动作并发

可见，多个相同动作的并发是参照了基本的并发动作的语义进行解释的。

(4)中断表示当允许中断时(interrupts_running为真)，如果触发条件满足的话就执行程序δ，否则就为false。

3 请求/服务协作的模型

3.1 模型的简介

在请求/服务协作模型中，Agent被分为两种类型，分别为请求 Agent(ReqAgt)和服务 Agent(SerAgt)。其中，请求Agent可以向任何服务Agent提出服务请求，服务Agent也可以为任何请求Agent服务，多个服务Agent之间通过通信动作[8]以协作的方式，共同为请求 Agent提供服务。请求/服务协作模型，如图1所示：

图1 请求/服务协作模型

在该模型中，当有请求Agent向服务Agent提出请求时，服务Agent首先要判断自己能不能完成该请求，如果可以，则不用请求其他Agent，直接交由规划部分进行规划。如果不能完成，此时服务Agent就通过通信方式，请求其他的服务 Agent来完成。也就是说，此时服务 Agent对请求Agent的请求负有责任，由ServAgt1负责请求另外的一个服务Agent(ServAgt2)完成。ServAgt2接到请求后也会根据自己是否能完成该请求来给 ServAgt1进行回复。ServAgt1接到ServAgt2的回复后，根据回复内容进行操作，如果 ServAgt2不同意，那么 ServAgt1就需要询问另外一个服务Agent(ServAgt3)，直到有服务Agent答应为RequAgti服务，如果其他所有的服务Agent都被询问过了，而且没有收到肯定的答复，那么就告知 RequAgti系统忙；如果ServAgt2同意提供服务，则将请求中的服务对象换成ServAgt2，然后进入规划。就是说，如果ServAgt2同意提供服务，就表示可以让规划部分安排其为RequAgti服务。

例如，在送咖啡的例子中，请求 Agent1(bill)向服务Agent(waiter1)提出请求 wantCoffee(bill,waiter1)，要一杯咖啡，而在waiter1还没有为bill服务完的时候，请求Agent2也向waiter1提出请求wantCoffee(sue,waiter1)。此时，waiter1就需要向其他的服务Agent请求协作，waiter1首先向waiter2提出请求，如果waiter2同意协作，那么就会把自己的名字作为此次通信的结果告知waiter1，waiter1就会将sue的请求waiter1的名字换成waiter2的名字，然后进入规划；如果waiter2在为另一个请求 Agent服务，那么就不同意协作，回答impossible。waiter1在得到impossible的回复后就会请求另外的服务 Agent(waiter3)，直到询问过所有的服务Agent，如果还没有肯定的答复，那么则告知sue，此时系统忙，请稍后再次请求。一个服务Agent对于请求Agent的请求的处理过程，如图2所示：

图2 服务Agent对请求的处理流程

3.2 请求/服务模型的协作实现

请求Agent向服务Agent提出请求时，如果Cond条件满足，那么请为我执行任务 Task。接收者Receiver收到该消息后，对条件进行判断，即 holds(Cond,H)，如果条件成立，那么将通信结果赋值为愿意完成，如果不成立，则赋值为不愿意。代码，如图3所示：

图3 对请求的处理过程

根据通信方式，对于消息的回复，服务Agent只需要将结果赋值给通信结果，不必再进行一次通信。如果发送愿意的消息，那么就表示此次通话的结果是请求得到满足，那么就把同意者的ID赋值给通话的结果，如果不愿意，那么就将另一个结果赋值给通话结果，此处的赋值用户可自定义，本文使用impossible表示不愿意。代码，如图4所示：

图4 根据愿意/不愿意给通话结果赋值

4 实例

为了在 VRML中展现多 Agent的协作行为，本文在VRML虚拟场景中进行了仿真。针对送咖啡的例子，模拟多Agent请求，本实例定义了3个服务Agent，waiter1、waiter2和 waiter3。giveCoffee(Person,Rob)表示主体 Rob把咖啡交给了用户 Person。startGo(Loc1,Loc2,Rob)表示主体 Rob从Loc1走向Loc2，Loc1和Loc2都是地点名称，本文中的地点名称可能是咖啡机 cm，也可能是用户的办公室office(Person)。 下面是Agent之间的协作流程。

(1)流

流的初始值的定义可以使用initially(Fluent,Value)来定义，is_busy(Rob)表示服务Agent忙，needServe(Person,Rob)则表示Person需要Rob为其服务，hasCoffee(Person)表示用户Person此时已经有了咖啡。

(2)外部动作

Exog_action(wantCoffee(person,Rob)):-isPerson(Person),isRob(R ob).其中isPerson(Person),isRob(Rob)是对用户的输入做检查。wantCoffee(bill,waiter1)是合法的外部动作，表示bill请求waiter1为其倒一杯咖啡。

(3) 多Agent交互部分

首先对Agent的请求进行检查exog_action_check/3，看Agent请求的服务Agent(Rob)在当前情景下是否有空，没空的话，那么被请求的 Agent就开始同其他的服务 Agent进行交互，请求他们为该 Agent服务，isRob(Rob2),+(Rob2=Rob1)就表示Rob2是另外的一个服务Agent，请求的消息为 inform(Rob1,Rob2, request(is_busy(Rob2)=off,H,serve_for(Person)),R_Result)，表示Rob1，即被用户Person请求但目前忙的服务Agent，向Rob2发送消息，内容为请求Rob2，如果在当前情景下 Rob2不忙，那么请为Person服务，请求的结果存储在变量 R_Result中，如果该变量值不是一个服务 Agent的 ID，那么重新选择一个服务 Agent再次开始请求，如果是，那么就显示成功，将Rob2为Person服务的事情放入动作规划中。

5 结束语

本文基于情景演算理论，在Golog的基础上增加了多Agent的协作，形成ConGolog语言.同时结合中断操作和并发优先，提出一个请求/服务协作模型.为多Agent在响应服务请求时提供了模型支持。解决了ConGolog交替并发和虚拟场景中多Agent动作并发之间的矛盾，使得虚拟场景中虚拟人可以流畅的、并发的执行规划动作。基于情景演算理论探讨的请求/服务协作模型还处于初步阶段，可以做进一步地深入研究。而且，由于协作模型有很多种，可以继续探讨情景演算是否适合于其它协作模型。

[1]杨爱琴,朱玲玲、程学云.基于流演算的多Agent 请求/服务协作模型的研究[J].计算机工程与设计,2011,32(2):681-684.

[2]Wooldridge, M.and Simon Parsons.Language for Negotiation [C].Proc.of 14th European Conf.on Artificial Intelligence, 2000.

[3]Thielscher M.Reasoning robots:The art and science of programmingrobotic agents[M].Germany:Springer Berlin,2005.

[4]ThielscherM.FLUX:A logic programmingmethod for reasoningagents [J].Theory and Practice of Logic Programming, 2005,5(4-5):533-565.

[5]Schiffel S,Thielscher M.Interpreting golog programs in flux[C].7th International Symposium on Logical Formalizations of Commonsense Reasoning,2005:193-198.

[6]Cohen P R, Perrault CR.Elements of a plan-based theory of speech acts[J].Cognitive Science,1979,3(3):177-212.

[7]Reiter R.Knowledge in action: logical foundations for specifyingand implementing dynamical systems[M].MIT Press,2001.

[8]杨爱琴.基于流演算的多agent 通信动作的研究[J].计算机工程与设计,2010,31(1):221-224.