从辅助驾驶到移动智能体：全栈AI迁移路径与量产实践

1. 从辅助驾驶到移动智能体一次范式转移的底层逻辑过去几年行业里谈得最多的是辅助驾驶——车道保持、自适应巡航、自动泊车功能越堆越多但本质上还是人开车系统帮忙。而移动智能体这个词指向的是另一个层级的东西车不再是被动执行指令的机器而是一个能感知、能决策、能持续进化的智能实体。这个转变不是加几个传感器、换一颗芯片就能完成的它要求整个技术栈从底层重构。我接触过不少做辅助驾驶的团队大家普遍有一个困惑功能做得越多系统越复杂但用户体验的提升却越来越不明显。原因在于传统辅助驾驶的架构是模块化拼接——感知模块输出目标框规划模块根据规则算轨迹控制模块执行。每个模块各自优化但模块之间的信息损耗和延迟累积导致系统整体表现存在天花板。而移动智能体的思路是端到端或全栈协同让感知、决策、控制在一个统一的框架下联合优化。福瑞泰克这家公司在辅助驾驶领域深耕多年量产经验丰富。到了IPO阶段它提出的全栈AI迁移路径本质上是在回答一个问题如何从传统的模块化辅助驾驶平滑过渡到移动智能体的技术架构这个迁移不是推倒重来而是在现有量产基础上逐步引入大模型、端到端学习、数据闭环等能力。对于正在做类似转型的团队来说这条路径的参考价值很高。提示移动智能体不是更高级的辅助驾驶而是技术范式的切换。理解这一点才能理解为什么全栈迁移是必须的而不是可选的。2. 全栈AI迁移到底迁移什么四个层面的拆解2.1 感知层从检测目标到理解场景传统感知层的核心任务是在图像或点云中框出车辆、行人、车道线。输出是一堆边界框和类别标签。但移动智能体需要的不只是那里有一辆车而是那辆车正在减速可能准备变道它的意图是什么。这就要求感知层从检测升级为理解。具体来说迁移路径上通常涉及几个动作第一引入BEV鸟瞰图感知把多摄像头信息统一到同一个空间坐标系下解决遮挡和视角不一致的问题。第二用Transformer架构替代部分CNN backbone因为Transformer的注意力机制更适合建模长距离依赖和全局上下文。第三加入时序融合把连续多帧的信息整合起来让系统能判断目标的运动趋势。我实测过BEVTransformer的方案相比传统CNN方案在复杂路口的目标关联准确率有明显提升。但代价是算力需求大幅增加对芯片的TOPS要求至少翻倍。所以迁移不是一蹴而就的需要根据量产平台的算力预算分阶段推进。2.2 决策规划层从规则驱动到学习驱动规则驱动的规划器本质上是人写了一大堆if-else如果前车距离小于X如果车道线曲率大于Y如果旁边有车切入……这种方案在常见场景下表现稳定但遇到长尾场景就容易失效。比如施工路段的异形路障、临时交通指挥手势、非标准车道线规则很难穷举。学习驱动的规划核心是用神经网络直接输出轨迹或控制指令。训练数据来自人类驾驶员的真实操作模型学习的是在这种情况下人类会怎么做。这条路径的难点在于第一需要海量的高质量驾驶数据第二需要解决黑盒问题让模型决策可解释、可验证第三需要保证安全性不能让模型输出危险动作。福瑞泰克的全栈迁移路径中决策规划层的过渡策略通常是规则兜底学习优化。也就是说学习模型负责生成候选轨迹规则系统负责安全校验和兜底。这样既能享受学习带来的泛化能力又能保证安全底线。2.3 数据闭环从离线标注到在线迭代传统辅助驾驶的数据流程是路测采集数据→人工标注→训练模型→OTA推送。这个循环周期长通常按月甚至按季度计算。而移动智能体要求数据闭环尽可能短最好能做到天级甚至小时级迭代。实现短周期闭环的关键在于第一车端具备数据筛选和回传能力只上传有价值的片段比如接管场景、边缘场景而不是全量数据。第二云端具备自动化标注和训练能力减少人工介入。第三模型更新能快速验证并推送到车端。这里有一个容易被忽略的细节数据筛选的策略直接决定了闭环的效率。如果筛选太宽松上传数据量太大云端处理不过来如果筛选太严格可能漏掉关键场景。我的经验是用不确定性采样——让模型对当前场景的置信度低于阈值时触发上传这样能精准捕获模型不会做的场景。2.4 算力与架构从分布式ECU到中央计算传统辅助驾驶的算力分布在多个ECU上摄像头一个、雷达一个、域控制器一个。这种架构的优点是模块化、易扩展缺点是通信延迟高、算力利用率低。移动智能体需要中央计算架构把感知、规划、控制都放在一个高性能计算平台上。迁移到中央计算涉及硬件和软件的双重改造。硬件上需要更高算力的SoC同时要考虑功耗和散热。软件上需要把原本跑在不同ECU上的模块迁移到同一个操作系统上解决资源调度和实时性问题。注意中央计算架构的迁移最大的坑不是算力不够而是实时性保障。多个任务共享一个计算平台如果调度策略不当关键任务可能被非关键任务阻塞。建议在迁移初期就引入实时操作系统或Hypervisor做好任务隔离。3. 迁移路径上的三个关键决策点3.1 先做端到端还是先做模块优化这是很多团队面临的第一个岔路口。端到端方案听起来很美好——一个网络输入图像、输出控制中间不需要人工设计模块。但端到端的问题也很明显可解释性差、调试困难、对数据量要求极高。我的建议是如果你的团队已经有成熟的模块化系统在量产不要一上来就推翻重做。更稳妥的路径是模块内先用AI替换再逐步打通模块边界。比如先把感知模块从CNN换成BEVTransformer再把规划模块从规则换成学习模型最后再尝试端到端。这样每一步都有回退余地风险可控。福瑞泰克的路径也印证了这一点它的全栈迁移是分阶段、分模块推进的而不是一次性切换。3.2 数据从哪里来怎么用移动智能体的训练需要海量数据但数据不是越多越好。关键在于数据的质量和多样性。我见过一些团队采集了几百万公里的数据但大部分是高速公路直线行驶这种数据对提升模型能力的帮助很有限。有效的数据策略应该是第一覆盖长尾场景比如雨天、夜间、施工路段、非标准路口。第二标注要精准特别是对于学习驱动的规划模块标注的轨迹质量直接影响模型表现。第三建立数据版本管理每次模型训练都能追溯到具体的数据集版本方便复现和对比。3.3 怎么验证迁移后的系统是安全的这是最棘手的问题。传统辅助驾驶可以用规则覆盖度来衡量安全性但学习驱动的系统很难用同样的方法验证。行业里目前的做法是仿真封闭场地实际路测三层验证。仿真验证负责覆盖大量边缘场景成本低、可重复。封闭场地验证负责测试真实传感器和车辆动力学。实际路测负责最终确认。三层验证的通过标准需要提前定义不能等到测试完再拍脑袋决定。验证层级覆盖场景成本周期主要目的仿真验证边缘场景、危险场景低短快速迭代模型封闭场地真实传感器、车辆动力学中中验证系统集成实际路测真实交通流、天气高长最终安全确认4. 实操中容易踩的坑与应对经验4.1 算力预算被低估很多团队在规划迁移时只考虑了模型推理的算力忽略了数据预处理、后处理、融合等环节的算力消耗。实际部署时发现算力不够只能降分辨率或降帧率导致性能打折扣。我的经验是在选型阶段把总算力需求乘以1.5到2倍的冗余系数。比如模型推理需要100 TOPS那平台至少选200 TOPS。冗余不是为了浪费而是为了给后续迭代留空间。4.2 数据标注的隐性成本自动化标注听起来很美好但实际用起来会发现自动标注的结果需要人工校验而校验的工作量并不比从头标注小多少。特别是对于轨迹标注自动生成的轨迹往往不够平滑需要人工调整。应对策略是把标注任务分级。简单场景用自动标注抽检复杂场景用人工标注。同时建立标注质量反馈机制让模型训练的结果反过来指导标注优化。4.3 组织架构没跟上技术迁移技术迁移往往伴随着组织架构的调整。传统辅助驾驶团队按模块划分感知组、规划组、控制组。但全栈AI迁移要求跨模块协作如果组织架构不调整各组还是各扫门前雪迁移就会变成各自为战。我观察到的一个有效做法是成立跨职能的迁移专项组从各模块抽调核心人员直接向项目负责人汇报。专项组的任务是打通模块边界定义新的接口和数据流。等迁移完成后再逐步过渡到新的常态化组织架构。4.4 忽视功能安全与预期功能安全学习驱动的系统功能安全ISO 26262和预期功能安全SOTIF的合规难度比传统系统高得多。传统系统可以用FMEA分析失效模式但神经网络的失效模式很难穷举。实操中通常采用安全架构运行时监控的组合。安全架构上保留规则兜底模块当学习模型输出异常时接管。运行时监控上实时检测模型输出的置信度和一致性低于阈值时触发降级。提示SOTIF的合规不是一次性工作而是贯穿整个开发周期。建议在迁移启动阶段就引入功能安全团队而不是等到产品化阶段再补。5. 从量产经验反推迁移节奏一个可参考的时间线5.1 第一阶段数据基础设施搭建0-6个月这个阶段的核心任务是建立数据采集、回传、存储、标注的完整链路。很多团队急于上模型忽略了数据基础设施结果模型训练到一半发现数据不够用、标注质量差只能回头补课。具体动作包括定义数据采集规范传感器配置、采集频率、触发条件搭建云端数据管理平台建立标注流水线和质量校验机制。这个阶段不需要追求模型效果重点是让数据流起来。5.2 第二阶段单模块AI化6-18个月选择一两个关键模块先用AI替换比如感知模块。这个阶段的目标是验证AI方案在量产平台上的可行性包括算力、延迟、功耗等指标。同时积累AI模型的训练和部署经验。这个阶段最容易犯的错误是追求SOTA。学术界的最新模型往往参数量大、算力需求高不适合直接量产。更务实的做法是选择成熟、稳定的架构在工程优化上下功夫。5.3 第三阶段跨模块协同18-30个月当单模块AI化跑通后开始打通模块边界。比如让感知的输出直接喂给规划减少中间的人工接口。这个阶段需要重新定义模块间的数据格式和通信协议工作量不小。跨模块协同的关键是联合训练。传统做法是各模块独立训练然后拼接。但联合训练能让模块之间相互适应整体效果更好。代价是训练复杂度增加需要更精细的超参数调优。5.4 第四阶段端到端验证与迭代30个月以后最后一个阶段是端到端系统的验证和持续迭代。这个阶段没有明确的终点因为移动智能体的能力需要不断进化。重点是建立高效的迭代闭环让系统能持续从数据中学习。这个阶段的核心指标不是功能数量而是接管率和用户信任度。接管率越低说明系统越可靠用户信任度越高说明系统越自然、越可预测。6. 移动智能体时代团队需要什么样的能力储备6.1 从功能开发到能力训练传统辅助驾驶团队的核心能力是写规则、调参数。移动智能体时代核心能力变成设计训练任务、管理数据闭环、调优模型。这不是简单的技能叠加而是思维方式的转变。我建议团队在迁移初期就引入机器学习工程MLOps角色负责数据版本管理、模型训练流水线、部署监控。这个角色在传统辅助驾驶团队里往往缺失但在移动智能体时代是必需的。6.2 仿真能力成为核心竞争力当系统越来越依赖学习模型仿真验证的重要性就越来越高。仿真不仅要能还原真实场景还要能生成大量边缘场景。这对仿真引擎的物理精度、场景多样性、运行效率都提出了更高要求。我见过一些团队仿真平台还是几年前的老架构只能跑简单的场景。迁移到移动智能体后仿真能力跟不上导致模型迭代速度受限。建议把仿真平台的建设作为独立项目推进而不是附属在某个模块下。6.3 安全与合规能力需要前置前面提到过SOTIF的合规难度这里再强调一点安全与合规不是做完再补的事情而是需要前置到架构设计阶段。比如在设计学习模型时就要考虑如何输出可解释的中间结果方便安全分析。在设计数据闭环时就要考虑数据隐私和合规要求。6.4 组织文化的调整最后一点也是最容易被忽略的组织文化。传统辅助驾驶团队习惯确定性——输入确定、输出确定、测试确定。但AI系统充满不确定性模型表现会有波动训练结果难以完全复现。团队需要接受这种不确定性并建立相应的容错机制。我的体会是迁移过程中最大的阻力往往不是技术而是人的惯性。让一个写了十年规则的工程师去调模型他可能会觉得这玩意儿不可控。这时候需要耐心沟通用实际效果说话而不是强行推着走。7. 写在最后迁移不是目的进化才是回到福瑞泰克的案例它的全栈AI迁移路径之所以值得关注不是因为路径本身有多独特而是因为它展示了一种在量产约束下做技术跃迁的务实态度。很多团队要么固守传统架构要么盲目追新而福瑞泰克选择了一条中间路线在保证量产交付的前提下分阶段、分模块地引入AI能力。我个人在实际操作中的体会是迁移过程中最宝贵的不是最终的技术方案而是团队在迁移过程中积累的学习能力。当你的团队学会了如何快速训练模型、如何高效管理数据、如何验证AI系统的安全性那后续无论技术怎么变你都能跟上。最后分享一个小技巧在迁移启动阶段先做一个最小可行迁移——选一个最小的模块用AI替换跑通全流程。这个过程中暴露的问题往往就是后续大规模迁移的预演。不要一上来就搞大而全的方案小步快跑快速试错才是迁移的正确姿势。