CN1914630A

CN1914630A - 作为数据类型的基于行为的多代理系统

Info

Publication number: CN1914630A
Application number: CNA2005800039250A
Authority: CN
Inventors: 迪迪尔·蒂加德; 斯特凡·戴科特; 菲利普·凡荷格
Original assignee: Individual
Current assignee: Individual
Priority date: 2004-01-05
Filing date: 2005-01-05
Publication date: 2007-02-14
Also published as: CA2552280A1; BRPI0506461A; RU2006123938A; EP1716522A2; US20070197877A1; WO2005069130A2; WO2005069130A3; JP2007523397A

Abstract

本发明的实施例包括具有计算机可执行部分的计算机可读介质，计算机可执行部分包括至少一个具有至少一个传感器部分和至少一个行为部分的代理，至少一个传感器部分具有目标或改变方法部分。至少一个传感器部分至少部分地基于来自于目标或改变方法部分的至少一个产生的值来产生至少一个事件。至少一个行为部分至少部分地基于来自于至少一个传感器元件的至少一个产生的事件来确定是否激活执行的线程。系统复杂的执行的线程可以通过代理层次、事件层次、传感器层次以及行为层次上的任何运算符来产生。

Description

作为数据类型的基于行为的多代理系统

技术领域

本发明主要涉及计算机程序设计语言，更确切地说涉及用于实现基于行为的多代理计算系统的系统和方法。

附图说明

当结合附图来考虑时，通过来参考以下详细说明，将容易获得对本发明实施例的更完全的理解，其中

图1是说明了根据本发明实施例，RIDL代理的不同部分的总体框图。

图2是说明了在根据本发明实施例，在RIDL中接受无效的地方的表格。

具体实施方式

本发明的实施例包括作为数据类型实现基于行为的多代理系统的几个方法的设备和实施例。

在此参考称为RIDL(机器人智能定义语言)的特定的语言实施而描述特定的程序设计语言概念。然而应该理解，在不脱离本发明的前提下，可以实现使用在此所描述的不同概念和方面的其它实施。

RIDL是适用于硬件或软件(虚拟的)机器人程序设计的机器人程序设计语言，在一个方面中，其在传统的语言上添加几个关键字。例如，RIDL可以是Java的超集，作为C#的超集的AGENT#，DOTNET和C++，然而应当明白，也可以使用除了C#、DOTNET、C++和Java之外的其它语言结构。因此，此处所描述的RIDL包括驱动RIDL应用程序类的不同概念、原则和方法的摘要说明。

如在此处将要描述的，将参考一个编译程序来描述RIDL的语言、方法和实施，然而，应当明白，本发明不局限于编译，并且本发明也不局限于此处所述的特殊语法和实施。例如，本发明的各方面可以用解释程序或其它语言读取引擎来实现。

编译器层次方面

作为数据类型的代理

在不同的实施例中，添加的关键字让多代理系统的创建变得非常简单。例如，在与传统的“对象”相同的层次添加关键字“代理”。对于此处的目的，从语法的观点来说关键字代理和对象是可互换的。关键字的作用表示块定义了代理。本领域的技术人员将注意到可以使用不同于“代理”的其它单词。此外还可能的是，用指出这类对象事实上是代理的属性来注释该对象。无论采用什么语法，其目的都是指出被封装的是代理并且如同那样地运行。

根据本发明的一个方面，认为代理是与对象完全类似的本地数据类型。所有可以对对象做出的动作也可以对代理做出。这类动作例如是新代理的创建、代理的消除、将代理作为参数传递、创建到代理的引用(指针)、复制代理等等。

如同对象一样，代理定义实际上定义了代理的类别。例如，一个代理实例由一个新的语句来创建，或者在定义那个类型(代理类别)的新变量的时候创建。

最后，可以定义一个语言，其中，所有对象都是通过定义代理，由此将不需要指出对象是代理。通过确定是否使用下面所描述的特征(传感器和/或行为)，编译器可以区分主动代理(代理)和被动代理(对象)。因此，只能够通过考虑下述的不同特征完全理解作为数据类型的代理。

传感器

传感器定义了代理将对其起作用的外部或内部信号。此处所用的传感器是注释为传感器的传统类型的变量。通过向该变量添加一个属性，或通过用新的关键字来指出定义了特定变量，可以完成这个注释。在一个例子中，属性“传感器”可以用来注释已有的变量。

传感器是多代理系统的一部分。在一个实施例中，传感器104是特定代理的一部分，然而，也可以将传感器定义为“全局的”，其中，它不是任何特定代理的一部分，而是可用于所有的代理(由此它不会像代理那样“死亡”)。

当传感器被更新或改变时，它引发一个事件以便指出发生了什么。与传感器相关联的事件有两个：更新事件和改变事件。传感器工作如下：每当它接收新值的时候都引发一个更新事件。如果该新值不同于先前的值，则也引发一个改变事件。这些事件能够由行为接收(如下所述的)。

在这时候，语言C#和C++已经具有注释，其在变量发生变化的时候允许变量来引发事件。然而，为了接收这个事件，收听者必须注册到该引发变量上。相比之下，根据本发明一个方面，收听者不需要注册来接收事件。例如，“行为”104可以监听事件的类型，并且任何符合该类型的事件将由行为106获得。因此，本发明与之前的多代理系统形成对比，其中，代理数量是动态的并且行为无须知道存在哪些代理。在这类情况下，行为不能注册到这些代理上。当论述任何(any)运算符时，将以进一步的细节来讨论这个功能。

使用一个描述性的比喻：假定你正在进行电话交谈。在C#和C++中，用户可以与在线路另一端的他所认识的任何人交谈。然而，如果另一端的某人说了一些话而该用户预先不知道其它的个人会在场，则该用户将不会听到其它的个人。在RIDL中，即便用户没有料到其它人在那儿或者该用户没有被预先通知有其它人存在，用户也将听见在另一端说话的每个人并且可以与他们所有人交谈。因此，这个方面考虑了环境内的不定性，并且以连续不断改变的代理数目以及改变的环境进行考虑。

在C#和C++以及相关的程序设计语言中，一个程序设计员明确地需要引发一个事件。程序设计员必须写代码来调用关于该事件的方法，以便通知收听者(例如“throwEvent(myEvent)”)。然而，在本发明的各个方面中，收听者可以决定是否记录一个事件。

行为

行为是活动的，这意指它具有它自己的执行线程。从程序设计员的观点来看行为是并发运行的。在特定事件出现的时候，行为不是返回值而是定义一些将要采取的行动。它定义响应于外部或内部事件应该做什么。行为总是空的并且不可以采用任何自变量。它们通过在明确定义的事件和代理状态的结合上激活来实现反应智能。

虽然目标和传感器在代理外面可见，但是行为总是私有的(private)或受保护的。只有受保护的行为可以被无效(overridden)，并且它们的可见性(受保护的或私有的)必须在所有子代理中保持不变。

行为是被注释为行为的方法(是对象的一部分、或者在本发明中，是代理的一部分的程序)。通过向方法添加属性，或通过用新的关键字来表示定义了特定方法，可以完成这个注释。因而，在一个例子中，用新的关键字“行为”来表示这类特定方法。

行为具有它们自己的事件。例如，每当开始一个行为，它就引发一个激活事件，并且只要完成，它就引发一个完成事件。可以定义其它的事件，并且此处所指出的事件名称只为了清楚的目的，确切的语法可能会不同。其它潜在事件的例子是挂起、出生、死亡、等待等等。可以实现任意数量的事件。在一个方面，事件可以向其它行为和其它代理提供关于它的状态的信息。在一个实施例中，行为将引发这些事件而不需要开发者部分上的任何动作。

在一个实施例中，行为在它们激活的方式上可能不同于传统的方法。例如，如同在面向对象的方法中定义的传统方法由一些别的方法调用。一个方法可能潜在地作为一个新的执行线程的创建部分而被调用，然而即使在这种情况下，确定什么时候调用该方法的是某些外部逻辑。相比之下，行为可以在它们激活的时候被完全控制。在一个实施例中，行为不能由外部逻辑调用并且只有它们自己可以决定什么时候激活。因而，这些行为106不需要外部代码来激活。

行为可以具有指出应该什么时候将它激活的区段。例如，这个区段可以包括一个触发条件。尽管它不是必须那样，该触发条件典型情况下与要执行的代码分离。然而，在不同的实施例中，触发条件是行为的规格的一部分。

如上所述，注意到触发条件对于行为是本地的是重要的。将要执行的代码以及导致它执行的那些条件集合在同一处。这使得能够推论隔离中的系统的行为。当描述代理的动作时，可以基于它对于世界的本地感知来描述它的行为，而不用知道什么导致这些感知以及是由谁引起的。代理仅仅响应于它周围的外因，这，例如，是用于经济学、计算机科学、金融、商业、社会科学以及许多其它领域中许多大型问题的自然模型。

在一个实施例中，触发条件使用由传感器和行为引发的事件来推动其激活。触发条件在概念上包括两个部分：指出它所响应的事件的“时间(when)”部分，和基于用于过滤该事件的值和其它参数的“条件(if)”部分。诸如VisualBasic，C#和C++以及Java之类的其它语言允许引发并捕获单一的事件。然而在RIDL中，例如，可能使用多事件和复杂条件来选择行为希望捕获的那个事件。本质上，行为向事件应用一些实时形式的询问。

基于已知的代理来定义触发条件是可能的。因为诸如对象之类的代理是数据类型，所以能够通过持有它们的变量(如果被保存在一个变量中)的名称，或者通过引用(指针)来引用它们。因此，可以静态地定义触发条件。

可以通过等待特定事件来表征不同的实施例。首先，那意味着需要在代理内指定想要的是哪个传感器或行为。接下来需要定义它们正在等待发生的事件的类型。例如，自然模型将指出正在等待的代理，接一个点，然后命名传感器，接一个点，然后命名该事件。例如“MyAgent.MySensor.updates”应该是一个自然模型。然而，该语法可以采取任何形状或形式。关键在于指出代理，然后指出传感器/行为，最终指出事件。

在触发条件的“时间”部分中，可以用“或者(or)”关键字或者通过具有类似含义的东西将事件连接起来。这允许人们创建他们想要行为对其敏感的事件的列表。

在触发条件的“条件”部分中，可以使用包括布尔操作符在内的所有常规的编程运算符。在“条件”部分中，所有可以在行为/方法的主体中使用的变量和运算符都是可用的。例如，可以使用一个范围之内的每个变量，其中，该范围如同诸如Java和C#以及C++之类的传统语言中那样来定义。

目标

目标执行对代理做出的请求。目标不是活动的对象并且它不包含数据。作为直接后果，目标没有与它们相关联的事件。目标可以用多个参数来调用并且这些参数可以是复杂数据类型。当它们被调用时，它们把它们的数据传递给(被动的)数据成员和成员传感器。因此，可以认为它们是代理的接口或通信信道。因为目标表示对代理的请求(代理可以决定对其做出或不做出反应)，所以它们不同于常规的方法(像在对象上那样)。

像任何其它的常规方法那样，目标也具有返回类型。因为传感器只能从目标里面进行设置而不能从常规方法里面来设置，所以认为方法是目标执行请求时的某种保证执行，它的结果可能对每个调用有所不同。不保证要考虑请求，而是取决于推论和代理的状态，它们可能导致不同的代理动作。毕竟，代理可能有重要的多的工作要做，例如在边缘上保持平衡的机器人决不会去注意它的声音传感器捕捉到的鸟叫声。

目标是其中允许改变传感器值的唯一的地方。因为它们表示对代理的请求，所以它们将它们的请求转化成传感器变化，而代理的活动部分可以对其产生反应。可以用方法来读取代理的状态，或者直接地、主动地完成某些事情。目标只具有“副作用(side-effect)”，它们概念化代理可能对其反应的对代理的请求。因而，目标只在代理上可用，而在总是被动的对象上不可用。如果调用方法，则你还知道该代理决不会‘知道’它。

在句法上以如同常规方法一样的方式宣告目标。然而，它们接收“目标”限定词以指出有人在处理代理请求。

图1阐明了不同的RIDL代理100构造、它们引发的事件以及处理它们的地方之间的关系。目标102具有对(仅仅同一代理中的)传感器104的写访问，传感器104通过引发变化或更新事件对新值反应，其由行为106处理，行为106在它们的轮次上引发激活和完成事件。这些事件最终由其它行为(未示出)捕获。所有的行为106都设法通过调用它们自己的代理目标102或其它代理中的目标来引起变化。

任何事件运算符

我们所等待的事件的明确指示经常都不够灵活。例如，在开发者想等待多个事件的时候。一个解决方案将无遗漏地确定所有的可能性，但是要与诸如下面定义的其它(other)运算符结合。这可能是很冗长的(并且有时甚至由于缺乏信息而不可能)。因而，在一个实施例中，本发明包括通有的事件。这个主意是可以等待来自于指定的代理的传感器104或行为106的任何事件。例如，书写这个的一个方式是省略事件名或将名称“事件”用于通有的事件。替换地，可以构思许多其它的注释。例如，注释“MyAgent.MySensor”或“MyAgent.MySensor.event”将对改变以及更新事件两者都做出响应。

任何传感器/行为运算符

在一个模式中，代理的结构是完全未知的，并且不知道哪个行为106或传感器104在该代理之内。仍然可能是某人希望被通知该代理的任何行为106或传感器104内的任何活动。到此，在一个实施例中，诸如“传感器”和“行为”之类的关键字替换了特定的传感器104或行为106的表示。再次，也可以使用其它的语法，但是关键在于使用存根而不是传感器104或行为106的明确名称。例如，书写这个的可能的方式是”MyAgent.sensor.changes”。这个代理将一直等到代理MyAgent中的任何传感器改变它的值(它将忽略不改变该值的更新)。本领域的技术人员将注意到，开发者再次具有指定事件，或者使用通有事件指示(如前一段落中定义的)的选择。在相同的倾向(vein)中，代理可以用指出正在等待任何行为的存根来替换明确行为的名称。例如，“MyAgent.behavior.activates”将意味着某一个正在等待代理MyAgent内的任何行为激活，这将有效地允许监视该代理是否活动而无须知道定义了哪些行为。

留下传感器104和行为106的名称的存根的能力可以允许可以处理在书写第一代理的时候没有定义的其它代理的代理应用程序。新的结构在触发条件的“时间”部分中工作正常。然而，对于条件的“条件”部分，很可能是希望对例如具有高于100的值的任何传感器做出响应。在这样的一个例子中，因为留下了传感器104的名称的存根，所以“条件”部分不知它将在哪个传感器上测试来查看它的值是否超过100。因而，“条件”部分所需要的是知道代理的哪个传感器104引发了该事件。因此，在一个实施例中，“时间”子句可以包括具有变量的名称的传感器104的注释。这个变量将存储引发了该事件的传感器104的引用。因为在“时间”部分之后对“条件”部分估值，所以“条件”部分可以使用这个变量来标识传感器104并且调查它的属性(比如它的值)。

在通过触发条件激活的行为106的主体内，也可以使用来自于“时间”部分的变量。因此，行为106可以按照需要把它的响应瞄准事件引发传感器104。这与自省属性结合是特别强大的。

任何代理运算符

在另一个示例中，行为106可能希望对来自于任何代理的事件做出响应，其中包括在行为106开始等待它的触发条件之后的任何时间点加入代理团体的代理。实际上，即使行为106是不活动的并空闲的，并且在开发者侧上没有任何代码，行为106也可能希望知道该系统中的每个代理，包括新加入者和离开该系统的代理。

本领域的技术人员将注意到这个问题从根本上不同于先前的问题。在设计时定义代理，由此代理类别在运行时不可以改变它的定义。因此，在编译时，代理总是知道它自己的行为106和传感器104的列表。先前，因为在代理层次不存在运算符，所以总是知道它们谈论的是什么代理。因此，如果一起编译所有的代理，在事件、传感器和行为层次处的任何运算符可以由编译器来求解(并且因为没有对代理使用任何运算符，由此总是用已知的数据类型(代理)查询变量或指针，编译器总是知道)。

在代理层次处的“任何”运算符引入了复杂性的新层次。如果在代理层次上使用“任何”运算符，则代理可以加入在编译时未知的团体。这意味着现在该代理必须在运行时求解它们的任何运算符。让RIDL代理加入来自于别处的团体成为可能的不同方面在下面关于“运行时层次方面”的章节中讨论。

在一个实施例中，代理可以谈论最初未知的代理。例如，在行为106的触发条件中，可以参考代理类别而不是参考特定的代理。如上所述的，代理是数据类型并且因而具有名称。数据类型的实例可能有或没有名称(变量相对于动态存储器分配)。因此，通过使用代理数据类型的名称(代理定义中使用的名称)，可以表示出该类别中所有的代理。当一个触发条件使用代理的类别名称时，它实际上意指它等待来自于是那个代理类别的成员的任何代理的特定事件。

再次，虽然这对于触发条件的概念上的“时间”部分有效，但是它对于”条件”部分以及还对于代码的执行可能带来问题。当获得事件时，然后它们可能想要检测发送该事件的代理是否符合特定条件(触发条件的“条件”部分)。因此，当它们接收到事件时，它们还需要捕捉发送该事件代理的引用。

在一个实施例中，代理类别可以用变量名来注释。例如，该变量将存储对那个引起该事件的代理的引用。通过这参考，可以访问该代理的所有公共属性，包括公共传感器的值。对于代理引用的所有常规动作都可以在这些生成的引用上完成。

在另一个实施例中，可以希望能够与先前未知的代理交互。为了这个目的，在一个实施例中，可以将引用(指针)包括在内以用于通有类型代理。例如，可以用这个通有的引用类型来定义代理。例如，对于“Agent.sensor.event”的调用将对来自任何代理的任何传感器的任何事件做出响应。本领域的技术人员将注意到不同的语法注释再一次是可能的。

代理层次事件和运算符

迄今为止，一直都假定只有传感器104和行为106可以引发事件。然而，在不同的实施例中，代理它们自己也可以引发事件。特别地，表示它们产生、将消亡，将加入团体(但是在别处产生)或离开组(而不是消亡)的事件。这允许代理更以相互的动作为目标地做出响应。在一个实施例中，“欢迎委员会”可以对代理的加入做出响应，例如通知它们该团体的规则。

代理层次事件可以与任何代理运算符相关联。例如，一个可能的注释是“<NewMember：>MyAgentjoins”，其等待类别MyAgent的任何代理加入该组，并且将那个新代理的引用分配到变量NewMember。这只是一个语法的例子，并且通过完全不同的注释可以获得相同的效果。另一个例子是“<NewBorn：>Agent.born”，其将对在团体内新创建的任何类型的任何代理做出响应。在下文中将参考服务层次方面进一步详细地讨论团体。

包含(subsume)/恢复(resume)

经常以层来创建智能系统，其中，较高层与较低层交互并且优先于较低层。尽管如此，较低层典型情况下保持活动。只有有限的功能被无效，而大多数动作保持原样。与其除去整个代理并由另一个来替换它，本发明宁可允许包含特定的行为。包含意指一个行为暂停另一个行为，并且接管控制。通常进行这个来处理所定义的关于行为的规则的例外情况。在处理了例外情况之后，通过恢复语句将控制恢复到包含的行为。

包含和恢复是运行时的特征。它们可以在任何行为106上使用。例如，如果一个代理存储在变量“MyAgent”中，则可以通过“MyAgent.MyBehavior.subsume”直接地指定具有名称“MyBehavior”的行为。再次地，其它语法可以实现相同的作用。

行为106可以由任何行为包含，包括它自己。在一个实施例中，一个被包含的行为可以从任何其它的行为恢复(因为它是不活动的，因此不由它自己来恢复)。做出包含的行为106不需要与做出恢复的那个行为相同。

在一个实施例中，每个行为106都具有称为“被包含”的(或某种等效的名称)预定义属性。虽然该属性是行为106的一部分，但是它是一个传感器104。例如，这种传感器104可以是标量传感器(例如“int”或“integer(整数)”)。在一个实施例中，属性统计传感器被包含的次数。如果行为没有被包含，则它被包含的属性将是零。每当行为接收到包含请求的时候，计数器将增加1。每当行为接收恢复请求的时候，它将减少它的计数器。如果被包含属性是零，则该行为将工作。一个被包含的行为在包含时完成。这意指在恢复时，它就再评估它的触发条件。这意味着该行为在它被重新激活的时候首先查看它的环境。这功能可以防止它执行错误的动作。

本领域的技术人员将注意到被包含的属性是一个真实的传感器。因此，当它改变时，它引发一个事件。包含状态可以在触发条件中使用。与一个(如下所述的)“completeWhen”语句结合，这也允许行为106监视它自己的包含状态。用这结构，行为106可以就在它被包含之前执行代码，从而由于行为在它的主体中间被中断而确保没有引起破坏。

因为上述特征是运行时特征，所以它们还可以用于只具有引用的代理。因此，可以在用“任何”算符选择其它行为的行为的主体中调用这些特征。

已经作为语法关键字描述了关于包含和恢复的特征。然而，这些特征还可以作为该代理上默认可用的方法来提供。例如，对于代理“shopAgent”，如果想要包含它的“buyBehavior”，则在该功能实现为该代理上的方法的情况下，可以写“shopAgent.subsume(“buyBehavior”)”。如果包含是一个关键字，则将沿着“subsume shopAgent.buyBchavior”的行来书写同样的。因而，无论是什么书写方式，概念保持不变。

继承

面向对象的其中一个关键特征是创建派生类型的能力。一个对象的功能可以通过继承所有功能来改进，并且根据需要使功能无效。可以用本发明来同样地对待代理。当改进代理时，可以进行与对对象所做的完全相同的处理。可以使方法无效以便改进。

在一个实施例中，因为它们自己决定激活的时间，行为无法由其它代码调用。因而，行为没有参数。当行为被无效时，它们立即由新的行为替代。

传感器是一种变量。因此，正常范围规则适用。这意味着传感器可以替换同名的传感器。

最重要的，事件机理在继承时保持原样。当代理正在继承一个行为时，这个行为的触发条件将考虑到它需要查看子代理中的行为。如果子代理中没有行为存在，则它将在父代理中寻找这些行为。结合任何传感器/行为运算符，这允许代理执行相对来说较复杂的逻辑，其中，父代理可以不用明确地知道子代理的结构或它的其它性能而提供功能。图2说明了一个实施例，其中，在RIDL中可以接受无效。

再访问的代理任何运算符

在代理“任何”运算符的定义中，可以指定类别的名称。如果“任何”类别指定具有后代的类别名称，则“任何”运算符将还考虑它所有的后代。因而，代理的子代理是具有改进的同一类别的代理。

如果在任何运算符中使用子代理的名称，则父代理将不是该任何运算符的一部分。父代理不是子代理的类别的一部分。例如，如果汽车是车辆的子代理，则任何车辆将包括汽车，然而，“任何”汽车将不包括每个车辆。

“任何”运算符是知道继承的事实使它们适用于做出复杂的决策。例如，代理可以在下列条件上激活行为106：如果任何船只正在靠近，并且附近没有军舰，则激活行为。在另一个示例中，如果老师没有教室并且没有可用的教室，则该代理可以激活行为。因为传感器是变量并且代理是数据类型，本领域的技术人员将注意到传感器可以自身就是代理。此外，也可以作为参数将代理传递给方法。

从行为(事件处理结构)划分事件/改变触发条件

上面的章节讨论了具有触发条件的行为。还可能创建对触发条件做出响应，并且或者引发特定事件，或者直接地调用方法的语言结构。这样的结构在一个方面本质上从方法/行为划分了触发条件。同样地，触发条件可以混合时间和条件部分。

服务层次方面

随着软件集成变得越来越困难，并且软件变得越来越复杂，所以软件的设计方法也在改变。近来，存在朝着面向服务的软件工程的倾向。这个趋势的本质是软件应用具有基于诸如XML环球网服务之类的标准的接口。软件通过这个接口作为服务提供其功能。集成不同的软件包变成纯粹是把服务结合在一起的事情。

在软件工程中，使用名称空间来把对象集合在一起成为逻辑部件。例如，“磁盘”名称空间可以包括与该磁盘接口的所有程序。根据本发明的一个方面，可以用名称空间来以类似于将对象集合在一起的方式集合代理。特别地，代理可以是名称空间的一部分，并且可以与对象共享名称空间。换言之，在这个方面，因为它们两者都遵循相同的规则，语言不区分代理和对象。

在名称空间层次，本发明的一个实施例包括“服务”。在它们用类似的功能来集合对象和代理的方面，语言层次处的服务类似于名称空间。特别地，它集合共同地实现单个服务的代理和对象。在不同的实施例中，通过使用新的关键字，通过使用注释该名称空间的属性，或通过假定每个包括代理的名称空间都是服务，可以指出名称空间是服务。

如果名称空间是服务，则它提供功能。该功能可以通过定义的接口来访问。在不同的实施例中，本发明提供指定这个接口的方式。

在第一实施例中，包括方法来明确地定义对象或代理是到该服务的接口。例如，这可以通过向该对象或代理提供属性而完成。

在另一个实施例中，包括方法来与该服务名称一致地命名该对象或代理。在这种情况下，公共变量和方法是该服务的实际接口。该服务开始的时候，将自动地例示这个类别的代理或对象，并且每次服务只能创建这个代理或对象的一个实例。

面向代理的数据库层次方面

面向代理的数据库(AODB)的一个方案是把每个记录(OODB中的对象)考虑为一个特殊种类的代理。该代理只包括传感器(没有行为)，并且禁止在这些代理上的继承。认为每个外部字段，以及每个计算的或者以其它方式获得的字段都是一个传感器。因此，数据库是只具有传感器的一组代理。

这个方案监视对每个记录的字段发生了什么。每当更新字段的时候，引发被更新的事件(行为的触发条件使用的类型)。如果字段改变值，则引发改变事件。结果是可以将行为定义成监视并且对数据库中的变化做出响应。从概念上的观点来看，数据库充满着其它代理可以对其做出响应的代理。

替换地，数据库代理可能就好比具有传感器和行为以及其它的属性的任何普通的代理。数据库代理和普通代理之间的差异是它的传感器存储在数据库中。在这种情况下，软件设计师概念上应付充分发展的代理。数据库的结构和代理系统的结构必须充分地匹配。这个方案的优点是设计师具有代理模型的完全的自由度。编译器将创建支持该模型所需的表格。当使用这个方案时，所希望的是用关键字来注释代理以表示这个代理是持久的。这允许编译器区分持久和不持久的代理。

运行时层次方面——执行阶段

在编译器方面描述的事件机制的能力通过编译器可以完成的优化类型而示出。这些优化影响运行时性能。在此在运行时将它们分类，但是它们需要编译器采取行动来生成用于运行时引擎的必需的列表和其它材料。

在不同的实施例中，实时优化和速度优化执行是RIDL的特征。如上所述的，将触发条件拆分成“时间”和“条件”部分。“时间”部分指定了触发触发条件的“条件”部分的估值的事件。因为每个事件都链接到预先定义的行为或传感器(以及更早之前定义的代理)，并且因为每个行为都在其触发条件中依赖这些事件，所以可以用传感器作为图表中的许可画出行为之间的依赖图。每当更新或改变传感器，或者激活或完成行为，该事件传播通过该图表并设置需要再次估值的触发条件的标志。对触发条件估值并且如果它们被满足，则设置标志来指出需要执行该行为。

在一个实施例中，存在选择经过标志的行为并执行它的执行线程的集合。例如，执行线程的集合可能一个极端上是单个线程，或者另一极端上是与行为一样多的线程。执行线程的数量可以取决于编译器执行，但是可能与系统中代理以及行为的数量分开。本领域的技术人员将注意到可以采用许多形式来“标志”行为。例如，它可以包括设置为标志的变量，可以将行为(标识)添加到列表和/或专用于该行为的执行线程可以开始(这相当于同时进行标志和开始执行)。

对于行为的自动优先级检测

根据本发明的一个方面，将较高的优先级给予在层次图中较低的行为。实际上，在层次中较低意味着该行为较靠近硬件或软件接口。那意味着它们比较靠近事件，并且可能要求它们是反应更迅速的。

机器人和机器控制中的例子让这个很清楚。如果行为直接耦合到硬件传感器，则很可能需要非常迅速的响应。然而，在最高层次，行为对由已经对其它RIDL传感器做出响应的行为建立的传感器做出响应。换言之，图表中较高的行为以更多的抽象数据工作。处理这些信息通常比低层次行为更少时间敏感(例如，“反射”相比于“思想”)。

如前所述，传感器104或行为106的事件将传播通过依赖图，并且将需要再估值的触发条件放置在列表中。在一个实施例中，触发条件处理器将处理这个列表。例如，该列表可以是基于优先级的，这意味着每当将新的行为的触发条件添加到该列表的时候，可以把它排序到执行队列中，从而一旦它具有所有等待行为的最高优先级就被执行。优先级反映到许可的距离，其中，许可具有最高优先级，并且每个附加的依赖降低优先级。

在较小的系统中，有可能对触发条件立即进行估值。在这种情况下，因为假定触发条件的估值是立即的，没有其它的行为正在等待，每个行为自动地具有最高优先级。

如果满足触发条件，则对应的行为就存储在包括要执行的行为的新列表中。再次地，这个列表可以通过该行为的优先级(用如同上述的同一优先级定义)来排序。然后，线程的集合可以执行具有最高优先级的等待行为。

最后结果是在取决于较低层次的行为的较高层次的行为得到执行机会之前，较低层次的行为可以执行多次。这意味着较高层次的行为可能遗漏“帧”，其中，帧定义为假定评估的话，将会是真实的触发条件。该特征在它保证了在需要迅速响应的最低层次处的迅速响应上可能是有益的。同时，它与对代理动作有决定性影响的不确定原则相匹配。代理永远不能保证它所相信为真的实际上(仍然)为真。因而，要求代理持续检测是否它的假定仍然保持。因为从底层向上构造多代理系统以处理不规则，这个不确定原则的最后结果是多代理系统鲁棒的多。

行为106总是等待多个事件。在这种情况下，行为106将总是具有一个低于刚导致它执行的事件的优先级。因此，行为的优先级在运行时动态地改变。

传感器104的事件具有低于更新传感器并引起该事件的行为106的优先级。在从行为106的外部更新传感器104的情况下，将认为它是具有最高优先级的许可事件。

在诸如计时器之类的系统定义事件上触发的行为106将被认为是许可行为并且将具有最高优先级。

在不同的其它实施例中，存在需要在所有行为上有效并且影响分配的优先级的附加规则。例如，基于另一个行为的完成而被激活的行为106，可能总是具有低于其它行为的优先级。在另一个例子中，基于另一个行为的激活而被激活的行为可能具有与那个另一个行为相同的优先级。

详尽的行为

在不同的实例中，上述的层次化方案可能产生并非意图的优先级。特别地，在软件的内部可能存在两个依赖图表。例如，其中一个图表可能对执行数据负责。另一个图表可能监视另一个图表的动作。因为这类图表可能从相同的传感器开始，并且在较高层次不能交互作用，所以编译器将不能向一个图表或另一个图表分配较高的优先级。替代地，编译器可以向两者分配类似的优先级，从而让它们在运行时间争夺资源。

这个问题的一个解决方案是让用户来明确定义行为的优先级。然而，这方案可能容易产生误差。因此，本发明的不同实施例包括一个“详尽的”指示符。例如，当将行为标记为“详尽的”时，这可能意指不允许该行为遗漏任何帧。例如，该行为将以充分的优先级来响应，以便保证它在下次它的触发条件变成真之前被执行。在不同的实施例中，详尽性不能保证行为在特定时间帧内被执行，然而，它可以保证每当触发条件变成真的时候它就被执行，而且下一个执行将在之前的一个执行完成之后发生。

而且，一个详尽的行为可以相对于它自己的事件是详尽的。因而，它的详尽性可能对依赖列表中的其它行为没有影响。换言之，不是因为一个行为是详尽的，它等待的另一个行为也变得详尽的或者以另一种方式在优先级中有所变化。因而，只有明确地标记为详尽的行为才肯定永不遗漏任何帧。当然，如果另一个行为仅仅依赖于详尽的行为，因为生成了它等待的许多事件，它可以比正常行为被更频繁地触发。

冗余行为

冗余行为与详尽的行为相反。当将行为标记为冗余时，这意指它具有比所有的常规行为都低的优先级。如同详尽的行为那样，冗余行为不以任何方式改变其它行为的优先级。例如，只有被明确标记为冗余行为的行为才可以具有这个较低的优先级。当然，如果另一个行为仅仅依赖于冗余行为，因为没有生成它正在等待的事件，它决不会比该冗余行为被更频繁地触发。

实时映射的层次图表

在实时系统的支持下，允许明确地将行为映射到特定的数字优先级层次。例如，开发者可以固定这些行为，并且对于没有定义数字优先级层次的每个行为，上面定义的规则可以应用。

continueWhen语句

“continueWhen”语句是后面跟着触发条件的语句。它是可以在行为主体内任意一点使用的语句。例如，它可以指示行为一直等到指定的触发条件结果是真为止。这样的语句在行为需要执行顺序的动作序列的时候是特别有用的。它还可以提供基本结构来确保行为之间的同步。一个示例情况是当机器人需要举起手臂来达到某个高度(传感器)(动作)的时候。然后，在它那样成功地做到之后，它可能需要按下一个按钮。

continueWhen语句是对于还可以使用状态机来实现的功能的简化符号。例如，可以将包括continueWhen语句的行为拆分成几个行为，这几个行为结合指定的触发条件用状态机来达到相同的效果。在一个实施例中，状态机最初处于其状态0并且正在与行为的触发条件一起等待状态0。在行为的第一部分完成时，它将状态机置于状态1中。模仿continueWhen之后的部分的第二行为与continueWhen中指定的触发条件一起等待状态1。当已经激活状态机中最后的行为时，将状态置回到0。

在一个方面中，编译器可以只把这个转变应用到软件，例如通过代码所示的：

　　void MyBchaviorQ：behavior
				
				<dp n="d16"/>
　　when TrigCondWhen

　　ifTrigCondlf

　　{

　　  Statement1；

　　  Statement2；

　　  continueWhen TrigCondContinueWhen1

　　         if TrigCondContinue1f1；

　　  Statement3；

　　  continueWhen TrigCondContinueWhen2

　　         if TrigCondContinueTf2；

　　  Statement4；

　　  }

这可以转变为：

　　int MyB ehaviorState＝0；

　　void MyBehaviorPart0()：behavior

　　when MyBehaviorState.changes or TrigCondWhen

　　if(MyBehaviorState＝0)and TrigCondIf

　　{

　　  Statement1；

　　  Statement2；

　　  MyBehaviorState＝1；

　　}

　　void MyBehaviorPart1()：behavior

　　when MyBehaviorState.changes or TrigCondContinueWhen1

　　if(MyBehaviorState＝1)and TrigCondContinueIf1

　　{
				
				<dp n="d17"/>
　　  Statement3；

　　  MyBehaviorState＝2；

　　}

　　void MyBehaviorPart2()：behavior

　　when MyBehaviorState.changes or TrigCondContinueWhen2

　　if(MyBehaviorState＝2)and TrigCondContinueIf2

　　{

　　  Statement4；

　　  MyBehaviorState＝0；

　　}

结果是该行为包括触发条件和执行到其终点的方法。

在一个实施例中，编译器可以把continueWhen行为变换成多个行为，并且可以保证变量从两个行为(而不是从别处)是可以访问的(因为它们在概念上是本地的)。例如，它可以通过用在代理中的任何其他地方没有引用的唯一的名称来创建在代理内是全局的变量来实现这个。

completeWhen语句

在上述的实施例中，在行为的主体内使用continueWhen语句。然而，when和completeWhen语句都在行为的主体的外面使用。因而，“when”条件指出什么时候执行主体。“completeWhen”语句是“when”语句的逆。它指定行为应该在其上停止执行的触发条件。completeWhen可以再次接着主体。在一个实施例中，当触发completeWhen时，停止行为的主体并且执行completeWhen之后的主体。在completeWhen的主体内，可以访问在行为的主体中定义的所有局部变量。概念上，该代码在主体内部并且替换留待执行的全部代码。

complete When语句可以通过变换行为的主体来实现。例如，假定以下行为：

　　void MyBehavior()：behavior

　　when TrigCondWhen
				
				<dp n="d18"/>
　　ifTrigCondIf

　　{

　　  Statement1；

　　  Statement2；

　　  Statement3；

　　}

　　completeWhen TrigCondCompleteWhen

　　ifTrigCondCompleteIf

　　{

　　  CStatement1；

　　  CStatement2；

　　}

这可以转换成具有相同效果的下列代码：

bool MyBehaviorCompleteNow＝false；

　　void MyBehaviorMustComplete()：exhaustive behavior//&amp; highest priority

　　when TrigCondCompleteWhen

　　ifTrigCondCompletelf

　　{

　　       MyBehaviorCompleteNow＝true；

　　}

　　void MyBehavior()：behavior

　　when TrigCondWhen

　　ifTrigCondlf

　　{

　　     if not MyBehaviorMustComplete
				
				<dp n="d19"/>
　　  {

　　  Statement1；

　　  if not MyBehavio rMustComplete

　　          {

　　          Statement2；

　　          if not MyBehaviorMustComplete

　　                  {

　　                  Statement3；

　　                  }

　　              }

　　    }

　　    if MyBehaviorMustComplete

　　    {

　　        CStatement1；

　　        CStatement2；

　　}

　　    }

在不同的实施例中，因为无论该行为的优先级有多高，它必须完成的事实都具有甚至更高的优先级，因此对完成条件的检查必须具有最高优先级。在一个实施例中，因为对完成条件的检查不更新触发事件的任何东西，可以在这种情况下使用详尽的关键字。例如，它更新变量而不是一个传感器。因而，编译器可以把第一代码转换成后者，并且从而实现该功能。替换地，也可以采用其它方法来实现所要求的功能。

无论选择什么方法，编译器都可以将具有completeWhen语句的行为转换成不具有这类语句的行为。因而，它仅仅是一个很有用并且强大的简化符号。语句的使用是极其频繁的，特别是结合每个行为的系统定义的包含的传感器，如下一个例子所示：

void MyBehavior()：behavior

　　when OtherSensorl.changes

　　{

　　    Statement1；

　　    Statement2；

    }

　　completeWhen MyBehavior.subsumedchanges

　　ifMyBehavior.subsumed

　　{

　　    Clean_up_behavior；

　　}

事实上，这个语句的使用如此的频繁，以至于允许在一个行为的结束端使用多个completeWhen语句，来捕获不同的事件并且采取不同的动作。例如，如果希望对多个事件采取相同的动作，则可以让触发条件更加精细。

在转换之后，在一个实施例中，编译器可以生成使用条件语句来执行多个completeWhen语句的代码。在具有嵌套条件语句的例子中：

void MyBehaviorO：behavior

　　when TrigCondWhen

　　ifTrigCondIf

　　{

　　  Statement1；

　　  Statement2；

　　  Statement3；

　　}

　　completeWhen TrigCondCompletcWhen1

　　ifTrigCondCompletelf1

　　{

　　  C1Statement1；
				
				<dp n="d21"/>
　　  C1Statement2；

　　}

  complete When TrigCondCompleteWhen2

  ifTrigCondCompletelf1

  {

    C2Statement1；

    C2Statement2；

  }

这可以转换成具有相同效果的下列代码：

int MyBehaviorCompleteNow＝0；

    void MyBehaviorMustCompletel()：exhaustive behavior(&amp; highest priority)

    when TrigCondCompleteWhen1

    ifTrigCondCompletelf1

    {

         MyBehaviorCompleteNow＝1；

    }

　　void MyBehaviorMustCompletel()：exhaustive behavior(&amp; highest priority)

　　when TrigCondCompleteWhen2

　　ifTrigCondCompleteIf2

　　{

　　    MyBehaviorCompleteNow＝2；

　　}

　　voidMyBchavior()：behavior

　　when TrigCondWhen

　　ifTrigCondIf

　　{

　　  if not MyBehaviorMustComplete
				
				<dp n="d22"/>
　　  {

　　  Statement1；

　　  if not MyBehaviorMustComplete

　　        {

　　        Statement2；

　　        if not MyBehaviorMustComplete

　　        {

　　              Statement3；

　　        }

　　  }

　　}

　　if MyBehaviorMustComplete＝1

　　{

　　      C1Statement1；

　　      C1Statement2；

　　}

　　if MyBehaviorMustComplete＝2

　　{

　　     C2Statement1；

　　     C2Statement2；

　　}

　　  }

再次，通过引发事件而不是使用嵌套条件语句，可以获得类似的效果。编译器还可操作来更智能地检查以便减少需要执行的测试数量。

本领域的技术人员将注意到包含也可以同样地工作。通过使用“条件”语句，或者通过引发事件，立即终止包含的方法而没有实际上杀死该线程(后者引起更多的开销处理以及更大的复杂性)。上述转换示出，上面对于没有continueWhen和completeWhen语句的行为所讨论的运行时层次执行，也可以应用到具有这些语句的行为。

死锁检测

运行时层次方面——代理的移动性

团体

上面的说明集中在都相互知道的代理。然而，在本发明的一个实施例中，代理只知道存在于其“团体”内的代理。例如，团体可能与应用程序相同。因而，应用程序内的所有代理都可以相互知道。本领域的技术人员将注意到通常一般地将包括多个团体的应用程序考虑成是多个应用程序。

在一个实施例中，团体自身可以迁移。即，服务可以把自己复制到另一个计算机，并且可以远程地启动它自己。因此，该团体可以让它自己在另一个计算机上活动。而且，在这样的一个实施例中，代理可以在复制的团体之间迁移。特别地，代理可以生成发送给另一个团体的消息，该消息包括它的状态。例如，这类消息可以包括该代理的类型以及它的所有传感器的值。一个实施可以是将代理的传感器“脱水”成XML，并且把这个XML定义发送给复制的团体。在那里，可以创建新的代理，并且可以将该代理所有的传感器都设置成XML消息中接收的值(“使再变为水合物”)。然后，该新的代理可以在消息后把确认发送给第一代理，第一代理然后可以选择毁灭自己。替换地，如果该代理不毁灭它自己，则它已经简单地复制了它自己。

在一个实施例中，当在团体内在任何时候以及为了任何理由新创建代理时(例如还通过数据类型上活动的新运算符)，那么将对所有行为的触发条件都进行估值。取决于结果，将激活或不激活该行为。因此，相当可能的是，在团体中激活并且产生它的代理的迁移到新团体的行为，因为它的触发条件在新团体中还不满足，不会在新团体内立即激活。

网格计算

团体(在其它的处理器和机器上)产生它们自己的副本的能力可以允许它们利用网络中可用的所有经过授权的处理能力。因而，网格计算的多代理解释可以产生。例如，经过授权使用的所有附近的计算机都可以自动并动态地创建执行多代理系统的计算网格。因此，对于诸如游戏、物理计算、大规模银行计算以及其它按比例增大的应用程序之类的应用程序，多代理系统可以成长超过单个计算机的能力。

在类似团体之间的迁移

如果所有代理的定义都是同样的，则团体在结构上是同样的，并且团体都不具有与另一个相关的附加代理。传感器的签名是该传感器的名称以及它的类型。因而，如果代理A具有相同的名称并且代理A的所有传感器具有带有与代理B中相同的签名的传感器，则认为代理A类似于代理B。而且，如果团体C1的一部分代理类似于C2中的代理，则团体C1类似于团体C2。然而，不是C1的所有代理都需要类似于C2中的代理。

在一个实施例中，代理可以在类似的团体之间迁移。特别地，代理可以生成发送给另一个团体的消息，该消息包括它的状态。例如，它的状态可以包括代理名称，以及对于该代理的每个传感器，该传感器的签名及其值。可以将这个信息组合到数据包中(例如，在XML定义中)并用复制请求发送到另一个团体。在进行接收的团体中，查看代理的指定的名称。执行检查来确定该代理是否是类似的。如果该代理不是类似的，则将那个意义的消息送回并且不采取进一步的动作。如果该代理是类似的，则将肯定确认发送回发送团体并且在接收团体中创建新的代理实例。将对于传感器的所有接收值都分配给该代理。代理的创建，以及传感器的更新将通过进行接收的团体发送大量事件。

代理怎样开始迁移

每个团体都是服务或者具有接口。例如，接口可以接收诸如ACL(代理通信语言)消息或XML消息之类的消息。在一个实施例中，RIDL利用XML环球网服务以在团体之间建立通信。每个团体都具有通常由URL来表示的唯一ID。

希望迁移的代理必须知道它要迁移到那儿的团体的ID。在一个实施例中，两个特殊函数是每个代理的预定义的方法：“int copyToCommunity(ID)″，其中，将上述的请求复制的数据包发送给具有指定ID的团体，并且该函数的返回码包括成功指示(0＝复制成功)；和“int migrateToCommunity(ID)”，其中，首先执行copyToCommunity，并且只要成功，就消除被复制的代理。如果代理迁移它自己，则可能是它不执行在迁移指令之后的那行。如果迁移没有成功，将执行下一行，来允许代理基于返回值来诊断。再一次，实施的语法可以变化。

在一个实施例中，开发者只须知道类似团体的ID，并且无须知道通信协议、环球网服务、ACL或任何其它的技术。因而，每当创建代理时，它就具有复制和在类似团体之间迁移的能力，而无须开发者做出任何工作。在一个实施例中，将这个功能包括在每个代理上都可用的方法中。替换地，这个功能可以由包括函数“int copyToCommunity(AgentType，ID)”和“intmigrateToCommuniry(AgentType，ID)”的库来提供。

因而，迁移对于语言是与生俱来的，或者在每个代理预定义的方法中，或者在连同语言一起发布的程序库中。通过改变团体开始的方式，开发者可以相当容易地用相同的源代码来创建“主要”和“次要”团体，其中，主要团体在某种自展(bootstrap)中创建自己的代理，而次要团体类似于主要团体，但是它们不包含代理并且安装在网络上的远程终端上，等待接收复制或迁移到它们那儿的代理。在一个实施例中，通过分析构造符并且除去创建初始代理的任何语句，可以将任何主要团体自动地转化为次要团体。在一个应用程序例子中，游戏开发者可以提供一个运行时引擎，其可以安装在局域网的PC上以便利用那些PC的能力而无须写附加码。

寻找具有类似代理的团体

在一个实施例中，通过使用在ACL和XML环球网服务的定义内已存在的基础结构，代理可以获得它希望迁移到那儿的团体的ID。另外，代理可以寻找计算机或网络上所有可用的团体或者包括类似代理的团体。一般而言，假定在那里存在团体时代理感兴趣的情况下，它知道它希望对话的代理的类型。例如，可以提供询问来在附近寻找包括指定代理的所有团体。指定的代理可能是代理本身或另一个代理。查找可以是对于类似的代理以及对于在结构上同样的代理。替换地，可以提供询问来确定有多少指定代理签名的代理的实例存在于团体中。

在一个实施例中，可能希望允许设计师使用这类功能而不必要知道它后边的协议。例如，每个代理都可以包括以下格式的预定义方法：

communityCollection findCommunities(StructuralIdentical：bool＝false)

其中，communityCollection类型是communityCollectionItem的集合，而communityCollectionItem是具有两个部分的结构：集合ID、以及已经存在的代理的实例的数量。参数“StructuralIndentical”可以指出是寻找结构上相同的代理(真)还是寻找类似的代理(假)，其中，缺省值是寻找类似的代理。再次，这个功能也可以是与语言一起发布的的库的一部分，其中，如下所示的函数是可用的：communityCollection findCommunities(AgentType：agent；StructuralIdentical：bool＝false)

本领域的技术人员将注意到通过用许多方式来改变语法可以获得相同的函数。

跨团体工作的代理

在一个实施例中，代理可以自动地迁移到具有较少特定类型的代理或者具有更多剩余CPU能力的团体。然而，“任何”运算符是依赖于团体的，并且不会选取其它团体中的代理。例如，在多用户视频游戏中，用户具有1,000个士兵的军队，并且每个士兵都由具有复杂的战斗和心理学行为的代理来表示。而且，另一个相对更强大的计算机是当地网络的一部分。如果该用户可以在游戏中使用那个机器，则计算能力可用于更庞大的军队并且该用户将在游戏中具有更大的能力。因而，次要团体可以用来接收补充的士兵。然而，在次要团体中并且通过任何运算符对它们的环境做出响应的士兵不再能看见主要团体中的其它代理。

上面的不同实施例对这个问题提供了解决方案。整个模型通过由传感器和行为产生的事件来推动。代理的状态主要存储在传感器的值中。为了让代理在团体之间互相响应，需要用存根来保持传感器。因而，可能希望在保留决定哪些代理可以移出到其它机器而哪些不可以的自由的同时，让这些存根由系统自动地创建。

为了达成这个目标，可以用关键字或属性将代理注释为“autoMigrate”。例如：

void MyBchavior()：autoMigrate behavior

在一个实施例中，对于所有的autoMigrate行为，编译器还可以在包括所有传感器但是没有行为的主要团体中创建第二“存根”代理。如下所述的，这个存根代理稍后将负责传送传感器。在次要团体中，autoMigrate代理的完全定义，以及autoMigrate代理依赖的每个代理的存根代理将是可用的。

当autoMigrate代理被激活时，它像普通的代理那样工作并且可以监视用于该代理的“执行列表”。在一个实施例中，如在上面的自动优先级检测的章节中所述的，执行列表是需要执行并且按照优先级排序的行为的列表。

例如，如果行为列表变得比值‘X’ 更长，则可以选择autoMigrate代理用于迁移，其中，‘X’是可以由设计师来配置的参数。因此，使用事件模型和得到的优先级检测作为处理器活动的测量，其中，只要存在足够的处理能力，autoMigrate代理就可以停留在计算机上。

为了选择用于迁移的autoMigrate代理，可以使用几个标准。例如，可以选择依赖最小数量的外部传感器的autoMigrate代理。在这种情况下，可以选择用于迁移的autoMigrate代理的次序可以在编译时间确定。另一个选择方法可以是使用被最频繁地激活的autoMigrate代理，以减少驻留的计算机的工作负荷。又一个方法可以是选择在执行列表上具有最大数量的行为的autoMigrate代理，或者选择随机的autoMigrate代理或另一个方法。

在一个实施例中，在主要团体中，每当在autoMigrate代理依赖的代理中更新传感器的时候，将对于该传感器的值更新就发送给次要团体，在那里它更新用于这个代理的存根。同样，在次要团体中，每当更新迁移的代理的传感器时，就将该传感器的相关值发送回主要代理，在那里，它更新用于迁移的代理的存根。因为我们要更新传感器，所以这将再造次要团体中存在的事件。从使用代理的观点看来，编译器将保证由存根创建的事件与由初始代理创建的事件一致。

在一个实施例中，团体之间的信息传输可以用XML包来完成。例如，可以添加系统定义的行为，其对该代理的事件做出响应，并且可以向其它团体中的存根代理发送信息。代理可以或者向(具有已知ID的)其它团体发送存根的名称，或者直接向该存根的传感器发送唯一的ID(指针)。

在设计时间，可以指定类别为autoMigrating。然而，迁移的是单独实例。因而，每个代理都将自己决定它迁移的时间。因此，autoMigrate代理的一些实例可以迁移，而同一代理类别的其它实例可以不迁移。

在一个实施例中，对于单个主要团体来说可能存在多个次要团体。在每次迁移时，可以用类似于上面的关于寻找具有类似代理的章节中描述的方法来选择团体，然而，在这种情况下，标准将是寻找具有在结构上相同的代理的团体。

迁移代理的安全性问题

在一个实施例中，在XML环球网服务的安全性层次(或ACL层次)解决了安全性问题。例如，关于服务使用的安全措施应该防止代理迁移到它们不具有授权的团体。

调试层次方面

调试行为

多代理系统是很难调试的，因为它们具有太多的并行行为。运行时的错误可能由于竞争条件以及非常难于再造的事件共同发生而产生。因为副作用使系统的并发特性的再造不完全，通过代码的“分步”几乎没有意义。在代理之间调试的时候传统的调试方法失效。因此，代理设计者应该保证代理对于外部错误尽可能鲁棒。

因而，通过按照代理、行为以及触发条件而不是按照例如方法和顺序代、码来推论，可以为了设计者的利益而利用上面列出的特征。

在一个实施例中，关键字或属性可以指出一个行为是“调试”行为，比如：

void MyBehavior()：debug behavior

when TrigCondWhen

ifTrigCondIf

{

//statements

}

在这样的一个实施例中，可以不同于普通行为地处理调试行为。例如，可以只在“调试”模式中编译调试行为。在“释放”模式中可以自动地除去这些行为。在另一个例子中，调试行为可以具有最高优先级。在一个实施例中，设计者可以使调试行为主体内的语句减到最少，其中，这类行为具有空的主体，因此只有该行为的触发被监视。在另一个例子中，调试行为可以没有continueWhen或completeWhen语句并且可以不被包含或恢复。一般而言，调试行为不会参与代理系统的活动。它将只观察(并且有时记录)活动。

在另一个例子中，在调试模式中，每个行为都可以包括能够使系统“冻结”的逻辑。冻结将停止所有行为以便允许分析动态系统的“快照(snapshot)”。在另一个例子中，调试行为可以在“零执行时间”运行，其中，当一个调试行为被激活时，它冻结系统，然后再一切保持冻结的时候执行主体。系统在调试行为完成的时候解冻。这允许调试行为在运行时间中的特殊点上运行检查，和/或由此更新日志。

处理例外

例外包括在运行时间执行的非法操作。这类动作包括空指针的使用、被零除、以及许多其它的问题。这些问题可能在触发条件估值以及执行主体的时候发生。

在传统的语言中，引发在行为的末端被捕获的错误事件。如果该事件没有被捕获，则该事件被向外传播，直到最终整个系统可能崩溃。根据本发明，在一个实施例中，可以将一个预定义的标量属性“例外”与行为相关联。如同被包含属性，例外属性是一个真的传感器。当它改变时，它将引发事件。例如，设计者可以使用completeWhen语句来在例外发生的时候捕获并且处理它们。在一个实施例中，如果行为不处理它的例外，则该行为立即完成。因而，该例外不被传播并且系统继续工作。

因为例外可以是真的传感器，所以该代理中任何其它的行为可能对它做出响应。因此，该代理中的另一个行为可以专用于处理该代理中发生的例外。

矩阵分析器

在一个实施例中，“矩阵分析器”可以在代理正在执行的时候监视它们。例如，如同电子设备中的分析器，它可以不断地示出所有相关参数的值并且用不同的查看格式来展示数据。

例如，一个查看可能示出在调试模式中的计算机上发现的团体(否则矩阵分析器不能看见它们)。另一个查看可以示出具有它所有的传感器和行为的单个代理。例如，对于每个传感器，可以示出一个值。对于行为，代码状态可以用颜色来示出，例如：黑色可以意指该代码当前不活动；绿色可以意指该代码正在执行；橙色可以意指该代码正在等待执行；而红色可以意指该代码在执行期间出现错误。

另一个查看可以把每个代理表示为单个块或者点，其中，颜色可以指出该代理的状态，例如：如果该代理的任何一部分代码在执行期间出现错误，则该代理可能是红色的；如果该代理不是红色的并且任何行为正在等待执行，则该代理可能是橙色的；如果该代理不是红色或橙色，并且任何行为是活动的，则该代理可能是绿色；并且对于“非上面任何一种”的条件，该代理可以是黑色。在一个实施例中，可以将这个查看表示为矩阵。例如，1600×1200像素的屏幕可以示出最多192万个代理的活动。而且，可以突出特定的像素以允许为特定的代理选择二级视图，例如，可以用来进行更详细的分析。

IDE层次方面

代理视图

在另一个实施例中，可以定义视觉代理设计者来可视地监视代理。因而，在这样的视觉建模者中可能存在大量的视图。例如，在一个视图中，开发者可以用类似于UML的方式看见该代理。替代于面向对象的(OO)建模中的变量或方法之前的单个指示符，可以存在两个指示符，其中，第一指示符与OO的相同，以指出方法、行为、变量或传感器是否是私有的、公共的或友好的(friend)，而第二指示符示出它是方法还是行为，以及它是变量还是传感器。第二指示符本质上指出它是代理概念(传感器或行为)还是对象概念(变量或方法)。

行为视图

在行为视图中，传感器和行为在它们所属的代理之外示出。它们由代理的名称来注释，但是同一代理的传感器和行为不需要示出在相同的附近。实际上，将行为和传感器根据依赖性扩展出去，许可传感器和行为显示在底部(或者在顶端、或者从左至右、或者从右到左，这都根据用户的偏好)。在一个实施例中，传感器和行为用示出了那些项之间的依赖性的箭头连接在一起。

依赖性视图

基于RIDL的概念，可以定义依赖性图表。在一个实施例中，这个图表可以以可选择的方式来显示。例如，可以将代理显示给用户(如同在代理视图那样)并且可以在代理之间画出箭头以示出依赖性(本领域的技术人员将注意到确切的优先级在运行时间可能变化并且不能静态地示出)。替换地，代理可以在行为视图中示出，并且可以再次在行为和传感器之间画出箭头以示出依赖性。

团体视图

在另一个实施例中，类似于上面的调试层次方面，团体视图可以在运行时间示出代理。

学习代理：神经代理——方面

在人工神经网络(ANN)中，神经元是数学公式。它们提供了表示它们的触发值的数量。往往用阈值来只创建作为触发值的0或1。神经元中的公式基于通常作为较低层次处的所有节点之和计算的值，其中，将每个节点都乘以专用的乘法值。在离散ANN的情况下，权值必须在0和1之间。通过改变单独的权值，并且通过将神经元置于层上，系统可以通过教导而学会处理复杂数据(比如识别图像上的对象)。

在RIDL中，可以略微改变地使用神经网络的概念。在一个实施例中，神经元由代理来表示。它的触发值是传感器并且它具有对来自于较低层中的触发值的事件做出响应的行为以重新计算它的触发值。最后结果是使用ANN的概念、RIDL软件可以学会非常复杂的任务而不用对解答编程(因而通过训练)。

为了创建代理的层，可以利用不同的原则。例如，可以用继承来将单个层的所有代理置于单个类别名称下。替换地，每个代理都可以具有它所在层的号码，并且这个号码可以是检查条件中的一个。

在一个方面中，在RIDL中不存在“对于全部(for all)”结构。一般地，不可能访问所有的代理，因为可能在这样的动作当中创建或毁灭代理。因此，由代理自己决定来保持它连接到的代理的列表。可以穿过这样的列表。例如，可以通过使用“任何”运算符将该列表一直保持最新(例如，如果我所监视的层内存在任何代理，因为认为它不在我的列表中，则将其添加到列表)。

自写学习代理：软件的遗传进化——方面

介绍

简单而言，遗传的编程在两个原则上工作：突变导致小的随机变化；交叉适应父辈，并且通过采用一个父辈的某些部分、以及另一个父辈的某些部分来创建单个子辈。

基于不同的应用程序相关的参数，可以确定代理的成功因子。允许最成功的代理“繁殖”，并且使用上面的两个原则创建后代。变化存在，其中，如果大量的父辈极其成功，则它们没有变化地移动到下一代。再次测量新一代的成功，并且新一代又可以繁殖来创建又一个代。一般而言，尽管代理的预期寿命有时可能是多代，对于每一代上一代死亡。正如所看到的，遗传的编程提供了允许软件自动进化成更有效率的软件的方式。

作为DNA突变基础的触发条件

如上所述的，基于行为的多代理系统可以用于遗传的编程。它们提供了代理之间的差别，行为在代理内形成了功能的离散块。这提供了可以指引突变和交叉运算符变得比盲目的源代码修改更有效的信息。

在一个实施例中，遗传的编程假定了大量的代理类别，并且每个代理类别只有一个实例。因此，每个代理都是单独并且唯一的。当应用突变或交叉时，除非另有说明，使用其中一个父辈的主体。代理的原始群体或者包括具有包含学习代码的主体的行为(例如神经代理)，或者包括采用所有种类的小动作的许多行为。

在一个实施例中，突变运算符对一个代理的一个行为工作。在一个方面中，定义大量的突变运算符，其用特定于应用程序的频率在该群体上随机地工作，例如：(a)行为中发生的传感器(通常在触发条件中)的名称由另一个存在的传感器的名称替代。不断地做出这个替换，因此所有的发生都被替换以便将软件的逻辑保持原样。传感器只可以由同一类型的传感器来替代。(b)触发条件中在行为中发生的行为的名称由另一个存在的行为的名称替换。(c)如果在触发条件的时间部分提及一个传感器，则等待同一传感器的不同的事件。因此，可以或者在“sensor.changes”中，或者在“sensor.event”中改变“sensor.updates”。(d)如果在触发条件的时间部分提及一个行为，则等待同一行为的不同事件。因此，可以在其它中间的或者“behavior.completes”或者“behavior.event”中改变“behavior.activates”。(e)可以丢弃触发条件的“时间”部分的事件。(f)可以丢弃触发条件的“条件”部分的条件。(g)可以添加关于触发条件的“时间”部分中已存在的任何传感器的附加条件。(h)可以将存在的行为或传感器的附加事件添加到触发条件的“时间”部分。(i)可以在代理中创建新的传感器，并且将传感器添加到该行为的时间条件。对这个传感器的更新可以来自于首先指定的突变。该传感器根据某种可能性是公共的或专用的。

代理层次交叉

在一个实施例中，例如，采用来自于一个代理的大量行为和来自于另一个代理的大量行为，可以从两个代理中构造一个新的代理。将这些行为集成到新的代理中。除了不在任何这些行为中使用的局部传感器之外，将两个行为的所有本地传感器都复制到新的代理。

基本的行为层次交叉

这个交叉以两个行为工作。可以通过把两个行为的触发条件的部分副本合并成一个新的触发条件而创建一个新的行为。在一个实施例中，新行为的主体从两个父辈的一个中取出。不触碰主体之内的代码，使算法保持原样。如果被复制的父辈具有“completeWhen”子句，则可以同一地复制该子句。这保证了保留与该算法相关联的错误处理。传感器名称上的突变还适用于completeWhen子句。

顺序的行为层次交叉

另一个交叉运算符可以让两个父辈有顺序。在一个实施例中，这个交叉运算符采用一个父辈，并且在该父辈的主体的末端，它放置具有第二父辈的触发条件的“continueWhen”语句。然后，它添加第二父辈的主体。然后，附加两个父辈的全部“completeWhen”子句。

顺序的行为层次突变

当行为具有“continueWhen”语句时，删除从主体的开头开始，或者从“continueWhen”语句开始，直到下一个“continueWhen”语句或者直到主体的结尾的代码。

可以使用其它的运算符。关键在于RIDL的触发条件和语法允许算法定义在那里它可以安全地把代码粘贴在一起的清楚的点，而不会从语法和语义层次引起软件突变。

活动中的延伸的团体

使用类似团体的概念来使多代理系统的遗传的编程成为可能。

在一个实施例中，因为开发者给遗传的程序提供了源代码的代表，遗传的程序可以访问它自己的源代码。遗传的程序对源代码做出改变，并且重新编译该代码。当这样做的时候，对于遗传的程序利用继承性是有用的。

在编译之后，启动这个新的程序，并且由此创建了新的团体。这个团体通常类似于原始的团体。因为使用了继承性，旧团体的代理类别基本上保持原样，但是已经创建了新的后代。

接下来，使得所有的代理都迁移到新的团体。在这发生之后，旧的团体被摧毁。最后结果是我们的代理仍然是相同的，但是现在处于它们需要与它们的后代竞争的环境中。

代理文件系统方面

当文件系统基于数据库时，如同通常这样，例如，在一个微软_视窗的当前版本中，于是可以用面向代理的数据库原则来向文件分配行为。例如，文件可以监视它自己并且决定它是否需要备份它自己，或者修复它自己，或者通知用户某些条件，或者用其它方法来自我管理。这将有利地使PC维护的负担远离用户。

虽然已经按照可仿效的实施例描述了本发明，但是它不限制在那里。实际上，应该宽广地解释附加的权利要求来包含本发明的其它变型和实施例，它们可以在不脱离本发明的等价物的范围的前提下由本领域的技术人员做出。

Claims

1.具有计算机可执行部分的计算机可读介质，计算机可执行部分包括：

至少一个代理，具有至少一个包含目标或改变方法部分的传感器部分和至少一个行为部分；

其中，至少一个传感器部分至少部分地基于至少一个从目标或改变方法部分产生的值来产生至少一个事件，并且至少一个行为部分至少部分地基于来自至少一个传感器部分的至少一个产生的事件来确定是否要激活执行的线程。

2.根据权利要求1所述的计算机可读介质，其中，至少一个行为部分确定是否记录至少一个产生的事件。

3.根据权利要求1所述的计算机可读介质，其中，至少一个事件是改变或更新事件中的一个。

4.根据权利要求1所述的计算机可读介质，其中，至少一个行为部分在至少一个事件产生传感器部分的代理之外。

5.根据权利要求1所述的计算机可读介质，其中，至少一个行为部分的激活包括产生至少一个调用。

6.根据权利要求5所述的计算机可读介质，其中，至少一个传感器部分可以由它的目标或改变方法部分来激活，以至少部分地基于至少一个调用来产生至少一个事件。

7.根据权利要求6所述的计算机可读介质，其中，将至少一个传感器部分包括在至少一个调用产生行为部分的代理之外的代理中。

8.根据权利要求1所述的计算机可读介质，其中，行为部分能够至少部分地基于来自至少一个传感器部分的至少一个产生的事件来包含或恢复至少一个其它的行为部分或代理。

9.根据权利要求1所述的计算机可读介质，其中，只要执行的线程激活，至少一个行为部分就产生状态事件，该状态事件能够由至少一个其它的行为部分接收。

10.根据权利要求1所述的计算机可读介质，其中，只要执行的线程完成，至少一个行为部分就产生状态事件，该状态事件能够由至少一个其它的行为部分接收。

11.根据权利要求1所述的计算机可读介质，其中，至少一个行为部分基于独立的触发条件来确定是否激活执行的线程。

12.根据权利要求11所述的计算机可读介质，其中，独立的触发条件还能够对于特定的执行的线程的激活确定优先级状态，并且其中，能够基于多个执行的线程的激活优先级状态而顺序地执行它们。

13.根据权利要求12所述的计算机可读介质，其中，至少一个行为部分内部或外部的ContinueWhen、resumeWhen和complete When语句中的至少一个可操作来基于执行的线程的激活优先级状态来同步它们。

14.根据权利要求11所述的计算机可读介质，其中，独立的触发条件包括至少一个时间语句和至少一个条件语句，其中，时间语句指出独立的触发条件所响应的事件变成活动的，而条件语句是基于预先确定的过滤值。

15.根据权利要求11所述的计算机可读介质，其中，独立的触发条件要求多个产生的事件变成活动的。

16.根据权利要求11所述的计算机可读介质，其中，独立的触发条件是基于至少一个行为部分的本地感知。

17.根据权利要求14所述的计算机可读介质，其中，至少一个行为部分在独立的触发条件再次变成活动的之前，对于活动的独立的触发条件激活执行的线程。

18.根据权利要求1所述的计算机可读介质，其中，对至少一个行为和传感器部分定义至少一个关键字，其中，至少一个关键字指出特定代理、至少一个行为或传感器以及用于激活独立的触发条件的特定事件中的至少一个。

19.根据权利要求18所述的计算机可读介质，其中，至少一个关键字可操作来指出至少一个代理所不知道的，行为或传感器部分、代理或事件中的任意一个。

20.根据权利要求18所述的计算机可读介质，其中，至少一个关键字可操作来指出预先确定的代理类别。

21.根据权利要求20所述的计算机可读介质，其中，至少一个关键字能够指出预先确定的代理类别内的特定代理。

22.根据权利要求18所述的计算机可读介质，其中，至少一个关键字可操作来指出特定的行为或传感器的可以激活的时间。

23.根据权利要求1所述的计算机可读介质，其中，至少一个代理能够产生事件。

24.在计算机可读介质上实现的计算机程序，用于实现基于行为的多代理计算系统，包括：

用于接收请求的代码段；和

执行框架，包括：

多个具有至少一个传感器部分的代理，包括至少一个目标或改变方法部分，和至少一个常规的，详尽的或冗余的行为部分；

其中，至少一个目标或改变方法部分产生至少一个值，至少一个传感器部分至少部分地基于来自至少一个目标或改变方法部分的至少一个产生的值来产生至少一个事件，并且至少一个行为部分至少部分地基于来自至少一个传感器部分的至少一个产生的事件来确定是否要激活执行的线程。

25.在计算机可读介质上实现的计算机程序，用于实现权利要求24的基于行为的多代理计算系统，其中，从至少一个代理接收请求。

26.在计算机可读介质上实现的计算机程序，用于实现权利要求24的基于行为的多代理计算系统，其中，执行框架在面向对象的语言结构上分层来变成面向代理的语言结构，其中，对象和代理在面向代理的语言结构内是能够互换的部分。

27.在计算机可读介质上实现的计算机程序，用于实现权利要求26的基于行为的多代理计算系统，其中，面向代理的语言结构包括基于面向对象的语言结构。

28.在计算机可读介质上实现的计算机程序，用于实现权利要求26的基于行为的多代理计算系统，其中，代理形成能够复制的代理的团体。

29.在计算机可读介质上实现的计算机程序，用于实现权利要求28的基于行为的多代理计算系统，其中，代理包括能够在复制的团体之间迁移的代理的团体。

30.在计算机可读介质上实现的计算机程序，用于实现权利要求29的基于行为的多代理计算系统，其中，代理可以通过知道目标团体识别参数在团体之间迁移。

31.在计算机可读介质上实现的计算机程序，用于实现权利要求29的基于行为的多代理计算系统，其中，代理可以搜索目标团体。

32.在计算机可读介质上实现的计算机程序，用于实现权利要求26的基于行为的多代理计算系统，其中，分层的系统允许通过代理团体繁殖它们自己以在网格计算中工作。

33.在计算机可读介质上实现的计算机程序，用于实现权利要求26的基于行为的多代理计算系统，其中，代理能够通过使用至少一个存根在团体之间活动，其中，存根能够保持至少一个传感器并且是自动地产生的。

34.在计算机可读介质上实现的计算机程序，用于实现权利要求26的基于行为的多代理计算系统，其中，那些代理变成能够集合在一起来实现服务的名称空间的一部分。

35.在计算机可读介质上实现的计算机程序，用于实现权利要求26的基于行为的多代理计算系统，其中，服务可以由注释名称空间的关键字或属性来指出。

36.在计算机可读介质上实现的计算机程序，用于实现权利要求26的基于行为的多代理计算系统，其中，至少一个代理可操作来代表神经网络的神经元，至少一个代理具有至少一个触发值作为至少一个传感器，并且至少一个行为部分可操作来对来自于至少一个较低层中的至少一个触发值的至少一个事件做出响应。

37.在计算机可读介质上实现的计算机程序，用于实现权利要求26的基于行为的多代理计算系统，其中，至少一个代理利用至少一个行为中的至少一个突变或交叉运算符来实现至少一个自写学习代理，从而允许计算机程序自动地发展。

38.在计算机可读介质上实现的计算机程序，用于实现权利要求26的基于行为的多代理计算系统，其中，将至少一个行为分配给至少一个文件来管理它自己。

39.面向代理的数据库，包括：

包括至少一个代理的多个区段；

至少一个代理具有至少一个包括目标或方法改变部分的传感器部分；

其中，至少一个传感器部分可操作来至少部分地基于来自于目标或方法改变部分的至少一个产生的值来产生至少一个事件。

40.根据权利要求39所述的数据库，其中，至少一个代理包括行为部分。