1. 从模块堆叠到统一智能Agent-Driver 到底在解决什么问题做过自动驾驶感知或者规控的朋友大概率都经历过那种“模块拼装”的痛苦。一个典型的 L2 系统感知模块输出障碍物列表预测模块给出未来轨迹规划模块再基于规则或者优化算法算出一条路径最后控制模块去跟踪。每个模块单独看指标都还行但一旦上路各种边界场景就开始暴露问题感知漏检一个锥桶预测没考虑到旁车突然加塞规划出来的轨迹要么过于保守被后车鸣笛要么过于激进让乘客紧张。更麻烦的是这些模块之间的接口是人工定义的信息在传递过程中不断被压缩和丢失前一个模块的置信度、不确定性很难完整传递给下游。Agent-Driver 这个方向之所以最近被反复讨论核心就在于它试图用一个大模型驱动的智能体把“感知—预测—规划—控制”这条链路里原本割裂的决策过程重新组织成一个具备推理能力、记忆能力和工具调用能力的统一体。它不是简单地把某个模块换成大模型而是让大模型扮演一个“驾驶决策中枢”的角色接收多模态输入摄像头图像、激光雷达点云特征、自车状态、导航指令结合历史记忆和当前场景理解输出带有解释性的驾驶决策并且能够调用不同的工具模块去完成具体计算。我个人的理解是Agent-Driver 的价值不在于它现在就能完全替代传统规控而在于它提供了一种新的架构范式用语言模型的推理能力去处理长尾场景中的语义理解和常识判断用传统算法去保证底层控制的实时性和安全性。这两者不是替代关系而是互补关系。对于做自动驾驶的工程师来说理解这套架构的设计逻辑比急着去复现某个具体模型更重要。这篇文章我会从架构拆解、训练策略、实操部署、问题排查几个角度把 Agent-Driver 这条技术路线讲清楚。适合有一定深度学习基础、做过感知或规控、想了解大模型如何落地到自动驾驶场景的读者。如果你之前只做过纯视觉或者纯规则规划也没关系我会尽量把关键概念用生活化的方式解释清楚。2. Agent-Driver 架构拆解大模型在驾驶闭环里到底扮演什么角色2.1 核心思路把驾驶任务重新定义为“推理工具调用”传统自动驾驶的决策模块本质上是一个映射函数输入是结构化的场景描述障碍物位置、速度、车道线信息输出是控制指令或者轨迹。这个映射函数要么是人工规则写的要么是优化算法算的要么是端到端网络学的。Agent-Driver 的思路不太一样它把驾驶任务重新定义成一个“推理过程”大模型先理解当前场景发生了什么然后推理出应该采取什么策略最后调用相应的工具去执行。举个例子前方有一个施工区域锥桶摆放不规则旁边还有一辆车在缓慢行驶。传统规控可能会因为锥桶不在标准车道线内而出现决策犹豫但大模型可以结合“施工区域”“锥桶”“旁车缓慢行驶”这些语义信息推理出“应该减速并保持安全距离同时准备变道避让”这样的高层决策。然后它调用轨迹生成工具在满足安全约束的前提下生成一条具体轨迹。这个过程中大模型不直接输出方向盘转角和油门刹车而是输出决策意图和工具调用指令。这样做的好处是大模型的推理能力被用在了它擅长的地方——语义理解和常识推理而具体的数值计算和实时控制仍然交给传统模块。这种分工方式既发挥了大模型的泛化能力又避免了它在数值精度和实时性上的短板。2.2 架构分层感知层、推理层、工具层、执行层从工程实现的角度Agent-Driver 可以拆成四层。感知层负责把原始传感器数据转换成大模型能理解的输入形式。这里不一定非要用端到端的方式把图像直接喂给大模型更常见的做法是用一个预训练好的视觉编码器提取特征再通过投影层映射到语言模型的嵌入空间。激光雷达点云可以用 PointPillars 或者 VoxelNet 提取 BEV 特征然后和视觉特征做融合。推理层就是大模型本身通常是一个经过驾驶领域数据微调的多模态大模型。它的输入包括当前帧的感知特征、历史帧的记忆摘要、导航指令、自车状态等输出是自然语言形式的决策描述和结构化的工具调用请求。这里有个关键设计大模型需要维护一个“驾驶记忆”把过去几秒到几十秒的关键事件压缩成文本或者向量形式供当前推理使用。这个记忆机制对于处理连续决策场景非常重要比如跟车、变道、路口通行等。工具层是一组可被大模型调用的函数或模块包括轨迹生成器、碰撞检测器、速度规划器、车道保持控制器等。大模型通过输出特定的调用格式比如 JSON来触发这些工具工具执行完毕后把结果返回给大模型大模型再决定下一步动作。这个过程中工具层实际上承担了“安全兜底”的角色即使大模型的决策意图有问题工具层里的碰撞检测和约束校验也能拦截掉不安全的输出。执行层就是传统的控制模块负责把工具层生成的轨迹转换成具体的油门、刹车、转向指令。这一层通常要求高实时性所以不会让大模型直接参与。2.3 为什么选择这种架构优势与代价这种架构最大的优势是泛化能力。传统规控在面对未见过的场景时往往需要人工添加规则或者重新调参而大模型可以依靠预训练阶段积累的常识推理能力对新的场景组合做出合理判断。比如“前方有救护车鸣笛旁边车道有空间”这种场景大模型可以推理出应该让行而传统规则可能需要专门写一条逻辑。第二个优势是可解释性。大模型输出的决策描述是自然语言的工程师可以直接看到它“在想什么”这对于调试和验证非常有价值。传统端到端模型的输出是一个黑盒轨迹出了问题很难定位原因。但代价也很明显。首先是推理延迟大模型的单次推理时间通常在几百毫秒到几秒之间对于高速行驶的车辆来说这个延迟可能无法接受。所以实际部署时大模型通常只负责低频的高层决策比如每 500ms 一次底层控制仍然由高频的传统模块完成。其次是训练数据需求要让大模型学会驾驶领域的推理需要大量带有决策标注的驾驶场景数据这种数据的采集和标注成本很高。还有一个容易被忽视的问题是工具调用的可靠性。大模型输出 JSON 格式的调用请求时可能会出现格式错误、参数越界、调用不存在的工具等问题。工程上需要加一层解析和校验逻辑对不合法的调用进行拦截和重试。3. 训练策略从通用大模型到驾驶智能体3.1 数据准备驾驶场景数据的采集与标注训练 Agent-Driver 的第一步是准备数据。和传统感知模型不同这里需要的数据不仅是传感器原始数据和标注框还需要决策层面的标注。具体来说每条数据样本应该包含当前场景的感知结果障碍物、车道线、交通标志等、自车状态速度、加速度、航向角、导航指令、以及对应的“正确决策”描述。这个“正确决策”描述可以是人工标注的也可以从人类驾驶数据中自动提取。比如用真实驾驶日志把人类驾驶员的操作反推成决策描述“前方车辆减速本车跟随减速保持 2 秒时距”。这种自动提取的方式成本更低但需要设计好反推规则。数据来源方面公开数据集如 nuScenes、Waymo Open Dataset 可以提供感知和轨迹数据但决策描述需要自己补充。仿真环境如 CARLA、VTD 可以生成大量带标注的场景特别是危险场景和边界场景这些在真实数据中比较稀缺。我个人的经验是真实数据保证分布真实性仿真数据补充长尾覆盖两者按 7:3 或者 6:4 的比例混合使用效果比较好。标注格式上建议统一成 JSON 结构每条样本包含 scene_id、timestamp、perception、ego_state、navigation、decision_text、tool_calls 等字段。decision_text 是自然语言描述tool_calls 是结构化的工具调用序列。这样既方便大模型做监督微调也方便后续做强化学习。3.2 微调方法LoRA 与全参数微调的取舍大模型微调这块目前主流有两种方案全参数微调和 LoRALow-Rank Adaptation。全参数微调效果通常更好但显存需求大7B 模型全参数微调至少需要 8 张 A100 80G而且训练时间长。LoRA 只训练低秩适配矩阵显存需求可以降到 1-2 张 A100训练速度也快很多。对于 Agent-Driver 这种领域适配任务我的建议是先用 LoRA 做快速验证效果不够再考虑全参数微调。LoRA 的秩rank通常设 8 到 64 之间驾驶领域任务我试过 rank32 效果比较均衡。学习率方面LoRA 可以用 1e-4 到 3e-4全参数微调则要降到 1e-5 到 2e-5否则容易灾难性遗忘。训练框架可以用 LLaMA-Factory 或者 Swift这两个都支持 LoRA 和全参数微调配置也比较简单。数据格式用 sharegpt 或者 alpaca 都行关键是把驾驶场景的输入输出组织成对话形式。比如{ conversations: [ {from: human, value: 当前场景前方 30 米有静止车辆本车速度 60km/h左侧车道无车。请给出决策。}, {from: gpt, value: 决策减速并准备向左变道。调用工具generate_trajectory(target_speed40, lane_changeleft)} ] }这种格式可以让模型学会“理解场景—推理决策—调用工具”的完整流程。3.3 训练环境搭建硬件选型与依赖配置训练环境这块如果只是做 LoRA 微调单卡 24G 显存的 4090 或者 A5000 就能跑 7B 模型。全参数微调建议至少 4 张 A100 80G。云训练平台可以用 AutoDL 或者阿里云 PAI按小时计费比较灵活。软件环境方面PyTorch 2.0 以上、CUDA 11.8 以上是基础。DeepSpeed 或者 FSDP 用于分布式训练transformers 和 peft 库用于模型加载和 LoRA 配置。如果要做多模态训练还需要额外配置视觉编码器比如 CLIP 或者 SigLIP。一个容易踩的坑是版本兼容性。peft 和 transformers 的版本要匹配否则加载 LoRA 权重时会报错。我一般会固定版本号比如 transformers4.36.0、peft0.7.0避免自动升级带来的问题。另外训练前一定要用少量数据跑通全流程确认数据加载、前向传播、损失计算、反向传播都没问题再上全量数据。3.4 强化学习与人类反馈的引入监督微调只能让模型模仿标注数据中的决策但标注数据不可能覆盖所有场景而且“正确决策”的定义本身就有模糊性。这时候可以考虑引入强化学习或者人类反馈。具体做法是让模型在仿真环境中执行决策根据安全性、舒适性、通行效率等指标计算奖励然后用 PPO 或者 DPO 算法优化模型策略。DPODirect Preference Optimization比 PPO 更简单不需要单独训练奖励模型直接用偏好数据对优化。偏好数据可以来自人类驾驶员的选择也可以来自仿真环境中的规则评分。比如同一个场景模型生成了两条决策一条导致急刹车一条平稳减速后者得分更高就可以构造一个偏好对。不过强化学习这块坑比较多奖励函数设计不好容易导致模型走捷径。比如模型发现“一直保持静止”可以避免碰撞但完全丧失了通行效率。所以奖励函数要平衡安全、效率和舒适性通常安全权重最高效率次之舒适性再次。4. 实操部署从模型到车端的完整链路4.1 模型量化与推理加速训练好的模型要部署到车端第一个问题就是推理速度。7B 模型 FP16 精度下需要 14G 左右显存车端芯片通常没有这么大显存所以必须做量化。常用的量化方案有 GPTQ、AWQ、GGUF 等可以把模型压缩到 4bit 甚至 3bit显存需求降到 4-6G。量化会带来精度损失但驾驶决策任务对数值精度的要求没有感知任务那么高4bit 量化通常可以接受。我实测下来AWQ 量化在驾驶场景问答任务上准确率下降大概 2-3 个百分点但推理速度提升 2 倍以上。如果车端芯片支持 INT8 或者 INT4 加速效果会更好。推理框架可以用 vLLM 或者 TensorRT-LLM。vLLM 的 PagedAttention 对长序列推理优化很好适合处理驾驶记忆这种长上下文场景。TensorRT-LLM 在 NVIDIA 芯片上性能更强但配置复杂一些。如果车端用的是地平线或者黑芝麻的芯片需要用厂商提供的推理工具链做转换。4.2 工具层的实现与安全校验工具层是 Agent-Driver 安全性的关键保障。每个工具函数都要有明确的输入输出定义和边界检查。比如轨迹生成工具输入是目标速度、目标车道、时间范围输出是一条轨迹点序列。工具内部要包含碰撞检测、动力学约束校验、交通规则校验等逻辑确保生成的轨迹是安全的。大模型输出的工具调用请求需要经过一层解析器转换成实际的函数调用。解析器要处理几种异常情况JSON 格式错误、参数缺失、参数类型错误、调用不存在的工具。对于格式错误可以尝试用正则表达式提取关键信息或者让模型重新生成。对于参数越界比如目标速度超过了道路限速解析器要自动截断到合法范围。还有一个重要设计是工具调用的超时和降级。如果某个工具执行超时或者返回异常系统要能自动降级到安全策略比如靠边停车或者保持当前车道行驶。这个降级逻辑不能依赖大模型必须是硬编码的安全兜底。4.3 仿真测试CARLA 与 VTD 的联合验证实车测试成本高、风险大所以大部分验证工作要在仿真环境里完成。CARLA 是目前最常用的开源自动驾驶仿真器支持 Python API可以方便地注入自定义决策模块。VTD 在场景渲染和传感器仿真方面更强适合做感知算法的验证。Agent-Driver 的仿真测试流程通常是在 CARLA 中搭建场景把大模型决策模块接入 CARLA 的车辆控制接口让车辆在仿真环境中运行记录决策日志和车辆状态。测试场景要覆盖典型场景跟车、变道、路口通行和边界场景cut-in、鬼探头、施工区域。我建议把仿真测试分成两个阶段单场景回归测试和大规模随机测试。单场景回归测试用于验证特定场景下的决策正确性每次修改模型或者工具后都要跑一遍。大规模随机测试用于发现未知的边界问题可以用 CARLA 的 ScenarioRunner 生成大量随机场景统计碰撞率、违规率、通行效率等指标。4.4 实车部署的注意事项从仿真到实车有几个关键差异需要注意。首先是传感器噪声仿真环境的数据太干净了实车的感知结果会有抖动和漏检大模型需要有一定的鲁棒性。其次是通信延迟大模型推理和工具调用之间的通信如果走网络延迟可能达到几十毫秒这个要在系统设计时预留好时间预算。实车部署时建议先用影子模式运行一段时间。大模型决策模块只做推理不实际控制车辆把决策结果和人类驾驶员的实际操作做对比。这样可以积累真实场景下的决策数据同时发现模型的问题而不影响行车安全。影子模式跑通后再逐步开放控制权限从低速场景开始逐步扩展到高速场景。5. 常见问题与排查技巧实录5.1 模型输出格式不稳定怎么办这是最常见的问题。大模型有时候输出纯文本决策描述有时候输出 JSON有时候 JSON 格式还不对。解决方法有几个一是在训练数据里统一输出格式让模型学会固定模板二是在推理时用 constrained decoding限制输出必须符合 JSON schema三是在解析层做容错用正则表达式提取关键字段。我个人的经验是训练数据格式统一比推理时约束更有效。如果训练数据里 90% 的样本都是标准 JSON 格式模型自然会学会这种格式。另外可以在 system prompt 里明确要求输出格式比如“请以 JSON 格式输出包含 decision 和 tool_calls 两个字段”。5.2 工具调用参数越界怎么处理大模型有时候会生成不合理的参数比如目标速度设为 200km/h或者变道目标车道设为对向车道。解析层必须做参数校验把越界参数截断到合法范围。同时要把校验结果反馈给大模型让它知道参数被修正了避免连续生成错误参数。更稳妥的做法是在工具函数内部也做一层校验。即使解析层漏掉了工具层也能拦截。比如轨迹生成工具在收到目标速度后先和道路限速做比较取较小值。这种双重校验机制可以大大提高系统的安全性。5.3 推理延迟过高影响实时性大模型推理延迟主要来自两个方面模型本身的计算量和输入序列长度。驾驶场景的输入通常包含感知结果、历史记忆、导航指令等序列长度可能达到几千 token。减少延迟的方法包括量化模型、缩短输入序列只保留最近几帧记忆、用更小的模型比如 3B 或者 1.5B、用推理加速框架。如果延迟仍然无法满足要求可以考虑异步推理大模型每 500ms 推理一次输出未来 2 秒的决策序列底层控制模块在这 2 秒内按照决策序列执行。这样大模型的推理延迟就不会直接影响控制频率。5.4 常见问题速查表问题现象可能原因排查方法解决思路模型输出纯文本无 JSON训练数据格式不统一检查训练样本格式统一训练数据格式加 system prompt 约束工具调用参数越界模型未学会参数范围打印模型输出参数解析层校验工具层双重校验推理延迟超过 1 秒模型太大或序列太长测量各阶段耗时量化模型、缩短记忆长度、异步推理仿真中碰撞率高决策过于激进或工具层校验不足回放碰撞场景日志调整奖励函数、加强工具层安全校验实车感知抖动导致决策异常模型对噪声鲁棒性不足对比仿真和实车输入分布训练时加入噪声增强、加滤波模块5.5 独家避坑技巧第一个技巧是记忆压缩要适度。驾驶记忆太长会拖慢推理太短又会导致决策不连贯。我试过用滑动窗口保留最近 10 帧关键事件每帧压缩成一句话描述效果比较均衡。关键事件包括障碍物出现/消失、车道变化、交通灯变化、自车加减速等。第二个技巧是工具层要能独立运行。即使大模型完全失效工具层也应该能基于传统规则生成一条安全轨迹。这样在大模型出现异常时系统可以无缝降级到传统模式保证基本安全。第三个技巧是仿真场景要定期更新。模型训练完后如果一直用同一批仿真场景测试很容易过拟合。建议每周生成一批新的随机场景特别是针对模型最近出错的场景类型做定向生成。6. 我对这条技术路线的一些实际体会做了一段时间 Agent-Driver 相关的实验最大的感受是大模型在自动驾驶里的角色更像是“副驾驶”而不是“主驾驶”。它擅长处理语义理解、常识推理、长尾场景判断但在数值精度、实时性、确定性方面传统方法仍然不可替代。所以架构设计上一定要让大模型做它擅长的事把不擅长的部分交给工具层和执行层。另一个体会是数据质量比模型大小更重要。我试过用 7B 模型在高质量决策数据上微调效果比 13B 模型在低质量数据上微调要好。驾驶决策数据的标注一致性很关键如果同一个场景不同标注员给出不同决策模型就会学乱。建议标注时制定详细的决策规范并且做交叉校验。最后安全兜底永远是第一位的。不管大模型多聪明工具层的安全校验和降级逻辑都不能省。我见过一些项目为了追求“端到端”的简洁性把安全校验也交给大模型结果在边界场景下出现了危险决策。这个教训值得所有做自动驾驶智能体的人记住。 Agent-Driver：大模型驱动的自动驾驶智能体架构与部署实践
1. 从模块堆叠到统一智能Agent-Driver 到底在解决什么问题做过自动驾驶感知或者规控的朋友大概率都经历过那种“模块拼装”的痛苦。一个典型的 L2 系统感知模块输出障碍物列表预测模块给出未来轨迹规划模块再基于规则或者优化算法算出一条路径最后控制模块去跟踪。每个模块单独看指标都还行但一旦上路各种边界场景就开始暴露问题感知漏检一个锥桶预测没考虑到旁车突然加塞规划出来的轨迹要么过于保守被后车鸣笛要么过于激进让乘客紧张。更麻烦的是这些模块之间的接口是人工定义的信息在传递过程中不断被压缩和丢失前一个模块的置信度、不确定性很难完整传递给下游。Agent-Driver 这个方向之所以最近被反复讨论核心就在于它试图用一个大模型驱动的智能体把“感知—预测—规划—控制”这条链路里原本割裂的决策过程重新组织成一个具备推理能力、记忆能力和工具调用能力的统一体。它不是简单地把某个模块换成大模型而是让大模型扮演一个“驾驶决策中枢”的角色接收多模态输入摄像头图像、激光雷达点云特征、自车状态、导航指令结合历史记忆和当前场景理解输出带有解释性的驾驶决策并且能够调用不同的工具模块去完成具体计算。我个人的理解是Agent-Driver 的价值不在于它现在就能完全替代传统规控而在于它提供了一种新的架构范式用语言模型的推理能力去处理长尾场景中的语义理解和常识判断用传统算法去保证底层控制的实时性和安全性。这两者不是替代关系而是互补关系。对于做自动驾驶的工程师来说理解这套架构的设计逻辑比急着去复现某个具体模型更重要。这篇文章我会从架构拆解、训练策略、实操部署、问题排查几个角度把 Agent-Driver 这条技术路线讲清楚。适合有一定深度学习基础、做过感知或规控、想了解大模型如何落地到自动驾驶场景的读者。如果你之前只做过纯视觉或者纯规则规划也没关系我会尽量把关键概念用生活化的方式解释清楚。2. Agent-Driver 架构拆解大模型在驾驶闭环里到底扮演什么角色2.1 核心思路把驾驶任务重新定义为“推理工具调用”传统自动驾驶的决策模块本质上是一个映射函数输入是结构化的场景描述障碍物位置、速度、车道线信息输出是控制指令或者轨迹。这个映射函数要么是人工规则写的要么是优化算法算的要么是端到端网络学的。Agent-Driver 的思路不太一样它把驾驶任务重新定义成一个“推理过程”大模型先理解当前场景发生了什么然后推理出应该采取什么策略最后调用相应的工具去执行。举个例子前方有一个施工区域锥桶摆放不规则旁边还有一辆车在缓慢行驶。传统规控可能会因为锥桶不在标准车道线内而出现决策犹豫但大模型可以结合“施工区域”“锥桶”“旁车缓慢行驶”这些语义信息推理出“应该减速并保持安全距离同时准备变道避让”这样的高层决策。然后它调用轨迹生成工具在满足安全约束的前提下生成一条具体轨迹。这个过程中大模型不直接输出方向盘转角和油门刹车而是输出决策意图和工具调用指令。这样做的好处是大模型的推理能力被用在了它擅长的地方——语义理解和常识推理而具体的数值计算和实时控制仍然交给传统模块。这种分工方式既发挥了大模型的泛化能力又避免了它在数值精度和实时性上的短板。2.2 架构分层感知层、推理层、工具层、执行层从工程实现的角度Agent-Driver 可以拆成四层。感知层负责把原始传感器数据转换成大模型能理解的输入形式。这里不一定非要用端到端的方式把图像直接喂给大模型更常见的做法是用一个预训练好的视觉编码器提取特征再通过投影层映射到语言模型的嵌入空间。激光雷达点云可以用 PointPillars 或者 VoxelNet 提取 BEV 特征然后和视觉特征做融合。推理层就是大模型本身通常是一个经过驾驶领域数据微调的多模态大模型。它的输入包括当前帧的感知特征、历史帧的记忆摘要、导航指令、自车状态等输出是自然语言形式的决策描述和结构化的工具调用请求。这里有个关键设计大模型需要维护一个“驾驶记忆”把过去几秒到几十秒的关键事件压缩成文本或者向量形式供当前推理使用。这个记忆机制对于处理连续决策场景非常重要比如跟车、变道、路口通行等。工具层是一组可被大模型调用的函数或模块包括轨迹生成器、碰撞检测器、速度规划器、车道保持控制器等。大模型通过输出特定的调用格式比如 JSON来触发这些工具工具执行完毕后把结果返回给大模型大模型再决定下一步动作。这个过程中工具层实际上承担了“安全兜底”的角色即使大模型的决策意图有问题工具层里的碰撞检测和约束校验也能拦截掉不安全的输出。执行层就是传统的控制模块负责把工具层生成的轨迹转换成具体的油门、刹车、转向指令。这一层通常要求高实时性所以不会让大模型直接参与。2.3 为什么选择这种架构优势与代价这种架构最大的优势是泛化能力。传统规控在面对未见过的场景时往往需要人工添加规则或者重新调参而大模型可以依靠预训练阶段积累的常识推理能力对新的场景组合做出合理判断。比如“前方有救护车鸣笛旁边车道有空间”这种场景大模型可以推理出应该让行而传统规则可能需要专门写一条逻辑。第二个优势是可解释性。大模型输出的决策描述是自然语言的工程师可以直接看到它“在想什么”这对于调试和验证非常有价值。传统端到端模型的输出是一个黑盒轨迹出了问题很难定位原因。但代价也很明显。首先是推理延迟大模型的单次推理时间通常在几百毫秒到几秒之间对于高速行驶的车辆来说这个延迟可能无法接受。所以实际部署时大模型通常只负责低频的高层决策比如每 500ms 一次底层控制仍然由高频的传统模块完成。其次是训练数据需求要让大模型学会驾驶领域的推理需要大量带有决策标注的驾驶场景数据这种数据的采集和标注成本很高。还有一个容易被忽视的问题是工具调用的可靠性。大模型输出 JSON 格式的调用请求时可能会出现格式错误、参数越界、调用不存在的工具等问题。工程上需要加一层解析和校验逻辑对不合法的调用进行拦截和重试。3. 训练策略从通用大模型到驾驶智能体3.1 数据准备驾驶场景数据的采集与标注训练 Agent-Driver 的第一步是准备数据。和传统感知模型不同这里需要的数据不仅是传感器原始数据和标注框还需要决策层面的标注。具体来说每条数据样本应该包含当前场景的感知结果障碍物、车道线、交通标志等、自车状态速度、加速度、航向角、导航指令、以及对应的“正确决策”描述。这个“正确决策”描述可以是人工标注的也可以从人类驾驶数据中自动提取。比如用真实驾驶日志把人类驾驶员的操作反推成决策描述“前方车辆减速本车跟随减速保持 2 秒时距”。这种自动提取的方式成本更低但需要设计好反推规则。数据来源方面公开数据集如 nuScenes、Waymo Open Dataset 可以提供感知和轨迹数据但决策描述需要自己补充。仿真环境如 CARLA、VTD 可以生成大量带标注的场景特别是危险场景和边界场景这些在真实数据中比较稀缺。我个人的经验是真实数据保证分布真实性仿真数据补充长尾覆盖两者按 7:3 或者 6:4 的比例混合使用效果比较好。标注格式上建议统一成 JSON 结构每条样本包含 scene_id、timestamp、perception、ego_state、navigation、decision_text、tool_calls 等字段。decision_text 是自然语言描述tool_calls 是结构化的工具调用序列。这样既方便大模型做监督微调也方便后续做强化学习。3.2 微调方法LoRA 与全参数微调的取舍大模型微调这块目前主流有两种方案全参数微调和 LoRALow-Rank Adaptation。全参数微调效果通常更好但显存需求大7B 模型全参数微调至少需要 8 张 A100 80G而且训练时间长。LoRA 只训练低秩适配矩阵显存需求可以降到 1-2 张 A100训练速度也快很多。对于 Agent-Driver 这种领域适配任务我的建议是先用 LoRA 做快速验证效果不够再考虑全参数微调。LoRA 的秩rank通常设 8 到 64 之间驾驶领域任务我试过 rank32 效果比较均衡。学习率方面LoRA 可以用 1e-4 到 3e-4全参数微调则要降到 1e-5 到 2e-5否则容易灾难性遗忘。训练框架可以用 LLaMA-Factory 或者 Swift这两个都支持 LoRA 和全参数微调配置也比较简单。数据格式用 sharegpt 或者 alpaca 都行关键是把驾驶场景的输入输出组织成对话形式。比如{ conversations: [ {from: human, value: 当前场景前方 30 米有静止车辆本车速度 60km/h左侧车道无车。请给出决策。}, {from: gpt, value: 决策减速并准备向左变道。调用工具generate_trajectory(target_speed40, lane_changeleft)} ] }这种格式可以让模型学会“理解场景—推理决策—调用工具”的完整流程。3.3 训练环境搭建硬件选型与依赖配置训练环境这块如果只是做 LoRA 微调单卡 24G 显存的 4090 或者 A5000 就能跑 7B 模型。全参数微调建议至少 4 张 A100 80G。云训练平台可以用 AutoDL 或者阿里云 PAI按小时计费比较灵活。软件环境方面PyTorch 2.0 以上、CUDA 11.8 以上是基础。DeepSpeed 或者 FSDP 用于分布式训练transformers 和 peft 库用于模型加载和 LoRA 配置。如果要做多模态训练还需要额外配置视觉编码器比如 CLIP 或者 SigLIP。一个容易踩的坑是版本兼容性。peft 和 transformers 的版本要匹配否则加载 LoRA 权重时会报错。我一般会固定版本号比如 transformers4.36.0、peft0.7.0避免自动升级带来的问题。另外训练前一定要用少量数据跑通全流程确认数据加载、前向传播、损失计算、反向传播都没问题再上全量数据。3.4 强化学习与人类反馈的引入监督微调只能让模型模仿标注数据中的决策但标注数据不可能覆盖所有场景而且“正确决策”的定义本身就有模糊性。这时候可以考虑引入强化学习或者人类反馈。具体做法是让模型在仿真环境中执行决策根据安全性、舒适性、通行效率等指标计算奖励然后用 PPO 或者 DPO 算法优化模型策略。DPODirect Preference Optimization比 PPO 更简单不需要单独训练奖励模型直接用偏好数据对优化。偏好数据可以来自人类驾驶员的选择也可以来自仿真环境中的规则评分。比如同一个场景模型生成了两条决策一条导致急刹车一条平稳减速后者得分更高就可以构造一个偏好对。不过强化学习这块坑比较多奖励函数设计不好容易导致模型走捷径。比如模型发现“一直保持静止”可以避免碰撞但完全丧失了通行效率。所以奖励函数要平衡安全、效率和舒适性通常安全权重最高效率次之舒适性再次。4. 实操部署从模型到车端的完整链路4.1 模型量化与推理加速训练好的模型要部署到车端第一个问题就是推理速度。7B 模型 FP16 精度下需要 14G 左右显存车端芯片通常没有这么大显存所以必须做量化。常用的量化方案有 GPTQ、AWQ、GGUF 等可以把模型压缩到 4bit 甚至 3bit显存需求降到 4-6G。量化会带来精度损失但驾驶决策任务对数值精度的要求没有感知任务那么高4bit 量化通常可以接受。我实测下来AWQ 量化在驾驶场景问答任务上准确率下降大概 2-3 个百分点但推理速度提升 2 倍以上。如果车端芯片支持 INT8 或者 INT4 加速效果会更好。推理框架可以用 vLLM 或者 TensorRT-LLM。vLLM 的 PagedAttention 对长序列推理优化很好适合处理驾驶记忆这种长上下文场景。TensorRT-LLM 在 NVIDIA 芯片上性能更强但配置复杂一些。如果车端用的是地平线或者黑芝麻的芯片需要用厂商提供的推理工具链做转换。4.2 工具层的实现与安全校验工具层是 Agent-Driver 安全性的关键保障。每个工具函数都要有明确的输入输出定义和边界检查。比如轨迹生成工具输入是目标速度、目标车道、时间范围输出是一条轨迹点序列。工具内部要包含碰撞检测、动力学约束校验、交通规则校验等逻辑确保生成的轨迹是安全的。大模型输出的工具调用请求需要经过一层解析器转换成实际的函数调用。解析器要处理几种异常情况JSON 格式错误、参数缺失、参数类型错误、调用不存在的工具。对于格式错误可以尝试用正则表达式提取关键信息或者让模型重新生成。对于参数越界比如目标速度超过了道路限速解析器要自动截断到合法范围。还有一个重要设计是工具调用的超时和降级。如果某个工具执行超时或者返回异常系统要能自动降级到安全策略比如靠边停车或者保持当前车道行驶。这个降级逻辑不能依赖大模型必须是硬编码的安全兜底。4.3 仿真测试CARLA 与 VTD 的联合验证实车测试成本高、风险大所以大部分验证工作要在仿真环境里完成。CARLA 是目前最常用的开源自动驾驶仿真器支持 Python API可以方便地注入自定义决策模块。VTD 在场景渲染和传感器仿真方面更强适合做感知算法的验证。Agent-Driver 的仿真测试流程通常是在 CARLA 中搭建场景把大模型决策模块接入 CARLA 的车辆控制接口让车辆在仿真环境中运行记录决策日志和车辆状态。测试场景要覆盖典型场景跟车、变道、路口通行和边界场景cut-in、鬼探头、施工区域。我建议把仿真测试分成两个阶段单场景回归测试和大规模随机测试。单场景回归测试用于验证特定场景下的决策正确性每次修改模型或者工具后都要跑一遍。大规模随机测试用于发现未知的边界问题可以用 CARLA 的 ScenarioRunner 生成大量随机场景统计碰撞率、违规率、通行效率等指标。4.4 实车部署的注意事项从仿真到实车有几个关键差异需要注意。首先是传感器噪声仿真环境的数据太干净了实车的感知结果会有抖动和漏检大模型需要有一定的鲁棒性。其次是通信延迟大模型推理和工具调用之间的通信如果走网络延迟可能达到几十毫秒这个要在系统设计时预留好时间预算。实车部署时建议先用影子模式运行一段时间。大模型决策模块只做推理不实际控制车辆把决策结果和人类驾驶员的实际操作做对比。这样可以积累真实场景下的决策数据同时发现模型的问题而不影响行车安全。影子模式跑通后再逐步开放控制权限从低速场景开始逐步扩展到高速场景。5. 常见问题与排查技巧实录5.1 模型输出格式不稳定怎么办这是最常见的问题。大模型有时候输出纯文本决策描述有时候输出 JSON有时候 JSON 格式还不对。解决方法有几个一是在训练数据里统一输出格式让模型学会固定模板二是在推理时用 constrained decoding限制输出必须符合 JSON schema三是在解析层做容错用正则表达式提取关键字段。我个人的经验是训练数据格式统一比推理时约束更有效。如果训练数据里 90% 的样本都是标准 JSON 格式模型自然会学会这种格式。另外可以在 system prompt 里明确要求输出格式比如“请以 JSON 格式输出包含 decision 和 tool_calls 两个字段”。5.2 工具调用参数越界怎么处理大模型有时候会生成不合理的参数比如目标速度设为 200km/h或者变道目标车道设为对向车道。解析层必须做参数校验把越界参数截断到合法范围。同时要把校验结果反馈给大模型让它知道参数被修正了避免连续生成错误参数。更稳妥的做法是在工具函数内部也做一层校验。即使解析层漏掉了工具层也能拦截。比如轨迹生成工具在收到目标速度后先和道路限速做比较取较小值。这种双重校验机制可以大大提高系统的安全性。5.3 推理延迟过高影响实时性大模型推理延迟主要来自两个方面模型本身的计算量和输入序列长度。驾驶场景的输入通常包含感知结果、历史记忆、导航指令等序列长度可能达到几千 token。减少延迟的方法包括量化模型、缩短输入序列只保留最近几帧记忆、用更小的模型比如 3B 或者 1.5B、用推理加速框架。如果延迟仍然无法满足要求可以考虑异步推理大模型每 500ms 推理一次输出未来 2 秒的决策序列底层控制模块在这 2 秒内按照决策序列执行。这样大模型的推理延迟就不会直接影响控制频率。5.4 常见问题速查表问题现象可能原因排查方法解决思路模型输出纯文本无 JSON训练数据格式不统一检查训练样本格式统一训练数据格式加 system prompt 约束工具调用参数越界模型未学会参数范围打印模型输出参数解析层校验工具层双重校验推理延迟超过 1 秒模型太大或序列太长测量各阶段耗时量化模型、缩短记忆长度、异步推理仿真中碰撞率高决策过于激进或工具层校验不足回放碰撞场景日志调整奖励函数、加强工具层安全校验实车感知抖动导致决策异常模型对噪声鲁棒性不足对比仿真和实车输入分布训练时加入噪声增强、加滤波模块5.5 独家避坑技巧第一个技巧是记忆压缩要适度。驾驶记忆太长会拖慢推理太短又会导致决策不连贯。我试过用滑动窗口保留最近 10 帧关键事件每帧压缩成一句话描述效果比较均衡。关键事件包括障碍物出现/消失、车道变化、交通灯变化、自车加减速等。第二个技巧是工具层要能独立运行。即使大模型完全失效工具层也应该能基于传统规则生成一条安全轨迹。这样在大模型出现异常时系统可以无缝降级到传统模式保证基本安全。第三个技巧是仿真场景要定期更新。模型训练完后如果一直用同一批仿真场景测试很容易过拟合。建议每周生成一批新的随机场景特别是针对模型最近出错的场景类型做定向生成。6. 我对这条技术路线的一些实际体会做了一段时间 Agent-Driver 相关的实验最大的感受是大模型在自动驾驶里的角色更像是“副驾驶”而不是“主驾驶”。它擅长处理语义理解、常识推理、长尾场景判断但在数值精度、实时性、确定性方面传统方法仍然不可替代。所以架构设计上一定要让大模型做它擅长的事把不擅长的部分交给工具层和执行层。另一个体会是数据质量比模型大小更重要。我试过用 7B 模型在高质量决策数据上微调效果比 13B 模型在低质量数据上微调要好。驾驶决策数据的标注一致性很关键如果同一个场景不同标注员给出不同决策模型就会学乱。建议标注时制定详细的决策规范并且做交叉校验。最后安全兜底永远是第一位的。不管大模型多聪明工具层的安全校验和降级逻辑都不能省。我见过一些项目为了追求“端到端”的简洁性把安全校验也交给大模型结果在边界场景下出现了危险决策。这个教训值得所有做自动驾驶智能体的人记住。