城市服务运行时：UE5 实现篇｜救护派遣、订单生命周期与出租车行程

城市中的服务车辆需要持续处理任务变化：有人倒地时响应，已有任务时保持绑定，资源不足时保留需求，现场处理结束后再接受新任务。请求撤销后，车辆需要结束旧任务，恢复普通驾驶。车辆能够驶向目标，只完成了其中的执行部分。

本篇承接《城市交通运行时：UE5 实现篇》与《车辆驾驶运行时：UE5 实现篇》的实现，讨论当前 UE5 原型怎样把事件、服务资源、订单和驾驶执行连接起来。救护场景展示共享服务池的派遣；出租车场景展示另一种由服务脚本持有的叫车与乘坐流程。两者复用座位、驾驶员资格和物理执行接口，各自保留任务状态。

下文使用七段独立录制的真实编辑器 PIE 视频。前三段观察救护响应、忙碌等待和取消后的恢复；后四段观察出租车接送、离开叫车区域、提前下车和临停后继续。实验位于原大城市场景的另一街段，原道路与编译路网没有改变。视频中的输入与事件由演示脚本回放，未进行人工操作验收。

事件、资源与订单分别保存什么

行人倒地之后，系统需要记录“这个位置还有一个服务需求”。即使第一辆响应车暂时无法工作，这个需求也可能继续存在。服务需求由事件持有，当前由谁响应则保存在订单中；两者具有不同的结束条件。

事件（Incident）保存目标位置、服务类型、需求数量和完成政策。服务资源保存本轮观察到的车辆、驾驶员、位置、有效性、可分配状态及当前订单。订单（Order）把一个事件与一组响应资源绑定，保存本次响应的目标和进度。现场任务消费订单，完成停车、人员离车、查看和返回等行为，再报告结果。

下面列出当前实现中与派遣有关的字段。类型名经过中性化，省略构造与容器代码；字段的存储归属保持不变。

struct ServiceIncident {
    uint32 id;
    Name owner, service;
    Vector target;
    int32 requested, allocated, assigned, completed;
    IncidentState state;
};
struct ServiceResource {
    EntityHandle vehicle, driver;
    Name service;
    Vector measuredPosition;
    bool valid, available;
    uint32 order;
};
struct ServiceOrder {
    uint32 id, incident;
    EntityHandle vehicle, driver;
    Name service;
    Vector target;
    OrderState state;
    bool markedForDeletion;
};

owner 用于确认谁可以撤销事件，service 限定由哪一种服务处理，id 关联这一次需求。资源里的 order 表示当前绑定，订单里的车辆与驾驶员则保存建立任务时的身份。订单不保存医护动作：离车、接近患者和返车仍由现场消费者推进，派遣只读取其回执。

仅保存“当前目标人物”无法维护这些状态。车辆接受新订单后，旧患者可能还在起身或步行；订单已撤销，原车辆仍可能继续普通驾驶。需求、任务和实体的更新不能随着一个目标指针一起结束。

文章目录

• 事件、资源与订单分别保存什么
• 一轮派遣怎样保留已有工作
• 到场以后，现场任务怎样报告完成
• 资源忙碌时，待处理需求怎样继续等待
• 事件撤销后，车辆恢复巡逻并响应新事件
• 出租车由独立的服务脚本管理
• 服务意图怎样进入 UE 物理帧
• 当前证据覆盖到哪里
• AI 协作复盘

保留参考机制中的职责边界

参考实现分别处理事件排序、资源需求、有效订单保留、资源获取和订单清理。当前原型保留了这些步骤的独立接口，采用 UE 容器和实体句柄保存状态，由各步骤分别更新状态，车辆到达回调只处理其中的阶段变化。

当前救护资源与参考机制的粒度不同：参考机制会筛选医护人物，并由救护任务组织车内与步行响应。当前有界原型用车辆与驾驶员作为派遣资源对，另由现场消费者维护随车医护。这一映射连接了现有实体与驾驶接口，还没有完整迁移参考实现中所有医护资源分支。

因此，车辆异常不能直接解释为整组医护失效。医护可能仍能下车接近患者。本文采用能够核对触发原因与后续行为的救护视频；单纯由脚本撤回整组、再让另一组接替的旧素材未纳入正文。

一轮派遣怎样保留已有工作

每轮更新先收集本服务的有效资源观察。实体仍然存在，不代表原驾驶关系或服务资格仍有效；消费者需要重新检查当前车辆、驾驶员和命令关系。没有收到本轮观察的旧资源会被标为无效，避免沿用过期信息。

资源观察（Resource Observation）是一份本轮快照，不是永久登记。当前 Observe 用车辆句柄定位资源，刷新驾驶员、位置与资格时保留管理器已有的订单编号，调用者不能通过新快照覆盖已有绑定。资源已有订单时，也不能在观察阶段直接改成另一服务类型。每轮结束会消费本服务的观察标记；下轮必须重新提供，缺失就按无效处理。

valid 与 available 表达不同条件。前者描述这组车辆与驾驶关系是否仍可使用；后者描述是否允许接收新任务。一个正在服务的有效资源可以不空闲，已有订单仍需保留。相反，模型还显示在路边，也不保证当前驾驶座关系和命令所有权有效。当前现场适配负责检查这些关系，再把结果交给派遣；管理器不会独立发现所有故障。

资源快照刷新后，服务更新按以下次序处理需求和订单。伪代码是当前 UE 实现的中性摘写，省略类型与容器细节。

void UpdateService(ServiceType type) {
    InvalidateMissingObservations(type);
    auto working = BuildActiveIncidentList(type);
    AllocateBudget(type, working);
    PreserveValidOrders(type);
    AcquireFreeResources(type, working);
    ClearMarkedOrders();
    UpdateIncidentRetirement();
    ConsumeObservations(type);
}

Requested 保存需求，Completed 累计被接受的完成回执；Allocated 是本轮预算，Assigned 在保留和新建订单时累计。活动且尚有未完成需求的事件进入工作集，并按 Requested 从高到低排序；相同需求由事件编号稳定排序。本轮会重置预算与分配计数，保留累计完成数。

预算按当前服务的可用容量计算，包含仍有效且已有订单的资源，以及有效、允许接单的空闲资源。对活动事件，可用以下摘写说明当前计算关系：

remaining = Requested - Completed
Allocated = min(capacityRemaining, remaining)
capacityRemaining -= Allocated

需要新增绑定时：
    Assigned < Allocated
    只在 valid && available && order == 0 的资源中选择

Allocated 表示本轮需求预算，不是对具体 Resource 的硬预留，也不是已经派出的车辆数。Assigned 随后由保留订单和新建订单累计。当前保留步骤检查事件、资源、驾驶员与绑定是否仍有效，不会因预算减少而抢占旧订单。因此不能把 Assigned <= Allocated 当作任意时刻都成立的断言，也不能只凭预算列判断现场已经换人。新分配还受当前订单容器和编号分配器限制；本地资源池耗尽时，不会自动生成额外车辆。

只有新建订单时才进行候选选择。当前按目标的三维直线平方距离排序，距离相同时用稳定资源编号确定结果。这是本地池的选择策略，没有使用路网成本或预计到场时间；直线距离最近，不保证沿实际道路行驶最快。排序不会改写仍有效的旧订单目标。

保留有效订单时，系统不会仅因排序变化而重新分派正在处理现场的人员。预算重新计算与已提交任务的持续性分别处理。一个事件没有获得空闲资源时继续等待，不会仅因暂时无人响应就被视为完成。

清理旧绑定需要核对订单身份

当前清理发生在新资源获取之后。被标记删除的订单在本轮安全清理点解除绑定；因此一个刚释放的资源可以在随后更新中用于新需求，不应把“同一帧立刻接单”作为普遍保证。

解除资源时，还需检查资源上保存的订单编号仍等于待删除订单。旧任务结束的回调可能晚于下一单建立；如果只根据车辆编号清空关系，就可能删除已经属于新任务的绑定。订单编号在当前管理器生命周期中递增，回执同时匹配订单、车辆和驾驶员，减少这种延迟操作的歧义。

到场以后，现场任务怎样报告完成

响应订单进入现场阶段后，派遣层等待现场消费者的结果。消费者负责人员离车、接近、查看与返车，订单管理器只接受符合阶段和身份的回执。驾驶员保持驾驶座，随车医护使用独立乘客座；医护离座不改变车辆当前驾驶员。

第一段从行人正常步行开始，倒地事件建立需求并获得资源。车体停稳、医护往返和订单完成分别对应位置条件、座位关系提交和服务结果回执。

视频 1：倒地事件触发响应，26.2 秒。先观察行人倒地，再看车辆到场和医护往返；这版患者保持倒地。订单完成表示当前查看任务结束。

订单有“途中”和“到场”两个独立阶段。当前演示以实测车体接近停车目标、速度低于 0.1 m/s 作为到场门槛，再调用座位接口让医护离开乘客座。到场回执只推进订单状态，尚不增加事件完成数。

现场消费者负责自己的行为进度。返回原车之后，乘客席重新入座成功，消费者才报告完成。订单管理器再次检查事件仍活动、订单处于到场阶段、车辆和驾驶员身份匹配，接受后增加完成数并标记订单删除。重复完成回执会被拒绝。

回执入口还检查当前订单阶段。以下伪代码保留当前管理器的接受条件；它描述的是调用边界，不是医护行为的实现：

订单不存在、已标记删除、车辆或驾驶员不匹配 → 拒绝
事件不存在或不再活动                      → 拒绝

Arrived   + Travelling → AtScene
Completed + AtScene   → Completed，增加事件完成数，标记删除
Failed                → Failed，标记删除，不增加完成数
其他阶段与回执组合                       → 拒绝

标记删除与实际移除之间可以隔着一次调度更新，入口仍会先检查删除标记，因此这段时间不会再次累计完成。Failed 只结束当前响应订单，不会自动满足事件需求。事件随后是否继续等待或退出，仍由自己的活动状态与完成政策决定。

这份身份检查依赖管理器当前生命周期内的订单编号，以及本次保存的实体句柄。它解决这里展示的旧回执问题，并未验收跨进程编号、网络迟到消息或世界卸载后的恢复。

第一段验证的是事件到现场任务的连接。它使用程序倒地与查看姿态，没有通用健康系统。后续场景中的恢复行走是显式的非致命场景结果，不能据此推断原型已经实现任意伤病判断或死亡复活。

资源忙碌时，待处理需求怎样继续等待

资源不足时，等待的是尚未满足的事件需求。派遣更新继续保留正在执行的有效订单，不为新的需求直接释放忙碌人员；事件也不会因一次未获分配就结束。

第二段同时保留三名倒地人物。A、B 已有响应资源，C 仍活动但没有绑定。画面显示前两处现场仍在处理中，随后原组结束 A 并转去 C，用来观察需求保留与实体复用。

视频 2：资源等待与原组复用，50.8 秒。A、B 先获得资源，C 等待；A 结束后，原车与原医护接续 C。三个现场均处理结束，人物恢复步行，医护回座后车辆关灯驶离。

本段检查车辆与医护身份是否连续。A 结束后前往 C 的车辆与医护沿用原实体，只有订单目标和现场消费者发生变化。A 的人物在原医护转去 C 后仍继续步行，避免把患者状态附着在“当前救援目标”上而停止更新。

查看结束、患者起身、人员返车、订单完成和资源释放发生在不同阶段。当前第二段增加了非致命恢复结果：人物经过程序起身混合后衔接步行动画，医护确认其行走，再返回乘客席。三单完成后，两车由原驾驶员恢复普通行驶，分别实测驶离至少 16 米。

这段录制包含三次分配、三次完成，结束时活动订单为零。A 与 B 的查看时间、三单结束后统一驶离属于演示编排；道路执行限制在原街段同向车道内。它没有验证任意城市位置的跨路口派遣。

下面用一个连续的教学示例检查释放过程。设 A、C 各需要一次服务，当前只关注原车与原司机组成的资源 R：R 已通过本轮有效观察，订单 a 正在处理 A，C 等待；没有其他空闲候选。表格按当前管理器的调用顺序推导，不对应视频的实际帧号，也不将独立录制拼成一次实验。

完成回执修改旧订单和 A 的完成数；解绑由清理步骤执行；新订单由之后的资源获取建立。每个阶段仍需检查订单与资源身份，不能仅凭车辆处于空闲状态就修改绑定。后续是否立刻分配仍取决于新的观察、可用状态、预算和其他候选，不保证固定延迟。

取消沿另一条入口开始。创建者撤销 A 时，事件先变为 Cancelled，完成数不增加；保留订单步骤再发现事件不再活动，将旧单标记删除，安全点随后解除绑定。即使旧单尚未实际移除，完成回执也会因事件不再活动而被拒绝。这里将正常完成和取消放在一起解释检查次序，不表示视频 2 与视频 3 是同一轮运行。

事件撤销后，车辆恢复巡逻并响应新事件

事件撤销由创建者发起，结束的是原需求，不增加服务完成数。订单管理器负责结束旧绑定，车辆后续执行什么任务仍由服务消费者决定；取消接口本身不提交刹车或巡逻命令。

当前场景在响应 A 途中，让 A 自行恢复并撤销事件。旧订单清理后，消费者切回普通巡逻，车辆关灯继续行驶。B 随后倒地，原组接受新订单并完成服务。

视频 3：撤销旧需求后继续巡逻，再响应 B，36.5 秒。注意旧灯光和任务结束后车辆仍行驶；新求助发生时，车辆已经处于普通巡逻。

参考救护任务在失去有效订单后会重新选择巡逻行为；车内没有伤员时，可以恢复车内巡逻，并在获得新订单后重新响应。当前原型据此修正了早期“取消后强制停车等待”的版本。

本段旧单解除后，车辆连续巡逻约 9.57 米，新分配发生时仍在移动。原车辆、驾驶员和医护身份保持不变。演示还在旧单解除后、建立新绑定后分别重发旧完成回执，两次均被拒绝，A 的完成数保持为零。

重发旧回执可以检查删除订单之后的状态保护：若旧回执仍能增加完成数，或清除新单的资源绑定，系统仍存在生命周期错误。事件的创建者身份也参与撤销检查，其他来源不能任意结束这个需求。

出租车由独立的服务脚本管理

出租车同样需要驶向一个位置，但它的任务还包含叫车者、接客点、等待上车、乘坐目的地和乘客输入。参考系统分别用叫车与乘坐脚本组织这些状态，独立于共享救护派遣链。

当前 UE 并未完整运行这两个参考脚本。演示 Actor 用本地阶段字段与场景模式承接已覆盖的叫车、接客、行程、取消和临停分支，再调用已有座位与驾驶接口。它没有完整脚本宿主，也没有全城寻车、计价支付和环境人口接管；出租车请求没有进入救护的 Incident／Order 管理器。以下区分参考职责与本轮实现映射。

接客与正常送达

叫车后，脚本经历调度等待，车辆赴约并停车等客。乘客预约后排座位，完成入座后才开始前往目的地。到站停稳后，乘客离车走上人行道，出租车再恢复普通行驶。

视频 4：正常叫车、接客与送达，27.7 秒。原始模拟保留约 10 秒调度延迟；发布剪辑缩短了其中约 7.8 秒无动作等待。座位确认、行程与下车过程连续保留。

当前车辆、驾驶员和乘客在同段中保持身份。后排预约与实际占座分开，司机的命令提交始终通过驾驶座关系检查。剖面车壳用于观察乘员，人物模型的显示不能代替逻辑占座。

按参考职责，叫车与乘坐需要分别保存持续状态；当前演示对象用本地字段承接其中已覆盖的部分。叫车阶段保存叫车者、原叫车点、调度等待和赴约车辆；乘坐阶段保存乘客占座、原目的地、停车请求及正常送达标记。接客点不能在乘客进入后继续充当行程目标，临停目标也不能覆盖原目的地。

后排入座沿用上一篇的关系接口：先预约并核对本次预约身份，确认通过后提交占座关系。车辆侧分配目标座位时就会清理该座位的预约，随后再写入人物侧关系。演示代码在成功入座后仍显式调用了一次 ReleaseTaskSeatReservation；此时预约已经为空，该调用按当前实现返回 MissingReservation，且演示未检查这个返回值。它没有再次改变预约，也不是标准入座流程必需的收尾步骤。当前实现还在提交入座前检查实测低速，接口失败则终止该演示用例，不继续把人物显示在后排。预约确认只是本次检查通过；车内姿态开始播放也不代表占座已经成立。

司机始终通过当前驾驶座关系提交车辆命令，乘客只改变行程意图。即使叫车者随后驾驶自己的蓝车离开，他的驾驶资格属于蓝车，不能据此获得出租车控制权。这一段同时存在乘客请求与驾驶员命令，复用的是底层关系检查，而非一份共享的“控制者”字段。

预置出租车、固定接客点和目的地是本场景的执行适配。当前位置到目标的纵向速度由简化运动模型计算，实际位置来自物理车体。完整城市寻车、计价、支付、同伴与通缉处理尚未接入。

离开原叫车区域，清理赴约请求

叫车者随后驾驶自己的蓝车离开。出租车尚在赴约，脚本检查叫车者到原叫车点的三维距离；超过 100 米后清空请求中的出租车与叫车者引用。空车短暂停顿后恢复普通行驶，经过旧接客位置时不再停车等人。

视频 5：离开叫车区域后取消赴约，19.9 秒。蓝车是叫车者自己的车；出租车全程空载。请求取消后，观察出租车继续驶过旧接客点。

100 米为已核对脚本中的阈值，比较的是到原叫车位置的三维距离，且必须严格大于阈值。本轮在约 100.001 米时触发清理，当时出租车仍以约 3.14 m/s 行驶。空车等待约 0.512 秒，对应参考脚本的 500 ms 暂停分支。

原叫车点在请求建立时保存，不随叫车者移动。将双方位置换成相同米制后，清理条件可以写成：

delta = callerPosition - originalCallPosition
distanceSquared = dot(delta, delta)
leaveCallArea = distanceSquared > 100 * 100

这里包含高度分量，恰好等于阈值仍留在范围内。参考脚本用平方距离比较，当前 UE 演示计算三维距离后使用严格大于判断；数学条件一致，本文没有据此声称阈值附近的所有浮点位模式等价。

清理的关键是先撤销赴约引用，再让空车执行短暂停顿与普通驾驶。不能只让车辆模型驶过接客点，却保留仍会等待原叫车者的脚本状态。当前验证同时检查引用已空、出租车没有乘客，以及两辆车的命令仍由各自司机提交。

原型清理了本地服务引用，仍由演示负责实体生命周期。完整“交回环境车辆系统”的释放、流送和人口接管尚未实现，不能将驶离画面等同于这些机制已经完成。

请求停车与提前下车分别发生

乘坐途中发出停车请求后，原目的地仍保存，乘客仍在后排。车辆减速停稳并等待，随后另一项离车操作才解除占座。途中下车结束这次服务，不设置“到达原目的地”的完成标记。

视频 6：途中停车后提前下车，14.2 秒。视频从已经确认后排占座开始。停稳时距原目的地仍约 36.15 米；乘客继续留座约 1.22 秒后，独立下车操作才生效。

当前附近停车点采用实测车位向前 3 米的同车道目标，用于展示停车与行程状态的分离。它没有实现通用靠边寻点或横向停车。低于 0.1 m/s 才允许离车是本演示安全规则，不能作为参考系统全部离车行为的统一门槛。

临停后继续前往原目的地

参考脚本还允许在临停状态再次触发同一控制，恢复原目的地行程。继续行程的出租车视频沿这条分支展开：停稳时乘客不离座，收到继续输入后重新行驶，直到原目的地才允许正常到站与下车。

视频 7：临时停车后继续行程，25.2 秒。观察停车、留座等候、恢复行驶和终点下车四个阶段；原车、原司机、原乘客与目的地保持不变。

本轮临停点距原目的地约 36.19 米，留座等候约 1.20 秒后触发继续。目的地坐标没有改写，车辆任务恢复读取原行程目标。实测在终点附近停稳后才设置完成标记，乘客离车步行，出租车随后驶离至少 16 米。

行程恢复只改变当前阶段及其执行目标。临停期间保存原目的地，车辆消费者临时读取附近停车目标；选择继续后，再读取原目的地。提前离车则经座位接口解除关系，并进入服务结束路径。这些操作都不需要把车体直接移到某个预设位置。

正常送达标记还要由原终点的接近与低速条件决定。停车请求、临停已停稳、乘客离座，各自都不足以设置该标记。当前演示的接近判定和低速判定使用本街段配置，完整路侧停车任务并未迁移；原脚本的停车意图与此处同车道目标要分别理解。

视频 6 与视频 7 是两次独立实验，分支输入不同。前者选择提前离车，后者选择继续；不能把两段拼成同一乘客先离车、再自动回座的连续记录。

服务意图怎样进入 UE 物理帧

派遣层提供服务目标，不写入车体位置。驾驶消费者读取订单或行程状态，经当前司机的驾驶资格检查提交控制命令，再由既有物理执行器消费。PostPhysics 阶段读取已完成的车体快照，更新逻辑车辆与驾驶员姿态，并判断到场、停稳和驶离距离。

模型前向与原生车体前向不同，呈现层根据实测朝向换算模型旋转。每个移动帧检查模型前向与实测速度一致，避免车身横向滑行。原道路表面也以车体足迹采样检查；人物步行阶段使用实际地面射线和足骨高度校正。

这些检查验证的是指定街段的物理结果与呈现一致性。服务目标仍采用有界同向路线，尚未接入完整跨路口寻路、全城服务策略或高精度驾驶手感。演示 Actor 负责触发测试事件、回放输入并记录结果，但事件与订单写入通过独立管理器接口进行。

当前证据覆盖到哪里

每段视频都有对应的构建与测试日志、逐帧状态和最终媒体校验。救护使用派遣生命周期与驾驶员所有权回归，出租车使用座位状态与驾驶员所有权回归，并各自运行原地图 PIE 场景测试。不同录制中的帧数不能相加为一次持续运行验收。

七段均为 1920×1080、10 fps 的独立演示，中文短字幕用于指出当前行为，英文正文提供对应说明。车壳剖面、程序倒地、起身和进出车过渡属于观察与表现适配。现场人物模型和医疗标识不构成完整医疗模拟；驶离画面也没有验证全城巡逻或返回基地。

这组实现建立了可继续扩展的服务生命周期：需求持续保存，已有绑定保持有效，执行结果独立反馈，释放后再分配。进一步扩大服务范围时，应优先补齐资源粒度、跨路口执行与具体行为任务，再增加更多事件类型。玩家自由驾驶与完整人物进出车任务仍需各自验收。

AI 协作复盘

AI 协助阅读派遣与出租车脚本、整理状态所有权、实现有界消费者，并制作逐帧记录与视频。人工审阅重点纠正了画面无法解释的行为：只显示等待却不处理前两单、任务结束后车辆不驶离、医护查看后患者没有可见后续，以及车头与运动方向不一致。

修订后，视频保留了触发事件、任务执行和结束后的行为。取消后强制停稳的早期编排也根据参考任务改为恢复巡逻。整组退出的旧视频仍缺少可解释的原因，本篇将其排除；后续若扩展资源失效，应先确定医护、车辆和任务各自的失效条件，再设计对应场景。

源码阅读、UE 适配与视频证据分别记录，能够减少从画面反推机制时的误判。逐帧检查、视频解码与本地页面验证分别覆盖不同问题，正式站点的媒体加载与版式另行检查。