作者：薛霄
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
面向Agent的软件设计开发方法试读：
前言
Agent和多Agent系统（MAS）现在已成为一种应对各种复杂IT情景的强大技术，如生产过程、Web服务、基于Internet计算的市场和分布式网络管理等。然而，新近出现的理解认为，MAS不仅是一种有效的技术，还代表了一种新型的软件开发通用范型，即基于自主软件实体（Agent）的设计和开发应用。这种实体位于某个环境中，可以通过高层协议和语言的交互来灵活实现其目标。这些特点非常适合于解决现时情景下的复杂软件开发。事实上，① 自治的应用组件，反映了现代分布式系统内在的分散性，并且可视为系统被不同的利益相关者所拥有，在模块化和封装概念上进行了自然延伸；② Agent运行和交互（包括相互之间及Agent与环境之间）所采取的灵活方式，适应于现今软件在动态和不可预知的情况下运行；③ Agent的概念为人工智能的成果提供了一个统一的观点，通过使用Agent和MAS作为存放智能行为的、可靠的和易管理的知识库，从而利用人工智能的成果解决现实世界中的问题。
在过去几年中，基于Agent的计算被日益接受为一种新型的软件工程范型，已经有大量的研究是关于定义合适的模型、工具和技术，以支持开发复杂的MAS软件系统。这些研究，即面向Agent的软件工程（AOSE），不断地提出各种新的建模方法和技巧、新的设计方法和工具，尤其是新型的面向Agent的范型。
关于AOSE的科学论文在文献中出现得越来越多，遍布在不同的会议、期刊和新闻上。因此，无论是新人还是专家，在这个领域中进行研究时，在操作所有这些材料时总会有困难。本书试图将各种研究结果和建议有组织地综合在一起，虽然非常多样化，但都以促进MAS的开发为相同的总体目标。我们的希望就是，这本书能够为研究者和学生了解AOSE的发展现状提供线索，而不用在现有的数字图书馆中搜索数以千计的文件，也不会在无尽的搜索中迷失方向。
当然，我们需要清楚地认识到，AOSE的研究仍处于初级阶段。在AOSE被广泛接受，并且在MAS复杂软件系统研究中成为实际可用的范型之前，就必须面对所出现的挑战。出于这些原因，本书避免支持特定的技术或方法，而只是给读者介绍不同的设计方法和实现技术，给予他们更多的选择余地。本书的内容共分为五个部分：
● 第一部分（基于Agent的软件开发基础知识）是介绍性的，目的在于阐明为什么基于 Agent 是设计复杂软件系统的合适方法（比现有的传统方法优越），同时从不同层面对AOSE的研究现状进行调查。
● 第二部分（面向Agent的开发方法）阐述了三种经典的方法学（即Gaia、Tropos和MaSE），它们在过去几年中作为通用方法来指导开发复杂的 MAS，在研究者群体中具有巨大的影响；三种特殊的方法（即ADELFE，MESSAGE 和Prometheus），虽然影响力不大，但自身的有趣的特性使它们非常适合于MAS特殊类（如自适应的MAS和基于Agent的系统）的设计和特殊的应用领域（如电信应用和智能商场）。● 第三部分（改进面向Agent的软件开发方法）针对目前AO方法所面临的困境，提出了层次开发框架HDA，为将Agent技术变为复杂系统建模的有力工具提供了一种可行的途径。HDA能够基于现有的各种AO（Agent Oriented）元模型定制出符合特定项目需求的方法，并为设计模型的实现提供了一整套的方案，解决了设计模型同软件实现相脱节的问题。
● 第四部分（面向Agent的软件工程工具和基础设施）将焦点从方法学转换到基础设施和工具上。事实上，尽管方法学驱动着构建MAS的过程，但只有提供了适当的工具和软件基础设施，才能最终实现一个良好的工程化软件系统。概念性工具列出了FIPA标准和AUML，软件基础设施则介绍了截至目前可供开发者使用的、最有前途的工具JADE。
● 第五部分（新兴的趋势和前景）更具有应用导向的性质，集中在MAS技术未来的假定应用上，如信息服务和普适计算。在这些新出现的技术背景下，基于Agent的系统有可能得到广泛利用，为了促进开发的可靠性和有效性，对 AOSE 的技术的需求也可能会更迫切。在此基础上，给出了该领域的AOSE研究路线图。
在国家科技支撑计划重大项目课题“三峡库区枢纽港经济圈物流服务示范工程（2006BAH02A20）”、国家科技支撑计划重点项目课题“生殖健康公共服务架构设计与信息标准研制（2008BAH24B01）”和北京市自然科学基金项目“现代服务理论及其在现代物流服务业中的应用研究（4082017）”和河南理工大学博士基金课题“Agent软件理论与关键技术研究（648227）”的支持下，作者进行了有关Agent建模技术在现代信息服务中的应用研究和开发工作，取得了一些初步的成果，希望通过本书与广大科技人员和读者交流与共享，从而推动Agent技术的研究和实施。
首先我想强调，这本书凝聚了AOSE领域很多研究人员的努力成果，在这里感谢他们为AOSE的发展所作出的显著贡献。没有他们，我们将永远不会形成对该领域研究的宽广视野。另外，这里要特别感谢河南理工大学计算机学院的贾宗璞教授在百忙之中抽出时间审阅了全书，提出了很多有价值的修改意见，对于全书的形成至为重要。
另外，本书的完成还要感谢我的妻子王淑芳，她对本书所参阅的文献资料做了大量的整理工作；感谢河南理工大学计算机学院的研究生朱红磊、李慧琴、张亚婷、潘亚峰、王娟、杨玲、车平、张纯等，他们为本书的插图和校对进行了大量辛苦的工作；感谢河南理工大学智能科学实验室的同事刘小燕、马永强、罗军伟、侯艳芳、王志衡和李会军，他们为本书的写作提出了很多宝贵的建议。感谢山东科技大学的博士生李东民和湖北工业大学的研究生朱传鸿，清华大学CIMS工程中心实验室的朱鹏、王婷、刘志宇和李梦生，他们为本书的完稿提供了很多力所能及的帮助。最后，我真心感谢本书的编辑，是她付出的辛勤劳动，使得这本书能最终面世。
作者
河南理工大学
2008年10月第1章 面向Agent的软件开发抽象【本章概要】本章提供了必需的历史知识和基础概念，以帮助读者完整了解面向Agent的软件开发工具和技术。我们首先回顾了软件技术发展的历史（从独立系统到开放系统）；然后讨论了由于软件系统变得日益庞大和开放，这种不断增长的复杂性所带来的挑战。本章展示了为什么Agent技术抽象是开发大规模开放式系统的理想选择；与组件相比较，Agent抽象所具有的相似性和差异性；以及它们在软件实践中所得到的结果。【本章知识结构图】1.1 引言
最初的计算机研究是基于集中式架构的，很少考虑编程方面所遇到的挑战，但是在相关技术方面已经取得了很大进步，例如以健壮的、可重用的模式来设计数据结构和算法。虽然目前的企业级系统大多采取分布式的计算结构，但是所有的系统架构都是由组件构成，每个组件都必须以健壮的方式进行开发，所以已经提出的方法仍然是有价值的。
分布式系统技术能够使企业中相互隔离的信息组合起来，从而被更好地使用。但是，在克服了网络方面的低层次挑战之后，系统在向分布式迁移时面临着一个痛苦的事实：难以将目前所存在的各个信息孤岛连接起来以获取额外价值。这里的一个关键问题就是异构性，也就是说，在不同信息源中存储的信息会出现语义不匹配。最为常见的是，根本无法对语义进行建模，协调各种不同的资源十分困难，甚至是不可能的。处理上述各种异构设置的最佳方法，就是采用静态信息模型或数据库模式对各种不同的资源进行建模，然后将这些模型集成起来。模型集成在处理异构信息系统时很少起作用，因为任何单个模型的变化都会导致整个集成模式的失效。
我们这里所讨论的系统是开放的，因为它们反映了组织本身所具有的开放性。在开放环境中，组件模式不但是异构的，而且是自治的，可能会快速地改变，各个组件也没有被要求一定要进行合作。开放架构的特点是可以对自主异构的组件进行动态增加和删除。随着电子商务的普及，开放架构正在变得越来越普及，其中最经典的一个应用就是Web服务。
Web服务架构把每个组件看做一个服务，服务所提供的一系列能力被定义为方法（Curberaet等，2002a）。服务可以被调用，也可以交换文档。在Web服务中，被调用的参数、结果和交换的文档，都需要按照XML协议进行结构化（Box等，2000）。开放架构所面临的一个独特挑战就是对所需的组件进行发现和定位。在Web服务中，这一点通过“统一描述发现和集成标准（Universal Description Discovery and Integration，UDDI）”中的“注册”概念来实现。服务被它们的实现者和推广者发布为一个注册项。潜在的消费者（即寻求支持特定接口服务的人）就会尝试着联系注册项，以找到匹配的服务实现。注册项将会提供一个满足给定要求的所有服务实现列表。消费者能够选择其中的一个服务实现，把它作为自己的合适选择。Web服务架构能够对大型系统进行灵活动态的配置，正在快速成为构建大型系统的事实标准，但是它仍然有一些缺点。首先，没有对所要处理的信息和服务语义进行编码，匹配过程是依据语法条件进行处理。其次，在特定的环境中缺乏可信度和适用性的概念，这些问题被留给用户自己去解决。
就某种特定意义而言，“计算”所存在的基本商业和组织环境并没有随着现代技术的发展而改变。例如，在“计算”出现的几个世纪之前，就已经出现了供应链。即使从计算的角度出发，供应链也能同早期出现的计算系统相适应。从实际意义上讲，现代技术在很大程度上也影响了商业和组织。这种“一分为二”的观点可以通过下面这个例子来理解。以前供应链中存在着很多问题，早期的“计算”主要是帮助改善供应链的建造、运行和效率检测。但这些是比较死板的方法，有很多缺点，无法很好地把握机会和处理异常，这在很大程度上限制了它们在实际应用中的效率。进一步，人们期望能够通过改进计算和通信基础机制来获得下列属性：效率、灵活性、敏捷性和健壮性。
面对当前环境下的实际挑战，传统的计算机科学无法提供强有力的抽象和灵活的技术。这些问题要求采用一种更为宽广的视野来看待“计算”，不仅要坚持科学原则，还要考虑计算发生时所处的组织环境，理解用户的需求，即计算所服务的对象。换言之，真正的世界在某种意义上一直都是开放的，只是我们采用构建和管理过程的技术对它们施加了一定的限制。现在所需的就是引入一种技术来避免这些限制，这就是Agent出现的原因。Web服务的层次架构在许多方面都很自然地体现了Agent的重要特征。如果把Agent系统开发看做是Web服务的上层结构，对于探索它们的现有特征，改进Web服务架构都是很有价值的。值得注意的是，应该避免在Web服务中试图复制Agent的每一个思想，这样会使系统出现冗余，变得难以理解，尤其是对于大量的软件开发人员而言。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）的精神，但目标却是针对承诺。1.3 Agent的体系架构
除了1.2节所给出的Agent概念之外，还需要强调一种不同的观点。这种观点把Agent看做是软件系统的建模抽象，面向Agent的软件工程就是基于这种观点。在这里，Agent通常用于模拟现实中的实体，软件系统被看做是为了实现预期功能而相互作用的一系列Agent。Agent凭借自主性、预动性和/或反应性等一系列特征，为应用程序开发人员描绘了一种很有前景的方法。更一般的，这意味着复杂应用程序可以在动态环境中运行。
基于这种观点，可以把Agent体系架构看做是软件模块的详尽集合，用带箭头的方框来表示数据和模块之间的数据流控制。Agent体系架构可以分为慎思型、反应型和混合型。慎思型体系架构是最先出现的，其标志就是采用明确表示的世界符号模型，基于模式匹配的决策进程和符号操作技术。因此，体系架构需要解决的问题就是：如何把真实世界转换为符号，以及如何有效准确地描述决策进程。一般来说，解决这些问题需要大量的计算，这使得慎思型体系架构不适合解决许多实际问题。这里不会详尽地阐述这个问题，因为它们与传统人工智能有着更多的联系，而与Agent方法联系较少，有兴趣的读者可以参阅（Ghallab等，2004）。这些困难导致了新的（和特定Agent）架构相继出现，如反应型和混合型体系架构。
反应型体系架构涵盖了范围广泛的方法，一般可以避免任何以符号为核心的世界模型或复杂的符号推理。由于这一点，这种类型的Agent对于环境变化可能会反应更迅速。由于它们简单，或许正因如此，反应型体系架构不可能用于开发那些“行为强依赖于执行历史”或“具有复杂推理”的Agent。
混合型体系架构努力整合慎思型和反应型体系架构中好的一面，主要是通过包含两个（或者更多）独立的构件：一个是协商型，另一个是反应型。慎思型构件负责规划和推理行为，反应型构件处理需要快速响应的重要事件。不过，构件间的准确关系和它们之间的控制取决于各自的具体架构。
信念—期望—意图（Belief-Desire-Intension，BDI）体系架构（Haddadi等，1996；Wooldridge，1999b）是混合型体系架构的一个重要类型。BDI体系架构是Agent的表示形式，Agent的行为可以被描述成好像拥有信念、期望和意图等思维状态。信念表示Agent拥有的知识，期望描述Agent追求的目标，意图说明Agent选择计划以实现哪些目标。
BDI体系架构形成了一个共享BDI观点的体系架构族，但是信念、期望和意图在系统功能中被分配的角色，以及表示和控制它们的形式，各不相同。虽然信念已经被充分理解，但是期望和意图所扮演的角色却受到了争议。当期望和意图同时指Agent想要达到的一个事物状态时，就意图而言，必须有一定的承诺去实现它们。因此，虽然 Agent会有一些期望，但是它可能永远不会去开始完成这些任务；而意图却会引起Agent的一个行动。有几种理论试图通过描述信念、期望和意图之间的关系，来描述、分析和确定一个Agent的行为。这种理论背后的动机是多元化的，有一些理论旨在从观察者的角度（Ferguson，1995）来解释和预测Agent的行为，有一些则是用于设计Agent的体系架构（d’Inverno等，2004），还有的是用于支持从事集体活动的Agent进行推理（Jennings，1993）。
自从BDI体系架构出现以来，它们在Agent社区之中很流行，这主要是出于三个关键的理由：第一，基于意图概念对系统进行建模，对我们人类来说更加自然。第二，大部分BDI体系架构有一个基础良好的哲学和理论背景。第三，这些体系架构比纯粹的慎思型或反应型体系架构更灵活。作为混合型，BDI体系架构介于纯粹反应型和纯粹慎思型之间。因此，在高度变化的环境中运行时，它们不可能表现出和纯粹反应式系统一样的性能，但是可以根据特定的应用需求，通过调整推理和慎思策略来提升性能。
BDI体系架构不仅用于研究，还成功应用于商业领域和工业领域。例如，空中交通管理系统OASIS（Rao和Georgeff，1995），它的发展是基于一种BDI体系架构DMARS（d’Inverno等，2004），已经在悉尼机场测试成功。OASIS中的Agent分为两种类型：aircraft Agent和global Agent。每个aircraft Agent都同一架飞机相关联，并且控制该飞机的飞行。相比之下，global Agent负责aircraft Agent的先后顺序和协调工作。在运行期间，高达80个Agent并发运行，给控制器发出实时控制指令。
BDI体系架构的成功取决于以下方面：
● 应用程序编制是基于计划构建，方便于模块化和递增式的开发。
● 由系统来管理反应行为和面向目标行为之间的平衡，终端用户不需要参与复杂的低级语言编程，这改进了可靠性。
● 终端用户采用人类的思维状态来对知识进行编码，而不是低级语言。
迄今为止，已经提出了很多不同的体系架构，我们不可能在有限的篇幅里给出一个详尽彻底的回顾。因此，我们把回顾限定在一些具有代表性的体系架构上。在这个回顾中，我们不再讨论慎思型体系架构，因为它本质上和传统人工智能中的规划很相似，不是基于Agent计算的，回顾这种体系架构并不会增加本书的内容。
1.包容性体系架构
包容性体系架构（Brooks，1986）是Brooks对反应型体系架构的改进，其功能是基于行为存在和它们的抑制关系。每个行为都计划完成一个明确的任务，并且将感知到的输入和行为联系在一起。例如，交通控制应用程序有这样一个行为“如果发现前方有一个障碍，就改变方向”；把感知输入“前方有障碍”和任务“改变方向”联系在了一起。为了追求其目标，每个行为不断地检测环境状态，直到环境状态与感知输入相匹配，然后执行这种情况下的相关行为。在这个例子中，不断地检测环境，直到发现交通工具前的障碍，然后执行改变行为的指令。然而一个环境状态可能会匹配多个行为，因此采用抑制关系来指明优先权。根据这一抑制关系，行为被分为不同的层次，低层行为可以抑制高层行为，层次越高行为就越抽象（如图1.1所示，说明了感知输入、行为和动作之间的关系，虚线表示抑制关系）。图1.1 包容性体系结构
例如，在交通工具的控制中，“避免碰撞”比“到达目的地”所处的空间层次更低，因为“避免障碍”的优先级高于“到达目的地”的优先级。
2.PRS
PRS（Procedural Reasoning System）（Georgeff等，1987）最初作为NASA工程的一部分被开发，具有良好的理论背景。在PRS中，信念、期望和意图被明确地描述，并且一起决定系统的行为。它们还会随着推理机制动态改变。如图1.2所示，PRS由解释程序和几个模块构成，模块包括数据库、目标栈、知识区域库和意图结构。数据库包含关于当前世界的事实，知识区域库所包含的知识区域（Knowledge Area，KA）分别是“如何完成任务的知识”和“如何在特定环境下做出反应的知识”。
KA由一个主体和调用条件组成。主体包含程序步骤，调用条件表明在什么情况下KA是可用的。KA库中的某些KA是针对特定应用的，而另一些则定位于PRS本身的通用管理，例如针对相关KA进行选择的策略。
与其他BDI体系架构相比较，在PRS中，目标代表了系统所期望的行为，而不是所要达到的静止状态。它们不仅在目标栈中被表示，还作为KA的一部分。意图是系统选择立即执行或将来执行的任务，由一个初始KA和完成任务过程中所调用的其他一些子任务构成。这样的意图被插入到意图结构中，意图结构实质上就是一个带优先权的列表。图1.2 PRS架构的主要组件
为了简要起见，这里不再详细阐述PRS的操作细节。简言之，系统运行中的解释程序控制过程如下：在一个给定的时间，系统具有某些目标且持有某些信念，根据这些，某些KA变得可用，其中一个KA被选择执行且被置于意图结构中。当执行这个KA时，会产生一些目标且置于目标栈中。如果请求新的信念，就会应用一致性检查过程。新的信念和新的目标也可以激活某些新的KA，在这种情况下，解释程序可以决定去执行其他某些目标。这使得Agent更少地忠于意图，更多地去感知环境。事实上，PRS中的KA可以实现对环境变化的快速响应，这就形成了混合型体系架构中的反应组件，虽然并不是作为一个单独的体系架构组件。1.4 Agent的组织类型
前面章节解释了Agent的内部组成，本节处理Agent之间的交互，即为了解决共同的或内部关联的问题，它们一起协作的方式。
虽然已经提出了几个比喻来对系统中的Agent交互方式进行建模（Iglesias等，1998），但是“组织”（Fox，1981）正在成为面向Agent软件工程（Agent Oriented Software Engineering，AOSE）中最为常用的一个比喻（DeLoach，2002；Kolp等，2002），因为它是直接的，并且已经在多种情况下被成功应用。大体上，组织比喻是源于人类在组织环境中可以通过协同工作来解决问题，如商业。商业有需要达到的目标，并且为了实现这些目标，需要将其分解为具体的任务，如生产和分配。然后，再将这些具体任务分配给由人扮演的角色。为了执行它们的任务，角色根据预定义的模式进行交互，这些模式定义了一些角色从属于另一些角色的权威。这些交互也形成了一个可辨认的通信路径网络。更一般地，根据组织比喻，MAS中的每一个Agent都可以扮演一个或多个角色；反之，每一个角色负责追踪一个或几个明确定义的责任，这些责任一般是通过与其他角色的交互来完成的。然而，两个角色之间的交互不仅是联合的关系，事实上还是一个建立权威的关系，这是角色定义的一个部分。角色、交互和权威关系定义了组织的结构。“组织”可以指导系统中的Agent通过交互来完成各自或全局的目标，并影响它们如何协调和分配资源，以及相互之间的从属关系。这样，通过和其他Agent的交互，“组织”可以帮助简单的Agent完成复杂的任务，帮助复杂的Agent降低过程的复杂性（Horling 等，2005）。可以认为，所有的MAS都有某种形式的组织，即使是隐含的。因为在任何MAS中，分布式Agent通过交互一起活动，执行分配的任务并且使用资源去完成这些任务。然而，可能不止一个组织适应于某一特定系统（例如，一条生产线可以被建模为一条管道，也可以是一个层次），因为组织的任务分配方式和所拥有的通信路径各不相同，不同的组织会导致不同的系统执行效率（如通信和计算的开销）、不同的可靠性和不确定性管理。除此之外，组织提出了可测量性、冗余和灵活性的不同标准。虽然没有两个组织是相同的，但是根据它们交互所形成的拓扑结构和Agent之间所展示的权威关系，把它们归为某一类型是可能的，下面是一些最常用的组织类型或范型。
1.层次（Hierarchies）
这是最简单的，也是被研究最多的组织形式（Fox，1981；Horling等，2005）。在层次中，Agent从概念上被排列为一个树形结构，角色的位置越高，就越重要。一般地，低层Agent会为高层Agent产生数据，高层Agent会执行更为复杂的处理，如合并、分析或决策。层次在分布式应用软件建模中被广泛应用（Fox，1981）。实际上，著名的合同网协议（Smith，1977）倾向于产生分层结构。在合同网协议中，Agent可以通过广播来分配一个子任务，在其他Agent所提供的服务中选择一个最为方便的，从而协助它完成任务。
2.组合（Holarchies）
在这个范型中，系统被认为是由基本组织单元构成，即一个子模块可以被看做是由其他（更基本）模块构成（Fischer等，2003；Horling 等，2005）；例如，一个制造系统由制造单元组成，而制造单元又是由设备、操作员和过程等组成。组合的关键是子模块的局部自治，因为缺乏自治性将会退化为分层，完全的自治性又会导致无组织群体。更明确地，如果系统中Agent之间的关系是完全从属的，组合会退化为分层。组合的另一个重要方面是每个子模块代表着一个复杂的子组织，需要进一步分解。把系统建模为一个分层嵌套结构，已经证明适合于对某些特定的实际问题进行建模，如制造业控制（Zhang等，1999）。在（Zhang等，1999）中，一个整合不同类型（静态的、中介者和动态的）子模块的模型被用于为制造业控制系统建立一个组织。这里，静态创建的子模块被用于表示环境实体，如制造设备、设计计划和传输带，而动态创建的子模块被用于表示新任务，中介者类型子模块管理次序和协调资源。
3.团队（Teams）
团队就是多个合作Agent追求共同目标的系统（Beavers等，2001）。因为没有对它们的交互类型加以制约，团队的拓扑结构往往是十分随意的。然而，团队成员经常共享它们的思维状态，尤其是对于“共同目标、相互信任和团队行为”的通用表示。例如，（Jennings，1995）展示了依赖于共同任务的表示和合作过程，Agent可以成功解决电力运输的问题，但是在缺乏共同表示时，它们倾向于无条理的行为。
4.市场（Markets）
在这种特殊类型的组织中，Agent可以购买和出售类似于服务或任务这样的项目（Fox，1981；Wellman，2004）。扮演购买者角色的Agent投标，扮演出售者角色的Agent接受投标并确定获胜者，其方式在很大程度上类似于真实的市场。通常是这种情况，一些Agent的存在是为了促进组织在共同任务中的操作，如接受投标和确定获胜者。Kasbah（Chavez和Maes，1996）是最早基于Agent的市场例子之一，其中购买者和出售者通过一系列的特征、期望价格和限制价格来描述它们感兴趣的货物类型。这里当购买者愿意付给出售者所期望的价格时，一次交易就会发生。
在每一种特定的方法中，组织表述的方式都不相同。例如，在Gaia方法学（Zambonelli等，2000）中，角色组织由组织结构和组织规则组成。组织结构通过其本身的拓扑结构和控制机制进行描述。拓扑结构包括一系列由组织中角色相互作用形成的通信路径，以及有可能采取的典型方式，如线、树或网络。另外，控制机制包含角色之间的权威关系；例如，在雇用控制机制中，作为工作划分的结果，低级角色要服从高级角色。最后，组织规则提供对组织元素操作方式的限制；例如，市场中的组织规则可以规定：如果没有收到相应的支付，不能交付相应的产品。
总之，将组织方法应用于多Agent范型是一种有前途的工具，可以处理目前软件系统的复杂性（Zambonelli等，2003；DeLoach，2002），这主要是由于以下事实：组织提供了一个概念性的框架，其中Agent所执行的复杂交互可以被适当地建模。这个概念性的框架建立了一个位于顶部的抽象层次，由Agent进行补充。1.5 Agent与组件的对比
近十年来，AOSE的创建和进一步发展已经将Agent提升为一种开发复杂软件系统的新方法。借助于AOSE，开发人员可以拥有Agent的灵活性和强大的表达能力，以帮助管理软件生命周期，从而改进最终软件产品的质量。在AOSE的短暂历史中，其研究焦点经历了一次重要的变动：最初它仅仅用于提供构建基于Agent系统的方法学和工具；现在却更侧重于了解基于Agent的方法可能给传统软件开发所带来的特征变化。研究焦点的变动并不是无足轻重的，它对应于在软件生命周期中采用Agent技术的不同原因。
前者是在实际软件生命周期开始之前，选择Agent作为开发的基本抽象。做出这样的决定是由于软件生命周期之外的原因，一般是根据系统的本质或所处理问题的复杂性。如Tropos方法（Bresciani等，2002）所建议的那样，在整个生命周期中（从早期的需求分析到系统的结束）采用面向Agent的思想，选择Agent作为基本的开发抽象。这种方法的一个主要缺点就是，经常难以找到合适的理由来选择Agent开发常规系统，如文字处理软件和财务管理系统。这也是后来的AOSE方法在需求分析和需求确认阶段之后（或在此期间），转而确定为什么要采用Agent技术。开发人员并不需要被迫采用Agent来实现他的系统，而是可以集中于需求分析，然后派生出后续设计。这种方法的主要缺陷在于，开发人员或许不能利用Agent的一些有趣特点，如突发行为和泛化，因为太多的注意力被放在了直接来自于客户的具体要求。后者强调了开发人员应该了解何时及如何优先采用Agent技术，从而取代传统的、更加成熟的技术，如面向对象技术。
自从在1997年第一次发布FIPA规范（参见http：//www.fipa.org），研究人员清楚地了解到使用Agent作为软件组件的可能性。它能够带来很多有趣的特征，如自治推理和目标导向行为。另外，FIPA选择CORBA接口来实现Agent之间的通信，这就更加强调了这些抽象之间的强相互关系。对于Agent和对象之间的区别存在着长期争论，（Wooldridge，2000a）就起源于这个比较，但这种争论有时是毫无意义的。
面向组件的软件工程提出了“扩展对象”的思想：通过组件的组装来实现复杂系统，满足对可重用模块的强烈需求。现实中的案例包括Web服务（http：//www.w3.org）、CORBA（Suhail，1998）、JavaBeans（http：//java.sun.com）和.NET（http：//www.ecma-international.org）。这些组件可以跨越不同的网络、语言和操作系统，在系统开发中给予开发人员最大的自由。然而，面向组件的软件工程长期追求的目标并不会随着可重用软件单元技术的实现而终结，它还要考虑以下要素：（1）商业现成（Off-The-Shelf，OTS）组件，即公开市场上可获得的组件，可以通过装配来创造具有附加值的系统。系统的质量和费用基本上取决于每个商业组件的质量和费用。市场会在提高可用组件质量的同时降低成本。（2）自动组装，即通过使用自动化技术来降低组件装配过程的费用。组装过程的质量和费用直接依赖于自动装配所采用技术的质量和费用。
一个基于组件的系统，其费用包括各个相关组件的直接投资与自动装配技术的费用，商业组件和自动装配的结合使用可以降低费用总和。同样，系统的质量随着单个组件质量和自动装配技术的提高而提高。
Agent和组件的比较如表1.1所示，在表中展示了组件和Agent的一些重要方面。更加精确地，我们考虑了Agent元模型的重要特征，并将它们与组件元模型的相应特征做了比较。为了使结果具有最大的通用性，我们避免考虑任何特殊的元模型，如微软组件中的.NET元模型或Agent组件中的SMART框架（Luck和d’Inverno，2001）。表1.1 Agent元模型和相应组件的特征
1.状态表达（State Representation）
Agent和组件都是包含状态的抽象，但它们采用了非常不同的手段来对外部世界描述和展示状态。组件的状态包括一组属性和一组与其他组件之间的关联。属性和关联可能是公开的，即其他组件可以直接操作它们。每个Agent都有思维状态，一般采用如下要素进行表示，如它所知道的（如信念）和它当前所追求的（如意图）。表示执行状态的模型之间所具有的主要区别如下所示：（1）一个Agent无法直接操作其他Agent的状态，但是可以通过通信来影响它；（2）Agent对于它们的目标有一个明确的表示；（3）Agent对于它们所处的环境，以及环境中的其他Agent，有着明确的认知；（4）除了唯一识别符，Agent没有公开属性。
Agent方法的一个主要优势在于：可以采取通用的推理技术来支持推导和“手段—目的”推理。相反的，组件的状态属性和关联不是在一个逻辑框架中构建，因此难以使用通用技术，必须在组件方法中对推理规划过程进行明确编码。
2.通信（Communication）
Agent和组件之间的主要区别在于它们所采用的通信机制。Agent使用发布性的Agent通信语言（Agent Communication Languages，ACL），而组件则使用元对象协议（Kiczales等，1991）。在面向Agent的方法中，消息发送仅仅是发送者试图将部分思维状态传递给接收者。我们采取FIPA ACL作为一个代表性的例子：它定义了行为原语（即语义消息类型），可行的前提条件（要求发送者发送消息时必须是真实的），合理的结果（即为什么发送者要发送这条消息）。当Agent收到一则消息时，它可以断言前提条件对于发送者成立的可行性，并且设法实现相应的合理结果。这是一个相当拗口的表达方式：发送者希望接收者知道“发送者想让它了解前提条件成立的可行性和实际上造成的合理结果”。使用结构化ACL的好处：除了能够更加自然地交换目标表达式之外，还可以简化具备复杂交互能力的反应式Agent的开发。没有推理能力的反应式Agent能够利用ACL的行为原语作为触发器，用于激活底层交互协议的状态自动机。JADE（Bellifemine等，2001）（参见第9章）和类似平台提供了这样的机制。
在面向组件的方法中，消息发送是出于两个原因：第一个是为了直接操作接收者的状态。通信的使用违反了组件的自治性原则，自治性要求组件应该单独为它自己的状态负责。用于实现组件的大多数技术禁止对状态的直接操作，这样是为了尽量满足软件工程的目标，将组件间的耦合性降低到最小。发送消息的第二个原因是发送者可以强迫接收者为其执行一个方法主体，而不用明确地与接收者通信告诉它为什么这样做。这样，执行的责任就完全在于发送者，它负责保证前提成立，以及在方法的完全执行过程中可能引起系统其余部分发生变化。
3.责任委派（Delegation of Responsibility）
我们已经指出，不管是Agent还是组件，责任委派都是基于通信的，它们在责任委派方式上的不同也正好说明了通信模式的区别。在面向组件的模型中，发送者仅仅负责一条消息的可能结果，也就是说，除了“请根据我的职责这么做”之外，发送者并不需要对接收者说更多。严格来说，组件根本就没有向其他组件委派责任。在面向Agent的模型中，接收者仅仅负责它自己的个体行为结果，发送者还需要说明为什么它要请求这个服务。Agent所能执行的一个非常重要的通信行为就是将其目标之一委派给其他Agent，如通过FIPA“achieve”行为原语。这个特殊的通信行为，被称为目标委派，是Agent用来委派责任的基本机制。
组件的元模型并不包含目标抽象，只使用了任务委派。组件通过强迫其他组件执行动作来实现它们的（隐含的）目标；Agent或许通过将目标委派给其他Agent来实现它们的目标（明确地）。这也是为什么我们一般把面向Agent的通信模型称为“发布性的消息传递”：Agent可能告诉其他Agent想要它们做什么，但是却没有明确陈述怎么做。相反，“强制性的”消息则被用于面向组件的方法，因为组件不可能只告诉其他组件做什么，而不说怎么去做。
对于组件而言，仅仅使用任务委派可能是一个很大的局限，因为目标委派是一个更加通用的机制。首先，任务委派是目标委派的一种特例，被委派的目标采取形式done（a），a表示一个行动，就像是FIPA ACL中为了获取合理的结果所要求的原语；其次，任务委派或许会抑制优化。如假定组件S具有目标g，需要组件R执行a1和a2来实现它的目标；S会先要求R执行a1，然后要求R执行a2。虽然S的根本想法是实现目标g，但这两个请求并不耦合，R无法利用a1和a2之间的跨越性进行任何优化。如果S和R是两个Agent，而不是两个组件，那么S仅仅需要把目标g委派给R，然后由R来自主决定实现目标的方式，也就是说，它将决定如何执行a1和a2。这种方法通过目标g将a1和a2耦合起来，使R能够执行a1和a2之间的跨越性优化。
4.各方之间的交互（Interaction between Parties）
不同的通信方式影响着Agent和组件如何将自身向外部世界发布。组件使用接口来列举它们所提供的服务，告诉客户如何同它们建立联系。复杂的组件模型，会给接口配上前提和后置条件。面向Agent（Agent Oriented，AO）的方法没有采用接口方式，而是提供了能力描述符，描述了一个Agent能够做什么，也就是它所采取行为的可能后果，以及它如何同其他Agent进行交互。能力描述符和后置条件之间的主要区别在于，前者能够表示在完全执行一个行为之后，环境的状态如何改变。后置条件仅仅能够断言，在一个行为执行后，组件的状态如何改变，因为环境并不是组件元模型的一部分。
5.与环境的交互（Interaction with the Environment）
正如我们已经提及的，环境是Agent元模型的一个结构组成部分，却不是组件元模型的组成部分。Agent 在一个能够获取知识的环境中执行，因为它是处于一定的上下文抽象中。Agent能够感知环境且从中接收事件。这两种情况都会使Agent的思维状态发生一定的变化，进而导致对环境的变化产生反应。这同面向组件的方法有着根本的不同，组件仅仅通过具体化的事件来同环境进行交互。组件可能对事件产生反应，仅仅依靠事件本身的具体化来构建关系。
面向组件的方法似乎比面向Agent的方法能够更好地执行封装：只有决定改变组件本身以对事件做出反应时，组件的状态才会改变。
试读结束[说明：试读内容隐藏了图片]