1. 从感知-规划-控制到LLM当大脑Agent-Driver到底改变了什么如果你在自动驾驶行业待过几年一定对传统模块化流水线不陌生感知模块出障碍物列表预测模块出轨迹规划模块出路径控制模块出油门刹车。这套架构跑了几十年稳定、可解释、容易过车规但它的天花板也很明显——每个模块只盯着自己那一亩三分地遇到长尾场景比如施工路段临时改道、前车突然开门下人、路边有人打手势就开始互相甩锅规划器拿到的输入永远是干净但残缺的世界。Agent-Driver 这个方向做的事情本质上是把大语言模型或者多模态大模型塞进自动驾驶的决策环里让它扮演一个会推理、会调用工具、会记忆经验的智能体而不是简单地做端到端回归。我第一次看到这个思路的时候直觉是这不就是把 ChatGPT 套个壳吗但真正拆开看它的架构设计会发现里面有几个非常关键的工程取舍值得单独拎出来讲。Agent-Driver 的核心定位是让大模型负责高层语义决策与工具编排而把底层的轨迹生成、碰撞检测、控制执行交给成熟的传统模块。它不追求用一个网络端到端吃掉所有东西而是走大模型做大脑、传统算法做小脑和脊髓的混合路线。这个定位决定了它的架构、训练方式和落地路径和纯端到端方案完全是两码事。适合读这篇内容的人我大致分三类一是做自动驾驶决策规划、想了解大模型怎么接进来的工程师二是做大模型应用、想看看智能体在实时物理系统里怎么落地的开发者三是做仿真和数据集、想搞清楚这套东西对数据管线有什么新要求的研究人员。如果你只是想调个 Coze 智能体玩玩这篇可能偏重了但里面的工具编排和记忆设计思路照样能借鉴。提示Agent-Driver 不是要取代现有的规划控制栈而是在它上面加一层语义决策层。理解这一点后面所有的架构选择都顺了。2. Agent-Driver 的四层架构拆解与各层职责边界2.1 感知抽象层把原始传感器数据翻译成大模型能读的话大模型再强也没法直接吃点云和 RAW 图像。所以第一层要做的是把感知输出抽象成结构化的自然语言描述或者轻量 token 序列。这里有个很容易被忽略的细节抽象粒度直接决定了大模型的推理质量。我见过两种做法。一种是极简派只给大模型喂前方 30 米有静止障碍物、左侧车道空闲这种高度压缩的语义另一种是详述派把每个交通参与者的位置、速度、朝向、历史轨迹都转成文本。实测下来极简派推理快但容易漏掉关键上下文详述派信息全但 token 消耗爆炸推理延迟直接顶到几百毫秒实时性就没了。比较稳妥的中间路线是分层抽象对当前决策直接相关的目标比如自车前方 50 米、相邻车道给详细描述对远处和无关目标只给聚合统计。这样既控制 token 量又保留关键信息。具体实现上可以用规则模板做初筛再用一个小模型做重要性打分把 top-k 目标转成自然语言。# 感知抽象层的简化示意分层筛选 模板化描述 def abstract_perception(objects, ego_state, radius50.0): relevant [] for obj in objects: dist compute_distance(obj, ego_state) if dist radius: # 近处目标详细描述 relevant.append({ type: obj.type, rel_pos: obj.position - ego_state.position, velocity: obj.velocity, heading: obj.heading, history: obj.trajectory[-5:], # 最近5帧 detail_level: high }) else: # 远处目标聚合 relevant.append({ type: obj.type, count: 1, detail_level: low }) return build_prompt(relevant, ego_state)这段代码只是示意真实系统里还要考虑坐标系转换、时间对齐、传感器融合后的置信度过滤。但核心思想就是别让大模型去干它不擅长的数值密集活儿把脏活累活在前一层干完。2.2 推理决策层大模型在这里到底想什么这是 Agent-Driver 最核心也最容易被误解的一层。很多人以为大模型在这里就是输出一个左转/右转/直行的标签那就太小看它了。实际上推理决策层要做三件事场景理解、意图推理、工具调用规划。场景理解是把抽象后的感知信息结合地图、交通规则形成对当前局面的判断。比如我在一个无保护左转路口对向有直行车流我的绿灯还剩 3 秒。意图推理是预测其他参与者可能的行为以及自车应该采取的策略。工具调用规划则是决定接下来要调用哪些底层工具——是调用轨迹生成器出一条候选轨迹还是调用碰撞检测器验证安全性还是调用记忆模块查历史相似场景。这里有个关键设计大模型不直接输出控制量而是输出工具调用序列 参数。这就像你让一个经验丰富的司机描述他接下来要做什么他会说我先看看左边后视镜然后轻踩油门试探一下而不是直接报一个方向盘角度。这种设计的好处是可解释、可干预、可验证。推理决策层的 prompt 设计是重中之重。我试过几种模板最后发现结构化 prompt few-shot 示例 工具描述的组合最稳。工具描述要写清楚每个工具的功能、输入输出格式、适用条件大模型才能正确编排。工具名称功能输入输出适用场景TrajectoryGen生成候选轨迹目标点、约束轨迹点序列需要变道/转弯CollisionCheck碰撞检测轨迹、障碍物安全/危险任何轨迹执行前MemoryQuery查历史经验场景特征相似案例遇到罕见场景RuleCheck交规校验轨迹、地图合规/违规路口、限速区2.3 工具执行层传统算法在这里守住底线工具执行层就是那些老伙计轨迹生成器、碰撞检测、运动学校验、控制接口。它们不参与语义推理只负责把大模型给出的高层意图变成具体、安全、可执行的轨迹。这一层的设计原则是确定性优先。大模型可以天马行空地推理但工具执行必须是确定性的、可复现的、有安全边界的。比如轨迹生成器无论大模型给什么参数它输出的轨迹都必须满足车辆运动学约束、不超过最大曲率、不超出道路边界。碰撞检测更是硬门槛任何轨迹在执行前必须过这一关不过就退回给大模型重新规划。我踩过的一个坑是早期版本里大模型输出的目标点偶尔会落在道路外面轨迹生成器直接报错整个决策链就断了。后来在工具执行层加了一层参数合法性校验把非法参数钳制到合法范围同时给大模型返回一个参数被修正的反馈让它下一轮调整。这个反馈机制非常关键相当于给大模型一个触觉让它知道自己的输出在物理世界里行不行得通。2.4 记忆与反思层让智能体吃一堑长一智记忆层是 Agent-Driver 区别于普通端到端模型的重要特征。它存两类东西短期记忆当前行程的决策历史、执行结果和长期记忆跨行程的相似场景、成功/失败经验。短期记忆的作用是保持决策一致性。比如大模型上一秒决定变道下一秒不能因为一点噪声就反悔否则车辆会画龙。长期记忆的作用是经验复用。当遇到一个罕见场景时先查记忆库里有没有相似案例有的话把当时的决策和结果作为 few-shot 示例喂给大模型能显著提升决策质量。反思机制则是定期比如每个行程结束对决策过程做复盘哪些决策导致了急刹车哪些场景下大模型犹豫了这些反思结果写回长期记忆形成闭环。这套机制听起来很美好但工程上最难的是记忆的检索和压缩——存太多检索慢存太少没效果而且文本记忆的相似度匹配远不如向量检索靠谱。3. 训练管线从数据采集到 Agent 微调的完整链路3.1 数据从哪来仿真为主、实车为辅的混合策略训练 Agent-Driver 需要的数据和传统感知训练完全不是一个东西。感知要的是图像-标注对Agent 要的是场景-决策-结果三元组。具体来说每条数据要包含抽象后的场景描述、大模型应该输出的推理过程和工具调用、工具执行的实际结果、以及这个结果好不好奖励信号。实车采集这种数据成本极高因为你需要覆盖大量长尾场景而长尾之所以叫长尾就是因为它罕见。所以主流做法是仿真为主。用 CarSim、PreScan、VTD 这类仿真器搭建场景让 Agent 在里面跑自动记录决策链路。仿真的好处是可控、可重复、可批量而且能人为制造危险场景而不担风险。但仿真有个致命问题sim-to-real gap。仿真里的感知是完美的实车感知有噪声、有遮挡、有误检。如果 Agent 只在完美感知上训练实车一上就崩。所以我的建议是在仿真数据里主动注入感知噪声——随机丢弃目标、偏移位置、加虚假目标让 Agent 学会在不确定下决策。这个技巧在实车测试时救过我很多次。实车数据虽然少但必须采。重点采两类一是仿真里难以复现的复杂交互场景比如人车博弈二是用来做最终验证的测试集。实车数据的标注成本高可以用大模型辅助标注——让一个强模型先跑一遍决策人工只做修正效率能提升好几倍。3.2 监督微调教大模型像老司机一样思考有了数据第一步是监督微调SFT。这一步的目标不是让大模型学会开车而是让它学会按照 Agent-Driver 的格式输出推理和工具调用。训练数据的构造是关键。每条样本的输入是抽象场景 工具描述 历史记忆输出是推理链 工具调用序列。推理链要写得像人话比如对向有车直行我的左转绿灯时间不足应该等待而不是抢行。工具调用要格式规范比如TrajectoryGen(target(x,y), constraint...)。这里有个经验推理链的质量比数量重要得多。我试过用自动生成的低质量推理链训练模型学出来的推理全是废话工具调用倒是格式对了但逻辑不通。后来改成人工精修 大模型辅助生成只保留逻辑清晰的样本虽然数据量少了一个数量级但效果反而更好。SFT 的另一个坑是灾难性遗忘。大模型在微调后可能丢失通用能力导致遇到没见过的情况时推理能力下降。缓解办法是混合一部分通用指令数据一起训练比例大概 10:1 到 20:1。这个比例需要根据基座模型的能力调基座越强通用数据可以越少。3.3 强化学习与偏好优化让决策越开越好SFT 之后模型能按格式输出了但决策质量还不一定好。这时候需要强化学习或者偏好优化来对齐什么是好决策。奖励函数的设计是核心难点。自动驾驶的奖励不能只看有没有撞那样太稀疏模型学不动。要设计稠密奖励安全性碰撞、急刹、违规扣分、舒适性加速度变化率、 jerk、效率通行时间、跟车距离、合规性限速、车道保持。这几项要加权权重怎么定是个玄学我的经验是先用规则跑一批 baseline看各项的分布再定权重让各项贡献大致均衡。偏好优化比如 DPO是另一条路不需要显式奖励函数只需要成对的好决策 vs 坏决策数据。这种数据相对好构造同一个场景让模型生成多条决策人工或者规则打分排序取 top 和 bottom 做偏好对。DPO 训练比 RL 稳定但需要的数据量更大。注意强化学习在自动驾驶里非常容易训崩因为奖励函数稍微设计不当模型就会钻空子。比如只奖励通行效率模型就学会疯狂超车。一定要有安全硬约束兜底RL 只优化软目标。3.4 工具调用的专项训练别让大模型手残大模型会推理不代表会正确调用工具。工具调用的参数格式、取值范围、调用顺序都需要专项训练。我的做法是构造大量工具调用专项样本覆盖各种边界情况参数缺失、参数越界、工具返回失败、需要重试等。训练时可以用课程学习先训简单场景单工具调用再训复杂场景多工具编排、条件分支。这样模型学得稳。另外工具调用的失败反馈也要作为训练信号——当工具返回参数非法时模型应该学会修正而不是重复犯错。4. 实战部署延迟、算力与安全的三重博弈4.1 推理延迟大模型上车最大的拦路虎自动驾驶对延迟的要求是毫秒级而大模型推理动辄几百毫秒甚至秒级。这个矛盾是 Agent-Driver 落地的最大障碍。解决办法有几个方向模型小型化。用 7B 甚至 3B 的模型做推理决策配合量化INT8/INT4和蒸馏。实测下来3B 模型量化后在车端芯片上能做到 50-100ms 的单次推理勉强够用。但小模型的推理能力有限需要靠工具和记忆来补。异步推理。决策不需要每帧都做可以每 N 帧做一次高层决策中间帧用传统规划器维持。这样大模型的延迟被摊薄了。N 取多少要看场景复杂度高速上可以大一点城区要小一点。缓存与预推理。对常见场景提前把决策结果缓存起来遇到相似场景直接查缓存。这依赖记忆层的检索质量。边缘-云端协同。复杂场景上传云端推理简单场景车端搞定。但云端有通信延迟和可靠性问题只能作为补充不能作为主路径。方案延迟算力需求适用场景风险小模型车端50-100ms中常规场景能力有限大模型车端300ms高复杂场景延迟超标异步决策摊薄中高速/快速路响应滞后边缘云协同100-500ms低车端非实时场景通信依赖4.2 安全兜底大模型可以错但车不能撞这是我最想强调的一点。Agent-Driver 无论怎么设计大模型都有出错的可能。所以安全兜底必须是独立于大模型的硬约束层。具体来说大模型输出的轨迹必须经过独立的碰撞检测、运动学校验、交规校验。任何一项不过直接否决回退到保守策略比如减速停车。这个兜底层不能用大模型实现必须是确定性的传统算法而且要经过充分验证。另外大模型的输出要有置信度评估。当模型对当前场景不确定时比如输出概率分布很平应该主动降级到保守策略而不是硬着头皮决策。这个置信度可以来自模型本身的输出概率也可以来自多个模型/多次采样的投票一致性。4.3 仿真验证上线前的最后一道关Agent-Driver 上线前必须在仿真里跑够里程。我的经验是至少要在仿真里跑够百万公里级的里程覆盖各种场景分布才能初步放心。仿真场景库要包含常规场景跟车、变道、路口、边缘场景cut-in、鬼探头、施工、极端场景传感器失效、通信中断。仿真验证的重点不是跑通而是跑出问题。要主动构造对抗场景看 Agent 会不会做出危险决策。我一般会用一个独立的对抗场景生成器专门找 Agent 的弱点找到就加进训练集形成迭代闭环。5. 那些文档里不会写的踩坑记录5.1 大模型的幻觉在驾驶场景里有多危险大模型有个通病叫幻觉就是一本正经地胡说八道。在聊天场景里这最多让人哭笑不得在驾驶场景里是要命的。我遇到过模型在场景描述里脑补出一个不存在的行人然后触发急刹也遇到过模型忽略实际存在的障碍物因为它在训练数据里没见过类似形状。缓解幻觉的办法一是感知信息要带置信度低置信度的目标明确标注不确定让模型知道哪些信息可信二是输出要可验证模型的每个决策都要能追溯到具体的感知输入和规则依据追溯不上的决策直接否决三是多模型交叉验证用两个不同基座的模型分别决策不一致时降级。5.2 工具调用的参数格式比想象中脆弱大模型输出 JSON 或者函数调用格式时经常出现各种格式问题多了个逗号、少了个引号、数字写成字符串、嵌套层级错了。这些在聊天场景里解析器能容错但在实时系统里直接崩。我的做法是双重解析 修复先用严格解析器解析失败则用宽松解析器尝试修复再失败则让模型重新生成带错误信息。同时工具调用的 schema 要尽量简单别搞太深的嵌套减少出错概率。5.3 记忆检索的相似但不适用陷阱记忆层最坑的地方是检索出来的相似场景看起来像但关键条件不同直接套用会出事。比如前车减速和前车急刹在文本描述上很像但应对策略完全不同。解决办法是多维度检索 条件校验。检索时不只看场景描述的相似度还要看关键条件相对速度、距离、道路类型是否匹配。匹配不上的记忆只作为参考不作为决策依据。另外记忆里要存适用条件和失效条件检索时先过一遍条件校验。5.4 仿真里跑得好实车一上就怂这是 sim-to-real 的经典问题。仿真里感知完美、其他车辆行为规律、没有传感器噪声Agent 学出来的策略在实车里往往过于激进或者过于保守。我的经验是实车测试要循序渐进先在封闭场地跑再在低流量道路跑最后才上复杂城区。每个阶段都要有安全员随时接管。另外实车数据要持续回流训练让模型适应真实世界的分布。这个迭代周期通常要几个月急不得。6. 我对这套架构的一些个人判断Agent-Driver 这个方向我的判断是方向对但落地节奏会比很多人预期的慢。大模型的推理能力确实能给自动驾驶带来质变尤其是在长尾场景和交互博弈上传统方法很难处理。但工程上的挑战——延迟、算力、安全、验证——每一个都是硬骨头不是靠堆模型就能解决的。短期内我比较看好的是限定场景的 Agent-Driver比如高速巡航、泊车、园区低速。这些场景复杂度可控对延迟容忍度高大模型的价值能发挥出来。全场景城区自动驾驶我觉得还需要几年迭代。另外工具层的建设被很多人低估了。大模型再强如果底层工具不给力决策也落不了地。轨迹生成的质量、碰撞检测的精度、控制接口的响应这些老技术在 Agent-Driver 时代反而更重要了因为它们是大模型能力的放大器。最后分享一个我在实际项目里的小技巧给大模型加一个自言自语的调试模式。正常运行时只输出工具调用调试时让它把完整推理链打出来。这样排查问题时能看到模型到底想了什么比看最终输出有用得多。这个模式在开发阶段帮我定位了至少一半的诡异 bug。