算子与运行时：AI模型落地的底层协同机制
2026/10/17 11:39:38
核心区别：
| 维度 | 系统级工作流状态机 | 业务对象状态机 |
|---|---|---|
| 建模对象 | 一个业务流程或工作流实例 | 一个业务实体（如Order、Payment）的实例 |
| 状态定义 | 流程的阶段或活动（如“正在验证”、“正在执行”） | 实体的业务状态（如“待支付”、“已发货”） |
| 关注焦点 | 控制与协调：哪个活动该在何时执行，流程如何推进 | 数据与规则：实体在业务规则下允许如何变化 |
| 转换触发 | 由子活动完成、外部事件或业务对象状态达到某条件触发 | 由具体业务操作（如pay()、ship()）触发 |
| 生命周期 | 相对较短，与单个流程实例的执行时间一致 | 相对较长，与实体的业务存在时间一致（如订单从创建到完成可能数天） |
具体例子说明
以一个简化的“在线订单履约”流程为例：
1. 系统级工作流状态机（用于调度）
状态（阶段）：
OrderReceived：订单已接收，初始阶段。PaymentVerification：支付验证阶段。InventoryReservation：库存预留阶段。ShippingArrangement：物流安排阶段。ProcessCompleted：流程完成。
转换触发：
从
OrderReceived到PaymentVerification：当订单对象被创建后自动触发。从
PaymentVerification到InventoryReservation：当支付对象的状态变为Confirmed（已确认）时触发。从
InventoryReservation到ShippingArrangement：当库存对象的状态变为Reserved（已预留）时触发。
关注角度：“接下来应该做什么？”。它不关心订单本身是“待支付”还是“已支付”，它只关心支付验证这个活动是否已经完成，从而决定流程是否进入库存预留阶段。
2. 业务对象状态机（以Order对象为例）
状态：
Draft：草稿。PendingPayment：待支付。Paid：已支付。Shipped：已发货。Delivered：已送达。Cancelled：已取消。
转换触发：
从
PendingPayment到Paid：由pay()操作触发。从
Paid到Shipped：由ship()操作触发。
关注角度：“这个订单当前能做什么？”。它定义了业务规则：订单必须在
Paid状态下才能执行ship()操作。它不关心发货这个动作是系统自动触发还是人工触发。
二者如何协同工作？
在上例中，系统级工作流状态机是导演，业务对象状态机是演员。
工作流处于
PaymentVerification阶段。这个阶段的活动会调用支付网关，最终将支付对象的状态改为Confirmed。支付对象状态变为
Confirmed这个条件，触发了工作流状态机从PaymentVerification转换到InventoryReservation。工作流进入
InventoryReservation阶段，该阶段的活动尝试预留库存。若成功，则将库存对象的状态改为Reserved。库存对象状态变为
Reserved，触发了工作流状态机转换到ShippingArrangement阶段。此阶段的活动会调用ship()操作，从而将订单对象的状态从Paid变为Shipped。
结论
系统级工作流状态机关注的是过程的进度和协调，其状态是宏观的活动阶段，转换依赖于阶段成果（常体现为其他对象的状态变化）。
业务对象状态机关注的是单个实体的合法演变，其状态是微观的业务状态，转换由具体的业务操作触发。
二者通过事件和条件紧密耦合：业务对象的状态变化作为事件，驱动工作流状态机的阶段转换；而工作流状态机的阶段活动，又是触发业务对象状态改变的主要执行者。理解这种区别与联系，对于设计清晰、可维护的复杂系统至关重要。