远程协助不是把驾驶员搬到云端，而是决定人该介入哪一层
施工区里，自动驾驶车辆突然停住了。
前方并没有真正封路，只是道路边界发生变化，系统找不到一条符合自己规则的可行轨迹。
这时最直觉的办法似乎是：
找个人来，远程把车开过去。
但真正开始研究远程操作以后，会发现事情没有这么简单。
远程的人看不到真实世界，只能通过摄像头、地图和车辆状态重新理解场景；网络传输可能有延迟；一个操作员还可能同时面对几辆车的求助。更关键的是，人并不一定非要亲自接管方向盘，才能帮助自动驾驶解决问题。
今天三篇论文共同指向了一个更值得讨论的问题：
自动驾驶解决不了时，人应该介入多少，而不是简单决定“人要不要介入”。
一、远程协助，不等于远程驾驶
Schrank等人的研究首先把两个很容易混在一起的概念分开了。
Remote Driving意味着远程操作员直接承担动态驾驶任务，包括转向、制动和加速，需要持续控制车辆。
而Remote Assistance更像是“远程顾问”：车辆自己仍然承担驾驶任务，人只在自动化遇到无法处理的事件时提供信息或建议。论文引用SAE定义，将其描述为一种事件触发式的人类支持，而不是把远程操作员变成自动驾驶的实时后备驾驶员。
这个区别非常重要。
如果前方积水让车辆无法判断能不能通过，人可以只回答：
可以继续。
如果前方有违停车辆挡住道路，人可以给几个绕行航点。
如果道路封闭，人可以从系统给出的候选路线里选择一条新的路径。
Schrank等人的实验正是围绕这三种典型远程协助任务展开：确认是否继续、设置绕行航点、选择替代路线。车辆获得人的帮助后，再恢复高度自动驾驶。
所以，远程求助的第一条经验不是“赶紧把车交给人”。
而是：
先问清楚，系统到底缺的是一条信息、一个判断，还是完整的驾驶能力。
二、“加一个人”并不会自动解决安全问题
Schrank等人测试了一套远程协助工作站。
最终分析包含34名参与者，他们都满足研究所依据的德国Technical Supervisor教育背景要求。实验同时加入了无副任务、1-back和2-back三种认知负荷条件，用来模拟远程操作员还要处理其他工作的情况。
结果很有意思。
认知负荷增加以后，参与者接受求助通知的反应时间没有出现显著变化；也就是说，他们仍然能很快点下“接受”。
真正受影响的是后面的处理过程。
随着认知负荷升高，任务完成时间显著增加；2-back条件相对于1-back平均多用了6.78秒。与此同时，参与者的情境意识下降，主观工作负荷明显上升。
这给远程操作中心一个很现实的提醒：
人能够“看到请求”，不代表他还有足够认知资源把问题处理好。
这和驾驶员接管问题很像。
“手放到方向盘上”不代表大脑已经恢复驾驶；同样地，远程操作员点击“接受任务”，也不代表他已经形成足够的情境意识。
论文因此提出，在简单、训练充分的日常任务里，这套HMI表现尚可，但复杂、陌生场景下会怎样仍需要继续研究；作者还明确提醒，把更多额外职责不断叠加给一个远程操作员应当非常谨慎。
三、那人到底应该怎么帮车？
第二篇ROADS研究把问题进一步具体化。
23名参与者面对道路施工场景，需要远程帮助自动驾驶车辆通过施工区域。研究比较了三种方式：
Trajectory Guidance：人直接画出车辆应该走的轨迹。
Waypoint Guidance：人只放置几个航点，由车辆连接并完成后续运动。
Path Planning：车辆自己提出几条候选路径，人从中选择。
三种方式代表的是三种不同程度的人类介入。
从“整条轨迹都由人画”，逐渐变成：
车先想，人再选。
结果非常明显。
在这项实验条件下，Path Planning的主观工作负荷最低，NASA-TLX平均约6.06；Waypoint约7.95；Trajectory Guidance约9.74。
系统可用性则正好相反：Path Planning的SUS平均82.47，Waypoint为65.16，Trajectory Guidance为58.48。参与者最终的主观排序也明确偏向Path Planning，其次Waypoint，Trajectory Guidance最低。
这并不意味着“以后所有远程协助都应该让人点选路线”。
真正值得注意的是另一个规律：
自动化承担得越多，人需要进行的连续、细粒度操作就越少。
这不仅影响体验，还影响一个操作员能不能同时帮助多辆车。
四、一个人同时救四辆车，会发生什么？
ROADS没有只让参与者处理一辆车。
实验把并发请求从1辆逐步增加到4辆。随着请求数量增加，未完成的请求、被忽略的时间、车道偏离和工作负荷总体都会变差，而Trajectory Guidance在多请求条件下恶化得尤其明显。
工作负荷也呈现同样趋势：
一项请求时NASA-TLX平均约5.50，增加到四项请求后约9.54。
作者根据自己的实验数据提出，在这套道路施工场景和交互设计下，1—3个并发操作可能是比较值得继续研究的范围，两项请求时满意度表现较好；但作者也没有把它写成远程运营中心的统一容量标准，而是明确要求后续继续研究长期任务、不同场景和不同交互方式。
所以我们不能把它简化成：
“一个人最多管3辆车。”
更合理的理解是：
远程操作员能管多少车，取决于车自己还能做多少事。
如果每辆车都要求人像开遥控车一样连续画轨迹，那么一人多车很快就会变得困难。
如果车辆能够自行规划，人只处理异常和高层选择，远程人的能力才有可能真正放大。
五、第三篇论文把“人该介入哪一层”做成了技术架构
Le Large等人在IEEE IV 2025发表的研究走得更进一步。
他们提出的思路不是：
自动驾驶不会了→ 人远程控制方向盘。
而是：
自动驾驶不会了→ 人修改规划器的约束 → 车自己重新算轨迹。
论文使用Arbitration Graph把远程协助作为一个新的行为组件接入自动驾驶决策系统。远程操作员可以看到车辆摄像头、环境模型和规划约束，然后修改这些约束；车辆规划器根据人的输入重新生成轨迹，再把轨迹交给人确认。确认以后车辆自己执行，操作员负责监控。
这里的人，不是在“开车”。
他更像是在告诉规划器：
这里可以走。
或者：
这条边界暂时可以放宽。
系统依然负责把这个高层信息转成满足车辆动力学和控制要求的具体轨迹。
这实际上是一种很有价值的人机分工：
人负责解决语义和规则层面的异常，机器继续负责精确控制。
六、一个冒烟井盖，就能看出这种分工的价值
论文展示了两个模拟场景。
第一个场景中，系统把一个冒烟的井盖识别成阻挡道路的障碍物，于是车辆停车。
远程操作员查看现场以后判断：
这个目标实际上可以安全通过。
他没有直接把车辆开过去，而是修改了纵向规划约束。随后车辆规划器重新计算轨迹，远程人员确认，车辆自行通过井盖，并重新回到正常自动驾驶。
第二个场景是真正的实体障碍物挡住车道。
系统按照当前道路边界无法生成合法轨迹。远程操作员于是把道路右侧肩部的一块区域加入可行驶空间，规划器据此重新生成绕障轨迹；操作员确认后，车辆自己完成绕行，再重新返回原车道。
这两个案例体现了一种和“远程驾驶”完全不同的思路：
人不是替机器解决所有问题，而是补上机器当前缺失的那一块知识或约束。
七、远程协助可以拆成四种介入深度
综合三篇研究，可以把远程人类的帮助理解为四个层次。这里是本文的综合整理，不是某篇论文提出的原始分级。
第一层：补事实。
例如：
“前面只是水面反光，可以通过。”
车辆得到一个新的环境判断，自己继续规划。
第二层：做选择。
例如：
“系统给了三条路线，选择第二条。”
人的作用是判断候选方案，而不是生成控制动作。
第三层：修改规划条件。
例如：
“右侧这块区域允许临时进入。”
人修改约束，车自己重新规划轨迹。
第四层：直接远程驾驶。
远程人员承担转向、制动和加速。
这四层并不存在简单的“越高越先进”。
真正值得研究的是：
当前问题最低需要哪一级人类介入？
能靠补一条信息解决的问题，就没有必要让人画完整轨迹。
能靠修改约束解决的问题，也未必需要把方向盘、油门和刹车都交给远程人员。
八、但“让车自己多做一点”也不是免费的
ROADS里Path Planning表现最好，一个重要前提是：
车辆本身必须有能力生成可信的候选路径。
论文也明确指出，如果系统给出的路径本身是次优甚至错误的，那么“让人从系统候选里选”就不再一定是理想方案。作者因此建议，Path Planning可以作为默认方式，但仍需要Waypoint Guidance这样的更细粒度方式作为补充。
这恰好说明：
人介入得少，并不意味着系统承担的责任也少。
恰恰相反。
人越往高层移动，自动驾驶系统越需要具备更强的：
·场景建模；
·候选方案生成；
·轨迹安全验证；
·异常检测；
·失败后停车和回退能力。
远程协助并不是把安全责任“甩给云端的人”。
它是在重新划分责任。
九、现有研究距离真实远程运营还有多远？
三篇论文分别留下了非常明确的边界。
Schrank等人的34人实验只有三种常规、训练充分的任务，认知负荷使用的是人为设计的n-back副任务，而且研究只针对Remote Assistance，不能直接外推到Remote Driving。
ROADS只有23名较年轻参与者，集中于一种道路施工场景；实验为了控制变量，还刻意没有加入通信延迟，使用的也是单屏模拟环境。论文自己把这些都列为外部效度限制。
而Arbitration Graph方案目前更偏工程概念验证：只有两个模拟用例，作者已经把真实车辆human-in-the-loop测试、动态环境变化后人类输入是否仍然有效，以及轨迹安全验证列为下一步研究问题。
因此，现在的证据可以支持：
高层远程协助具有降低人工连续操作负担、提高可扩展性的潜力。
但还不能直接证明：
这种架构已经比远程驾驶在真实开放道路上更安全。
十、下一步最值得研究的是“什么时候升级人类介入”
三篇论文放在一起以后，一个新的研究问题非常清楚。
未来系统不应该只有：
自动驾驶 / 人类接管
两个状态。
更值得研究的是一个分级协助决策器：
车辆先判断自己的不确定性和剩余能力。
如果只缺一个事实，就请求远程确认。
如果候选方案已经存在，就让人做选择。
如果规划边界不适用，就请求人修改约束。
只有当前面这些层级仍无法解决问题时，才考虑更直接的远程控制。
而且，这个升级过程还必须同时考虑场景风险、剩余时间、通信质量和远程操作员当前负荷。
因为当四辆车一起发来求助时，问题已经不再只是：
“这辆车该怎么走？”
而变成：
“哪个问题必须先让人处理？”
这会把远程协助从单车HMI问题推进到真正的人机协同调度问题。
十一、研究、专利和教学可以从这里继续展开
在论文研究上，一个很值得继续的方向，是建立“ADS不确定性—道路风险—人类协助深度—操作员负荷”联合模型。研究不只是比较一种界面好不好，而是回答什么时候只问一个事实，什么时候请求航点，什么时候修改规划边界，什么时候必须进入直接控制。
专利上，可以进一步形成一个候选闭环：
异常识别→ 自主解决能力评估 → 场景风险 → 操作员负荷/可用性 → 协助等级选择 → 人类输入 → 轨迹安全验证 → 自动执行与恢复。
这里真正值得保护的可能不是“远程控制汽车”，而是怎样动态决定人介入到哪一层。当然，在进行正式专利检索和权利要求对比之前，这只能作为候选方向。
教学上，这三篇论文很适合组成一个完整案例。可以给学生同一个“施工区车辆卡住”场景，让他们分别设计“给许可”“选路径”“画航点”“改规划边界”和“直接远程驾驶”五种方案，再比较它们对操作员负荷、车辆技术能力、网络要求和安全责任的影响。
学生最后会发现：
最高级的人机协同，并不是让人做得最多。
结语：人类最有价值的地方，不一定是重新握住方向盘
当自动驾驶卡住时，我们很容易沿用一个旧世界的思路：
机器不会，那就让人来开。
但三篇研究展示的是另一种可能。
人类真正稀缺的能力，可能不是远程完成每一次转向和刹车，而是：
看懂系统没看懂的场景，
判断系统不知道的规则，
修改系统当前不合适的约束。
然后，再把精确驾驶交回自动化。
所以，未来远程协助系统真正需要回答的不是：
“人什么时候接管？”
而是：
“这个问题，究竟需要人介入到哪一层？”
远程协助最值得追求的，也不是把驾驶员搬到云端。
而是：
让人的判断能力进入最需要它的地方，同时尽可能让自动化继续做它擅长的事。
参考论文
[1]Schrank, A., Walocha, F., Brandenburg, S., & Oehl, M. Human-Centered Design and Evaluation of a Workplace for the Remote Assistance of Highly Automated Vehicles. Cognition, Technology & Work.
[2]Le Large, N., Brecht, D., Poh, W., Pauls, J.-H., Lauer, M., & Diermeyer, F. Human-Aided Trajectory Planning for Automated Vehicles through Teleoperation and Arbitration Graphs. IEEE Intelligent Vehicles Symposium 2025.
[3]Colley, M., Westhauser, J., Andersson, J., Mirnig, A. G., & Rukzio, E. Introducing ROADS: A Systematic Comparison of Remote Control Interaction Concepts for Automated Vehicles at Road Works. CHI 2025.
