爱华网摘要： 随着人工智能技术的发展，利用具有一定自主推理、自主决策能力的智能代理（Intelligent Agent）以及由其组成的多智能代理系统（Multi-Agent System），用来模拟、优化、实施、控制企业供应链的运行，已经成为研究和实施供应链管理的重要方法之一。为了印证Multi-Agent系统在供应链管理中的可行性与有效性，我们使用英国电信实验室开发的Zeus多代理设计开发平台，以一个典型的个人电脑生产企业为原型，构建了一个企业供应链的Multi-Agent模型，用来模拟企业供应链的运行，尝试利用该系统对企业供应链的运行提供决策支持，实现供应链的自动运行。本次实践也是对掌握一套开发多代理应用系统的分析与设计方法的一次有益的探索。关键词： 供应链；多Agent模型；角色建模1． 1．Zeus系统简介 Zeus多代理设计开发平台（The Zeus Agent Building Toolkit）是英国电信实验室智能代理研究小组综合了现有的代理技术规范，研究开发出来的，用于快速开发协作式多代理系统的设计开发平台[1]。它希望通过定义一套标准的单个代理功能结构以及多代理通讯协调的体系，使用户能够摆脱复杂而繁琐的对代理底层结构的定义工作，从而关注于对应用问题的设计与实施，使用户能够快捷的开发出协作式多代理的应用系统。Zeus系统严格遵循FIPA97规范[2]，系统的Java源程序全部公开以方便用户研究与扩展。1.1基于Zeus的多代理应用系统的系统体系结构一般我们设计开发多代理应用系统，需要解决两个层次的问题：一是对应用问题的分析与设计，定义各个功能代理的相互关系；二是设计底层单个代理的推理、协调、通讯机制。Zeus系统为了让用户能够迅速的开发多代理应用系统，已经提供了尽量完备的单个代理的功能体系与多代理协调与通讯机制。用户只需要关注特定应用问题的分析与设计，只有在必要时才需对代理的底层机制进行增强与改动。一个基于Zeus系统的多代理应用系统的系统结构如下图所示：图一：Zeus应用系统框架图1.2 Zeus Agent的协调求解机制Zeus Agent作为一个完备的任务执行体，它具有消息接收与发送、目标协调求解、行为计划与调度、动作执行与监控、以及内部状态和资源管理五个大的功能模块。其中，目标协调求解是Agent的核心，它决定了Agent完成任务的途径，同时它还负责调度Agent的其他功能与内部资源，自动的完成预定的目标。Zeus Agent通过可递归的行为转换网络图（Recursive Transition Network Graphs）来实现Agent的任务求解推理。这个网络图是由行动节点（node）与状态转换弧（arc）构成的。行动节点表示的是Agent采取某一种行动，弧则用来检验从一种状态到另一种状态的可能行。Zeus Agent缺省定义的行为转换网络图如下图所示：图二：Zeus Agent缺省的协调求解机制如上图所示，人们或外部程序通过设定任务目标（Goal）来触发Agent的自主求解机制，如果Agent在任务求解过程中，需要外部Agent的功能与资源，它将通过合同网络协议（Contract Net Protocol）[3]，生成外部合约（Contract）与其他Agent进行谈判（Negotiation）。Zeus系统允许用户自己定义谈判的策略，甚至进一步开发自己的Agent谈判协议。1.3 Zeus Agent的信息表达与通讯在Zeus系统中，系统用本体（Ontology）统一表达和管理在代理之间传递和使用的概念和定义。具体的说，它使用Fact这个Java对象及其派生出来的Java类表示和存储这些概念和定义。一个Fact由名称及其属性构成，需要在设计开发过程中事先定义。Zeus Agent通过代理通讯语言（ACLs）进行消息传递[4]。ACL基于语言行为理论（speech act theory[5]），该理论认为人们的语言表达的一般模式是行为（Action）加上该行为的对象。Zeus定义了常用的通讯协调行为，如Query，Inform，Propose，同时它也为用户定义自己的通讯协调行为预留了扩展空间。 2． 2．问题与模型我们以一家国内著名的个人电脑生产企业作为原型，进行供应链的多代理建模研究。该企业采用根据定货装配（Assemble-to-Order）的生产模式，在全国建有四个装配生产厂与配套仓库，企业还与专业的运输公司合作，把产品及时输送至各个代理分销商手中。为了应付产品零配件供应的意外情况以及顾客需求的突然增长，企业还要保有一定的零配件安全库存与产品的额外库存。为了应付原材料与客户需求的快速变动，企业迫切需要有一套决策支持系统，能够快速评估各种参数变动所造成的后果，发现供应链运行的瓶颈，但同时还要求系统具有良好的可拓展性，以适应由于企业自身快速的增长而带来的业务变动与机构变动。通过分析，我们认为企业的库存水平是影响该企业效益的关键瓶颈。我们的模型将以企业的原料库存与产品库存为中心，通过模拟供应链运行，获得供应商供货提前期、产品装配延时、顾客需求变动、运输延时等参数对企业库存水平以及定单完成率（Order Fulfillment Rate）的影响，从而辅助决策者制定库存管理方案。同时，我们还想通过该模型，尝试利用代理的自主推理、自主决策的特性，实现供应链的自动运行。由于Zeus系统引入了本体对象Fact的概念，我们就可以把供应链中每个实体之间的相互关系都抽象为对Fact的一种买和卖的供求关系。我们把现实供应链的实体，依据不同的业务功能以及决策权限，把它们归类、整合成为一个个的功能角色。一种功能角色将根据任务处理的复杂程度度由一个或多个Zeus Agent来实现。这种划分角色、设计代理的方式有利于企业管理者更快更好的理解模型，代理之间良好的独立性也方便使用者设置参数，同时使系统具有良好的可扩展性。图三：供应链的多代理模型基于以上考虑，我们把一个典型的PC厂商的供应链抽象为上图所示的结构，其中包括供应商代理，采购代理，原料库存代理，生产计划代理，制造代理，产品库存代理，定单处理代理，运输代理，以及分销商代理，各代理的功能如下：1. 1. 供应商代理。该代理模拟多个供应商的行为。代理根据预设的参数，模拟零配件（如CPU，显示器）的生产数据，包括生产批量，提前期与价格波动。该代理还要能够自动处理供货定单，能够在一定范围内实现价格协商。2. 2. 采购代理。该代理模拟企业采购部门的功能。代理负责收集原料库存的实时数据，根据预设的采购策略，自动实现向供应商定货及处理定单。3. 3. 原料库存代理。该代理模拟四个原料仓库的库存。代理模拟原料仓库的库存情况，自动记提库存成本，响应其他代理对原料库存的查询请求，自动处理原料的出入库操作。4. 4. 生产计划代理。该代理模拟企业生产计划部门的功能。代理负责归并定单数据，根据产品库存情况、原料库存情况、生产能力情况，制定生产计划，下达到制造代理进行生产。同时监控生产的进度。5. 5. 制造代理。该代理模拟四个生产工厂的生产情况，包括生产能力、生产进度、半成品库存、废品率等数据。代理还要能自动完成零部件提取，产成品入库的操作。6. 6. 产品库存代理。该代理模拟四个产品仓库的库存情况，自动记提库存成本，响应其他代理对产品库存的信息请求，自动处理产品的出入库操作。7. 7. 定单处理代理。该代理模拟企业定单服务部门的功能，接收从分销商处发来的产品定单，根据产品库存情况以及生产计划制定的情况，决定是否接受该定单，并跟踪定单的执行。8. 8. 运输代理。该代理模拟两个运输公司的行为，包括模拟多个运输公司的运力，运输延时。代理还要能自动完成提货，送货的运作。9. 9. 分销商代理。该代理模拟企业四个大区总分销代理的行为。代理根据预设的数据，模拟产品的需求波动，自动产生与完结定单。3． 3．角色建模——系统概念设计有了系统的整体框架模型，我们需要进一步设计每一个的代理的功能与内部状态。在多代理系统中，必须根据这个代理所处的外部环境，才能明确该代理所应该具有的内部功能与外界的交互。角色建模方法[6]作为分析设计多代理系统一种方法，能够逐步明晰代理的责任与功能，为下一步对代理的详细设计打下良好的基础。我们在设计与建模的过程中，采用了角色建模的思想与方法。角色建模虽然借鉴了许多对象建模的思想与方法，但是它仍是一种区别于对象建模的一种多代理系统分析设计方法。它的主要特点是：1. 1. 与实际业务或问题密切结合，反映的是以功能角色为单位的系统的面貌。它比对象建模所描述的业务层次要高，更接近于现实问题；2. 2. 一个角色并不一定要对应于一个代理，但一个代理至少是一种角色的反映；3. 3. 角色有着良好的完备性，模块性，自治性。进行角色建模过程中，我们以一个角色为中心，分析该角色与其他角色的功能交互。这样，形成了九个子模块，逐步明确九个功能角色的功能与内部状态。下面我们以对定单处理角色的分析为例来说明。图四：定单处理代理交互图代理交互行为列表交互行为 描述1 发出定单 分销商发出商品定单2 库存查询请求 定单代理发出查询请求3 库存情况 产品库存发回库存情况4 提交生产请求 定单处理询问是否能够生产5a 允许生产确认 生产计划确认可以生产5b 生产完成确认 生产计划通知生产完成6 定单接受确认 确认定单接受7 开始运输通知 通知运输车队开始运输8 完成运输通知 运输车队通知运输任务完成或失败4． 4．Agent设计——系统功能详细设计在使用角色分析方法完成对代理的功能关系分析之后，我们将根据Zeus多代理开发平台的特点，对每个代理进行详细的设计。这个阶段分为本体设计，代理行为设计，以及代理协调关系设计三个部分。4.1本体设计
本体（Ontology）对象Fact作为Zeus系统中表达与管理基本概念与定义的数据对象，在整个开发基于Zeus的多代理系统的过程中，需要首先设计。同时，由于Fact还是代理任务的输入输出对象，我们在决定Fact的同时，一般也就能确定代理之间的相互功能关系与协作方式。根据它们在系统中的作用，这些本体对象可以分为两种类型：实体本体（Entity）与消息本体（Message）。实体本体表示的是供应链中实际的物流的流动，系统提供了对数量、金额等属性自动处理的机制，如定单（Order）；消息本体表示的是系统内部的控制信息或实际供应链中的信息流，它不能自动处理数量、金额等属性，如库存通知（PInevNote），生产请求（ManufactPurpose）。以定单本体为例：Fact：OrderAttributes：Name Type Restriction Default ValueOrderID Integer Owner String Pname String "Server | PC | Laptop" PCAcceptDate Integer Delay Integer 6Status String "New | Accept | Deny | Made | Finished" NewUnit_cost Real Amount Integer 1 4.2任务设计Zeus Agent执行任务有两种方式：一是通过IF…THEN形式的基于规则（RuleScript）的响应式动作执行，另一种是通过外挂的任务程序（Task），完成相应的业务逻辑。规则RuleScript的优点在于能够迅速的对发生的事件作出响应，缺点是响应的功能较弱，不能完成复杂的业务逻辑。 下面以一个简单的例子说明RuleScript的设计与形式。该RuleScript的功能是定单服务代理在得到库存代理或生产计划代理确认的信息之后，把定单状态由New变为Accepted，并通知供应商代理，同时产生新的运输请求，并通知运输代理。(:Rulebase acceptOrder(accept?acceptedorder <- (Order (OrderID ?var10) (Owner ?var11) (Pname ?var12) (AcceptDate ?var13) (Delay ?var14) (Status Accepted) (Amount ?var 15))?neworder <- (Order (OrderID ?var10) (Owner ?var11) (Status New))=>(retract ?neworder)(assert (TransPlan (OrderID ?var10) (Owner ?var11) (Pname ?var12) (AcceptDate ?var13) (Delay ?var14) (Amount ?var 15)))(send_message (type inform) (content ?acceptedorder) (receiver ?var11)))(informtransporter?transplan <- (TransPlan(Carrier ?var16))=>(send_message (type inform) (content ?transplan) (receiver ?var16))))任务程序（Task）则以独立Java进程的形式出现，能够处理复杂的业务逻辑，适合用来模拟和实现实际复杂的业务活动。Zeus Agent要求Task指定任务输入输出的Fact，以及任务发生的成本与延时，Zeus Agent就能够根据这些参数，由Agent的计划日程安排模块（Planning and Scheduling）统一分配调度资源、安排任务处理时序、处理意外与资源冲突、提供回溯（Backtracking）处理机制。以下是定单处理代理所具有任务及其属性：Task Name Consumed Fact Product Fact Cost Time DescriptioncheckInv PinvNote Order 0 1 定单代理向成品库存代理询问目前产品库存情况manuPurpose ManufactPurpose Order 0 2 定单代理向生产计划代理提出生产请求由于以上两个任务反映的是企业内部信息的传递，不存在资金成本的问题，所以它们的任务执行成本（Cost）都设为0；而信息的传递往往需要时间，尤其在现实情况中，确认定单是否有能力执行需要更长的确认期，所以我们把询问库存的延时设为1个时间单位；确定生长能力的延时设为2个时间单位。4．3代理任务协调Zeus 代理内部的任务触发机制是源于一个目标（Goal）的生成。一个Goal生成之后，Zeus代理自动检查自身是否能够完成该任务以及是否占有完成该任务所需的全部资源，若否，Zeus代理将把所缺少的资源，以子目标（SubGoal）的形式向相关代理发出询问，寻求合作。因此，在确定代理内部的任务处理之后，我们要描述整合以本体Fact为信息流的任务之间的相互关系，明确子目标，从而反映出代理之间的任务协调关系。图五：定单代理任务协作图5． 5．系统实现在多代理供应链模型的运行过程中，我们还设计了一个单独的功能代理，用来同步各个代理以天为单位的运行时间，设计了用户界面，方便用户设置参数与监控代理运行状态。Zeus系统通过NameServer，Facilitator等公共代理（Utility Agents）提供代理名字与功能解析服务，从而能够实现Zeus Agent分布式的网络计算。为了缓解计算压力与运行开销，我们把以上企业供应链模型中的九个代理，在多台Unix工作站与Windows个人电脑上分布运行，实现了对企业供应链运行的模拟。参考文献：
