1.2 Agent的开发抽象

近些年，人们已经提出了很多有关Agent的定义。有些定义侧重于Agent在用户界面中的应用，使图形界面具有一些典型的人性化特征，能够根据用户特征实现自适应变化。这种Agent同本书并没有什么直接的关联。有些定义阐述了Agent有能力同其他各方进行交互，或者同某些特定技术紧密相关，例如基于定理证明器，或者使用思维概念中的数据结构；又如信念、知识、目标、期望、意图等。这些定义的局限性在于考虑Agent的内部结构过多，限制了它们的通用性，即运用于开放环境的可能性。还有一些定义先假定Agent具有一定的理性，这可能会对Agent的自治性产生一些不合时宜的限制。

Wooldridge和Jennings描述了有关Agent的两种观点（Wooldridge和Jennings，1995a）：一个是弱概念，另一个是强概念。Agent的弱概念在主流计算中很流行，尤其是软件工程师。这种观点认为Agent类似于UNIX进程，具有自治、社交、反应和预动等属性。自治是指Agent在没有人为干预下的工作能力，可以控制它们自己的状态和行为。社会能力是指与其他Agent进行高层对话的通信能力。反应是指对外界变化做出及时的感知和响应。预动是指Agent选择本身的目标，并且依照目标进行动作的能力。相比之下，Agent的强概念在人工智能领域中很常见，认为Agent是一个计算机系统。除了具有上面提到的所有属性外，还可以被概念化或模型化，具有人类的特征，例如知识、信念、目的和义务等思维概念。

Agent技术近几年的发展努力使这项技术走向一个合理、务实的方向。几年前，Agent领域内部还在为Agent的定义争论不休。然而，当研究人员意识到不可能在Agent的定义上达成一致，或者说是不需要时，这场争论就变得悄无声息了。定义的关键在于“提出这样一个定义的目的”。如果这个目的是为了说明如何构造单个的Agent，那么定义Agent的内部设计就是合理的。然而，如果这个目的是想定义一个开放系统，保证不同的Agent都能够参与进去，那么重点就应该放在Agent之间的交互上，而不是如何去构建它们。按照上述想法，一个更为激进的立场是，不要为形式化的定义去烦恼，而应该关注如何去测试是否为Agent （Huhns和Singh，1999）。Huhns和Singh所提议的测试主要考虑了一个Agent如何同其他Agent进行交互，在其他Agent的影响下如何改变自身行为。这个定义是从外部特征来描述Agent，留下了一些不确定的事实，例如何构建一个Agent，Agent是否具有信念和意图，是否具有理性等。这样定义的Agent，可以用于开放环境中的各种实际计算，能够反映所代表参与者（在一个信息环境中）的自治性和异构性（在现实世界中）。

当开始强调交互时，我们的兴趣点很自然地就从单个Agent转移到了多Agent系统上来。这是一个合理的转变，因为事实上单个Agent系统并不是那么令人感兴趣。如果你一定要拥有Agent，那么就必须把它们作为多Agent系统（Multi-Agent System，MAS）的一部分。这么说的理由在于，如果没有交互性和开放性，那么，传统的计算机科学应该能够很好地满足你的要求。如果你不打算从Agent的特殊属性中受益，为什么要引入它们呢？

开放系统的挑战和Agent的潜在灵活性都表明Agent将为现实应用提供一个优秀的解决方案基础。当然，这个实践的整体意义是展示Agent如何匹配开放系统的要求。回顾一下上面所提到的，开放系统一般都是由自治、异构和动态的组件构成。从广义上讲，基于Agent的软件开发是能够充分挖掘Agent主要特征的技术与方法学。现在让我们考虑一下与Agent概念相关的关键抽象，研究如何把它们捕捉为计算抽象，并给出这么做的一个典型手段。通过下面的简要讨论，可以为后续章节打下基础。

1.自治性（Autonomy）

自治性也就是指一方具有独立性，能够根据自己的意愿来行动。从广义上讲，商务交易中参与者的自主决策就反映了自治性。没有人能够强迫你买卖任何东西；也没有人能够强迫你听命于另一方，或者与之妥协；更没有人能够强迫你使用某种特定的推理策略。特别地，一个自治个体甚至不需要任何外部意义下的“理智”，因为这样的要求会限制它的自治性。

如果某种方法能够使交互各方的自治性呈现出良好的效果，那么这种方法应该很容易适用于几乎所有的场合。值得注意的是，有些场合所呈现出的自治现象，真实情况或许并不是由于自治性，而是由其他一些原因引起的。例如，参与者没有对消息做出反应，可能并不是它做出的自治性反应，而是因为基础机制失效。当然，在相同的框架下，实现自治的参与者也可以自如地处理基础机制的变化。因此，判断某个行为是自治性的体现，还是由于基础机制的失效而引起的，这点可能很重要。

一般来说，不受约束的计算自治性就如同现实世界中不受约束的自治性一样，将会产生不可预期的结果。并且，为了给出完整的计算模型，或者做出可靠的预测，我们都必须假设参与者的自治性在某种程度上受到约束。典型地，根据协议进行交互就可以实现对自治性的限制。

2.异构性（Heterogeneity）

异构性源于设计者构建组件的方式相互独立，导致组件的信息模型或过程模型各不相同。一般来说，在功能系统中，异构性的产生是由于历史原因造成的。没有人开始就想设计一个异构系统，但是构建大型系统的最终结果往往是异构的。反之，在设定一个开放系统的参数时，不假定内部结构的同质性是非常重要的。最终，为了能够让这些组件一起运作，就要对它们之间的异构性施加一定的限制。也就是说，一定要有对共同性的说明。就信息模型而言，通过一个共享本体来捕捉共同性（Gruber，1991）；这是同Agent相关的，但是并不特指Agent，因为它的产生也是源于将异构信息源组合起来。就过程模型而言，可以通过确定典型外部事件的方法来捕捉共同性（Singh，2003）。这个思路是，Agent的行为标记是指对外界的响应结果，而不需要暴露内部的构造细节。这些标记具有被标准化的潜力，事实上是分布式数据库事务处理中两阶段提交协议所采用的方法（Gray和Reuter，1993）。任何按照特定标准实现的Agent，都被要求公布合适的特定事件，但并不需要暴露内部的实现细节。

3.动态性（Dynamism）

动态性是指管理者能够独立对系统进行灵活配置，并且可以根据需要改变其配置，而不需要明确通知相关各方（系统中的其他成员）。开放系统具有最大程度的动态性，因为原则上它们根本不需要管理者。事实上，它们出于特定目的可能会需要一些管理功能，如监测和安全、根据应用限制潜在的成员参与等。原则上，这些功能可以分布于成员之间，不需要管理者，但是出于社会政治原因，系统中经常需要有一方来负责。

Agent方法所倡导的动态配置技术有一些变种，已经被广泛使用，例如在UDDI中。然而，更深层次的挑战并不在于服务发现，也就是UDDI所强调的，而是在于如何从几个可能发现的服务中选择一个最合适的服务实现。一些与之最相关的Agent方法，在很大程度上还没有被吸收到商业方法中，包括如何进行匹配。工程化的Agent系统经常包含一个进行匹配的组件。有一些方法考虑基于Web服务的语义描述进行匹配（Trastour等，2001）。另一类方法主要是考虑所获得服务的质量，引入了服务质量的概念模型，并把它嵌入到了一个框架中，其中服务选择被看做是一个集成组件（Maximilien和Singh，2002）。还有一些方法则是改进传统的推荐系统，不仅可以处理产品选择，还能处理服务选择（Sreenath和Singh，2003）。

4.通信（Communications）

任何组件都可以通过它们所共享的环境进行交互。当一方对环境做出改变时，其他各方能够看得到。当采用Agent对组件进行概念化时，它们之间的交互呈现出一种不同的风格。很明显的，Agent能够通过环境进行持续交互：如果它们是机器人，可以采用彼此碰撞对方的方式；如果它们是信息Agent，可以通过修改文件或数据库来实现。然而，通过环境交互可能会影响交互各方的自治性，也就是说，各方除了交互之外没有其他选择。例如，机器人除了碰撞可能没有别的选择，而这种碰撞可能导致一方或双方打断原来的程序。类似的，一个信息Agent或许需要修改一些数据项来完成一项任务，另一个Agent或许需要读这个数据项，如果观察到数据项被修改，那么就需要特别注意这些被修改的值。

我们把通信定义为“保留参与各方自治性的交互”。通信并不要求采用计划或“信念—意图”结构来支持。从这个意义上讲，“通信”概念是基于自治的；如果交互能够保留相关各方的自治性，那么它就是符合要求的通信。很显然，一个给定环境中的碰撞和修改数据都可以作为传输信息的手段。在低层次上，通信是借助于某些物理手段来实现（也就是环境），如通过一个数据链路来发送数据包。但是，如果上升到各方都能够根据自己的意愿来进行通信（也就是发送数据和接收数据），那么就可以把通信看做是一个交互。

通信语言被很典型地划分为三个主要部分：传输层提供消息，在有限程度上是可靠的；内容层提供了表达相关领域细节的一个手段，与一个本体典型关联，在语言本身之外就被确定了；通信行为层确定了通信态度，如这个通信是否为断言、指令、许诺等。依靠这个理论，这组原语可能会发生变化，但是原语的数目一般很小（典型的是小于10）。虽然在何种情况下选择何种通信行为是很清楚的，但是希望参与者在任何情况下都做出正确的行为选择还是有些困难的。因此，就有了一个趋势，仅仅选择一个通信行为（通常这对应于断言一个事实的行为，被称为“断言”或“告知”），为它加载所有其他通信行为的含义。也有一些反对这种倾向的尝试，采用更为丰富的对话和论证模型，也取得了一定的成功（Pasquier和Chaib-draa，2003），但是这些还没有体现在核心的软件方法学中。

通信是最重要的一个Agent概念抽象。大家经常想当然地，把这个概念和底层的数据传输（这个仅仅属于通信机制）相混淆。通信语义的研究目前主要有两种方法，分别基于心理概念和社会概念，已经足以说明问题了。如上所述，心理概念主要处理Agent的内部结构，因此并不适用于开放环境。社会概念则有着更广泛的应用，文献（Singh，1998）对此进行了更为严格的论述。

5.协议（Ptotocols）

很难采用一种独立的方式对通信进行研究。当没有办法去查看通信Agent的内部结构时，对通信行为的组合进行标识可能是更简单和更为合适的选择。这些组合就是协议，也就是前面所暗示的“对于Agent行为所采取的限制”。简言之，协议阐述了一个Agent应该何时，以及如何同其他Agent进行通信。举一个简单的商业案例，一个Agent在受到询问时给出报价，在收到所订购物品时完成付款等。

计算机科学的其他分支也对协议进行了研究，尤其是在网络领域。例如，网络协议就限制了通信各方所能发送的消息和响应。这些协议定义了在各种情况下如何为需要通信的数据进行编码，如报头。严格的定义对于保证可靠的实现是非常重要的。然而，我们希望Agent的灵活性能够最大化（换言之，就是尽可能少的限制它们的自治性）。要兼容灵活性是非常有挑战性的，尤其是要确保Agent的行为能够正确符合一个协议的规定。

6.承诺（Commitments）

尽管传统的通信研究是基于心理概念的，而对协议的研究却是在社会概念的框架中形成的。我们这里就使用“承诺”这个典型的社会概念来实现目的（Singh，1999a）。虽然也可以定义别的概念，但是“承诺”对于实现当前目标已经足够了。“承诺”涉及债务人、债权人、条件或行为，以及上下文。基本含义就是债务人有义务帮助债权人实现所陈述的条件，或者执行所要求的行为；这些行为甚至经常被当成前提条件。给定的承诺可以在一定的上下文中获得，例如虚拟企业这样一个组织，或是供应链这样一个商业抽象。承诺可以通过以下手段进行操作，如委派（变更债务人）、转让（变更债权人）、取消（债务人违反承诺）、豁免（债权人豁免债务人）。像“取消”这一类操作，很明显是具有一定风险的。需要通过进一步的“元承诺”（用于定义基本层次承诺的操作环境）来限制它们。更重要的是，增加“元承诺”可以使我们为应用中的许多实际协议进行建模（Yolum和Singh，2002）。

关于承诺的早期研究工作假定：根据对所期望交互的理解，直接由设计者来决定所期望的承诺和元承诺。最近的工作已经产生了对于承诺更为精确的阐述，可以用做构建系统的基础。目前的时序逻辑方法中有可以表达承诺的语义，可以将“承诺的可重用交互模式”形式化（Fornara和Colombetti，2002）。这些模式可以用做设计多Agent系统的基础，并确保最终产生的交互具有某些属性。另一些工作则是基于对所期望交互的分析，考虑提出正确承诺的方法要素（Wan和Singh，2003），这体现了文献（Huhns等，2002）的精神，但目标却是针对承诺。