AI大语言模型赋能自动驾驶让车和车直接“对话”自动驾驶开始“组队”了高速公路上一辆自动驾驶卡车准备向左变道。毫米波雷达和激光雷达告诉它旁边车道有一辆小车距离42米速度比它快3km/h。但传感器回答不了最关键的问题那辆小车是打算加速通过还是会让出位置传统单车智能只能“看到状态”看不到“意图”。于是决策模块选择保守等待结果是卡车错过了一个明明可以安全完成的变道窗口。如果车与车之间可以直接交流这个场景会完全不同。卡车发出消息我需要在300米内完成变道已经打转向灯请求左后方车辆配合小车回复本车正在巡航允许你安全变入预估超车窗口约4秒。随后两车在协商结果的基础上各自调整速度和轨迹。这就是“车车对话”和“车队组队”在自动驾驶场景中的朴素含义。大语言模型天然擅长理解意图、生成结构化结论并让多个智能体共同完成协商。这两年关于“大语言模型自动驾驶”的讨论并不少但很多人一上来就希望让LLM直接接管方向盘这其实是最不合理的切入方式。我认为更值得关注的机会在中间层把大语言模型作为自动驾驶系统的“车队协调中枢”让车辆之间通过语言级的共享意图来实现协同。这个方向既保留了传统自动驾驶控制栈的安全边界又解决了单车智能难以突破的意图盲区。这篇文章会从技术栈分层讲起分析大语言模型在自动驾驶中的三种角色然后用一个最小可运行的“匝道合流协商”示例演示车车如何通过LLM“对话”并依据协商结果执行。同时会讨论本地部署大语言模型、自动驾驶ros系统集成、自动驾驶数据集与图像回灌等工程细节以及真正落地时会遇到的主要坑点。1. 为什么“车车对话”是自动驾驶的下一站1.1 单车智能的短板不是“看不见”而是“不知道别人想干什么”单车智能过去十年的进步主要集中在“感知更准、预测更稳、控制更细”。但一个越来越明显的问题是无论单车算法多强它都只能基于其他交通参与者的历史轨迹去做预测本质上是在“猜”别人的意图。这种猜测在很多普通场景下够用但在博弈性强的场景中会非常低效。所谓博弈性场景就是几个交通参与者需要在同一时空窗口内互相让步例如高速匝道合流主路车辆是否让行直接影响合流车能否顺利汇入。无保护左转对向直行车流中需要找到一个可穿插的“空当”。多车道同时变道两辆车同时向中间车道并线谁先谁后需要协商。前方事故或施工需要重新规划队列顺序和通过时机。传统做法是每辆车用“预测算法”猜测对方下一步动作然后按保守策略执行。预测模型再准也无法知道对方是否愿意让行。保守策略带来的后果就是通行效率下降甚至在高峰期形成“幽灵堵车”——明明没有事故车流突然减速原因只是一辆车对另一辆车意图的不确定。“车车对话”解决的不是感知问题而是意图共享问题。当车辆能直接交换“我想做什么、我可以等多久、我最晚什么时候必须完成”这些信息时决策不确定性会显著下降。1.2 从V2X到LLM通信层解决“听到”语义层解决“听懂”很多人会问V2X车路协同通信不是早就提出了吗为什么还需要大语言模型参与这个问题的答案在分层。V2X解决的是“物理层和消息层”的问题车辆通过DSRC、C-V2X等通信方式把位置、速度、方向等信息以标准消息格式广播出去。这条链路解决的是“一辆车能被另一辆车听到”但是“听到”不等于“听懂”。传统V2X消息里的字段是固定的比如BSM基本安全消息里规定了经纬度、速度、加速度、转向灯状态等字段。它适合广播“当前状态”却不适合表达复杂的协商语义比如“我在左侧车道如果后方车辆在3秒内不加速我可以在当前窗口变道否则我会放弃”。这类内容需要更长、更灵活的结构化表达。大语言模型在这里补上的正是“语义理解、意图生成、多轮协商”这一层。车辆把自身状态和意图序列化后交给LLM协调器LLM通过模型已有的常识和推理能力生成一个多车共识方案。也可以把它理解成V2X提供了“电话线路”LLM则负责“通话内容”。1.3 “组队”不等于固定队列更常见的是动态协调提到“自动驾驶组队”很多人第一反应是卡车编队即多辆卡车以极短间距组成纵向队列行驶后车跟车距离可缩短到10米以内从而大幅降低风阻和油耗。固定编队是“车队组队”的一种极端形态但它对通信时延、传感器同步、紧急制动响应要求极高目前主要用于商用车长途干线物流。真正更常见、也更容易落地的是“动态协调组队”车辆在某一具体场景中临时形成一个协调小组共享意图解决问题后自动解散。比如多辆车同时接近一个施工区它们临时商量好依次通过顺序又比如交叉路口多辆车需要左转它们协商出一个让行序列。这种“临时组队”不需要车辆之间建立长期绑定只需要在特定时空窗口内进行一次或多次协商而且协商结束后所有车辆恢复独立决策。这也是本文后续示例所采用的模型。2. 大语言模型在自动驾驶中的三个角色与常见误区我经常看到一种观点用大语言模型做自动驾驶就是让模型直接输出方向盘转角或油门踏板值。如果从技术演进的角度看这个想法并不是完全没道理但从工程落地的角度看它忽略了安全约束、实时性和可解释性。当前更现实的路径是把大语言模型放在自动驾驶系统的不同层次上。角色输入输出典型运行频率安全边界视觉语言模型VLM感知解释器相机图像、激光雷达点云、里程计结构化场景描述、障碍物语义、异常检测秒级低风险输出用于数据/标注/难例挖掘LLM高层决策Agent局部地图、感知结果、任务目标目标点、行驶策略、行为建议秒级到分钟级中风险需要规则约束LLM多车协商协调器多车意图、道路拓扑、冲突检测结果协同策略、通过顺序、速度建议秒级到分钟级中风险安全闸门兜底2.1 角色一视觉语言模型作为感知解释器这里说的视觉语言模型VLM是同时具备视觉编码能力和语言推理能力的大模型。它不再只是输出“前方有障碍物”这样的感知框而是能输出“前方两车道被事故车辆占据右侧车道可通行但公交车辆正在左侧车道等待”这样的完整场景描述。这类能力目前在自动驾驶数据集标注、难例挖掘、场景分类上非常有用。过去人工标注一个复杂场景需要几分钟VLM可以先把粗标签生成出来再由人工校验。另一个常见用途是“镜头回灌”场景下的解释生成把车辆采集到的真实图像回灌到仿真环境中然后让VLM对每一帧生成语义解释用于训练下游模型。2.2 角色二LLM Agent作为高层决策规划器LLM Agent是当前AI工程领域最热的概念之一。放到自动驾驶场景就是让模型拿到高阶任务后自行拆解先做什么、再做什么、遇到什么情况切到哪个策略。在低速园区、矿山、港口、封闭道路等场景中LLM Agent已经可以辅助生成行驶决策。原因是这些场景速度低、规则明确、风险可控。但在高速公开路段LLM直接输出决策仍然存在很大不确定性尤其是幻觉问题和推理延迟问题。目前更稳妥的做法是让LLM Agent在“行为层”以上工作它负责把任务翻译成一条条符合规则的行为序列再由传统规划控制模块把行为序列细化为轨迹和扭矩。这类“人机协同”的路线相比“LLM替代一切”要现实得多。2.3 角色三多车协商协调器即“车车对话”的落点这是本文将重点演示的角色。多车协商协调器的输入不是图像也不是点云而是多辆车的“意图消息”输出也不是方向盘转角而是“谁先谁后、何时通过、建议速度”等结构化建议。这种设计的好处非常明显工作在较低频率对实时性要求没那么极端。输入输出都是结构化文本或JSON便于记录、审计和回滚。输出结果可以和传统规划控制模块解耦即使LLM出错安全闸门也能拦截。符合“车车直接对话”的产品直觉方便跨团队沟通。也正因为这些特点我认为它才是大语言模型在自动驾驶领域最可能率先规模落地的方向。3. 车车“对话”的架构设计与核心概念3.1 系统架构从单车智能扩展到“车队协调”要支持车车对话系统架构不能只停留在单车内部。一个典型的多车协调架构包含四层层级职责典型组件单车感知与控制层感知、预测、规划、控制相机、雷达、融合模块、MPC控制器通信层在车辆间传递意图与状态V2X模块、4G/5G消息通道协调层汇总多车意图生成协同策略LLM协商服务、冲突检测模块、安全闸门决策执行层根据协同策略调整局部轨迹规划器、轨迹跟踪控制器这里面最核心的变化是“协调层”。它不再是一个纯规则系统而是内置了大语言模型的协商能力。车辆的状态不再是“感知结果”而是“可以被其他车辆理解的意图消息”。3.2 几个必须搞清楚的术语Agent在自动驾驶语境下Agent可以指一辆车所拥有的智能体它能感知环境、生成意图、执行动作也能与其他Agent通信。多车协商就是一个多Agent系统。意图Intent车辆希望执行的动作和原因。例如“我想在300米内变到相邻车道因为3公里后要右转最晚变道窗口在2.5秒后”。协商Negotiation多个车辆在冲突场景中交换意图、给出让步、达成一致的过程。协商结果不是最终轨迹而是一个约束性建议。承诺Commitment车辆在协商后承诺采取某种行为比如“我将等待右侧车辆通过后再合流”。承诺一旦生成就要在后续控制中执行。安全闸门Safety Gate在LLM输出建议后用硬编码的规则检查该建议是否会引发碰撞或违反交规。如果检查不通过系统自动切换为保守策略。图像回灌把真实采集的图像数据在仿真引擎中重新播放用于测试感知算法和协调策略在真实场景中的表现。回灌时需要注意时间戳对齐和传感器标定一致性。3.3 ROS系统在车车对话中扮演什么角色自动驾驶ros系统是很多人已经在用的基础设施。ROS将自动驾驶流程拆解为多个节点感知节点、定位节点、规划节点、控制节点节点之间通过Topic通信。车车对话引入之后ROS仍然是很好的承载体。我们可以把LLM协商服务封装成一个ROS节点节点订阅来自V2X的状态消息发布最终的协商建议。这样原来系统里所有的传感器、规划、控制模块都无需重写只需要新增“协调”这一层。例如在ROS2中可以定义一个自定义消息类型比如CoordinationIntent.msg包含车辆ID、时间戳、位置、速度、目标车道、动作类型和紧急度等字段。车辆把这条消息发给协调节点协调节点收集一个小时间窗内的所有车辆意图后调用LLM生成策略再把策略发布到规划模块。4. 本地部署大语言模型的工程选型4.1 云端API还是本地部署车车对话场景对数据隐私和通信可靠性要求较高。如果所有车辆状态都传到公网再用外部API做协商一方面会引入网络延迟另一方面也涉及数据安全问题。因此在自动驾驶研发中本地部署大语言模型是更常见的诉求。对比维度云端API本地部署延迟网络抖动影响大可控但取决于GPU硬件数据隐私状态数据需要传到外部数据不出机房或边缘节点部署成本按Token付费初期成本低需要GPU服务器和运维投入模型升级服务商统一升级自己控制版本定制能力有限可微调、可量化、可裁剪更实际的策略是“两者结合”测试阶段用云端API快速验证效果进入仿真和封闭场地测试阶段切换到本地部署保证数据链路可控。本地部署的技术栈通常包括模型推理框架和模型权重两部分。模型推理框架可以选择Ollama、vLLM等模型权重则可以选择7B到14B参数规模的开源模型。版本号变化比较快本文不再写死具体版本重点演示通用接入思路。4.2 本地推理服务的最小启动方式以Ollama为例本地拉起一个OpenAI兼容服务只需要几条命令。需要说明的是这里的模型名称和命令格式会随版本变化实践时以官方文档为准。# 拉取一个适合边缘/本地部署的中小规模模型 ollama pull qwen2.5:7b # 启动服务默认监听 11434 端口 ollama serve如果你的项目使用vLLM也可以用一个类似的命令启动python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --served-model-name qwen2.5-7b-instruct \ --port 8000启动后客户端只需要把API地址指向本地服务即可代码和调用云端API几乎一致。这也是车车对话工程中比较顺滑的接入方式先在云端调通逻辑再切到本地服务。4.3 自动驾驶数据集与图像回灌多车协商策略能不能用很大程度上取决于测试场景是否丰富。自动驾驶数据集在这里非常重要公开数据集提供了大量真实交通场景包括车辆、行人、红绿灯和复杂交互。我们可以先用这些数据集观察“真实回合中的博弈行为”再把典型冲突场景抽取出来注入仿真环境。图像回灌的价值在于真实采集图像保留了大量传感器特性和细节把图像“回灌”到仿真系统中可以让协调层在更接近真实的条件下被反复测试。需要注意的是回灌数据必须和其他传感器数据时间对齐否则感知和协商模块会看到不同步的信息。当前也有很多团队开始用工作流引擎来编排自动驾驶数据流水线比如通过argo workflow做数据处理任务调度采集原始数据、提取关键帧、调用VLM生成场景描述、触发模型评测。这种数据链路和LLM协商链路配合可以形成“采集—标注—回灌—评估—再训练”的闭环。5. 核心流程拆解与最小实现示例5.1 选择最小场景匝道合流协商为了让例子足够简单我选择两个车辆在合流区竞争的典型场景车辆A在加速车道需要汇入主路目标是“变道进入主路”。车辆B在主路行驶保持当前车道。冲突区域两车将在同一时空窗口到达同一车道位置。整个流程可以拆成五步每辆车生成自己的意图消息。车辆A通过通信通道把意图发给LLM协调器。LLM协调器对多车意图进行推理生成协商计划。安全闸门校验协商计划。各车根据协商结果调整速度或等待策略。5.2 代码示例一生成车辆意图消息首先定义车辆意图的数据结构并将它序列化为JSON。这个步骤在真实工程里对应“单车意图生成”模块。# 文件路径scripts/intent_pack.py import json import time from dataclasses import dataclass, asdict from typing import List dataclass class VehicleIntent: vehicle_id: str ts: float pos_x: float pos_y: float speed_mps: float current_lane: int target_lane: int action: str # keep / change_lane / merge / brake urgency: int # 0(低) ~ 3(高) conflict_zone: str # 冲突区标识 intention_desc: str # 自然语言意图描述给LLM理解 def pack_intent(intent: VehicleIntent) - str: msg asdict(intent) msg[type] coordination_request msg[create_time] time.time() return json.dumps(msg, ensure_asciiFalse) if __name__ __main__: vehicle_a VehicleIntent( vehicle_idveh_A, tstime.time(), pos_x100.0, pos_y30.0, speed_mps12.0, current_lane1, target_lane2, actionmerge, urgency2, conflict_zonemerge_zone_01, intention_desc我在加速车道准备汇入主路请主路车辆配合。, ) print(pack_intent(vehicle_a))这段代码的核心价值是“把车辆状态变成可以被LLM理解的上下文”。注意intention_desc字段它把车辆意图翻译成自然语言这一步对LLM推理很关键。5.3 代码示例二调用本地LLM进行协商下一步是调用LLM协调器。这个示例使用OpenAI兼容协议指向本地推理服务。无论后端是Ollama还是vLLM调用方式基本一致。# 文件路径scripts/llm_negotiator.py import json import re from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, # 本地推理服务地址 api_keyEMPTY # 本地服务通常无需真实密钥 ) NEGOTIATION_PROMPT_TEMPLATE 你现在是高速公路匝道合流区域的多车协调中枢。 你会收到同一时间窗口内多辆车的意图 JSON请完成三件事 1. 找出可能冲突的意图组合 2. 为冲突组内的车辆分配先后通过次序 3. 对每辆车输出一条明确建议建议类型只能从 wait / pass / adjust_speed 中选择并给出原因。 输入意图 {vehicles_json} 输出格式必须是 JSON不要输出多余文字 {{ analysis: 简要分析冲突原因, plans: [ {{ vehicle_id: ..., recommendation: wait, reason: ..., suggested_speed_mps: 0.0 }} ] }} def negotiate(vehicles_json: str) - dict: prompt NEGOTIATION_PROMPT_TEMPLATE.format(vehicles_jsonvehicles_json) resp client.chat.completions.create( modelqwen2.5-7b-instruct, # 与推理服务加载的模型名保持一致 messages[ {role: system, content: 你是严谨的自动驾驶车队协调器只输出合法 JSON。}, {role: user, content: prompt}, ], temperature0.2, max_tokens1024, ) content resp.choices[0].message.content content re.sub(r^(?:json)?|$, , content.strip()).strip() return json.loads(content) if __name__ __main__: sample_intents json.dumps([ { vehicle_id: veh_A, pos_x: 100.0, speed_mps: 12.0, current_lane: 1, target_lane: 2, action: merge, urgency: 2, conflict_zone: merge_zone_01, intention_desc: 我在加速车道准备汇入主路。, }, { vehicle_id: veh_B, pos_x: 105.0, speed_mps: 14.0, current_lane: 2, target_lane: 2, action: keep, urgency: 0, conflict_zone: merge_zone_01, intention_desc: 我在主路巡航保持当前车道。, }, ], ensure_asciiFalse) result negotiate(sample_intents) print(json.dumps(result, ensure_asciiFalse, indent2))这段代码最重要的设计是“结构化约束”。提示词里明确规定了输出格式并且要求只能从三种推荐类型中选择这能显著降低LLM“自由发挥”导致结果不可用的问题。实际工程中还可以进一步用JSON Schema校验而不是只靠正则。5.4 代码示例三安全闸门与执行校验LLM输出并不直接下发到控制层必须先经过安全闸门。下面的示例演示如何检查合流冲突如果两辆车都被允许“pass”且到达冲突区的时间差小于阈值则判定协商计划不安全。# 文件路径scripts/safety_gate.py import json from typing import Dict, List T_MIN_GAP_S 2.0 # 两车到达冲突区的最小时间间隔 MAX_ACCEL_MPS2 3.0 # 安全加速度上限 def time_to_reach(speed_mps: float, distance_m: float) - float: if speed_mps 0: return 999.0 return distance_m / speed_mps def check_conflict(v1: Dict, v2: Dict, plan: Dict) - bool: p1 plan.get(v1[vehicle_id]) p2 plan.get(v2[vehicle_id]) if not p1 or not p2: return False # 只要有一方等待就不构成同时冲突 if p1[recommendation] wait or p2[recommendation] wait: return False t1 time_to_reach(v1[speed_mps], v1[distance_to_conflict]) t2 time_to_reach(v2[speed_mps], v2[distance_to_conflict]) return abs(t1 - t2) T_MIN_GAP_S def validate_plan(plan: Dict, vehicles: List[Dict]) - bool: for i in range(len(vehicles)): for j in range(i 1, len(vehicles)): vi, vj vehicles[i], vehicles[j] if vi[conflict_zone] ! vj[conflict_zone]: continue if check_conflict(vi, vj, plan): print(f危险{vi[vehicle_id]} 和 {vj[vehicle_id]} 同时通过冲突区) return False return True如果安全闸门返回False系统应该跳过一个默认的保守策略比如“等待其他车辆先通过”。这里的校验逻辑只是示意实际系统还会加入速度限制、加速度约束、交通规则检查等更完整规则。6. 运行结果与效果验证6.1 预期输出与判断标准运行llm_negotiator.py后合理的输出大致如下{ analysis: 车辆A从加速车道汇入主路与车辆B在主路存在时空冲突。车辆B处于主路且速度更高路权更优。, plans: [ { vehicle_id: veh_A, recommendation: wait, reason: 车辆B路权优先且当前速度差异较大车辆A应等待更安全窗口, suggested_speed_mps: 8.0 }, { vehicle_id: veh_B, recommendation: pass, reason: 车辆B保持当前巡航速度通行, suggested_speed_mps: 14.0 } ] }运行安全校验时因为车辆A的建议是wait所以不会触发冲突判定校验通过。验证时不能只看单个输出建议采用批量评测方式准备一批合流场景用例包含不同的相对速度、距离、车道数和紧急度。对每个用例调用LLM协商器生成计划。用安全闸门检查计划是否安全。统计“安全通过率”“冲突率”“平均等待时间”等指标。只有当一个批次里绝大多数用例都能在安全闸门下通过才能说明策略具备基本可用性。如果失败第一步先看日志确认是LLM推荐不合理还是安全闸门参数过严。6.2 常见失败特征LLM协商最常见的失败有两种。一种是输出不合法JSON导致解析失败这种通常可以通过更严格的提示词和重试机制缓解。另一种是推荐动作本身不合理比如让主路车辆强行急刹车为合流车让路这时安全闸门会拒绝系统自动转入保守策略。从工程视角看安全闸门比LLM本身更能决定系统能不能上线。7. 常见问题与排查思路问题现象可能原因排查方式解决方案LLM返回内容无法解析为JSON提示词约束不足模型自由度太高打印原始响应检查模型输出前缀增加输出格式示例使用JSON Schema校验必要时增加重试协商结果忽左忽右不稳定温度参数过高或输入上下文缺少关键信息对比多次输出核对输入字段降低temperature到0.1~0.2使用采样种子统一随机性决策延迟过大本地模型推理速度慢或通信链路有延迟查看推理服务日志和网络耗时使用量化模型、小模型或升级GPU资源协商频率允许降低车辆明明等待了仍然出现冲突时间戳不同步或安全闸门未考虑通信延迟检查各车消息时间戳对过期消息做丢弃或补偿安全校验引入时间误差窗口图像回灌后协商效果明显变差回灌数据与传感器时间不同步或场景标注不一致比对原始帧时间段和标注版本回灌前做时间戳对齐场景标注版本统一管理本地部署显存不足模型参数量过大或推理框架配置不合理查看GPU内存占用选用更小量化模型调整max batch size必要时用CPU推理做低速场景模拟环境下通过实车表现差仿真与真实传感器分布存在差异对比仿真输出和实车采集数据做域随机化增加视觉噪声先在封闭场地小规模验证8. 最佳实践与工程建议8.1 始终把LLM放在安全边界之外这里说的“安全边界之外”是指不要让LLM成为唯一且最底层的决策源。LLM应该是“建议生成器”而不是“执行机构”。多车协调建议生成之后必须经过安全闸门再交给传统的规划控制模块。哪怕LLM完全失效系统还能回到独立决策模式不会直接失控。8.2 设计一个轻量的意图协议车车对话的核心不是“让模型听懂人话”而是“让模型听懂车话”。建议为意图消息设计一个轻量协议至少包含车辆ID、时间戳、位置、速度、当前车道、目标车道、动作类型、冲突区域ID、紧急度和自然语言描述。其中自然语言描述字段看似冗余但它能有效提升LLM的推理准确率。8.3 用有限状态机约束协商进程LLM擅长生成结果但“什么时候发起协商、协商超时怎么办、对方不响应怎么办”这类流程问题更适合用有限状态机管理。可以把整个对话拆成几个状态空闲、请求中、协商中、已达成、已超时。只有状态机允许发起协商时LLM才会被触发这样可以避免大量无效请求。8.4 日志、回放与审计必须完整车车对话一旦涉及多台车排错难度会比单车系统大很多。所有车辆意图、LLM输入、LLM原始输出、安全闸门判定结果都应该打点存储。提供完整日志之后才能做到“每次异常行为都可以回放、归因、修复”。这也是自动驾驶测试环节的硬性要求。8.5 模型升级要有灰度方案大语言模型迭代很快但自动驾驶系统最怕“换个版本行为大变”。模型升级前先用同样的测试集跑一遍对比评测观察“安全通过率”和“冲突率”等指标是否回退。条件允许时可以采用新旧模型并行运行只有新模型在仿真测试中稳定通过才逐步扩大实际使用范围。8.6 从两辆车开始再扩展到多车多车协商的复杂度会随车辆数量显著上升。车辆越多LLM输入越长冲突组合也越多。工程上建议从两车协商起步先跑通完整链路再逐步扩展到三车、五车、十车。每扩展一个数量级都需要重新评估推理延迟、安全校验时间和通信带宽。9. 总结与后续学习方向回到开头的问题车和车是否能直接“对话”我的判断是能而且不需要等L5级自动驾驶完全落地。只要我们把对话内容限制在“意图共享”和“行为协商”层面大语言模型就有足够的切入空间。真正决定这套系统能否上车的不是模型有多聪明而是安全边界画得多清楚、数据链路有多完整、异常情况有没有兜底方案。如果你想动手实践建议先做一件小事用两辆车模拟一个最简单的合流场景让每辆车输出自己的意图文本再用本地部署的大语言模型生成协商结果最后写一个安全校验函数对结果做检查。这个最小链路跑通之后再逐步加入自动驾驶数据集、图像回灌、ROS节点接入和批量评测。当车队从两辆车扩展到二十辆车时你会更深刻地理解一个结论自动驾驶的下一个瓶颈很可能不在感知而在协同。