城市交通落地：UE5 中的持续巡航、跟车、换道与路口通行

车辆沿路前进时，路线决定方向，前车影响速度，路口和信号决定何时通行。遇到阻塞后，车辆还要保留当前任务，等条件解除再继续。本文按一帧的处理顺序，说明各模块读取的数据、作出决策的依据，以及执行结果如何反馈到下一帧。

本篇承接城市交通运行时（上）与城市交通运行时（下），整理截至 2026 年 10 月 11 日的 UE5 原型与演示。讨论范围包括有向路网、短路线窗口、前车感知、跟车与换道、路口许可、信号权限、局部车流维护，以及一组真实驾驶员参与的物理车队实验。各项实验沿用原有道路几何和已编译路网，分别录制对应机制。

这批材料包含两种执行路径。大部分短片使用路线／Actor 执行（非物理车辆），车辆沿已验证的路线更新位置；长时车队片段使用真实 Ped（驾驶员实体）与物理车辆。34 个路线／Actor 槽位与峰值 6 辆的物理车队是不同实验。 两者的数量和验证结果分开列出。

全文配有 12 段独立视频，分别展示各项机制的状态变化。影片中的道路和车辆来自真实 PIE 视口；部分文字、地图和信号圆点根据运行记录叠加。不同实验之间存在场景重置，物理长时片段还包含明确跳切，不能把这些短片理解为同一次连续的全城模拟。

交通画面中的运行时状态

先看一个规模稍大的局部场景：2 辆演示车与 32 辆环境车同时存在。车辆在道路上持续移动，画面侧边显示全车分布、路线和逐车状态。要解释其中一辆车为何减速或停车，可以将画面与它的路线、感知输入和等待原因对照。

视频 1｜局部车流与生命周期，60.03 秒。先看左侧实景编号，再与右侧地图和下方名单对应。紫色连接线表示旧路线释放、新路线建立的替换事件，不表示同一辆车瞬移。34 个槽位采用路线／Actor 执行。具体维护规则见后文。

关注同一个编号时，可以依次检查四件事：它当前使用哪个 route ID，正在沿哪一段有向链接行驶，驾驶状态是否处于跟车或等待，以及路线窗口有没有成功续接。槽位编号保持不变而 route ID 改变，说明这个槽位中的环境车已经替换；route ID 不变、目标节点前进，则属于同一条持续路线的执行。

独立的观察者负责切换镜头、刷新名单和缩放地图，只读取已发布的运行状态，不改变车辆的车道、路线或通行权。车辆停住时，记录应能指出原因：前车、障碍、路口、邻道间隙，或预测冲突。观察者不会为了演示而暂停车辆运动。

本文结合三类材料：参考引擎源码中的职责和更新顺序、UE 项目的具体计算，以及同轮视频、逐帧 CSV 和日志中的执行结果。某个机制在源码中存在，不代表当前短片执行了它；短片显示车辆通过，也不能独自证明所有输入和安全条件都正确。

图 1｜机制示意：路网与路线、感知、驾驶任务、通行权限和执行反馈分别保留自己的状态。观察者读取发布结果，不参与驾驶决策。

一帧中的数据传递

路网运行时先提供当前有向链接、车道和未来路线。感知层结合车辆姿态、车体边界与路线收集前车、邻道车辆、静态障碍和预测冲突。驾驶任务用这些输入更新持续状态，提出目标速度、行进距离或换道请求。随后，路口、信号、同车道队列和执行层的安全检查共同限制这次请求。实际执行结果再反馈到下一帧。

驾驶任务提出的行驶距离可能超过执行器允许的距离，换道请求也需要经过候选路线检查。请求被拒绝时，旧状态和拒绝原因都要保留。因此 HUD 除了目标速度，还需要显示实际进度、许可和执行限制，才能解释车辆为何移动或停留。

这个分工保留了参考机制中的状态所有权与更新顺序。在 UE 中，这些职责分别由 Subsystem、Actor、Canvas 和碰撞查询实现。接口仍需明确各自持有的状态，避免一个每帧 Tick 的 Actor 同时管理全部交通逻辑。

有向路网与不断前移的短路线窗口

两段道路在几何上相连，车辆是否能够通行，还取决于方向和车道连接。运行时读取的是已经编译的 Region、Node、Link 和 Lane 数据：Region 组织数据，Node 提供位置与连接端点，Link 表示有向可达关系，Lane 提供该方向可使用的车道。道路材质和标线帮助玩家理解场景，车辆的逻辑连通性则来自这份路网。

确定下一步路线时，需要同时知道车辆从哪条链接进入、当前所在车道，以及能否驶向下一节点。分支、路口、车道数量变化和门户连接都会影响后续选择。仅按“离当前位置最近的道路点”推进，容易在相邻道路、对向车道或高低道路之间产生错误连接。

路线窗口保存当前段与后续节点

短路线窗口保存车辆接下来要经过的节点、链接与车道点。车辆当前位于一个已提交路段，沿该段积累进度；越过目标点后，目标节点继续前移。未来计划接近耗尽时，路线运行时尝试延长窗口，而不是重建当前车辆身份或从出生点重新寻路。

当前原型通常为环境车请求约 12 个未来节点，在剩余计划节点不超过 4 个时尝试续接。这些是原型的规划长度和触发阈值，不是参考引擎的统一常量。车辆保留当前状态，逐步补齐后续路线，不必每帧重新搜索完整城市路线。

图 2｜机制示意：当前链接和段内进度保留，未来路线先构造候选，检查成功后提交；失败时不把空候选覆盖到旧路线。图中节点为教学编号。

当前续接实现先复制路线状态，在候选中补齐精确链接索引，再按尾部的实际车道和进入链接搜索后续。如果缺少有效连接，或后续窗口无法构造，函数返回失败。成功时才把新节点及链接追加到候选中。历史窗口压缩还要同步调整换道完成索引，避免节点数组缩短后把一次尚未结束的换道误判为完成。

此时车辆可能仍在换道，或已确定从某个路口出口离开。若窗口续接时只保留节点坐标、丢失原车道与执行索引，下一帧就可能从错误车道继续，甚至重新接受一个互相冲突的横移请求。

视频 2｜有向路网与短路线窗口，8.87 秒。红车是观察对象，黄色标出当前目标，青色标出后续路线与方向。依次观察目标从 2418 更新到 2419、2420，同时车辆继续沿原路段前进。此片展示车辆沿已编译路段推进，不展示离线路网生成。

两次目标切换均有状态记录，实验中未出现路线续接失败。该结果验证了指定路段上的窗口推进，尚未覆盖全部路口、所有跨区域连接或任意目的地寻路。

更新未来路线时保留当前执行状态

参考巡航机制分别处理未来路线替换、当前车道和位置反馈。项目沿用这一划分：候选提交后可以改变后续节点，车辆当前的姿态和段内进度则继续保留。检查候选时还需要考虑已经提交的路口运动、换道和占用约束。

遇到障碍时，也要保留这种区分。车辆可以沿原路线制动等待，或通过重规划入口提交合法替代路线。这些操作延续同一辆车的任务；若将整个环境实例释放后重新生成，则属于人口替换，需要另行记录，不能算作这辆车成功绕障。

前车感知与跟车速度怎样计算

判断一辆车是否在前方，需要结合自身路线和实际行驶方向。隔壁车道上的车可能在画面上更近，弯道外侧车辆可能与自身 XY 距离很小，后车也可能出现在未来路线回环附近。只用两车中心的欧氏距离，无法正确区分这些情况。

当前前车查询先检查候选身份、车体边界、朝向、距离和相对高度，再沿自身未来路线逐段测试候选车体。路线段穿过候选包围范围且方向符合条件时，才形成前车观察，并输出沿路径的间距和投影速度。这里的具体包围盒扩展和方向阈值属于 UE 项目实现，不能据此宣称完整参考 scanner 已被复现。

路径间距与车体净空的定义

源码中的观察量包含中心沿路径距离，也使用自身前端、对方后端和局部车体边界做资格检查。距离以米进入驾驶计算，而世界坐标部分以厘米存储。教学公式中的 gap 统一表示传给驾驶任务的间距观察，不将它直接解释为车头到车尾的净空。使用不同定义的距离时，静止间距与车体尺寸也必须相应匹配。

这类单位和语义错误很容易被最终画面掩盖。车辆看起来仍然在减速，但如果感知层传的是中心距、控制器却按保险杠净距理解，停止位置和跟车距离就会系统性偏移。排查时应先固定一辆车、一个前车和同帧路线点，确认传递的数据含义，再调整参数。

检测到前车后，驾驶任务结合当前速度和驾驶档位计算期望间距，再根据实际间距与前车速度调整目标。当前原型的期望间距可写成：

desiredGap = standstillGap + currentSpeed × followingTime
closingSpeed = max(0, currentSpeed − leaderSpeed)
brakingGap = standstillGap
           + closingSpeed² / (2 × deceleration)
           + closingSpeed × dt

其中，standstillGap 是静止时保留的间距基准；跟车时还会与执行队列要求的最小值取较大者。followingTime 把速度转换成时间头距，速度越高，期望间距越大。closingSpeed 只保留自身比前车快的部分，最后一项计入本次更新期间继续接近的距离。

这些公式来自当前项目控制器。实现沿用了参考机制中对前车身份、相对运动和速度限制的区分，具体采用时间头距反馈与制动包络；公式和参数不等同于参考引擎。

图 3｜教学示意：间距不足时，目标速度围绕前车速度下降；期望间距处趋向速度匹配。公式旁的数字用于演算，不是视频逐帧测量值。

速度匹配比持续接近更稳定

前车正在移动且尚未进入必须停车的距离时，当前控制器使用：

targetSpeed = clamp(
    leaderSpeed + (gap − desiredGap) / max(0.5, followingTime),
    0, cruiseSpeed
)

这条反馈的平衡点是 gap = desiredGap：后车的目标速度等于前车速度。间距大于期望值时，可以适当追近；小于期望值时，目标速度低于前车，让间距恢复。若在期望间距处仍继续加速接近，下游队列就会反复强制停车，画面表现为不必要的启停。

以一组教学数值为例：自身速度为 10 m/s，前车速度为 8 m/s，静止间距取 5 m，时间头距取 1.5 s。期望间距为 20 m；实际观察间距为 17 m 时，上式给出的目标速度为 6 m/s。这个值是当前帧的目标，不代表速度立刻从 10 变成 6。

任务还会用制动包络限制目标，并按加减速度逐步接近目标速度。路线执行器根据旧速度与新速度的平均值计算本帧请求距离：

newSpeed = approach(previousSpeed, targetSpeed, rate × dt)
requestedDistance = (previousSpeed + newSpeed) × 0.5 × dt

队列、通行权限和执行层的安全检查还可能缩短本帧移动距离。记录时应分别保留目标速度、驾驶任务中的速度、实际路线进度和物理车实测速度，以便判断限制发生在哪一层。

视频 3｜跟车与减速，6.03 秒。观察红车与蓝色前车的间距和红车速度一同下降。该连续区间内，间距由约 23.9 m 降到 12.8 m，速度由约 28.2 km/h 降到 12.4 km/h。它展示本轮路线执行下的跟车响应。

此片选自一次 18 秒的跟车实验，车辆持续处于跟车状态，未出现续路失败。视频用于观察减速过程，运行记录用于核对控制器当时收到的输入；短片只展示其中一段。

可选换道：请求、接受与完成是三个时刻

前车变慢可以触发换道意愿，但意愿并不等于执行许可。驾驶任务先确认道路允许换道，当前没有尚未完成的横移，路口权限没有禁止，且档位的等待时间和冷却条件满足。再评估邻道前方的通行情况，并检查前后间隙。

邻道判断尤其需要后方信息。邻道前方空旷，而后车正在快速接近，横移仍可能危险。当前实现将后车相对接近速度乘以前视时间，加入后方所需间距；同时保留车体长度项。它没有把纵向巡航所需的整个头距直接搬成横向换道阈值。

当前可选换道分支的间距条件可以概括为：

frontRequired = 2 × selfFrontExtent + 1
rearClosing = max(0, rearSpeed + rearAllowance − currentSpeed)
rearRequired = max(
    2 × selfFrontExtent,
    selfRearExtent + rearHalfLength + rearClosing × rearLookAheadTime
)

这里的前后 gap 是邻道观察中的中心间距。前方阈值直接使用自身前端尺寸的两倍，没有显式读取前车半长，这是当前原型的简化策略。在两车纵向尺寸相同、前后半长对称时，这一尺寸项等价于两车半长之和；尺寸不同或车体不对称时不能这样解释。额外的 1 m 为项目安全余量。只有观察有效、目标确为相邻车道，且已观察到的前后车辆满足要求时，这一层检查才通过。没有前车或后车，不等于可以跳过整条路线的可达性与占用检查。

图 4｜机制示意：驾驶意愿、邻道资格、候选路线提交和完成反馈分别发生。被拒绝的候选不覆盖当前路线；计数增加也不直接等于车体已经完成横移。

跨节点的邻道车辆查询

早期实现只在同一条链接内查找邻道车辆。当一辆邻车刚跨过节点时，两车仍然相邻，链接编号却已不同。这时若将它从观察中排除，系统就可能误以为横移空间已经足够。

当前适配会沿方向连续、容量一致的普通走廊查询邻道，最大读取约 50 m、最多 32 条已编译链接。遇到路口、分支、门户、车道容量或宽度变化、缺失连接等条件则停止。50 m 和 32 条是项目的查询预算。是否继续向前查询，取决于路网中的连续关系；两个车体 XY 接近不足以说明它们位于同一条走廊。

换道计数与完成反馈

驾驶请求提出后，路线执行器还要构造候选并做占用与安全检查。候选提交成功后，车体才按执行路径逐步横移；到达完成条件后，车道索引和任务中的请求状态再更新。并行发生的路线窗口压缩也必须维护完成索引。

视频 4｜受约束换道，5.03 秒。依次观察换道计数、红车横移、车道索引变化和从前车侧面通过。这个片段与跟车片段之间重置了场景，不是同一辆车自然接续的后续事件。

原始记录中，全局第 622 帧换道计数已为 1，第 668 帧车道索引才由 1 变为 0，第 700 帧能看到红车在蓝车左侧通过。计数增加只表明决策状态发生了变化。确认换道完成，还要检查车道索引、车体位置和执行反馈。

本轮完整换道实验运行 18 秒，记录 1 次换道、0 次续路失败。该实验验证了指定路段和车辆布置下的可选换道，尚未覆盖其他超车策略或完整的物理并线协议。

必选车道与可选超车的职责

可选换道是在当前路线仍可继续时，尝试改善速度或避开前方阻碍。必选车道则来自未来路线约束：前方道路从三车道缩为两车道，当前外侧车道不能按原编号直接延续，路线需要提前给出目标车道。

两者可以共用部分间隙和执行检查，但不能共用同一个意图来源。若必选车道被放进可选超车的冷却或“此刻能否立即横移”判断中，车辆可能直到缩口前才发现应当并线。参考路线机制把 required-lane 保存在路线点并提前传播，供后续目标计算读取；当前 UE 实现沿用这一职责。

先保留路线意图，再判断何时能够执行

项目入口向前查看约 100 m 的路线，发现经核验的三变二转换时，为外侧车道 2 给出目标车道 1 及剩余距离。它只是报告未来约束，不直接移动车辆，也不修改道路图。100 m、车道 2 到 1 的映射和具体缩口标记，都是当前项目的配置。

必选意图存在后，可选超车冷却不应将它删除。不过，绕过冷却不代表绕过安全检查。邻道有车时仍要保留目标，等待前后空隙，再由候选路线占用检查、提交资格和最终移动保护决定能否开始。候选被拒绝时，车辆继续使用旧路线和制动状态，下一帧可以重新评估。

两个代码分支在这里有所不同：可选换道辅助函数直接检查当前横移间隙；按参考机制组织的 required-lane 路径先保留路线意图，再由下游检查整条候选路径能否安全提交。这一区别需要在调用接口中保留。

多节点横移解决短链接上的提交问题

原地图一个缩口前约有 32.166 m 可用距离，但每段只有约 3 m。旧单段横移条件要求至少 8 m，每次只看当前短段，就可能连续拒绝所有提前并线。道路总长度足够，局部接口却没有表达跨节点动作的能力。

当前路线执行适配器使用约 15 m 的多节点平滑横移，从测量得到的段内位置开始构造候选。第一段的横向变化约为 0.220 m，随后沿原路线节点继续过渡。候选整体通过占用检查后再提交；动作期间禁止嵌套换道和局部重规划，历史压缩同步调整结束索引，源车道的所有权保留到规定完成点。

这些处理解决的是路线执行器的数据连续性。15 m 不应被解释成所有车型都适用的物理并线长度，也不能因为路线点平滑，就推出真实车体在任意速度、轮胎条件和坡度下都能完成相同动作。

视频 5｜必选车道与邻道空隙，17.47 秒。影片包含两场重置实验：先看单车提前由外侧车道 2 并入车道 1，再看邻道有车时等待空隙。道路方向箭头和车道调试层保留。两场均使用路线／Actor 执行，不是 Chaos 必选并线验收。

本次分别测试了单车提前并线，以及邻道有车时等待空隙。两场实验都完成了并线，出口车道均为 1，记录中未出现车体重叠；双车场景还记录到了等待邻道空隙的过程。

此前完整测试还包含密集车流和下游队列两类情况，本轮视频只录制了前两场。这 17 秒片段对应本轮两场实验，另外两类仍以先前测试记录为准。另一条物理执行路径当时明确拒绝此多节点协议，如何根据实测姿态确认动作完成、何时允许开始，以及怎样交接安全约束，仍需单独实现和验证。

路口许可、占用与信号相位

信号转绿、获得路口许可和驶入冲突区，发生在不同阶段。绿灯允许对应方向通行，局部路口还需检查其他运动与占用。车辆实际驶入后，才记为已进入的参与者。这些状态若共用一个布尔值，就难以判断车辆为何等待、许可何时可以撤回，以及占用何时能够释放。

项目用局部路口运行时维护参与者、入口／出口意图、许可和清空后释放。感知、跟车与物理运动仍由各自层处理。当前演示控制区是可替换的局部适配，并非完整参考引擎的全部入口和运动冲突矩阵；视频证明的是这组已绑定路线上的状态转换。

图 5｜机制示意：未进入的许可可以重新评估，已提交占用需要等车辆清空后释放。无冲突运动可以并行，存在冲突时等待前一占用解除；图中关系为教学示意。

无冲突车辆可以同时获得许可

两条运动在当前局部规则下不冲突时，可以同时持有许可，各自通过路口，再分别释放占用。检验这种并行行为，应看车辆所属控制区、许可身份和清空状态，不能仅凭两辆车画面接近就认定它们在冲突区互相穿越。

视频 6｜局部路口并行许可，6.53 秒。红车和蓝车在同一控制区同时持有许可，沿各自路线通过；离开后该区许可归零。本轮没有停车让行，也没有信号相位变化。

完整实验记录到两车同时持有许可、通过并清空控制区，期间未发生停车等待。该结果只对应本轮无冲突运动组合，其他入口组合和冲突关系需要另行测试。

冲突让行需要真实发生等待

另一轮实验专门设置汇入冲突：蓝车沿支路到达控制区，红车正在通过相关运动段。蓝车因通行权约束停车，待冲突解除、获得许可后再驶出。这里应观察等待原因、许可和速度的对应变化，而不只看车辆停住了几秒。

视频 7｜路口冲突让行，6.70 秒。先看蓝车停在汇入前，再看红车通过，最后观察蓝车获准并恢复行驶。这是独立 PIE，不能与上一段并行许可拼成同一轮实验。

完整实验记录到蓝车等待红车通过，获准后恢复行驶，两车随后清空控制区。记录中未出现冲突运动同时获准的情况；短片展示其中的等待与放行过程。

拥堵时尤其需要区分尚未进入车辆的许可与已经进入车辆的占用。已进入的车没有清空时，不能仅因等待过久就删除它的占用，否则后车可能被授予一项与真实车体冲突的权限。超时可以触发诊断或受控恢复，但占用仍应按实际清空情况释放。

信号权限还需要入口元数据

信号运行时有相位，并不代表保存的地图中所有道路都已绑定信号节点。当前保存的路网没有永久信号入口；为演示车辆如何按信号权限通行，在 PIE 前将指定节点临时标成入口，运行后恢复内存标记，没有保存地图和路网资产。

相位周期由当前项目的车辆人口 Actor 持有，再向路网发布相关组的权限。这是当前原型的模块安排。车辆根据对应入口的权限判断能否通行；画面里的彩色圆点只按真实相位绘制，并不是场景中已经存在的实体灯具。

视频 8｜信号相位与停车放行，9.03 秒。观察红相位停车、全红清空、目标方向绿相位和重新起步。圆点是状态说明层；入口元数据为 PIE 临时配置。本片不证明永久灯位、灯具或全城配时已完成。

完整实验记录到红相位停车，以及绿相位后的起步。测试后恢复了临时入口标记，并确认保存的路网资产未被修改。入口检查与资产核对用于确认实验条件，不能代替信号算法验证。

即使目标方向允许通行，前方队列和障碍仍可能限制行驶。信号相位与前车、下游空间、局部许可共同约束车辆通行。若车辆绿灯时没有起步，应检查前车、下游空间和局部许可，而不是先把等待一律归为信号错误；反过来，红灯时车辆越线，也要确认入口绑定、停止距离和本帧执行限制是否一致。

等待与恢复：保留任务，也保留阻塞来源

同样是 0 km/h，停车原因可能是前车停住、静态障碍、路口尚未授予许可、邻道无空隙、预测冲突，或已经发生车体接触。不同原因决定何时可以恢复，也决定哪一层有权改变状态。

当前项目保留 TrafficHoldReason，用于把这些原因带到发布快照和 CSV。枚举用于归类，前车 ID、冲突车辆、路口参与关系和感知距离则保留判断依据。原因变化时，可以结合目标速度和执行限制检查状态切换是否合理。

条件解除后继续原路线

阻塞等待实验展示预测冲突导致车辆停车，条件变化后继续加速。驾驶任务持续存在，路线和身份没有因为等待而被重置。观察恢复时，应同时确认速度重新增加、路线进度继续和等待状态解除。

视频 9｜阻塞等待与恢复，7.03 秒。红车先停等，再重新起步。完整实验使用预测冲突与执行约束形成等待；片段展示恢复过程，不是观察者定时暂停和播放车辆动画。它与跟车、换道实验之间各自重置场景。

该实验完整运行 21 秒，记录到阻塞等待、条件解除和恢复行驶，未出现路线续接失败。跟车、换道与阻塞恢复分别进行实验，发布短片也保留了各自的场景边界。

静态障碍停车与主动绕障分开验收

静态障碍实验在道路上临时放置一个真实碰撞体。车辆感知到它后停车，第 8 模拟秒移除障碍，车辆恢复。为了隔离这条纵向路径，实验暂时关闭可选换道。这个设置使停车原因更明确，也决定了本片不能用来证明主动绕障。

视频 10｜静态障碍停车与恢复，14.00 秒。白色碰撞体真实参与感知，红车进入静态障碍等待；障碍移除后继续行驶。本实验关闭可选换道，只证明停车和恢复，不证明绕行或物理碰撞响应。

完整实验记录到静态障碍等待与移除后的恢复，临时 Actor 和设置在 PIE 后恢复。使用真实碰撞体验证了感知入口；球形 sweep、完整车体扫掠和物理接触仍需分别检查。

对于没有解除的障碍，等待本身不等于错误。需要诊断它是否合理阻止进入、未来路线是否仍可用，以及有没有明确实现的重规划策略。原型已有静态阻塞后的局部路线替换记录，但相关候选次数、重试间隔和检测体积属于项目恢复政策，本次短片未执行完整主动绕障，因此这项能力仍以另外的实验为准。

图 6｜机制示意：观察与权限产生阻塞，持续任务保留路线；条件解除后重新评估并执行。只有原条件解除或合法替代方案提交，才能恢复相应动作，观察者和超时提示不直接改变通行事实。

预测方向与后续修复也有版本边界

参考机制对普通减速使用的方向，以及避让改变后使用的替代方向有明确区别。源码阅读记录将“普通情况下的实际行驶方向与部分转角”同“避让后的目标方向”分开。若一律使用最终目标点方向，弯道上的前后资格和预测矩形可能与真实运动不一致。

项目对这项机制保留了显式能力分支。其修复过程曾出现“车辆最终都退出，但仍记录到接触帧”的运行。因此，完成退出数不能单独充当零接触验收。后续专门的六车实验记录为零接触，也只对应那次测试配置和指定路段，不能据此宣称所有能力分支、原有拥堵现场和任意路线都已修复。

这次失败暴露了退出计数与接触检查之间的差别。方向、路线意图、候选提交和真实车体接触分别属于不同问题。改变其中一个条件，即使最终画面变得流畅，也仍需检查同一轮日志中的安全指标。

局部车流的生成、续路与回收

开头的 34 槽位场景由 2 辆演示车和目标 32 辆环境车组成。演示车提供持续观察对象，环境车用于形成局部交通密度。两者生命周期不同：环境车可以按策略回收补充，关注车的路线连续性不能用这种替换来掩盖。

人口维护先解决数量和合法出生位置，驾驶系统随后决定每辆已存在车辆如何移动。数量目标不能直接推导车速、路口许可或可用间隙。32 辆环境车即使全部成功生成，也可能因为道路范围和通行条件而形成拥堵，因此人口与交通行为需要分别记录。

出生位置通过路网与占用条件筛选

当前项目在第一辆演示车周围寻找环境车入口。初次候选距离约为 35–300 m，后续补充约为 90–300 m，并检查高度差、合法有向车道、车体占用、跟车间距、路口出生保护区和可见保护范围。初次尝试填满目标数量，后续每 0.5 秒维护一次，每次最多处理 4 个补充或替换。

这些半径、数量和维护预算用于维持当前演示周边的局部车流。参考引擎完整的城市人口分配、密度场和驾驶目的地生成不在本轮实现范围内。

生成位置检查还需要确认点位所属的道路和车道。一个点在镜头外、距离合适，并不意味着它位于合法车道上；在路口内部生成，也可能直接占据已经授予其他车辆的运动区域。因此候选通过空间筛选后，还要经过路网、占用和局部保护检查，成功后才能建立路线与执行对象。

图 7｜项目策略示意：人口槽位维护、同路线窗口续接和旧路线释放重建是不同操作。槽位可复用，但每次替换保留旧／新 route ID。图中的半径和预算属于当前局部项目配置。

同一路线续接与环境车替换

环境车通常以持续巡航为目标，计划一段有限未来；接近窗口尾部时尝试续路。已提交的路口出口和换道意图不能被下一次随机游走选择随意覆盖。续路成功保留当前 route ID 和实际进度，追加后续可用路段。

当环境车完成路线，或距离关注车超过约 360 m，且不处于可见保护范围时，人口层可以释放旧路线，从合法入口重新建立一个环境实例。视频同时显示旧、新 route ID。紫色线将两个位置联系起来，是为了说明替换事件，不能作为该车真实驶过两点之间道路的轨迹。

需要区别三个计数：同时在场槽位、累计环境投放、总路线身份。本轮保持 34 个槽位，初始 32 辆环境车加上 85 次替换，累计环境投放为 117；加上 2 条演示路线，共出现 119 个 route ID。117 表示累计投放，不能理解为同时运行 117 辆车。

累计环境投放由初始车辆与后续替换相加得到：32 + 85 = 117。这些结果对应本轮局部车流实验，尚不足以判断更长时间运行后的拥堵情况。

本轮最多同时等待 7 辆、跟车 10 辆。记录出现过无等待、前车限制、路口权限、邻道间隙和预测车辆冲突状态；本轮没有覆盖静态障碍等待或车体接触，这两项需要独立实验检查。未出现的状态，需要在能触发它的场景中检查。

驾驶档位怎样影响响应

项目驾驶档位提供巡航倍率、跟车时间、静止间距、加减速度和换道冷却。它们能使相同路线上的车产生不同响应，但不会改变路网的方向、冲突区占用或安全准入。激进档位仍需要合法路线、邻道空隙和通行权限。

视频 11｜项目驾驶档位对比，6.53 秒。同一地点与路线分别重置运行，再按相同模拟时间并排。此片比较当前项目参数，不是参考引擎驾驶人格精确数值还原，也不代表实际 Ped 的完整人格所有权。

两轮各运行 10 模拟秒，发布片段配对各自连续的 2.0–8.5 秒画面。在第 4 秒，谨慎档为约 24.5 km/h、换道计数 0；激进档约 49.0 km/h、计数 1。首次换道计数分别出现在约 7.0 秒和 3.6 秒。到第 8 秒，激进档速度反而低于谨慎档，因此结论只限于这个场景中更快的初期加速和更早发起换道，不能写成“激进档在任何时刻都更快”。

参考机制中的人格输入还涉及实际驾驶员、模型值、覆盖值、无驾驶员占位输入及随机状态的所有者。这些输入不能由三个固定档位完整表达。本次对比只检查项目控制参数；驾驶员切换、占位表示转换和覆盖值读取仍需分别验证，才能判断人格输入的映射是否完整。

物理车队：从路线命令到实际运动

路线执行和物理执行都读取路线与驾驶意图，但执行方式不同。路线执行器按有效路径推进段内进度，Actor 显示该结果；物理执行器还要把意图转换为车辆控制，由动力学得到实际姿态和速度，再把测量反馈给下一帧。

对物理车来说，目标速度与实测速度之间可能有差距，转向目标也不代表车身立即对齐。坡度、车体尺寸、轮胎状态和控制更新都会影响执行。交通层若持续使用理想路线姿态去替代真实车体，就可能在画面已经接触时仍认为候选安全。因此物理验收还要检查实际位置、接触和恢复，而不只看路线是否到达终点。

六车重复放行的实验范围

本次物理实验在指定原地图路段，每波安排六辆真实 Ped 驾驶的物理车先形成队列，再解除前车静止约束，让车队继续行驶。队列、跟车、放行与执行反馈使用已有运行时；相机和方向箭头只负责观察，没有控制车队运动。

完整测试运行 12 波，峰值 6 辆物理车，累计 72 辆退出，模拟时间约 372 秒，检测记录未发现车体接触。72 是累计退出数，并非同时在场数量；其他车辆模型、路口、拥堵和物理必选并线不在这次验收范围内。

视频 12｜真实驾驶员参与的物理车队，10.87 秒。分别观察第 1 波与第 12 波的队列和放行，中间明确跳过第 2–11 波。最终 72／72 来自同轮完整测试日志，不是在这 10 秒里逐车可见。

短片展示第 1 波和第 12 波的队列与放行，中间以跳切注明省略的波次。第 12 波画面结束时，累计退出数为 66／72，最后六辆随后退出。片尾的 72／72 引用同轮完整日志，不能仅凭短片画面得出。

物理执行沿用了前文的路线、感知、权限和等待状态，又增加了车辆控制与实测反馈。两条执行路径可以分别测试这些交接，但物理车队的结果不能替代其他路段和行为的验收。

将接触和恢复纳入通过条件

修复历史中曾有一次车队全部退出，但日志记录到接触；当时测试缺少零接触断言，旧 Success 只表示已有断言通过。补上断言后，新的测试结果才同时包含退出和接触两项检查。

测试中的 Success 只表示已设置的断言通过。若目标是无接触完成，就需要验证接触计数；若目标是主动恢复，就需要证明发生过阻塞并在条件变化后继续；若目标是必选并线，就要让车辆实际从需要并线的车道出发。没有触发目标分支的一次流畅行驶，不算该分支验收。

“未记录到车体接触”只适用于当前检测方式与实验配置，不代表所有未经测试的几何都不会碰撞。增加车型、速度、路面和车流密度后，仍应重新执行相应检查。

UE 接入中需要保留的接口与失败处理

接入 UE 时，首先要确定状态由谁持有、哪些函数只读、哪些操作能够提交修改，以及失败后下一帧保留什么。参考机制提供函数职责和更新顺序，Subsystem、Actor 等 UE 类型用于组织这些实现。

当前项目中，StreetPath Subsystem 提供路网、路线及相关通行查询入口；感知与驾驶模块处理观察和持续任务；车辆人口 Actor 组织局部参与者、批量更新和当前演示信号周期；路线或物理执行器完成运动；观察者负责镜头、章节重置和记录。这是当前工程的分工，不要求所有项目使用同样的类结构。

读取状态不应隐式修复运行时

早期交通就绪检查已经明确了一条接口约束：快照可以报告身份、驾驶员、命令来源、车道、路线和注册信息是否完整，不应在读取过程中创建路线或重建注册。如果查询本身会修复状态，连续查询两次就会得到不同的现场，也无法判断恢复究竟由哪个操作触发。

这项原则也适用于视频采集。观察者可以把相位绘制成圆点、把路线绘制成箭头，但不能为了保证镜头效果而授予许可、清除等待或重置关注车。必要的场景初始化和实验重置在入口完成，并在视频与记录中注明；开始采集后，展示层读取正常运行结果。

只读约束针对的是快照接口。路线推进、驾驶、路口许可和信号更新仍由对应模块执行，查询函数不负责补齐缺失状态。排查时才能区分：系统本来就已就绪，还是某次修改操作使它恢复了运行。

候选构造和实际提交分离

路线续接、换道与局部重规划都需要候选状态。候选可以包含未来节点、链接、车道点和结束索引；旧路线仍保持有效，直到候选通过相应检查。提交失败不能留下“路线已经改了、执行器却没接受”的半更新状态。

多车更新时，还需要检查候选对应的所有者和状态版本。候选计算期间，车辆可能已推进到下一节点，横移动作可能仍未结束，路口运动也可能已经提交。接口应在修改生效前检查这些条件，避免旧快照构造的候选覆盖新状态。事后调整显示位置无法补救这类状态冲突。

失败时应返回具体原因：没有合法连接、窗口数据不足、邻道观察无效、候选被占、当前动作不允许嵌套、通行权限不足或执行距离受限。若只记录“车辆速度为零”，恢复逻辑便无法区分需要等待的条件。

坐标单位、时间来源与队列排序

世界坐标通常以厘米保存，驾驶速度、间距和制动参数以米制计算，展示速度再转换为 km/h。转换位置需要明确，不应把同一个变量按不同阶段随意解释。路径距离、中心距离、车体净空和沿车道进度也需要各自命名。

时间同样有三个来源：模拟时间推进驾驶状态，采样帧确定记录间隔，墙钟时间包含渲染、截图、编码和等待。录制原图可能使 10 模拟秒耗费更长墙钟时间，这不说明车辆停了更久，也不能把采集效率写成游戏运行帧率。

队列顺序需要在同一参考坐标下比较。项目历史记录出现过各车按自己的朝向投影世界坐标，导致场景平移后顺序变化的错误。改用相对位置和共同参考方向后，队列排序不再随场景平移变化。另一个由静态障碍造成的长期阻塞仍需单独处理。

对于同帧观察，CSV 通常在采集 Tick 读取，视口则来自最近完成的渲染；人口视频记录明确提示可能有一帧显示延迟。解释精确事件先后时，应以状态序列与原帧编号核对，不从一个已压缩的画面推断亚帧级因果关系。

现有安全约束不能为了演示而削弱

原地图道路和碰撞是验收输入的一部分。遇到路杆、缩口或相邻车阻挡时，不能删除资产、忽略碰撞、缩小车体或把超时占用直接清空来获得流畅画面。若需要临时元数据来触发机制，就像信号实验那样明确说明入口、恢复步骤和保存资产是否变化。

同理，给关注车替换路线后，应记录这是合法重规划；释放整个环境实例再重建，则记录为人口替换。移动车体、修改许可和替换身份分别属于不同操作，不能用一种成功掩盖另一种失败。

视频、状态记录与验收结论的对应关系

视频展示运动过程，逐帧数据保留当时的输入和状态，日志与断言给出整轮检查结果。核对一次实验时，需要将三者对应起来；片尾的 Success 卡只能作为结果摘要。

图 8｜验证示意：完整运行包含状态记录和断言，发布视频从中选择可读片段。短片时长、原始运行时长、日志结果和适用范围分别保存，不能相互替代。

将短片与完整实验对应

路线窗口片段关注目标节点更新；跟车片段关注间距与速度；可选换道片段关注请求和完成的时序；必选车道片段关注路线意图与邻道空隙；路口两段分别关注并行许可和冲突让行；信号段关注相位权限；障碍段关注感知停车和清除恢复。人口和物理车队则分别解释生命周期与执行稳定性。

短片展示行为过程，下表归纳完整实验的结果与适用范围。

各项结果只对应表中列出的范围。人口片没有展示所有等待原因，信号片没有验证永久灯位，物理车队没有验收全部必选并线协议，路线窗口也不证明离线路网构建正确。

如何理解修复前后的记录

本轮开发中遇到的主要问题包括：短链接阻止提前横移、同链接观察遗漏跨节点邻车、各车使用不同投影方向、换道计数被误解为完成，以及缺少接触断言使旧 Success 含义过强。复查这些问题时，需要同时核对修复前后的实现和对应实验记录。

后续已经补齐让行和信号视频，早期“没有相关可视化”的记录应按日期理解。全城覆盖、完整参考 scanner 和长期拥堵恢复仍有未验证项，新增局部短片没有改变这些范围。

本轮结果来自上述已有实验，没有新增整城测试或交通性能测量。机制图解释状态与交接，车辆运动则以原始视频和对应运行记录为依据。

结论

当前原型已经能在保存的道路地图上持续沿有向路线行驶，处理前车、邻道、局部路口与信号权限，并在指定条件解除后恢复行驶。局部人口策略维持 34 个路线／Actor 槽位，独立物理实验完成了六车重复波次的规定检查。各项结果分别有对应视频、状态记录和日志。

各阶段需要保留并明确区分相关状态：未来路线不能重置当前进度，换道请求不能提前当作完成，许可不能替代实际占用，环境替换不能当作同车绕障，目标速度也不能替代物理反馈。速度与距离由各模块计算，结果按状态所有权和提交顺序进入下一帧。

接下来需要增加路口运动组合与永久信号绑定，补足物理必选并线的准入和完成反馈，再检查更复杂车流、长期阻塞恢复与人口调度。扩展到新执行路径或新场景时，还需要分别记录输入、失败分支和验证结果。

AI 协作复盘

本次整理以现有落地草稿和 12 段独立插入视频为入口，再读取路线、感知、驾驶控制的当前实现，以及人口、让行、信号、必选车道、驾驶档位和物理车队的验收记录。AI 负责重排文章、建立术语与实验对应关系、整理公式和图注，并从真实成片提取预览帧。

核对时重点检查素材来源和结论范围。原稿按补充时间排列，容易将不同 PIE、执行器和日期的结果混在一起。整理后，每段视频分别注明片长、完整实验、重置或跳切及适用范围；项目策略与参考机制也分开说明。

另一个需要纠正的误读是把计数当作事件完成：换道次数增加早于车道索引变化，物理车队短片结束前只显示 66／72 退出，最终 72／72 来自窗口之后的日志。图注据此区分决策变化、动作完成和整轮结果，便于复查与后续开发。

这轮工作整理了已有证据并补充可视化，没有新增运行时算法或重新验收全城。文章、机制图、独立视频和来源清单均保留，具体采集统计、源码位置与文件校验记录另存于内部核对清单。