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 与全参数微调的取舍

大模型微调这块，目前主流有两种方案：全参数微调和 LoRA（Low-Rank Adaptation）。全参数微调效果通常更好，但显存需求大，7B 模型全参数微调至少需要 8 张 A100 80G，而且训练时间长。LoRA 只训练低秩适配矩阵，显存需求可以降到 1-2 张 A100，训练速度也快很多。

对于 Agent-Driver 这种领域适配任务，我的建议是先用 LoRA 做快速验证，效果不够再考虑全参数微调。LoRA 的秩（rank）通常设 8 到 64 之间，驾驶领域任务我试过 rank=32 效果比较均衡。学习率方面，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_speed=40, lane_change=left)"} ] }

这种格式可以让模型学会“理解场景—推理决策—调用工具”的完整流程。

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 权重时会报错。我一般会固定版本号，比如 transformers==4.36.0、peft==0.7.0，避免自动升级带来的问题。另外，训练前一定要用少量数据跑通全流程，确认数据加载、前向传播、损失计算、反向传播都没问题，再上全量数据。

3.4 强化学习与人类反馈的引入

监督微调只能让模型模仿标注数据中的决策，但标注数据不可能覆盖所有场景，而且“正确决策”的定义本身就有模糊性。这时候可以考虑引入强化学习或者人类反馈。具体做法是：让模型在仿真环境中执行决策，根据安全性、舒适性、通行效率等指标计算奖励，然后用 PPO 或者 DPO 算法优化模型策略。

DPO（Direct 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 常见问题速查表

5.5 独家避坑技巧

第一个技巧是记忆压缩要适度。驾驶记忆太长会拖慢推理，太短又会导致决策不连贯。我试过用滑动窗口保留最近 10 帧关键事件，每帧压缩成一句话描述，效果比较均衡。关键事件包括：障碍物出现/消失、车道变化、交通灯变化、自车加减速等。

第二个技巧是工具层要能独立运行。即使大模型完全失效，工具层也应该能基于传统规则生成一条安全轨迹。这样在大模型出现异常时，系统可以无缝降级到传统模式，保证基本安全。

第三个技巧是仿真场景要定期更新。模型训练完后，如果一直用同一批仿真场景测试，很容易过拟合。建议每周生成一批新的随机场景，特别是针对模型最近出错的场景类型做定向生成。

6. 我对这条技术路线的一些实际体会

做了一段时间 Agent-Driver 相关的实验，最大的感受是：大模型在自动驾驶里的角色，更像是“副驾驶”而不是“主驾驶”。它擅长处理语义理解、常识推理、长尾场景判断，但在数值精度、实时性、确定性方面，传统方法仍然不可替代。所以架构设计上，一定要让大模型做它擅长的事，把不擅长的部分交给工具层和执行层。

另一个体会是，数据质量比模型大小更重要。我试过用 7B 模型在高质量决策数据上微调，效果比 13B 模型在低质量数据上微调要好。驾驶决策数据的标注一致性很关键，如果同一个场景不同标注员给出不同决策，模型就会学乱。建议标注时制定详细的决策规范，并且做交叉校验。

最后，安全兜底永远是第一位的。不管大模型多聪明，工具层的安全校验和降级逻辑都不能省。我见过一些项目为了追求“端到端”的简洁性，把安全校验也交给大模型，结果在边界场景下出现了危险决策。这个教训值得所有做自动驾驶智能体的人记住。