PlanProjU：一种基于BPMN到HDDL的HTN规划方法，用于大学项目执行 作者：Jhon Wilder Sanchez-Obando、Néstor Dario Duque-Méndez 和 Luis Fernando Castillo-Ossa

《Computers》：PlanProjU: A BPMN-to-HDDL HTN Planning Approach for University Project Execution Jhon Wilder Sanchez-Obando, Néstor Dario Duque-Méndez and Luis Fernando Castillo-Ossa

　　摘要：本研究旨在通过将基于BPMN的过程模型转换为分层规划表示，从而自动化生成大学项目的执行计划，这些表示可以被HTN规划器执行。有效实施大学扩展项目需要明确管理目标、依赖关系和操作约束，然而这一过程通常是由人工完成的，且缺乏正式的规划支持。为了解决这个问题，本文提出了PlanProjU，这是一个基于Web的平台，它通过BPMN捕获项目知识，并将其转换为HDDL领域和问题文件，以便使用SHOP2和PyHOP进行执行。该系统通过真实的大学项目案例和生成的替代计划的比较分析进行了评估。结果表明，基于BPMN的项目知识可以转化为可执行的分层规划结构，并且不同的规划器可能会根据项目特征产生不同的计划方案。本研究的创新之处在于设计了一种可追踪的BPMN到HDDL的工作流程，用于大学项目规划，该流程在一个集成平台中实现，该平台将业务流程建模与HTN自动化规划相结合，在此领域之前的研究关注较少。从这个意义上说，该提案既是一个创新的研究贡献，也是机构环境中结构化实施决策的实用替代方案。

1. 引言
大学项目的设计和执行通常遵循项目管理专业人士（PMP）方法论[1]。然而，在官方的大学推广项目中，由于高等教育机构的技术和结构限制，PMP方法论往往没有得到完全实施。这一差距表明，仅仅拥有一个通用的项目管理方法论是不够的；相反，迫切需要在所有项目阶段进行详细规划。从人工智能的角度来看，人工智能规划领域（也称为自动化规划）提供了一个成熟的计算框架，通过生成可执行的计划来自动化整个规划过程，从而简化规划过程并提高效率[2,3]。最近在项目规划方面的进展得益于决策制定、资源分配、风险分析、成本效益评估和财务评估技术的重大进步[4]。这些传统方法在许多情况下都证明了其有效性，但它们在促进实时监控和明确考虑不确定性因素方面仍然存在固有的局限性，而这些因素在大学环境中尤为重要。在过去的几十年里，研究广泛探索了各种方法论、数学模型和算法，以提高项目规划效率[5,6]。

随着生成式人工智能的兴起，一个当代趋势是将大型语言模型（LLMs）集成到项目规划中。例如，Herroelen等人[7]提出了一个基于深度学习的任务规划系统，该系统嵌入在LLM中，以模拟人类专家在任务调度中的推理能力，展示了LLMs在提高项目规划能力方面的潜力。同样，Weglarz等人[8]应用知识工程设计了一个推理框架，当与LLM集成时，该框架支持SCRUM方法下的工程项目规划，进一步突出了LLMs在项目规划中的优势。然而，尽管有这些进展，大多数应用仍然局限于机器人技术和软件工程领域，这表明在更广泛的项目管理领域应用LLMs方面存在显著的研究空白，强调了进一步探索和发展的需求。

Zhou等人（2020年）[9]调查了将大型语言模型（LLMs）集成到自动化规划中的尝试。然而，这种方法受到一些根本性挑战的阻碍，包括幻觉现象，这会损害从初始状态过渡到目标状态时的推理可靠性。这一限制进一步凸显了需要替代方法。自动化规划技术通过使用嵌入的约束和启发式方法，在给定领域描述和初始/目标状态的情况下生成计划，提供了一个可行的替代方案[10,11]。一个有前景的子领域是分层任务网络（HTN）规划，它将复杂任务分解为一系列基本的、可执行的动作[12,13]。虽然基本动作在预条件和效果方面有明确的定义，但在最广泛使用的形式化语言HDDL中，复合任务缺乏这种明确的语义，HDDL是2020年和2023年国际规划竞赛（IPC）中使用的领域描述语言[14,15]。

HTN规划中的一个关键挑战是手动创建领域模型，这需要专家级别的知识。这一过程可以通过结构化的现实世界知识表示来支持，例如业务流程模型和符号（BPMN）。BPMN基于Frederick Taylor的科学管理原则[16]，假设存在一个可以由过程管理调度（PMS）系统自动化和执行的底层固定业务流程（BP）。实施可重复业务流程的过程包括三个关键步骤。首先，需要识别一个可重复的业务流程（BP），这是对实际工作流的结构性抽象。这一步至关重要，因为它为后续步骤奠定了基础。第二步是将识别的BP形式化为一个过程模型，该模型捕捉了朝向业务目标的任务执行流程。这个过程模型通常使用业务流程模型和符号（BPMN）中的显式控制流来创建，BPMN是建模业务流程的广泛接受的标准。使用BPMN可以清晰无误地表示过程，促进利益相关者之间的有效沟通和理解。第三步也是最后一步，是通过PMS自动化流程的路由。PMS将任务分配给适当的参与者，无论是人类还是软件代理，确保过程高效有效地执行。这种自动化使得从初始状态到目标状态的过渡无缝进行，从而证明了将项目管理表示为BPMN建模过程是合理的。

BPMN在建模大学项目方面有两个明显的优势：（1）它提供了因果依赖关系的图形化、分层表示；（2）其XML序列化可以解析以识别每个项目组件中的状态转换。这些转换编码了决策流的条件操作，从而产生具有相应约束的顺序和并行任务执行[17]。一旦解析了BPMN图，就会生成两个HDDL文件：包含HTN动作模型的领域文件和定义特定大学项目初始和目标状态的问题文件。然后应用了2002年IPC中引入的SHOP2规划器，该规划器最初是用LISP实现的[18]。与其前身不同，SHOP2支持部分有序的子任务，在处理简单知识库时提高了效率。PyHOP是一个用Python编写的简单HTN调度器，兼容2.7到3.2版本，代码行数少于150行。它的调度算法基于SHOP的算法[19]，但它避免了需要特定的调度语言，因为任务网络及其方法是用Python编写的，使用替代语法来定义变量、动作和方法。PyHOP的开发源于观察到应用程序开发者经常自己编写调度系统，而不是学习专门的AI调度语言[20]。PyHOP的创建旨在为没有AI经验的人提供易于理解的HTN调度器。PyHOP的作者并没有大力推广它，但其易于理解和使用的特点使其在快速原型设计中非常有用，因此被用于各种项目和出版物中。

先前结合自动化规划和BPMN进行过程自动化的研究已经证明了这种方法的有效性。Suschel的工作（2006年）[21]是一个值得注意的例子，因为它利用经典规划来自动化自适应工作流的流程定义，展示了适应变化情况的能力。同样，Nau（1999年）[22]成功地将知识模型集成到电信网络安装的时间经典规划器中，突显了这种方法在复杂领域中的有效性。此外，Nau（2013年）[23]通过使用归纳逻辑编程在经典规划中发现动作操作符，解决了人类知识表示的挑战，强调了改进自动化规划系统中知识表示的必要性。然而，这些贡献仅限于时间和数值经典规划，没有涉及HTN规划，鉴于现代项目管理的复杂性，这是一个重要的空白。本研究解决了三个关键问题：（i）大学项目的自动化执行系统稀缺；（ii）缺乏基于HTN的项目自动化，以生成适应动态项目管理条件的计划，这可能导致计划不灵活和无效；（iii）缺乏优先考虑自动计划生成的项目规划系统，这可能会妨碍对变化的项目需求的响应。

尽管基于BPMN的过程建模和自动化规划研究取得了进展，但在大学项目执行的背景下，它们之间的交叉点仍然存在一个重要空白。先前的研究探讨了来自工作流模型、服务编排和过程自动化的规划，但它们没有明确说明如何将大学项目的BPMN表示转换为支持在用户导向平台内通过多个HTN规划器进行比较执行的可追踪分层规划工件。因此，大学项目的实施仍然缺乏一个将过程建模、可执行计划生成和比较规划支持连接在一起的统一环境中的正式机制。本研究追求以下研究目标。首先，设计一个可追踪的转换工作流程，将基于BPMN的大学项目模型转换为适合分层规划的HDDL表示。其次，在一个集成平台PlanProjU中实现这一工作流程，该平台能够通过不同的HTN规划器生成替代执行计划。第三，在真实的大学项目案例中评估所得规划工件的可行性和比较行为。

为了指导研究，定义了以下研究问题：
RQ1. 基于BPMN的大学项目模型能否系统地转换为HTN规划的可执行HDDL表示？
RQ2. PlanProjU是否能够通过不同的HTN规划器生成和比较大学项目的替代执行计划？
RQ3. 不同BPMN结构特征的大学项目案例中，规划器的行为有何不同？

这些问题将确定的研究空白与研究目标联系起来，并为所提出工件的设计和评估提供了分析基础。鉴于研究的面向设计的性质，研究不是通过正式的统计假设来构建的，而是通过评估导向的命题来构建的。
P1. 一个BPMN到HDDL的转换工作流程可以将大学项目知识转化为可执行的分层规划表示。
P2. 一个结合了BPMN建模、转换和HTN规划器执行的集成工件可以支持大学项目实施的替代计划的比较生成。
P3. BPMN结构特征的差异可能会影响HTN规划器在计划成本和步骤数量方面的比较行为。

此外，这项工作的贡献不仅限于制定基于HTN的规划方法；它还包括在一个统一平台中实现了一个模块化软件工件，该工件集成了BPMN解析、HDDL生成、规划器执行和比较计划分析。这种设计使该提案对大学扩展办公室具有实际意义，因为比较替代执行计划的能力可以支持更一致的调度决策，并改善任务间依赖关系的管理。本研究的新颖之处在于将基于BPMN的项目知识捕获与可追踪的HDDL转换工作流程和比较HTN规划器执行相结合，在大学项目规划环境中进行，而不是将过程建模和自动化规划视为孤立的组件。除了应用于大学项目执行之外，这项工作也从跨学科研究的角度来看也是相关的。通过将基于BPMN的过程建模与HTN规划联系起来，该研究促进了业务流程管理和自动化规划之间的对话，展示了如何将结构化的工作流表示操作化为可执行的项目规划。

从这个意义上说，该研究在方法论上和实践上都做出了贡献：方法论上，通过引入BPMN到HDDL的转换和比较HTN规划工作流程；实践上，通过提供一个可用于形式化和支持大学项目实施的实用替代方案。通过在这些不同领域应用HTN规划，研究人员可以识别共性并开发更通用的解决方案，最终促进该领域的进步。总体而言，将AI规划与组织管理相结合代表了弥合理论AI研究和实际项目之间差距的关键一步。这次整合有潜力提供对人工智能如何在其他现实世界情境中有效使用的更全面理解。本文的其余部分以逻辑清晰、连贯的方式组织，使得观点的进展更加明确。具体来说，结构如下：第2节对相关文献进行了全面回顾，为本文所呈现的工作奠定了基础。第3节概述了开发PlanProjU所采用的方法论，详细介绍了所采取的方法。第4节介绍了实验。第5节展示了这一开发的结果，从而可以评估该方法论的有效性。第6节对发现进行了深入讨论，突出了关键见解和意义。最后，第7节提出了结论和未来的工作。

2. 相关工作和定义
本节强调了研究自动化规划与BPMN过程建模集成到其他用于构建HTN规划领域和问题的应用程序中的重要性。共识别并分析了27项研究，以描述当前BPMN相关规划研究的现状，并确定PlanProjU在这方面的贡献。尽管所审查的研究在过程感知规划、工作流自动化和基于模型的执行支持方面展示了重要的进展，但它们也表现出一些反复出现的局限性。一些研究关注通用过程自动化，而没有针对大学项目管理这一特定领域。其他研究使用工作流表示进行规划，但没有提供层次化的任务公式或可追溯的转换机制。在某些情况下，所提出的方法在形式上是强大的，但缺乏集成的用户界面工具或可比较的规划器执行。因此，有必要对优缺点进行结构化的比较，以明确PlanProjU所解决的差距。如表1所示，先前的研究在过程建模、工作流执行和基于规划的自动化方面提供了有价值的基础。然而，文献仍然缺乏一种结合了基于BPMN的项目建模、可追溯转换为HDDL、可比较的HTN规划器执行以及专为大学项目规划设计的用户导向平台的方法。这一差距激发了PlanProjU的开发。

表1. 文献中识别出的代表性研究的优缺点总结

2.1. BPMN和基于规划的过程自动化
几十年来，人工智能社区一直积极参与业务流程管理研究，大量工作研究了自动化规划技术在流程管理系统中的作用。这些系统旨在管理复杂的业务流程，同时保持对环境和任务变化的鲁棒性、反应性和适应性。最初解决这一研究挑战的工作之一是Reijers（2016）[27]，该工作概述了如何利用规划社区的规划技术来合成新的业务流程，并修复不再适合给定情况的先前定义的流程。这突显了规划技术在提高业务流程灵活性和响应性方面的潜力。Marella（2019）[28]进一步研究了基于规划技术的智能助手的使用，如果预期在流程执行过程中发生故障，该助手可以建议补偿程序或重新执行活动。这证明了规划技术在减轻潜在故障和确保业务流程顺畅运行方面的能力。La Rosa等人（2017）[29]描述了如何将规划与流程执行和计划细化相结合，并研究了计划修补和计划修复作为提高灵活性和响应性的手段。这种将规划与流程执行相结合的方法对于确保业务流程能够适应变化的情况至关重要。

2.2. 文献中的BPMN到规划的方法
规划技术的应用在Web服务组合领域也很重要，其中使用规划来解决复杂的挑战。值得注意的是，只有少数研究使用领域无关的规划器来生成原子Web服务的组合，证明了规划在这一领域的有效性。在[28,29,30,31]中的研究探索了使用规划技术在知识层面实现服务组合的方法，如[34]所示，这突显了规划在解决复杂Web服务组合挑战方面的潜力。此外，像Hoffman[35]这样的研究使用了定制的规划器，包括FF规划器，从以规划方式描述的原子IT实体构建服务编排，展示了规划技术在Web服务组合中的多功能性。此外，结合情境演算与规划技术来执行服务组合[34,35]，提供了一种全面的方法来应对Web服务组合挑战。与将服务视为原子规划操作符的工作不同，大量研究[37,38]将服务视为具有明确定义的行为描述的状态实体，这些描述来自BPEL规范。在这些研究中，所需组合服务的要求用类似时间逻辑的语言表达，并使用基于模型检查的规划技术进行服务组合，强调了在基于规划的Web服务组合中考虑服务状态性质的重要性。同样，Bertoli（2006）[39]等人在符号搜索方面的最新进展表明，像过程建模这样的复杂场景需要将动作模型进行分割。另一方面，由于HDDL开发框架的局限性，过程建模的研究主要基于传统的AP方法发展，而不是HTN。鉴于这一困难，Berchner（2025）[40]开发了一个类似于PDDL中的开发框架的HDDL框架，以改进在过程建模等替代情境中的动作和问题模型的构建。

2.3. 研究差距和PlanProjU的贡献
现有的BPMN到规划的研究提供了有用的基础，但它们没有明确地将基于BPMN的项目建模、可追溯转换为层次化规划表示、多规划器执行以及针对大学项目规划的用户导向支持整合到一个单一的工件中。此外，以前的研究没有明确地将四个方面结合在一个统一的工件中：（i）基于BPMN的项目建模，（ii）可追溯转换为层次化规划表示，（iii）使用多个HTN规划器的执行，以及（iv）通过集成Web平台支持非专家机构用户。为了更明确地定位PlanProjU，表2使用从本研究目标中得出的一组标准，将所提出的工件与代表性的相关方法进行了比较。这些标准关注以前的工作是否支持基于BPMN的建模、自动转换为规划表示、层次化规划、可追溯性、可比较的规划器执行、用户界面交互以及适用于项目规划。

表2. PlanProjU与代表性相关方法之间的基于特征的比较
如表2所示，先前的研究在过程感知规划、工作流自动化和基于规划的自动化方面提供了有价值的基础，但它们没有结合PlanProjU中集成的所有特征。特别是，基于BPMN的项目捕获、可追溯转换为HDDL、使用多个HTN规划器的可比较执行以及在用户界面平台中对大学项目规划的支持，使当前的提案与所审查的相关工作区分开来。因此，这项研究的贡献不仅限于软件集成。首先，它引入了一个针对大学项目规划的BPMN到HDDL转换工作流，其中过程结构被转换为保留任务顺序、分解逻辑和支持分支依赖关系的层次化规划表示。其次，它在基于Web的系统中实现了这一工作流，即PlanProjU，该系统支持使用两个HTN规划器SHOP2和PyHOP生成和比较替代计划。从科学角度来看，这项工作的新颖之处在于通过明确的转换管道和可比较的执行环境，将层次化规划与基于BPMN的大学项目模型相结合。这使该提案与之前的BPMN到规划方法区分开来，后者要么在不同的领域操作，要么依赖于非层次化的规划公式，要么没有暴露出可追溯和用户导向的规划工作流。从这个意义上说，PlanProjU的贡献不仅对于大学项目执行的自动化很重要，而且对于业务流程建模和层次化规划集成研究也很重要，特别是在需要将机构工作流转换为可执行规划知识的领域。因此，PlanProjU不仅仅被定位为一个实现平台，而是一个针对大学项目执行的BPMN到HDDL转换和可比较HTN规划框架。

2.4. 技术基础和规划器选择理由
选择HTN规划是因为大学项目执行本质上是层次化的，需要将机构计划分解为子项目、任务和操作决策。HDDL为层次化规划领域和问题提供了标准化的表示，提高了形式上的清晰度和互操作性。选择SHOP2和PyHOP作为互补的HTN规划器，是因为它们能够从相同的BPMN派生的规划结构生成不同的替代计划，尽管在实现风格和操作行为上有所不同。HTN规划实例可以写为?? =???,??, ??,??,??0,???????,??,???。这里，L、A、??0、??和??具有经典规划中的通常含义（文字集、原始动作集、初始状态、目标条件以及成本/度量）。集合C包含抽象任务符号（高级活动），并且与原始任务名称不相交，即?? ∩?? =?。任务被排列成任务网络????? =???,?, ???，其中T是一个（可能为空的）任务标识符集合，?? :?? →?? ∪??为每个标识符标记一个原始任务或抽象任务——允许同一任务名称在网络中出现多次。优先关系? ?????????是一个严格的偏序（不可逆的、传递的，因此是不对称的）。组件??表示将抽象任务分解为子网络的方法集合，???????是初始任务网络。

当两个任务网络????? =???,?, ???和?????′ =???′,?′, ??′?仅在任务标识符的重命名上不同时，它们是同构的。形式上，存在一个双射?? :?? →??′，使得对于所有??,??′ ∈??：(??,??′) ∈ ? ?(???(??),???(??′)) ∈ ?′且???(??) =??′?(???(??))。在HTN规划中，分解由方法指定。方法将抽象任务符号?? ∈??与子任务网络?? =???,???,?????配对。考虑一个任务网络?????1 =???1,?1,??1?和一个标识符?? ∈??1，使得??1?(??) =??。可以通过用子任务网络的新鲜副本替换t来应用方法??，得到一个任务网络?????2 =???2,?2,??2?。形式上，必须存在一个同构的重命名θ，使得^?? =?^??,?^??,??^???具有新鲜的标识符（??1 ∩^?? =?）且?? ?^??。存在一个任务网络?????′ =???′,?′, ??′?，其中?????′ ??????且??1 ∩??′ =?。任务网络?????2定义如下：
?????2=((??1\{??})∪??′,?′∪???,(??1\{??→??}∪??′)),
(1)
???={(??1,??2)|(??1,??)∈ ?1,??2∈??′} ∪{(??1,??2)|(??1,??2)∈ ???1,??1∈ ???′} ∪{(??1,??2)|(??1,??2)∈??1,??1≠??∧??2≠??}
??是分解方法的集合。我们将写???????,?? →?????′来表示可以通过应用方法??将?????分解为任务网络?????′，如果可以使用一系列方法将?????分解为?????′。分解可以从单个初始任务开始，也可以从任务网络开始（可能包含多个任务）。使用单个初始任务有时有助于保持证明的简单性。使用初始任务网络可以将搜索空间中的每个搜索节点解释为一个新的规划问题[44]。然而，这两种定义是等价的：给定一个初始任务网络???????，可以通过引入一个新任务????（即新的初始任务）和一个将新任务分解为原始任务网络?? =(????,???????)的方法??来编译它。

一个任务网络????? =(??, ?,??)是给定HTN规划问题?? =(??,??,??,??,??0, ???????,??,??)的解，当且仅当以下解决标准成立：
??????? →??????，即可以通过分解初始任务网络达到它。
??? ∈?? :???(??) ∈??，即所有任务名称都是原始的。
存在一个任务序列???1,??2….?????，它在?中是一致的，即??? 最后一个解决标准要求HTN解决方案导致目标状态。这是相当不寻常的，因为大多数层次化形式主义缺乏（基于状态的）目标定义，尽管有些形式主义有，例如Bercher（2017）[45,46]引入的那些。

选择HTN规划是因为大学项目执行本质上是层次化的。机构性举措通常被分解为子项目、活动、依赖关系和操作决策，这些可以通过任务细化来更自然地表示，而不是通过扁平的动作序列。这使得HTN规划特别适合于建模项目实施工作流，在这种工作流中，高层次的项目目标是通过逐步细化的活动来实现的。HDDL被选为规划表示语言，因为它提供了一种正式和标准化的方式来表达层次化规划领域和问题。在本研究的背景下，HDDL是合适的，因为它允许从BPMN模型中提取的层次结构以任务、方法和规划问题的形式进行编码，具有明确的形式语义。这提高了生成规划成果的可重复性，并促进了转换模块与HTN规划环境之间的互操作性[47]。选择了两种HTN规划器进行比较执行：SHOP2和PyHOP。选择SHOP2是因为它是一个成熟且建立良好的HTN规划器，支持显式的领域知识和有序的任务分解。选择PyHOP是因为它提供了一个轻量级且灵活的HTN环境，更容易通过编程进行集成和实验。它们的联合使用使得可以比较不同的HTN实现在同一BPMN派生的规划表示上执行时的行为。选择SHOP2和PyHOP的依据是五个标准：(i) 与层次化任务分解的兼容性，(ii) 实施的实用性，(iii) 在HTN研究中的成熟度和先前使用情况，(iv) 互补的实现风格，以及(v) 集成到PlanProjU转换和执行工作流中的可行性。因此，这些规划器的选择是方法论上的和实用的，而不是任意的。

2.4.1. SHOP2
SHOP2首次在2002年的“国际规划竞赛”[48]中展示。它最初是用Lisp语言编写的，Lisp是一种函数式编程语言，与SHOP类似。SHOP2的一个关键特性是它保持了规划任务的执行顺序，这使得它可以快速生成计划[21]。然而，SHOP2与SHOP有一个重要的不同之处：它允许子任务部分有序，同时仍然保持性能。这一修改还使得可以使用规划操作转移和分解（POTD）方法[1]来交错不同任务的子任务，从而避免了全局规划指令的需要。要启动SHOP2规划器，需要定义：
s :i?n?i?t?i?a?t?e, s?t?a?t?e, T :p?a?t?i?a?l?y o?r?d?e?d s?e?t of s?u?b t?a?s?k?s a?n?d D :d?o?m?a?i?n o?c?t?i?o?n m?o?d?e?l
开始时执行：run SHOP2(??,??,??)。
[1]中的伪代码示例：
??←??,??????? ??=0 ?????????? ????????????????? ???????????????????????????????????????????????????????????????????????????? ????????????? ?? ??????????? (??,??)∈?? ??????????????2 ?? ????? ??????????????????????? ??, ????????????????? ?????????(??)????? ?????????(??) ≠0 ?????????? ??0←??∈?????????(??)??????????? ??0←??∈??

2.4.2. HDDL
层次化领域定义语言（HDDL）是规划领域定义语言（PDDL）的扩展，它包含了层次化任务网络（HTN）。由Nau和Holler[48]引入，HDDL为层次化规划系统提供了一种标准化的语言，并附带了全面的文档和一系列领域及问题。这些资源中的许多来自国际规划竞赛（IPC-HTN）的层次化任务网络赛道，特别是2023年的IPC-HTN赛道。HDDL的设计使用户能够通过调整层次化任务网络来定义或修改问题解决方法，以满足他们的特定需求。
规划动作模型或领域的定义：一个规划领域??是一个元组（??,????,????,??），它定义了：??是底层谓词逻辑，????是原始任务和复合任务的有限集合，????是复合任务，??是从???? ∪????集合上的任务网络的分解方法的有限集合。
规划问题的定义：一个规划问题??是一个元组（??,????,???????,??），它定义了：???? ∈??是在假设封闭词的情况下谓词的正文字的合取。???????是初始任务网络，可能不一定被具体化。??是目标描述，是对谓词的一阶公式（不一定被具体化）。

2.4.3. PyHOP
PyHOP是一个用Python编写的简单HTN调度器，兼容2.7到3.2版本，代码行数少于150行。它的调度算法基于SHOP的算法，但它通过使用Python来编写任务网络及其方法，避免了需要特定的调度语言，使用替代语法来定义变量、动作和方法。PyHOP的开发源于这样一个观察：应用程序开发者经常自己编写调度系统，而不是学习专门的AI调度语言。PyHOP的创建旨在提供一个对没有AI经验的人来说易于理解的HTN调度器。PyHOP的作者并没有过多地推广它，但其易于理解和使用的特点使其在快速原型设计中非常有用，从而被用于各种项目和出版物中。表3显示了组件、选择标准和在HTN规划中的使用理由。

HTN规划特别适合这项工作，因为大学项目的实施本质上是层次化的：机构性举措被分解为子项目、活动和操作决策，这些可以表示为任务细化，而不是扁平的动作序列。选择HDDL是因为它提供了一种标准化的正式语言来表达层次化规划领域和问题，提高了互操作性和可重复性。选择SHOP2和PyHOP作为互补的HTN规划器，是因为它们允许在同一生成的规划结构上进行比较执行，同时在实现风格和操作行为上有所不同。这使得研究不仅可以检查是否可以生成BPMN派生的层次化计划，还可以检查规划器的选择如何影响最终的方案。

3. 方法论
本研究采用设计科学研究（DSR）方法作为构建和评估旨在解决相关实际问题的工件的系统方法论。在这项研究中，DSR为设计PlanProjU、实现BPMN到HDDL的转换工作流以及评估生成的规划工件提供了框架[49]。本文旨在使用自动化规划为大学项目开发实施计划，这种方法通过案例研究得到了验证[50]。本节描述了用于构建和评估PlanProjU工件的DSR程序。它解释了问题分析、工件设计、实现和评估所遵循的方法论阶段。结果规划系统将能够识别大学项目实施计划，并促进创建适用于各种情境的通用项目规划环境。下图1显示了DSR方法论。图1. DSR的阶段。来源[50]。
图1显示了设计科学中的研究过程是一个结构化和系统化的方法，涉及几个阶段，以确保开发出针对相关问题的明智且有效的解决方案。该过程从第1阶段识别相关问题开始，这对于在第2阶段制定结构化的研究问题至关重要。理解问题及其背景，包括工件的原因和功能，在这一阶段至关重要，因为它为后续阶段提供了坚实的基础。
第3阶段的系统文献回顾涉及咨询各种技术数据库，如Scopus、WoS、IEEE、Google Scholar和ArXiv，以证明开发工件和解决问题的重要性。这一阶段至关重要，因为它使研究人员能够识别现有的知识空白和改进领域，从而指导工件的开发。第4阶段，识别解决类似问题的工件，使研究人员能够应用最佳实践，而问题类别的配置定义了他们的贡献范围。这一阶段至关重要，因为它使研究人员能够基于现有知识开发出针对特定问题的解决方案。第5阶段提出工件与解决特定问题相关，研究人员考虑所提出工件的可行性和现实性。这一阶段至关重要，因为它使研究人员能够开发出实用且有效的解决方案。第6阶段，所选工件的设计涉及考虑其运行的整个环境以及对研究问题的满意解决方案。
在这一阶段描述构建和评估工件的所有程序是必要的，因为它提供了对研究方法论的清晰理解。第7阶段进行工件的构建，而第8阶段涉及评估工件的行为，以提供对问题的满意解决方案。这一阶段至关重要，因为它使研究人员能够评估解决方案的有效性并识别改进领域。第9阶段涉及澄清所获得的学习成果，解释促成研究成功的因素以及失败的因素。这一阶段至关重要，因为它使研究人员能够反思他们的经验并识别改进领域。第10阶段的结论展示了研究结果、实施过程中做出的决策以及可能引发未来研究的局限性。这一阶段至关重要，因为它使研究人员能够传达他们的发现，并为该领域的知识进步做出贡献。第11阶段允许将知识推广到类似的情况，而第12阶段涉及通过期刊、研讨会、会议和其他平台传播结果，从而通过出版物显著推进知识。这一阶段至关重要，因为它使研究人员能够传播他们的发现，并为更广泛的学术界做出贡献。

3.1. 设计工件：映射到图模型BPMN
在这一步中，介绍了DSR方法论的第5阶段，前提是之前的阶段已经得到了充分的开发和验证。在前几个阶段建立的基础为后续阶段提供了坚实的框架，确保了研究的连贯性和系统性。在这一阶段，引入了专门为解析BPMN图而设计的算法1。该图是由一位过程设计专家为大学外展项目作为案例研究开发的，为研究提供了实际背景。这种基于图的中间表示不仅是工件的实现细节，也是支持语义提取过程的方法论步骤。它为识别活动依赖关系、分解边界和分支关系提供了结构基础，这些在HDDL中得到操作化之前。从这个意义上说，图模型充当了BPMN过程语义和层次化规划表示之间的桥梁。

3.2. 算法：解析或翻译BPMN到HDDL
在PlanProjU中实现的翻译旨在提供支持的BPMN构造与HDDL中的层次化规划表示之间的可追溯的操作对应关系。在当前版本中，转换明确处理了核心工作流元素，如任务、序列依赖关系、网关和项目分解结构。与声称在整个BPMN标准上具有完全的语义完整性不同，当前工作专注于与大学项目规划相关的BPMN构造的子集。HDDL特别适合这种工作流，因为PlanProjU处理的BPMN模型描述的项目结构不仅仅是顺序的，而是层次化和可分解的。因此，转换需要一种能够编码复合任务、细化方法和可执行问题实例的表示形式。HDDL以标准化形式提供了这种能力，使其适合表示从BPMN项目模型中提取的层次化语义，以便HTN规划器可以在平台上系统地检查和执行。
在这个范围内，翻译提供了三个实际保证。首先，它保留了BPMN模型中编码的支持活动的结构顺序和优先关系。其次，它通过HDDL中的层次化任务公式保留了分解逻辑。第三，它实现了BPMN元素与生成的规划实体之间的可追溯性，允许用户和开发人员检查过程级知识如何转换为可执行的规划表示。对任意BPMN模型的正确性和完整性的形式证明超出了本文的范围，并被确定为未来工作的方向。表4显示了BPMN到HDDL的映射。

表4. PlanProjU中使用的BPMN到HDDL映射。

为了使评估指标明确，PlanProjU将生成计划的成本定义为分配给其可执行动作的成本之和：
????????????(??)=∑??∈?????(??) (3)
其中π表示生成的计划，a表示计划中包含的每个可执行动作。根据这种表述方式，总计划成本等同于生成计划中包含的可执行动作的数量。采用这种表述方式是为了提供一个简单、透明且可复制的比较标准，以便在不同从相同BPMN派生项目模型生成的计划之间进行比较。因此，在PlanProjU的当前版本中，成本指标应被解释为一种结构化的计划比较度量，而不是项目执行的详细经济模型。未来的工作可能会通过引入基于活动类型、资源使用、执行时间或机构成本数据的差异化权重来扩展这种表述方式。下表5显示了作为HTN领域元素表示的BPMN元素。表5. 从BPMN活动到规划动作的基于规则的映射。

3.3. 工件：PlanProjU
PlanProjU系统是在DSR方法论框架内设计的，提供了一种结构化且可重用的大学项目规划方法。该系统以BPMN图作为输入，将项目知识转换为HDDL领域和问题表示，这些表示可以由不同的HTN规划器执行。除了生成有效的计划外，该工件还旨在作为一个决策支持平台，允许项目经理在共同的过程规范下比较规划器的输出，从而提高实施调度和依赖管理的一致性。图2展示了这个模块化平台的架构。图2. PlanProjU系统架构。来源：自制。图2总结了PlanProjU的分层软件架构，并强调了将基于BPMN的大学项目模型转换为可执行的HTN规划工件的端到端工作流程。该架构分为四个主要层次：表示层、应用层、处理层和规划层。在表示层，用户通过基于Web的界面与平台交互，该界面支持项目注册、BPMN上传、计划可视化和结果检查。应用层通过FastAPI实现的REST API暴露核心服务，而身份验证和授权则通过基于JWT的访问控制和基于角色的权限来处理。处理层负责BPMN解析、语义提取、图构建以及转换为HDDL领域和问题文件。最后，规划层使用HTN规划器执行生成的表示，并将结果计划和比较指标返回给用户界面。这种分层设计支持平台内的模块化、可追溯性和可扩展性。项目管理组件协调CRUD操作、文件上传和元数据处理，将持久化责任委托给数据层，其中PostgreSQL支持事务存储（ACID）和JSONB结构，Redis为热点数据提供性能优化，并且文件存储维护BPMN文件和相关文档。最后，处理层实现了核心研究贡献：BPMN解析器执行XML处理、结构验证和模型特征提取，然后将结果输入规划引擎，该引擎使用替代算法（SHOP2和PyHOP）生成可比较的计划变体。这个流程展示了一个为模块化和可扩展性设计的架构，允许BPMN解析子系统、规划后端和用户界面独立发展，同时能够在单一平台内系统地比较规划结果。这种模块化分离对于机构采用尤为重要，因为它允许规划工作流程、BPMN解释过程和替代计划的比较评估被重用和扩展，而无需重新设计整个系统。图3展示了PlanProjU的组件。图3. PlanProjU主要组件。来源：自制。图3提供了PlanProjU平台的组件级视图，并详细说明了在项目建模和计划生成过程中主要模块之间的交互。该架构包括用户界面、项目管理服务、BPMN处理模块、身份验证服务以及负责生成基于HTN的替代计划的规划引擎。这一视图补充了图2中展示的分层架构，突出了参与BPMN解释、HDDL生成、规划器执行和结果可视化的具体软件组件。图3表明，PlanProjU不仅是一个用于输入项目信息的前端应用程序，还是一个将知识捕获、形式转换和比较计划分析集成在一个平台中的综合工件。这些交互由围绕基于JWT的身份验证（令牌生成、会话管理、安全层）、项目管理（CRUD操作、文件/元数据处理）、作为协调器的规划服务（算法选择和异步执行）以及用于用户/系统配置和分析的管理模块来中介。

在处理引擎中，BPMN解析器执行XML解析、模式验证和结构提取，生成准备规划的表示，然后由两种替代规划器SHOP2（分层HTN、深度优先搜索、成本优化）和基于PyHOP的引擎（基于状态的HTN执行）执行。计划输出和运行时指标由专门的指标分析器汇总，该分析器支持质量评估、性能统计和比较评估，然后将结果数据反馈给前端进行可视化和决策支持。这一组件是PlanProjU实际贡献的核心，因为它使用户能够检查从相同BPMN模型生成的替代执行计划，并在选择实施策略时使用比较证据。总体而言，架构证明了一种模块化设计，使得规划子系统、指标评估和UI层之间的紧密集成能够独立发展，这是研究级规划平台中可复制实验和迭代改进的重要属性。图4展示了PlanProjU的使用层次。图4. PlanProjU使用层次。来源：自制。图4展示了PlanProjU用于解析BPMN模型并将其转换为规划表示的内部工作流程。该图显示了上传的BPMN/XML文件如何被处理以识别相关的结构元素，构建中间图表示，并提取分层规划所需的依赖关系。然后使用这些元素生成相应的HDDL领域和问题文件，这些文件随后由选定的HTN规划器执行。这种转换工作流程是本文贡献的核心，因为它将编码在BPMN中的项目知识转换为可执行的规划工件，同时保留了原始过程模型支持的结构关系。工作流程还通过导出结果（PDF/Excel/JSON）和可定制的报告生成得到了补充，这支持可追溯性和离线审查。同时，平台提供了面向治理的功能，如配置参数（算法设置、高级调整和微调）和管理用户（CRUD操作、角色/权限和访问控制），这些主要与管理员的责任对齐，但根据权限分配可能有所不同。总体而言，该图展示了操作执行和系统管理之间的明确分离，同时确保了从BPMN摄取到计划评估和报告的整个规划生命周期在一致的基于角色的访问控制（RBAC）方案下得到支持。此外，还为UTP案例生成了仅限SHOP2的导出，该导出是在不同的参数配置下进行的。由于这次辅助运行没有在相同条件下与PyHOP执行配对，因此没有包含在主要比较分析中，仅作为补充证据。

4. 实验
本节通过基于案例的比较分析，评估了PlanProjU作为设计科学工件的性能，分析了从BPMN派生的大学项目模型生成HTN计划的情况。评估重点关注两个目标：(i) 验证基于BPMN的项目规范可以转换为可执行的规划表示并产生有效的替代计划；(ii) 比较SHOP2和PyHOP在相同项目输入下的行为。该研究比较了SHOP2和PyHOP这两种互补的HTN规划环境，选择它们是因为它们的实际可行性、不同的操作风格以及与PlanProjU中实现的BPMN到HDDL工作流程的兼容性。

4.1. 评估目标和设计
实验评估旨在评估BPMN到规划的流程的可行性以及集成到PlanProjU中的规划器的比较行为。具体来说，研究检查了系统是否能够一致地从大学项目模型生成替代计划，以及生成的计划在成本、步骤数量和执行时间方面是否因使用的规划器而有所不同。评估不仅依赖于定性检查，还使用描述性统计总结了每个规划器和案例的导出计划变体，从而可以使用一组共同的指标来比较规划器，并描述生成计划的观察到的变异性[51]。

4.2. 案例研究
使用了PlanProjU生成的输出分析了三个案例研究。第一个案例与环境治理和领土干预相关的UTP项目有关。第二个案例是标记为U Caldas proyection 1的大学扩展工作流程。第三个案例是Extension FADMON过程。在所有三个案例中，系统都识别了一个主要子项目，并使用PyHOP和SHOP2生成了替代计划。UTP案例包含16个活动。其BPMN模型包括16个任务、2个并行网关、21个序列流、1个开始事件和1个结束事件，最大分支度为3，没有循环结构。U Caldas proyection 1案例包含20个活动。其BPMN模型包括20个任务、11个排他网关、42个序列流、1个开始事件和3个结束事件，最大分支度为4，没有观察到循环。Extension FADMON过程案例包含6个活动。其BPMN模型包括6个任务、1个排他网关、9个序列流、1个开始事件和1个结束事件，最大分支度为2，没有观察到循环。表6显示了评估的BPMN案例的结构特征。

4.3. 执行协议
对于每个案例，PlanProjU使用PyHOP生成了三个计划变体，使用SHOP2生成了三个计划变体，每个案例共有六个计划，三个案例研究总共十八个计划。每个案例中使用相同的项目规范作为规划器执行的基础，从而可以直接比较两种规划器产生的输出。由于可用证据对应于导出的计划变体，而不是在基准环境中的随机重复试验，因此报告的统计应被视为每个案例的规划器输出的描述性总结。因此，比较强调了生成计划在成本、步骤数量和输出稳定性方面的观察到的差异。

4.4. 指标和统计处理
评估中使用的主要计划级指标包括：(i) 总计划成本；(ii) 总步骤数量；(iii) 以秒为单位的执行时间。在案例层面，研究还报告了输入模型的结构描述符，包括子项目数量和活动数量，如果BPMN模型可用，还包括任务数量、网关数量、序列流数量、结束事件数量和分支度。对于每个案例-规划器组合，分析报告了生成的计划变体数量、平均值、标准差、最小值和最大值（针对成本和步骤数量）。执行时间也进行了描述性报告；然而，由于导出文件中记录的值非常小，应谨慎解释时间差异。评估中报告的成本指标遵循“成本模型和从BPMN到规划动作的基于规则的映射”部分描述的单位成本模型。根据这种表述方式，每个可执行的规划动作的成本为1，而事件和网关的成本为0。因此，总计划成本对应于生成计划中包含的可执行动作的数量。由于当前实现采用了可执行动作的单位成本，总计划成本与计划长度密切相关。因此，为了完整性，这两个指标都被报告，但应将其视为当前系统中同一结构属性的互补视图。为了保持方法论的一致性，修订后的手稿将定量比较限制在可以直接从导出的规划证据中验证的指标上。当前评估侧重于可以直接从生成的规划输出中计算的结构比较指标。特别是，使用计划成本和计划长度来比较替代计划在动作组成和执行紧凑性方面的差异。这些指标并未完全捕捉项目计划质量的所有相关维度，如资源利用、对风险的响应性或执行灵活性，这些超出了当前评估的范围。

4.5. 范围和当前限制
当前评估支持PlanProjU流程的可行性，并提供了对SHOP2和PyHOP在真实大学项目案例上的初步比较特征描述。然而，当前的证据在范围上仍然有限。该研究包括三个案例研究，每个案例研究都有一个主要的子项目，目前尚未构成一个涵盖系统多样化BPMN（业务流程建模）家族的大规模基准。因此，研究结果应被视为对这一工具的结构化案例验证，而不是一个确定的可扩展性基准。通过使用更多的BPMN模型和完整的计划日志进行更广泛的评估，将能够未来分析深度、计划规模、可扩展性以及对更复杂工作流模式（如循环、异常和密集的并行资源依赖性）的敏感性。

4.6. 以用户为中心的评估
为了补充以系统为中心的评估，通过一份结构化的问卷对与平台互动的五名参与者进行了以用户为中心的评估。受访者包括三名大学扩展经理、一名研究人员和另一名参与者。问卷内容包括与基于BPMN的项目表示、易用性、生成计划的充分性、规划问题和生成计划的可见性、注册难度以及对大学扩展的感知价值相关的封闭式问题。收集到的回答通过频率分析二分式问题，并通过平均值分析李克特类型问题。这项评估旨在提供潜在机构用户对系统可用性和实际相关性的初步证据。然而，由于该问卷较为简短，并非按照标准化的SUS（系统使用满意度）、TAM（技术接受度）或UTAUT（用户任务态度）问卷设计，因此所得到的证据应被视为描述性的用户反馈，而不是一个完整的正式可用性基准。

5. 结果
研究表明，该平台结合了HTN（层次化任务网络）规划环境与BPMN标准中表示的任何大学项目的基础知识捕获能力。在报告的比较中，总计划成本应按照PlanProjU采用的单位成本公式进行解释。由于每个可执行动作都会增加一个单位成本，因此该指标反映了生成计划中选定的可执行动作的总数。因此，这里使用成本作为透明的结构比较指标，而不是直接估计财务支出。表7显示了聚合的计划器性能。表7总结了三个评估案例中聚合的计划器结果。在UTP案例中，SHOP2生成的计划成本和长度都显著低于PyHOP，平均成本从167.67降至15.33，平均步骤数从16.67降至4.00。在UCaldas项目1案例中，SHOP2再次产生了更低的平均成本和更少的步骤数。相比之下，在Extension FADMON流程案例中，PyHOP实现了更低的平均成本，而SHOP2生成的计划平均长度略短。这些结果表明，计划器性能取决于具体案例，不应将任何单一计划器视为适用于所有项目结构的最佳选择。

以用户为中心的评估得出了令人鼓舞的描述性结果。在五名受访者中，80%的人表示可以在PlanProjU中将扩展项目表示为BPMN流程，60%的人认为该平台易于使用。在李克特类型问题中，生成计划中项目活动的充分性平均得分为3.8/5，规划问题和生成计划的可见性得分为4.0/5，PlanProjU对大学扩展的感知价值得分为3.8/5。这些发现表明用户对平台有积极的初步印象，尽管在入职和注册方面并未获得一致的好评。表8显示了PlanProjU系统的使用情况。表8显示了以用户为中心的评估的描述性结果。在大学扩展经理子组（N=3）中观察到了更积极的结果。在这个子组中，100%的人表示可以在PlanProjU中使用BPMN表示扩展项目，并且认为该平台易于使用。生成计划的充分性、规划输出的可见性和对扩展的感知价值的平均得分分别为4.33/5、4.67/5和4.33/5。

该平台生成的计划有助于项目经理选择在大学中实施项目的最佳方法。项目制定者或负责执行大学项目的人员可以通过该系统获得适用于不同大学环境的实施计划，该系统以用户为中心。平台不需要规划专家来建模动作和问题，而是接受.xml格式的BPMN图。平台根据BPMN输入生成多种项目实施计划，并通过计划成本和步骤数等结构化指标支持它们的比较。在当前版本中，成本遵循单位成本公式，因此应将其解释为结构比较指标，而不是直接估计财务支出。这使项目经理能够在大学环境中检查不同的执行策略并支持实施决策。

研究表明，PlanProjU系统将HTN规划环境与专门针对大学项目的BPMN知识源相结合。它根据不同的指标生成多种计划，从而支持大学环境中的项目实施。项目开发者可以通过该系统自动生成实施或执行计划，而系统始终关注用户需求。该平台已在哥伦比亚的公立大学参与者的机构环境中进行了测试。对于UNAL-Audifarma项目，在bpmn.io平台上生成了以下BPMN模型，如图5所示。图5展示了Audifarma-UNAL培训扩展项目的BPMN模型，该模型通过池/通道定义了责任（请求者、课程协调/管理和教学/交付角色）。流程从课程请求和提案的准备/提交开始，随后是审查和决策活动，这些活动由一个专用网关支持，根据结果将流程分支为批准或拒绝。如果获得批准，模型还包括定义日期和资源分配等规划活动，以及一个指定物流和/或成本条件的网关，规定额外成本由公司承担。然后，课程的交付（每次3小时，共5次）与出勤记录相关联，出勤记录作为合规控制：只有当参与者至少出席80%的课程时才会颁发证书；否则，将导致未认证的结果。总体而言，该图展示了具有明确决策点、成本可追溯性和验证机制（出勤）的过程，确保培训服务的提供与机构认证标准一致。

与每位官员的互动大约需要1到1.5小时，考虑到平台演示会议期间的中断。每位官员都接受了平台导航的指导，并被告知右上角的问号中包含一个在平台内开发的指南，以帮助他们构建BPMN图。在互动过程中，一些官员表示需要查看BPMN或XML格式的文件。他们被告知，PlanProjU平台不提供这种可视化功能，因为它专注于HTN类型的人工智能规划，而不是生成符合BPMN标准的图表可视化。然而，他们被告知可以使用bpmn.io工具加载生成的bpmn或xml文件来查看和修改图表，并且将可视化模块集成到平台架构中是未来的研究工作。图6展示了在PlanProjU中生成的计划。图6展示了PlanProjU为Audifarma-AUNAL培训案例生成的计划。该平台为每种计划器（SHOP2和PyHOP）生成了六个计划，并以摘要形式展示了每种算法的最佳计划以及基于最低成本标准的总体推荐。这一组织对于验证非常重要，因为它将BPMN 2.0过程的结果转换为一组基于成本和步骤长度指标的可比选项。这使最终用户或公共官员不仅可以评估单个计划，还可以评估不同搜索/启发式变体之间的解决方案稳定性。分析哥伦比亚国立大学的数据揭示了经济效率与计划长度之间的明显权衡：SHOP2在其家族中被选为最佳，成本为6，步骤数为7；而PyHOP v3的成本为7，步骤数为4。因此，平台推荐SHOP2，因为它便宜一个单位，尽管计划长度更长。这种行为表明，对于这个项目，搜索过程对某些决策的惩罚比单纯减少活动数量更为严重。从解释角度来看，PyHOP似乎生成了步骤更少的计划，但总体成本更高；而SHOP2则实现了更优的解决方案，这与进一步分解活动可以选择更便宜的替代方案的情景一致。

最后，在比较请求公司、国立大学和教授三个面板时，很明显平台保持了相同的决策逻辑，并明确突出了结果的敏感性：例如，在请求公司面板中，由于成本差异为1 vs. 5，推荐选择了SHOP2；而在教授面板中，SHOP2的优势仍然存在（5 vs. 7），尽管计划长度较短（4–5步）。这种跨领域的一致性加强了PlanProjU作为决策支持工具的实用性，因为作为扩展办公室工作人员的用户可以根据可量化的差异来证明所推荐计划的选择是合理的。此外，当成本不是唯一相关标准时，他们还可以检查其他选项（v1–v3）。总体而言，这些数据表明，验证过程不仅限于生成计划，还允许对计划器生成的计划进行可复制的比较分析。表9和表10显示了PyHOP和SHOP2生成的计划。表9显示了使用PyHOP为UNAL-Audifarma项目生成的计划。表10显示了使用SHOP2为UNAL-Audifarma项目生成的计划。图7展示了为UNAL-AUDIFARMA扩展项目生成的计划的比较指标。图7使用两个评估标准（总计划成本和步骤数）展示了SHOP2和PyHOP为UNAL-AUDIFARMA项目生成的计划的比较视图。上方面板显示SHOP2为该案例生成的计划成本低于PyHOP，表明在平台采用的成本模型下这是一个更高效的解决方案。下方面板显示SHOP2在步骤数上也生成了更短的计划，表明规划问题的分解更为紧凑。综合这些结果，表明对于这个项目，根据两个评估指标，SHOP2的表现优于PyHOP。因此，这个案例说明了在PlanProjU内比较不同计划器的实际价值，而不是依赖单一执行策略。

对于Caldas大学项目，在bpmn.io平台上生成了以下BPMN模型，如图8所示。图8展示了Caldas大学项目的BPMN模型。该图明确了主要活动、控制流结构和定义项目工作流的决策点，在转换为层次化规划表示之前。这个BPMN模型作为PlanProjU的过程级输入，并为生成相应的HDDL领域和问题文件提供了结构基础。这样，该图展示了项目知识如何首先在BPMN中形式化，然后再转换为可执行的规划工件。图9展示了在PlanProjU中为Caldas大学项目生成的比较计划输出。图9展示了在PlanProjU环境中SHOP2和PyHOP为Caldas大学项目生成的比较计划输出。该图强调了两种计划器如何从相同的BPMN派生项目表示生成不同的计划，尽管在成本、步骤数和内部分解结构上存在差异。这种比较可视性在大学项目规划中非常重要，因为它允许用户在选择实施策略之前评估各种权衡。这表明获得最佳计划的步骤减少了49步。在大学项目规划中，这种比较可见性非常重要，因为它允许用户在选择实施策略之前评估各种权衡。这支持了界面自动推荐SHOP2的决策，因为SHOP2的成本低了49个单位。SHOP2计划的详细分解显示了一个具体且可追踪的活动序列，表明该计划优先考虑了以最低总成本达到目标状态的最低程序。同样，每个规划器存在多个变体，揭示了一系列具有成本-长度权衡的解决方案：SHOP2提供了成本和步骤同时变化的替代方案，而PyHOP保持了10步的恒定长度，但成本不同（分别为17和66），这与搜索策略和任务分解的差异一致。总体而言，该图表支持了平台生成计划并允许用户根据成本和步骤长度指标选择最佳计划的观点。表11和表12显示了使用PyHOP和SHOP2为Caldas大学生成的计划。图10显示了为Caldas大学扩展项目生成的计划的比较指标。图10显示了Caldas大学扩展项目生成计划的比较指标。来源：自制。图10通过报告总计划成本和步骤数量，展示了SHOP2和PyHOP在Caldas大学扩展项目中的比较分析。在上方面板中，SHOP2生成的计划成本低于PyHOP，表明对于这种情况下考虑的BPMN派生规划问题，SHOP2是一个更高效的资源解决方案。在下面板中，SHOP2还生成了更短的计划，这表明执行结构更为紧凑，操作应用也更少。SHOP2在这两个指标上的双重优势表明，规划器的选择可以显著影响生成方案的质量。这一结果支持了将多规划器比较集成到PlanProjU中的价值，作为其决策支持能力的一部分。

6. 讨论
本节不仅解释了结果，还讨论了它们对大学项目规划的影响。首先，它研究了规划器相对于评估的BPMN案例的结构特征的比较行为。其次，它讨论了这些发现对大学项目经理的实际意义。最后，它概述了当前研究的主要方法论局限性和有效性威胁。

6.1. 规划器比较的解释
本小节考虑了案例结构和评估范围，解释了规划器的比较结果。比较结果表明，规划器的行为取决于具体案例，不应通过单一的普遍优势标准来解释。在UTP案例和U Caldas projection 1案例中，SHOP2产生的平均成本和平均步骤数都低于PyHOP，这表明在结构更丰富和分解要求更高的工作流中，SHOP2的表现更强。相比之下，在Extension FADMON过程案例中，PyHOP实现了更低的平均成本，而SHOP2仍然平均生成了稍微短的计划。这种模式表明，每个规划器的相对适用性取决于项目结构和用户优先考虑的优化标准。表6中包含的结构BPMN描述符也有助于将规划器比较置于具体背景中。更大和更分支的案例显示了SHOP2和PyHOP之间更明显的差异，表明工作流结构在规划器行为中起着重要作用。尽管当前数据集尚未包括节点扩展等规划器内部指标，但现有表格为将计划结果与案例复杂性联系起来提供了更清晰的基础。第二个相关发现是，随着BPMN模型包含更多活动、网关和分支选项，规划器之间的差异变得更加明显。UTP和U Caldas案例在结构上比Extension FADMON过程更复杂，显示出SHOP2和PyHOP之间更明显的分歧。这表明规划器的选择不仅仅是一个技术实现细节，而是一个可以影响最终执行策略的分析因素。因此，应将规划器比较的支持视为PlanProjU贡献的一部分，而不仅仅是一个附加平台功能。报告的规划器之间的差异应在本研究使用的指标范围内进行解释。由于评估主要基于成本和步骤数量，结果表明了结构效率和分解行为的差异，而不是对计划质量的全面评估。其他相关维度，如资源分配效率、对中断的适应性和在变化执行条件下的灵活性，在当前研究中并未直接测量。

比较结果表明，规划器的适用性取决于项目结构和优化标准。在UTP和U Caldas projection 1案例中，SHOP2生成了成本更低且更短的计划，表明在结构分支和分解选项更多的工作流中表现更强。然而，在较小的Extension FADMON过程案例中，PyHOP产生了更低的平均成本，而SHOP2在计划的紧凑性方面保持了轻微的优势。这种模式表明，在结构更复杂的项目模型中，SHOP2可能更具优势，而在优先考虑成本而非紧凑性的情况下，PyHOP可能仍然具有竞争力。

6.2. 对大学项目管理的实际意义
本小节讨论了这些发现对大学项目管理的实际意义。从实际角度来看，结果表明PlanProjU可以通过使项目结构、依赖关系和执行选项更加明确来支持大学项目经理。通过使用BPMN作为输入语言，该平台允许将机构知识捕获在一个熟悉的过程建模格式中，并随后转化为可执行的规划工件。这在过程设计和计划生成之间建立了桥梁，可以帮助扩展办公室和学术单位将项目工作流形式化，否则这些工作流主要依赖手动和经验处理。以用户为中心的评估在范围上也仍然有限。尽管它提供了关于感知有用性和可解释性的有用描述性证据，但样本量较小，且该工具不是基于SUS、TAM或UTAUT等标准化可用性框架。因此，以用户为中心的发现应被视为对实际相关性的初步支持，而不是决定性可用性验证。未来的工作应通过更广泛的数据集、标准化的评估工具以及在多样化工作流模式下更系统地测试BPMN到HDDL的转换来解决这些限制。

6.3. 方法论局限性和有效性威胁
本小节概述了当前研究的主要方法论局限性和有效性威胁。当前的成本公式化是有意简化的，使用单位成本来表示可执行动作。这提高了透明度和可重复性，但也意味着报告的成本指标不应被解释为大学项目实施的详细经济表示。基于活动类别、资源需求、持续时间或机构预算数据的更丰富的成本模型是未来工作的方向。当前评估的另一个限制是，计划质量是使用一组有限的结构指标来评估的。尽管成本和计划长度对于生成计划的透明比较很有用，但它们没有捕捉到更广泛的运营质量，如资源利用、灵活性或对不确定性的响应性。这些维度需要更丰富的项目注释、资源感知的表示和基于场景的评估协议，而这些在当前版本的工件中是不可用的。尽管有这些令人鼓舞的发现，当前研究仍有一些重要的方法论局限性必须承认。首先，评估基于三个案例研究和总共十八个生成的计划，这支持了结构化的基于案例的验证，但尚未构成大规模的基准。其次，比较仅限于两个HTN规划器SHOP2和PyHOP，因此没有建立其他层次化或非层次化规划方法的更广泛普遍性。第三，尽管为评估的案例恢复了结构BPMN描述符，但研究尚未包括一个受控的合成基准，以隔离循环、异常或密集并行性的影响。以用户为中心的评估提供了关于感知有用性和可解释性的初步描述性证据，特别是在大学扩展管理者中。然而，样本量仍然有限，且该工具不是基于标准化的可用性框架。因此，这些发现应被视为对实际相关性和采用潜力的初步支持，而不是决定性的可用性验证。当前的评估应被视为结构化的基于案例的验证，而不是全面的基准研究。尽管这三个案例在活动数量、网关和分支程度上有所不同，但数据集仍然有限，且没有使用受控的合成BPMN模型家族来隔离循环、异常或密集并行性的影响。此外，导出的证据支持了成本、步骤数量和基本结构描述符的验证比较，但尚未保留用于深入指标（如计划深度或搜索空间探索）的完整规划器日志。因此，当前结果应被视为比较结构性能的证据，而不是计划质量的全面排名。

7. 结论和未来工作
本研究为大学项目执行中的层次化规划提供了一个可追踪的BPMN到HDDL工作流。其主要贡献不仅仅是实现了一个Web平台，还包括设计了一个转换管道，该管道将BPMN项目知识转化为层次化规划工件，同时支持使用两个HTN规划器进行比较计划生成。基于案例的评估表明，这种方法在真实的大学项目环境中是可行的，并且规划器的行为可能因工作流结构和决策标准而异。从应用角度来看，该研究还有助于创建一个模块化平台，可以帮助大学扩展办公室比较不同的实施计划，提高调度决策的一致性，并使项目依赖关系更加明确和可追踪。第四，这是首次将HTN规划应用于大学项目管理的工作，从科学角度来看，它通过关注大学项目管理作为新的应用领域，并强调层次化分解、转换可追溯性和以用户为中心的工件中的规划器比较，扩展了BPMN到规划的研究。同时，对整个BPMN标准的正式验证超出了当前研究的范围，应在未来的工作中解决。这允许最终用户根据生成的计划是否准确反映了评估项目的信息来批准或拒绝这些计划。该研究专注于自动化生成大学环境中的项目执行或实施计划，从而解决了在HTN规划的帮助下制定和实施过程中出现的成本和偏见问题。这样的研究通过整合项目管理和自动化规划（如HTN）两个知识领域推动了创新和科学进步。当前结果支持了BPMN到HDDL转换的可行性以及为大学项目生成替代HTN基计划的比较。然而，当前的评估仍然集中在结构指标上，特别是成本和计划长度。未来的工作应通过纳入额外的计划质量维度（如资源利用、在执行变化下的灵活性和对风险的响应性）来扩展这一评估，从而为评估项目计划质量提供更广泛和更现实的基础。本研究强调的创新包括几个关键区别：虽然现有工具利用广泛的语言模型来细化PDDL和HTN中的领域构建，但它们忽略了HDDL形式主义的考虑，并将其测试限制在众所周知的领域（如物流、机器人技术、运输和风险管理）中，用于计划生成。相比之下，PlanProjU结合了HDDL形式主义，分析了新的领域（如大学项目），使用SHOP2和PyHOP规划器生成多个计划，并提供了一个为非技术用户（包括大学项目开发者）设计的直观界面，从而为HTN规划和项目管理的研究开辟了新的途径。与两所大学和三个不同生成项目的实验验证表明，PlanProjU减少了项目实施所需的时间。在本研究的范围内，SHOP2和PyHOP作为两个互补的HTN规划环境，使得可以比较BPMN派生的层次化规划表示的执行，允许评估生成计划中依赖于规划器的差异。这种效率是由于自动化了扩展办公室为项目收集的98%的知识。在案例研究中，生成的计划是哥伦比亚大学扩展官员感知有用性的初步证据。这些定量研究结果表明，PlanProjU不仅自动化了大学项目的执行和实施过程，还能够在以前未被探索的情境中应用分层任务网络（HTN）人工智能规划技术，从而在项目规划中取得有效成果。除了基于规划器的比较外，对五名用户的用户导向评估也提供了初步的描述性证据，表明该平台在表示扩展项目、检查生成的规划方案以及支持机构对规划结果的解释方面具有实用性。然而，仍需要更大样本量和标准化可用性工具的更广泛研究。因此，这项工作不仅对大学项目经理感兴趣，也对业务流程管理、流程建模和自动化规划领域的研究人员具有吸引力，因为他们致力于将结构化的流程知识转化为可执行的规划表示形式。未来的研究将致力于整合和扩展该方法论框架，将业务流程建模与表示法（BPMN）与分层任务网络（HTN）规划相结合，以实现大学推广项目的自动化；尽管当前系统已成功将BPMN流程结构转换为HDDL领域，但仍需进一步努力来完善参与者、资源和控制流依赖关系的语义表示和上下文细微差别。通过引入领域本体和知识图谱，我们可以实现BPMN实体与HTN结构之间更准确的对齐，从而增强规划模型的表达能力。最后，研究议程呼吁整合神经肌肉学习方法以提高系统的适应性和预测能力；通过将机器学习技术与HTN符号推理相结合，系统可以直接从项目执行日志中自动学习行动模型、成本估算和分解模式，并利用大型语言模型和基于变压器的架构从文本项目文档中提取程序知识。总体而言，修订后的研究结果支持这样的观点：PlanProjU不仅在BPMN建模和HTN规划交叉领域提供了创新的方法论贡献，而且为在实际机构环境中构建大学项目实施提供了实用的辅助机制。综上所述，这些发现表明，PlanProjU不仅是一项技术成果，也是大学项目管理的实用支持工具，同时为结构化组织工作流中的分层自动化规划研究做出了特定领域的贡献。