远程人的建议不应该被当作“最高优先级命令”，而应该被当作一条仍需经过机器验证的决策输入。

施工路段把原车道挡住了。自动驾驶车停在实线前，自己找不到合法、可行的绕行路径，于是向远程操作员求助。远程操作员看完画面、地图和车辆状态后，给出建议：“从左侧绕过去。”

问题来了：只要远程人已经看懂现场，这辆车就该照做吗？

未必。远程人可能点错目标、误判障碍物，也可能在法律约束、道路几何和实时风险之间做出一个“对人来说合理、对机器来说却不可执行”的选择。远程协助真正困难的地方，并不是把一个人接进系统，而是决定：人的判断进入自动驾驶系统以后，哪些可以执行，哪些需要修改，哪些必须被拒绝。

一、人进了回路，不代表风险就消失了

远程协助常被描述成一种优势互补：机器擅长持续感知、轨迹规划和稳定控制，人擅长理解异常、常识和模糊情境。这个思路没有问题，但它容易掩盖一个事实——人类输入本身也可能成为新的风险源。

Brecht等人在2024年的研究中，把远程操作系统拆成三个相互独立但必须协同的部分：远程操作概念、用户界面和安全概念。更值得注意的是，他们把“错误人类输入所引入的风险”直接列成评价指标。所谓错误输入，可以是点错GUI元素，也可以是输入位置不准确。换句话说，研究者并没有把远程人默认成“正确答案提供者”。

在他们讨论的Shared Control中，操作员输入会与碰撞避免等安全目标进行比较；如果输入不满足安全目标，车辆控制器可以覆盖或调整这条输入。对于Waypoint Guidance，远程人给出的是路径点，车辆仍需要验证路径并生成可执行轨迹。这里的核心不是“系统不信任人”，而是把人的长处放在判断层，把机器擅长的连续安全检查留在执行层。

这项研究还用8名来自汽车、远程操作和相关研究领域的专家，对5类自动驾驶脱离场景进行了工作坊评价。它给出了很有价值的趋势判断，但边界也必须保留：这些概念并没有全部在真实远程操作系统中实现，场景主要通过模拟视频和概念说明呈现，参与者数量与场景数量也有限。因此，它更适合支持“错误人类输入必须进入安全设计”这一判断，而不能证明某一种远程协助架构已经在真实道路上全面更安全。

二、更合理的分工，是“人选意图，车守安全”

Majstorović和Diermeyer提出的动态协同路径规划（DCPP），把这种分工做得更具体。车辆遇到超出自身处理能力的场景时，不是把完整驾驶任务直接丢给远程人，而是先根据地图、占用信息和扩展后的ODD生成多个候选路径，并把每条路径涉及的ODD修改一起展示给操作员。

远程操作员负责选择路径和相应的高层决策；车辆继续负责路径生成、路径跟踪、动态驾驶任务以及整体安全。论文中的算法甚至明确保留了一个“输入是否有效”的检查：远程响应只有在通过有效性判断后才进入执行，否则系统报错并重新请求。与此同时，车辆在任何时候仍保留触发最低风险机动（MRM）和再次请求远程协助的能力。

这条链很值得注意：远程人并不是绕过自动驾驶系统，直接把意志写进执行器；人的选择还要重新进入车辆自己的规划与控制模块，变成满足车辆运动学和环境约束的轨迹。

但这里同样不能越过证据边界。DCPP目前主要是工程概念验证，论文展示了CARLA仿真和与Autoware生态的集成，测试场景相对直接；作者也明确提出还需要专家工作坊和人因实验来评估情境意识、交互时间和操作员压力。因此，我们可以把它看成一种有说服力的安全架构思路，而不是已经完成开放道路验证的量产方案。

三、真正难的不是“要不要验证”，而是“人到底能改写什么”

如果只是要求“所有远程指令都做安全检查”，问题还没有真正解决。最棘手的地方是：自动驾驶之所以求助，往往正是因为原有规则、感知或ODD把它卡住了。此时远程人的价值，恰恰可能是允许系统在特定条件下做平时不会做的事情。

Tener和Lanir设计了一套基于高层离散命令的远程协助界面，并让14名具有地面车辆远程操作经验的专家进行评估。他们用三个典型边缘场景——警察封路、繁忙车流汇入、静态障碍物挡路——构建了175屏的高保真交互原型。研究发现，高层命令这种“指导而非驾驶”的方式总体上得到较好接受，但在Discussion里，作者把一个更尖锐的问题摆了出来：远程协助中的控制权并不像远程驾驶那样简单。

论文举了一个很有代表性的对比。如果车辆因为连续实线而无法绕过挡路目标，在获得远程人的许可后，跨越这条逻辑约束可能是合理的；但如果远程人把车辆指向一堵墙，车辆显然不应该照做。作者进一步提出：如果远程人给出的命令让车辆越出ODD并发生事故，责任应该怎么算？如果人把目标点标在路缘甚至人行区域，车辆该不该前往？这些问题并没有在论文里被彻底解决。

这恰恰说明，未来的“安全验证”不能只是一句抽象的“碰撞检测”。系统需要区分至少两类边界：一类是可以在授权、场景和法律条件下临时调整的逻辑约束；另一类是即使远程人要求，也不能被轻易越过的物理安全约束。更复杂的情况还包括：某条建议在下达时可行，但车辆真正开始执行时，旁车、行人或信号状态已经变化。

同时，这篇研究本身也有明显边界：它基于模拟图像和可点击的静态高保真原型，不是完整动态系统；作者明确指出，由于原型的静态性质，很多交互流程无法覆盖，错误处理基本缺失。因此，它最有价值的不是证明“命令式远程协助已经安全”，而是把控制权、责任和错误处理这些尚未完成的接口暴露了出来。

四、ISO把远程协助放进了系统闭环，而不是放在系统之上

ISO 7856:2025给了一个很重要的工程参照。它面向预定义路线上的L4低速自动驾驶系统，区分远程监控、远程协助和非常有限条件下的远程驾驶。对今天这个问题最关键的是：在“远程协助”中，远程人并不执行动态驾驶任务，而是向LSADS提供信息；LSADS控制器再把这些信息与车辆自己的其他感知信息结合，继续完成DDT。

标准给出的远程协助数据示例包括：判断当前是否安全通行、提供新的避障路径。它还明确规定了远程协助的状态转换、监控信息、通信性能和失败后的回退。例如，当远程协助尚未完成就发生端到端通信失败时，系统需要转入MRM/MRC相关处理；在特定场景中，如果远程人没有在安全停止时间前回应，车辆也应进入最低风险机动。标准还要求对远程协助相关通信信息进行记录，以便事后分析。

这些条款并没有直接写出一个统一的“人类指令六道安全门”，也不能被解读成“ISO已经规定每一条远程建议必须用某一种算法验证”。但把它们放在一起，可以得到一个很清楚的系统工程启示：远程人的信息是自动驾驶闭环中的输入之一，系统仍然需要状态管理、通信监测、执行条件和失败回退。远程人不是凌驾于自动驾驶安全架构之上的“万能管理员”。

另一份正在制定中的ISO/CD TS 17691则把视角进一步推向人因。ISO公开预览显示，这份文件试图建立远程支持中人的能力与局限模型，并给出促进安全交互的原则，涉及工作移交、感知、执行和乘客管理；重点角色是远程监控者和远程协助者，而不是远程驾驶员。它目前仍是委员会草案、处于开发阶段，不能写成已经发布的国际标准。但它释放出的方向很明确：远程人不是系统外部的“完美判断器”，人的能力、限制以及人—自动化—环境之间的整体表现，本身就是远程支持安全设计的一部分。

五、从“远程建议”到“车辆执行”，中间至少要补上六步

把三篇论文与两份ISO文件放在一起，可以把远程协助后的安全执行闭环概括为下面六步。这个框架是基于上述来源的综合归纳，不是任何单篇论文或标准的原始模型。

第一步：人类建议。远程人基于视频、地图、车辆状态和任务背景，给出“可以通行”“选择某条路径”“暂时修改某个环境或ODD判断”等高层信息。

第二步：机器解释。系统先确认这条输入对应什么对象、什么任务、什么时间点和什么控制状态，避免点错目标、输入过期或上下文错位。

第三步：规划验证。把人的高层建议重新交给车辆自己的地图、环境模型和规划器，检查是否存在可执行轨迹，而不是把建议直接变成转向、加速和制动。

第四步：安全约束。区分可在授权条件下调整的逻辑约束，与不能轻易越过的物理安全边界；必要时还要检查ODD、交通规则和系统安全目标之间是否冲突。

第五步：执行监控。建议通过验证也不代表“一次批准、永久有效”。车辆执行过程中仍要持续观察环境变化和轨迹偏差，发现新风险时重新规划、暂停或终止执行。

第六步：失败回退。远程信息无效、通信中断、条件变化或规划不可行时，系统必须有明确的拒绝、重新请求、升级到其他远程模式或进入MRM/MRC的路径。

真正安全的远程协助，不是让机器永远听人，也不是让机器永远拒绝人，而是把“人类的异常理解能力”和“机器的连续安全约束能力”组合成一个可验证、可回退的闭环。

六、这个缺口值得继续做成研究、专利候选和教学任务

研究上，最值得做的不是继续比较“哪种远程界面更好看”，而是把“人类建议安全验证”变成可测量的问题。例如，可以设计逻辑约束、物理障碍、信息过期、错误点选和动态交通变化等场景，分别测量系统对错误建议的误接受率、对合理建议的误拒绝率、任务完成时间以及远程人的工作负荷。这样才能回答：安全门太松会不会放过危险输入，太严又会不会把远程协助重新变成“什么都解决不了”。

工程上可以形成一个“远程协助输入安全门”的专利候选：把RFI/RFD状态、时间戳、场景快照、建议类型、ODD变化、轨迹可行性、安全约束和回退策略放进同一个闭环，在人的建议进入执行前自动给出接受、修正、二次确认或拒绝。这里仍只能称为专利候选，是否具有新颖性和创造性还需要另行做专利检索。

教学上，则可以把同一个施工区场景交给学生：远程人要求跨实线绕行、驶入临时施工通道、把某个目标标记为可忽略，或者给出一个过于靠近行人的路径点。学生不仅要判断“听不听人”，还要给每条建议标注：哪些约束可以被授权修改，哪些必须由车辆保留最终否决权，系统又该怎样记录、监控和回退。这样的任务比单纯讲“人在回路中”更接近真实的系统安全设计。

结语

远程协助最容易产生的一种错觉，是把“人类加入系统”理解成“系统终于有了正确答案”。

但三篇研究和两份ISO文件共同提醒我们：人可以帮助机器突破认知盲区，也会把新的误判、误操作、责任和控制权问题带进系统。真正成熟的架构，不应该问“机器到底听不听人”，而应该问“什么样的人类输入，在什么条件下，经过什么验证，才能进入车辆执行链”。

所以，当远程操作员说“可以走了”时，一辆更可信的自动驾驶车不应该只是回答“收到”。它还应该有能力继续问自己：这条建议现在还成立吗？能规划出来吗？会不会撞上真实障碍？是否越过不可接受的安全边界？如果答案不确定，我能不能安全地说“不”，或者先停下来再问一次？

能把人接进回路，只是远程协助的开始。即使人也会犯错，系统仍然保留一次安全拒绝的机会，才更接近真正可信的人机协同。

参考文献与标准

1. Majstorović, D., & Diermeyer, F. (2023). Dynamic Collaborative Path Planning for Remote Assistance of Highly-Automated Vehicles. 2023 IEEE International Automated Vehicle Validation Conference (IAVVC). https://doi.org/10.1109/IAVVC57316.2023.10328097

2. Brecht, D., Gehrke, N., Kerbl, T., Krauss, N., Majstorović, D., Pfab, F., Wolf, M.-M., & Diermeyer, F. (2024). Evaluation of Teleoperation Concepts to Solve Automated Vehicle Disengagements. IEEE Open Journal of Intelligent Transportation Systems, 5, 629-641. https://doi.org/10.1109/OJITS.2024.3468021

3. Tener, F., & Lanir, J. (2025). Guiding, Not Driving: Design and Evaluation of a Command-Based User Interface for Teleoperation of Autonomous Vehicles. International Journal of Human-Computer Interaction. Published online 15 Dec 2025. https://doi.org/10.1080/10447318.2025.2594751

4. ISO 7856:2025. Intelligent transport systems - Remote support for low speed automated driving systems (RS-LSADS) - Performance requirements, system requirements and performance test procedures.

5. ISO/CD TS 17691. Road Vehicles - Principles for human remote support of automated driving systems. Committee Draft, under development (status checked 2026-08-13).