智能体在车联网落地48天：从决策闭环到多车协同的实践记录

智能体在车联网里跑了48天今天正好是一个阶段性的节点。不是那种demo验证、跑通就发朋友圈的48天而是每天顶着数据、时延、通信断连、边缘资源这些硬约束一遍遍调参、压测、复盘才走到了这一步。这十天半月里我们铺了一整套智能体体系在车端和路侧用真实的路口车流数据回灌让智能体在模拟环境里替车队做路径协商、红绿灯通行决策甚至做异常驾驶行为的提前干预判断。今天想把这48天的实践摊开聊一聊哪些场景真的吃这套哪些是在硬凑以及落地时绕不开的坑是什么。这篇文章适合正在做车路协同、边缘AI、或者打算把大模型能力塞进车载设备的朋友也适合对智能体应用边界有好奇的人。为什么之前市面上聊智能体上车多数还停留在“车载语音助手更聪明一点”这个层面因为真正涉及车控、车队协同、路侧感知融合这类闭环决策时智能体的每一步都会牵扯到时延、安全冗余、和通信带宽的硬限制。这48天我们就是在跟这些硬限制周旋。接下来按时间线和问题域拆开讲先说说这48天是怎么过来的再说智能体具体在解决车联网里的什么问题然后是第48天这一天的实况最后是踩坑清单和后续规划。1. 为什么“第48天”才适合写这篇分享1.1 从第1天到第48天智能体上车的三个阶段第1天到第10天我们做的事情其实是“祛魅”。团队里有人觉得智能体是银弹丢到车联网场景里就什么都能干有人觉得这玩意儿就是个API封装叫智能体还是叫函数没什么两样。这种分歧本身就需要用事实验证。前十天我们把目标场景梳理了一遍列出了大约二十多个候选应用点最后用“是否真的需要推理”“是否真的需要自主决策”“数据是否可达”三个筛子过了一遍淘汰了大部分。第11天到第30天是单点验证期。我们挑了三个场景深挖高速匝道汇入时的协同决策、交叉路口多车通行协商、以及异常驾驶行为识别。这三个场景有一个共同点就是单靠预设规则能覆盖80%的情况但剩下20%的边界情况会把规则的缺陷暴露得很彻底。我们把智能体部署成“规则之外的第二层决策者”让它在规则不覆盖的地方补位。这一步跑通之后团队内部才开始真正认同智能体的价值。第31天到第48天是多智能体协同和系统压测阶段。当每个车端都有智能体路侧也有智能体它们之间开始需要协商、承诺、互相等待问题就变了。单智能体做得再好多个智能体在一起也可能出现“集体不智能”。第48天我们实际上就是在处理这种多智能体之间的一个协商失效问题这个问题很有代表性所以干脆把这一天的记录当作今天的重点。1.2 智能体做对了什么不是聊天而是闭环决策很多人对智能体的理解还停留在“会聊天、能问答”这个层面。但在车联网场景里智能体真正值钱的地方是它能接感知数据、做推理决策、下发控制建议然后接收执行结果再反思调整形成闭环。比如我们在交叉路口场景里智能体不是“告诉司机前方有车”而是“基于当前车速、对方车速、路面摩擦系数、信号灯剩余时间给出一个通过路口的建议速度并把这个建议推送给车端执行模块”。这跟传统专家系统的区别在哪传统规则是if-then的遍历组合边界情况要靠人肉堆规则智能体可以在规则覆盖不到的组合空间里基于上下文推理出一个合理的动作。这也是我们选择在车联网里试智能体的根本原因——车联网场景天然具备“感知—决策—执行—反馈”的数据闭环而智能体的推理能力恰好可以在这个闭环里发挥作用。1.3 这篇文章适合谁看如果你是做车路协同、边缘AI、物联网应用开发的这篇文章里的架构思路和踩坑记录可以直接参考。如果你只是对智能体在行业里的落地感兴趣也可以从这些细节里看到智能体真正进入产业场景时面对的不仅是算法问题还有工程、通信、安全等一系列问题缠在一起。我不打算把过程讲得天花乱坠只把第48天的真实经历、前面的阶段性结论、以及那些踩了之后才知道的坑尽可能完整地摆出来。2. 车联网场景里的智能体到底在解决哪些问题2.1 车载端从“听懂话”到“会决策”车载端的智能体最直接的形态是让车“听”懂人的意图。但车联网里这个“听”不只是语音识别而是理解驾驶场景中的多模态信息。我们做的一个功能是让智能体接收车内的摄像头画面、车速信号、导航路径当乘客说“前面是不是有点堵换条路吧”时智能体不是简单地重新规划一条路径而是结合实时路况、剩余里程、充电条件等多维信息生成“在当前电量下若改走A路线会比原路线多绕6公里但能避开拥堵预计晚5分钟到达”这样的决策建议并说明理由。这就是从“听懂话”到“会决策”的差别。年初我们试过用传统槽位填充的方式做这个功能效果很生硬。规则能处理“换条路”这种明确意图却无法处理“有点堵”这种模糊描述与“电量焦虑”这类隐含条件的关联。智能体模型天然擅长这种模糊语义与结构化决策之间的衔接这是它比较突出的优势。2.2 路侧端多目标协同调度路侧的智能体管的不只是一台车而是“一群车”。我们部署在某个模拟路口的智能体会持续接收来自四个方向、约两公里范围内的车辆轨迹数据和信号灯状态实时计算各方向车流的等待成本动态调整信号配时。这个场景如果只是“车多就放行”规则就能解决。但真实情况复杂得多特种车辆优先、公交准点率、行人过街需求、非机动车穿插这些因素相互影响。我们的路侧智能体采用了一种“多目标加权迭代”的策略每个目标单独建模用智能体在每次决策时按当前优先级排序。遇到救护车时它的优先级会瞬间提升到最高但算法在让行时不会让整个路口陷入死锁而是给周边车辆一个有序的减速计划。第20天左右我们统计了一下这个策略比固定配时的方案路口平均延误下降了约17%同时没有出现一次让行导致的死锁。这个数据当时让团队很有信心。2.3 云端跨车聚合与模型迭代云端智能体负责“看得更远”。车端智能体看到的是局部几百米的局面路侧智能体看到的是一个路口的局面而云端智能体可以把数十辆车上传的轨迹、事件、道路状态汇聚起来训练更全局的决策模型再下发给端侧更新。我们把它比喻成“老司机带新司机”。云端是那个见多识广的老司机它见过各种极端天气、突发事故、不按套路出牌的司机所以能沉淀出更稳健的决策模板。端侧智能体则是每天在这条路上跑的新司机它结合云端给的模板和本地实时数据做出更贴合当下的决策。两边通过车联网通信频繁同步每隔一段时间端侧会上传自己的决策记录和效果回执云端基于这些样本做模型微调。第48天的很多问题恰恰出在这个同步机制上——通信一旦抖动端侧拿不到最新的模型或指令就会按过时策略行动。3. 第48天的实况记录链路联调中的三个关键进展3.1 当天任务让智能体接管一组真实的车流量模拟第48天我们设定的目标是在仿真环境里接入一组真实早高峰流量数据一小时内让路侧智能体全程接管信号配时和车辆诱导不依赖任何预设调度规则。值班人员只负责监控不负责干预。这意味着整个小时里所有调度决策都来自智能体越权的风险完全暴露在系统里。这个实验的意义在于检验智能体的“连续决策能力”。之前测的是单点、单回合这次是连续一小时、上千次决策任何一次错误如果没被兜底机制拦住都可能导致连环异常。上午十点数据回灌开始。前十分钟比较平稳智能体给出的信号配时方案与历史经验值基本一致。十五分钟后出现第一次差异某方向车流突然增大智能体把绿灯延了6秒。我们当时盯着屏幕以为这是误判结果两分钟后该方向确实排起了长队那6秒正好让车队在红灯亮起之前多通过了八辆车。3.2 时延问题推理延迟从2.8秒压到380毫秒时延是智能体上车的第一个拦路虎。最初我们直接接了一个公开的通用大模型API一轮推理动辄两三秒这对“对话”来说勉强能忍对“路口调度”来说根本不可用。信号灯的配时周期最细到秒级两秒的推理延迟意味着决策刚出来局面已经变了这等于闭着眼开车。我们用了三招降延迟。第一招是模型裁剪把一个大模型蒸馏成三个小模型分别负责交通流预测、调度决策、异常识别每个模型只有原来十分之一大小。第二招是推理缓存对于相似状态输入如果上一轮决策在生效期内直接复用结果按置信度加权避免重复推理。第三招是端侧部署改造把推理框架换成手机级端侧引擎量化精度从FP16降到INT8换来了速度保住了精度。压测下来的结果是路侧智能体的单轮决策延迟从最初的2.8秒降到了380毫秒。听上去还是不低但在我们的场景里因为决策是滚动做的每秒钟会触发四到五次推理380毫秒的延迟配合预测结果已经足够让决策指令提前到达执行端。关键不是让单次推理无限快而是让“预测—决策—下发”的节奏能提前于现实半步。3.3 一个小意外传感器噪声如何“欺骗”智能体第48天上午十一点意外出现了。路侧一个传感器节点因为温度漂移输出的车速数据整体偏高约8%。这个偏差单看不大但智能体没有校准环节直接把这个偏高数据当作真实数据参与决策。结果某方向的车流被判定为“高速接近”智能体给出的策略是延长该方向的绿灯让车流快速通过但实际上那些车没开那么快延长绿灯的结果是另一个方向的车白等了一轮。这个现象很有意思传统规则系统里输入数据漂移8%输出结果最多带8%的偏差是可容忍的。但智能体不同它基于对场景的“理解”做推理一个偏差可能改变它对整个状态的认知导致决策逻辑整体换一套。就像一个人看错了温度计不仅会觉得天热还会决定脱外套、开空调、改行程一连串行为都变了。这个问题后来靠的是在输入层加一个传感器健康度监测模块偏差超过阈值就把该通道的置信度权重下调并标记为“可疑数据”参与决策而不是直接把它当真实值。3.4 一个小时的收官智能体的“主动性”体现完整闭环下午的模拟收官阶段我们见到了这48天里最有价值的时刻。一辆模拟的故障车在快车道抛锚后方车流迅速堆积智能体在接到前一个传感器的告警后主动生成了一套临时疏导演示方案诱导后方车辆从旁路分流同时协调上游两个路口的信号灯把车流导入相邻的次干道。整个过程没有人工指令智能体自己判断了“故障车不会立刻消失”这个隐含条件所以它选择的是分流而不是等待。这个案例说明智能体真正区别于传统规则系统的是它能在没有被明确告知“故障车要停多久”的情况下自己基于常识推理出“停很久所以需要分流”的结论。这种推理来自模型对世界运行规律的理解积累不需要为每个现场场景去手写规则。传统系统只有在故障类型被提前定义过的情况下才会响应而智能体面对未见过的情况也能尝试给出一个不那么离谱的方案。48天里这种案例出现了好几次也是我们坚持在这个方向投入的主要原因。4. 多智能体协同车辆之间怎么“对话”4.1 单智能体和多智能体的本质差异单智能体的核心是“做出正确的决策”多智能体的核心是“在不确定别人会怎么做的情况下依然做出正确的决策”。这两种情况对模型的要求完全不同。单智能体只需要考虑环境状态多智能体还要考虑其他智能体的策略、意图、可能反应——这个层面的复杂度是指数级上升的。拿我们之前做的交叉路口协商场景来说四辆车同时到达路口每辆车都有一个智能体它们要决定谁先通过。如果每个智能体都只站在自己的角度算最优结果就是大家都想先走路口死锁。我们一开始就是这么做的每个车端智能体用同样的模型、同样的自私策略结果没有一个能学会“让一步”。后来我们意识到多智能体场景里单个智能体再聪明也没用关键是“协商的框架”也就是它们之间用什么语言说话、怎么表达意图、怎么承诺、怎么反悔。这和人类社会的默契类似路口的车能顺畅通过不是因为每辆车都完美预测了其他车而是因为有一套大家都默认遵守的通行秩序。4.2 协商协议让交汇路口的车自己商量怎么通过我们在第38天到第40天集中做了这件事给智能体们设计了一套轻量级的协商协议。这套协议分三层第一层是“广播状态”每辆车到达路口前把自己的位置、速度、预计到达时间广播出去第二层是“提出方案”每辆车的智能体根据其他车的广播信息提出自己期望的通行顺序第三层是“解决冲突”当多辆车的期望互斥时按一个优先级函数排序这个函数考虑了等待时间、车辆类型、是否执行紧急任务等因素。这套协议的实现并不复杂代码量也就数百行。核心难点在于让智能体“学会”表达自己的诉求并且能读懂别人的意图。我们让每个车端智能体在模型输出里增加了一个“协商意图”字段它不只输出“我建议我先走”这样的结论还输出“我为什么这么建议”——基于我还剩多少秒能通过、我后面是否压着车流、我是什么类型的车。这些信息注入到协议层之后其他智能体就能根据这些上下文做出真正的让步而不是机械地执行优先级表。4.3 冲突处理与容错机制当协商失败时怎么办第48天下午我们就遇到了一次协商失败。两辆车几乎同时到达一个无信号灯的小路口它们的广播消息因为通信抖动彼此都没有收到对方的意图数据。结果两辆车都减速到了停止线前互相观望谁也没走。这种情况如果发生在真实道路几秒钟内后方就会鸣笛但在仿真里两个智能体就僵在那里了。排查下来问题出在协议层缺少“超时默认动作”的兜底逻辑。后来我们加了一条规则如果某个协商请求在500毫秒内没有得到响应智能体自动切回保守模式按“右侧来车优先”的基本交通规则执行。同时把这次交互记录下来上传到云端做离线分析持续优化协议参数的默认值。这次故障之后我们在所有协商场景里都强制了“心跳超时”检测宁可保守也不能死锁。多智能体系统里容错不是可选项而是必须嵌入协议设计的第一性原则。5. 这些天踩过的坑智能体车规级落地的避坑清单5.1 数据漂移训练时的车载数据和实车的根本不是一回事第一个大坑是数据漂移。我们第一个版本的车端智能体在实验室里用公开数据集训练效果看着不错。一旦接入实车采集的数据准确率掉得很快。原因很简单公开数据和真实环境的车辆轨迹、传感器噪声、天气干扰特征完全不一样。实验室数据是“干净”的真实环境是“脏”的。这就像在驾校里学车用的是教练车刹车油门都是校准过的真上路之后车身尺寸、方向盘间隙都不同手感自然全变了。解决这个问题的标准做法是“数据同分布化”尽早从目标环境采集真实数据哪怕数量少也要让模型见过“脏”数据的样子。我们后来建立的流程是每次模型迭代都必须先在实车数据上做验证通过之后再进仿真压测。顺序不能倒仿真里跑得再好到了实车环境还是可能一塌糊涂。5.2 推理框架的兼容性模型再准部署不上也白搭第二个坑是我们一开始过于侧重模型精度忽略了对端侧推理引擎的适配。第一代模型的精度确实比第二代高两个百分点但没法在车端硬件上运行只能跑在服务器上推理一次要1.8秒。后面我们花了大量时间做模型量化、算子融合、编译优化才把它塞进了端侧引擎里。如果刚开始就按端侧约束来设计模型结构而不是先做大模型再压缩至少能省掉两周的适配时间。这给我们一个很重要的经验车联网场景里的模型第一性约束是计算资源和时延脱离了部署约束谈模型效果都是空中楼阁。现在我们的模型迭代流程会把“目标硬件上的推理时延”当作模型结构的硬约束与精度指标同等对待谁都不能单独拍板。5.3 安全兜底智能体的“免责机制”和“人工接管预案”第三个坑涉及安全也是这48天里最敏感的。智能体任何时候都可能做出错误决策车联网场景里这些错误可能直接关系到行车安全。所以我们从第15天开始强制给所有智能体决策加了一个“免责机制”智能体输出的所有决策都标注置信度置信度低于阈值的决策不会直接下发执行而是转成“建议”推送给驾驶员或中心监控员由人来做最终确认。同时系统必须有“人工接管预案”任何时刻监控员都有一键切回规则模式的权利。这件事在纯技术视角里经常被忽略但在真实落地里是生死线。智能体不是绝对正确的神它只是一个推理工具越早承认这一点越能在系统设计里做好兜底。置信度低时人类干预置信度高时智能体自治这个平衡是靠两个月的真实反馈一点点调出来的。5.4 模型更新策略端侧模型不能像云端一样随时热更第四个坑是模型更新策略。云端模型随时可以热更新但端侧模型不行。车端设备可能处于弱网或离线状态如果模型版本不一致不同车上的智能体对同一场景的理解就可能不同这会给协同制造麻烦。第42天我们就遇到过一次两辆相邻的车一辆用的是上一版模型一辆用的是新版模型在同一个路口协商时一个坚持概率最高的方案另一个坚持“上一版策略里概率也还行”的方案僵持了好几个回合。后来我们建立了严格的版本管理机制模型升级必须做到向后兼容新模型要能在旧模型的输出分布空间里平滑过渡不能让决策风格突变。端侧升级也采用灰度策略先在一小部分车辆上跑新模型观察效果和数据回执稳定后再逐步铺开。这个机制保证了同一条路上的多辆车间不会因为“智能水平不同步”而产生协同混乱。6. 下一步从“能用”到“好用”的三个方向6.1 端到端的主动安全联动目前智能体的决策还停留在“建议”和“诱导”层面下一个阶段我们准备打通到主动安全执行车辆自身传感器检测到即将追尾时智能体在置信度足够高的情况下直接触发自动紧急制动不再经过人工确认。这一步会把智能体的权责边界从“辅助建议”推进到“执行干预”对安全体系的要求会高很多。我们已经在仿真里跑过几百次极端工况没有出现漏报或误报但距离真正上路还有不小的工程距离。6.2 从单个路口的智能体到区域级智能体群现在的路侧智能体还是“各自为政”的一个路口一个智能体它们之间只有点对点的信息交换没有形成区域级的整体优化。下一步我们计划让一个区域内的所有路侧智能体互相同步形成一个区域级的分布式决策网络当核心路口拥堵时周边路口提前进入预疏散模式而不是等地面的拥堵已经形成后才反应。这个目标对通信布局、实时数据同步、分布式一致性协议都会提出新的要求。6.3 智能体的可解释性不只是“结果正确”还要“理由可信”第48天里那个传感器漂移案例让我们重新审视了可解释性的重要性。智能体给出的决策理由如果只是为了解释而生成那其实没有价值。真正的可解释性是让运维人员能快速定位“是哪一路输入数据的变化导致了这个决策差异”。这不是一个简单的模型特征归因问题而是整个系统的观测性设计问题。我们准备在模型输出之外增加一层“决策溯源记录”每次决策都保存一份关键输入快照和内部推理权重的摘要这样一旦出现异常可以回溯到是哪一步导致的。对车联网这种容错率极低的场景来说可追溯可能比可解释更紧迫——你可以允许模型的理由不那么完整但你不能允许决策发生了却完全不知道它是怎么发生的。老实说第48天之前我对智能体在车联网里的价值判断还是比较纠结的。一方面眼见为实的效果确实明显尤其在异常流量、多车协同时刻智能体的灵活应对是规则系统给不了的。另一方面我也很清楚今天跑通的东西离真正的全天候、全场景可靠运行还差得远。传感器会漂移通信会抖动模型会过时这些基础层的稳定性问题不解决智能体的上限再高也落不了地。但我自己实际操作下来的体会是这些问题不是无解的关键是别把它们当成单纯的技术问题而是当成系统工程问题来设计数据链路要监控决策链路要兜底版本发布要保守。把这几件事做好了智能体才能从仿真环境的玩具变成一个在车联网里真正帮得上忙的搭档。