21世纪经济报道记者 郑植文
汽车里的智能功能越来越多，体验却未必同步改善。J.D. Power今年5月发布的中国汽车智能化体验研究显示，先进配置的普及程度继续提高，功能表现指数却出现四年来首次下滑。在先进配置的各类质量问题中，“不稳定、不准确”占到48%。这项覆盖32,813位车主的调查并非针对大模型，却指出了汽车AI必须面对的需求：功能要用得稳，操作要有结果。
理解一句指令之后，系统还要校验权限、调用服务、执行操作并确认结果。端云一体需要明确车端和云端如何分工，才能让这些步骤连续、可靠地完成。
国际欧亚科学院院士张景安将技术碎片化、长尾场景和安全伦理压力列为行业挑战。他提出，基础技术与通用平台可以联合攻关，应用层再进行差异化竞争。放到一辆车里，这种协作有很具体的含义：模型、通信、车控和第三方服务需要共同完成一项任务，其中任何一个环节出错，都可能让用户重新操作一遍。
端云一体首先涉及计算任务如何分工。
联友科技总经理助理兼联友智连总经理文军红解释，车端需要负责实时处理，保障断网时的基础功能并提供安全兜底；云端则适合提供不断更新的知识、更复杂的推理和外部服务。系统要解决的是“什么任务在端侧，什么任务在云侧”。
例如，明确的空调调温指令，应当尽快交给本地执行链路；一段包含目的地、充电和休息安排的出游需求，则可能需要查询外部信息、拆分步骤，再调动多个服务。两类任务对算力、网络和等待时间的要求不同。
这种分工还取决于芯片、模型和云平台能否配合。阿里云AI汽车行业线华南解决方案总经理王淼提出“芯云模一体”，并将舱驾融合作为汽车智能化的演进方向。把这一思路落实到产品，车企还要明确模型如何取得数据、调用服务，以及硬件能否支持相应任务。
在模型接入外部数据和服务这一环节，奔驰在2025年1月公布了一项合作方案：将Google Cloud基于Gemini的汽车AI智能体与Google Maps地点数据结合，用于新CLA的地点搜索和导航对话。语言理解接入可更新的数据和实际服务，用户才可能从询问地点，继续进入设置导航环节。
理解之后，系统还要处理执行中的一系列问题。按照联友智连舱驾开发服务部总监杨威介绍的万演引擎方案，系统需要拆解任务、调用工具，执行前检查用户权限和车辆状态，执行后读取结果，失败时再恢复或反馈。比如，系统生成了调温指令，还需要确认空调是否完成设置；用户没有授权的操作，也不能因为模型认为合理就直接执行。
这使得“响应快”需要被重新拆开来看。万演引擎方案的目标是：针对只包含一个明确要求的指令，在指定车端硬件和标准测试条件下，至少95%的请求能在0.6秒内得到首次回应；针对复杂需求，则在稳定联网、使用指定云端模型的条件下，1.8秒内给出首次回应。两项指标衡量的都是系统多快作出回应，并不代表任务已经完成。
当AI进一步参与驾驶，验证还必须明确运行场景。同济大学汽车与能源学院教授朱西产指出，端到端技术仍面临边缘场景和安全边界难题。他建议从固定线路上的自动驾驶应用入手，探索车路云商业化，先发展货运，再拓展客运，先在固定线路运营，再逐步扩大范围。车路云还涉及道路侧设施，与座舱端云协作有不同的系统边界；对后者有参考价值的是这种验证思路：先限定任务和使用条件，再评估能力可以扩展到哪里。
涉及车辆控制的任务，最终仍需由车内系统执行。蜂窝网络负责连接车辆与云端，车内网络则要在计算单元、传感器和控制器之间传输数据。两者的时延指标不能混用，公网连接更快，也不代表车辆内部的控制链路已经足够可靠。
联友智连首席技术官黄健平介绍的百灵通信技术平台，试图解决两组不同的问题：车外的蜂窝、卫星及近场通信如何协同，车内的高速网络如何调度数据、区分任务优先级并处理链路故障。对于需要在规定时间内送达的控制数据，仅增加带宽还不够，系统也要避免它与其他业务争抢资源。
通信升级本身还有工程代价。黄健平将高速光模块和交换芯片的成本、光纤连接器封装等问题列为工程挑战。按照联友智连的规划，成熟的全光主干网与高速互联整套方案预计在2028年前后交付。这意味着，相关能力仍有研发和验证过程，不能将远期架构直接视为已经在量产车上实现的体验。
算力也不必全部集中到最大的处理器上。恩智浦大中华区软件定义汽车和边缘AI市场负责人邓尚超将虚拟传感器、电池管理等列为边缘AI的应用方向。这类模型处理特定车辆信号，与座舱语言大模型有不同用途。恩智浦的公开演示展示了虚拟传感器模型在S32K5虚拟开发环境中的验证过程，但不能据此认定其已经大规模量产。
端云配置还需要算一笔持续使用的账。将更多计算放到车端，要考虑芯片、内存、功耗和散热；放到云端，则要考虑推理、通信和后续服务开销。车企需要结合任务频率、车辆配置和服务期限判断哪种组合划算。要判断一套方案在全生命周期内是否更具成本优势，还需要可比的使用数据与成本测算。
另一个成本发生在集成环节。国汽智控产品总监周国茂在介绍ICVOS时，强调硬件、系统和应用分层，以及跨芯片适配和软件复用。对车企而言，这类设计的吸引力在于，换一款芯片或扩展一个车型时，可以少重做一部分工作。但具体能复用多少，仍要看接口、车辆功能和验证要求是否一致。
万演引擎的标准方案适配周期目标为3至5个月，前提是项目满足标准软硬件与接口条件。这一限定揭示了平台化交付的难点：软件可以封装成通用模块，实际车辆的控制权限、数据格式、已有座舱系统和外部服务却未必相同。
张景安提出共建通用平台、推动测试结果互认，回应的正是重复开发和重复验证的问题。不过，合作伙伴越多，接口和责任也越需要明确。谁允许智能体调用车辆功能，谁维护地图或内容服务，更新之后由谁验证，出了问题由谁定位，都应在交付之前约定。
评价端云一体的进展，还要看量产后的使用记录：常用任务实际完成要多久，弱网和断网时保留了哪些能力，失败后是否需要用户反复介入，以及每辆车的持续服务成本。芯片、模型和云平台的协同，最终需要接受具体场景的检验，车企才有依据决定哪些功能可以扩大部署。
