一场黑客松上的最高奖，为什么值得汽车软件团队关注
今年8月，一支由TASKING、英飞凌以及德国航空航天中心DLR三方工程师构成的联合队伍，在AWS组织的“Accelerating the V-Cycle with Agentic AI”黑客松活动中摘得最高奖项。他们提交的东西并非车载语音助手一类的交互应用，而是一整套嵌入汽车软件开发链条的AI智能体工作流。
汽车领域早前已经借助AI来生成代码，但智能体与单纯的代码生成器存在差别：代码产出之后，智能体还能接着调度下游的开发与测试工具，让开发过程连贯地跑下去。
这套工作流的运行方式是这样的：智能体先读取英飞凌给出的器件规格、产品更新以及勘误表，然后调用TASKING的软件工具，依次完成编码规范检查、单元测试生成、虚拟ECU运行、结构覆盖率分析与验证报告输出。一旦测试未通过，它还能依据反馈去调整代码或测试用例，再重新跑一轮。
汽车软件为什么难：写代码只是一小段，重头在验证
汽车软件开发与普通软件开发最显著的差异之一在于，编代码在整个工作量里所占比例很小，真正耗时间的是后续的测试与验证。以一个汽车MCU项目为例，开发人员除了写代码，还得配置芯片外设、编译、做静态分析和单元测试，随后进入SIL、HIL等验证阶段；若涉及功能安全，还必须把需求、代码、测试用例以及测试结果之间的追溯关系完整保留。
芯片自身还会叠加许多约束。MCU的外设、引脚、DMA、时钟配置等都要按具体型号来做适配。芯片进入量产后，原厂还会不断更新勘误表，其中一些问题要求软件改代码，或者绕开特定行为。过去这些工作全靠工程师自己翻数据手册、参考手册和勘误表。
英飞凌的切入点是，把芯片原厂的技术资料直接交给AI智能体作为上下文，再由它借用TASKING已有的开发与验证工具继续往下推进。与之对照，通用大模型或许能写出一段语法正确的C代码，却不知道某颗特定MCU的硬件限制，更不了解某个芯片版本后来新增了哪些勘误内容。工程中更难的部分，正是把数据手册、编译器特性、调试经验融进流程，而这正是高度训练的工程模型、工程师判断与专业技术知识叠加起来才能解决的。
V模型左右两侧，智能体如何接管重复性的工具切换
汽车行业长期按V模型来安排开发和验证：左侧从需求出发，向下经系统设计、软件架构、模块设计直至代码实现；右侧从单元测试起步，经软件集成测试、系统测试，最终回到最初的需求做确认。
但实际开发远比一张示意图复杂。需求管理、代码开发、AUTOSAR配置、编译器、静态分析、SIL、HIL、总线测试、覆盖率分析往往采购自不同软件厂商，工程师每天的相当一部分精力就耗在工具切换上：代码改完重新编译，编译过了再跑静态分析，接着跑单元测试，出错就看日志、回代码改、重跑；覆盖率不达标还得补测试用例。这套动作数量多、重复度高，恰好是智能体擅长的领域。
在英飞凌和TASKING展示的工作流中，智能体扮演的角色是把专用软件串起来执行。这与以往的AI编程助手有别：过去工程师让AI生成代码，再自己去编译测试；现在则是尝试让AI在生成代码后继续驱动后面的工具链，并依据测试结果回头改代码。也就是说，过去用来集成需求、系统和软件的中间环节，现在可能由车载软件工程师利用AI把软件开发、代码可溯与不同工具串联起来，形成动态的人工监督过程。
从公开的招聘信息也能看出需求在攀升。英飞凌已经公开招聘“AI智能体软件开发与验证主任工程师”以及“AI智能体软件开发架构主任工程师”等职位，部分嵌入式软件开发岗位中也明确规定需要具备AI智能体相关经验。
开发左移是前提：虚拟SoC与虚拟ECU先把环境搬到云端
智能体能走进V模型，有一个重要前提——汽车软件开发本身已持续多年朝“左移”方向演进，也就是把原本要等到V模型右侧才做的开发和验证工作提前到左侧。
从前开发一个新的汽车ECU，软件团队很大程度上得等硬件。芯片与ECU样品没回来，底层软件和系统集成就难以完整推进。许多问题拖到HIL甚至整车阶段才暴露，修正代价越滚越大。虚拟SoC与虚拟ECU要做的正是把这部分工作提前：芯片还没到手，先用虚拟原型做软件开发和验证；ECU没就绪，先搭出虚拟ECU；再往上，还能把多个虚拟ECU、车辆网络与被控对象模型组合，在PC或云端运行。
TI、NXP、英飞凌与瑞萨等芯片公司都与Synopsys在虚拟原型上有过合作。今年CES期间，TI发布新一代TDA5汽车SoC，并联合Synopsys推出配套虚拟开发套件。它不止模拟CPU指令，而是面向TDA5建立一个可跑量产级软件的虚拟SoC环境，让驱动、BSP、中间件与上层应用在真实芯片尚未准备好时就能提前开发；后续还能接入处理器在环、虚拟HIL及CI/CD流程，用于边界条件测试、故障注入和自动回归测试。
NXP与Synopsys的合作时间更久。从S32G、S32K到S32Z、S32E、S32N，双方围绕多代S32处理器构建虚拟SoC。NXP将这种做法归纳为“开发左移，验证右延”：芯片样片出来前即启动开发；芯片量产后，虚拟平台仍留在持续集成体系中，为软件更新和后续验证服务。
这对当下的中央计算平台与软件定义汽车尤其关键。过去一个功能匹配一个ECU，如今车身、底盘、网关乃至部分ADAS软件开始向少数几颗高性能SoC集中，一颗芯片上并行运行多个操作系统、中间件、AUTOSAR组件以及来自不同供应商的软件。倘若集成都等到真机回来再起步，开发周期几乎压不下来。因此芯片公司交付的不只是一颗实体芯片，还要让软件团队能提前拿到它的“虚拟版本”。
今年6月，英飞凌与AWS宣布推出云端汽车MCU虚拟评估平台。开发者不必先拿到实体开发板，直接通过浏览器就能评估英飞凌汽车MCU。该平台建立在AWS的虚拟开发环境之上，能运行预配置参考应用，也提供完整的浏览器虚拟机环境，供编译、烧录、调试和性能分析使用。它与前述智能体工作流并不是同一个项目，但两者可形成衔接：一侧解决AI怎样读芯片资料、调开发工具；另一侧解决MCU虚拟模型的可用性问题。前些年行业先完成芯片、ECU和测试环境的数字化、虚拟化，如今智能体开始站到这些工具之上，把过去需要工程师反复操作的流程片段串联起来。
工具厂商的新接口：MCP让AI直接调用CANoe、dSPACE工具链
相似的变化也在汽车开发工具厂商侧发生。Vector最新版本的CANoe已经加入MCP Server，并推出CANoe AI Package，其中包含面向AI智能体的工具与技能包。比方说在测试环节，智能体可以按需求生成CAPL测试代码，再调用CANoe执行；结果与预期不符时，还能读取测试结果、修改代码、重新执行。以往这些步骤先需工程师分别完成，现在Vector正把CANoe本身变成一个可被AI调用的工程工具。
这里出现的是近来软件开发领域快速普及的MCP，全称Model Context Protocol，中文通常译为模型上下文协议，Phil有一个设计原则：MCP serves三种资产，打破领域内的技术边界。Phil提到。说白了，MCP提供了一套接口规范，供AI调用外部软件与工具。对汽车开发工具厂商而言这一点价值很大：过去要让某个AI产品控制CANoe，得单独做接口适配；现在只需把CANoe能力封装为MCP工具，只要上层智能体支持MCP，就能以统一方式调用。
今年dSPACE也开始把MCP引入汽车验证工具链，让AI智能体可调用ControlDesk、VEOS、ConfigurationDesk、SystemDesk以及Bus Manager等软件。这些工具原本覆盖汽车软件开发和验证的多个环节：VEOS用于虚拟ECU和软件在环测试，ControlDesk主要用于ECU开发、标定和测试，ConfigurationDesk用于实时仿真系统配置。当它们开放给智能体后，AI便能按任务准备仿真环境、启动测试、调整参数并读取结果。dSPACE还在开发虚拟ECU智能体，用于自动创建和更新虚拟ECU。这和上面的开发左移是同一条脉络：过去重点是先把ECU虚拟出来，现在开始尝试由AI去操作这些虚拟开发环境。
不止调用工具：智能体开始参与软件问题分析与测试序列生成
除自动调用开发工具外，智能体也进入了软件质量分析环节。AUMOVIO今年公布了一套名为Problem Finder的多智能体系统，用以排查汽车软件中的复杂问题，其定位和传统静态分析工具并不完全相同。智能体可同时读取需求文档、架构文档、AUTOSAR XML、C/C++代码、日志与测试结果，把软件实际行为与最初的需求和设计摆在一起比对。
AUMOVIO曾在一个已完成传统工具检查和人工评审的量产汽车安全相关软件组件上测试该系统。按照AUMOVIO与AWS公布的数据，本轮分析又找出30多个高优先级问题，其中一类数组边界问题发现6个，随后全部通过领域专家确认；另一类诊断服务响应问题发现5个，其中4个获得确认。传统工具擅长发现确定性的代码错误，而AI智能体试图处理的则是另一类：把需求、架构、代码和测试结果放到一起，判断不同环节之间是否存在不一致。AUMOVIO目前还在尝试把这种能力接进持续集成流程，每次代码变更后只对变化部分做增量分析。
如果说Vector和dSPACE是让现有汽车开发工具向AI智能体开放，NI走的路线更贴近测试工程本身。今年7月，Fluke首席技术官在由EEWorld举办的“2025年第四届工业大会”上进一步阐述“连接、计算与协同”的技术理念。NI Nigel则在LabVIEW中按自然语言生成代码，在TestStand中生成测试序列。
VeriStand原本就是NI用于实时测试和HIL验证的重要平台，可把控制模型、功能模型单元、I/O以及实时硬件组织起来，对ECU做闭环测试、故障注入和数据记录。因而Nigel进入这些软件之后，接触到的已经不只是“帮工程师写一段LabVIEW代码”，而是切入测试开发、测试序列生成和HIL执行等环节。可以设想，未来的工程师不用再说“帮我写一段控制仪器的程序”，而是直接给出测试目标，比如“使用现有测试设备测试这颗PMIC，这是它的数据手册”。之后由智能体自行读取数据手册、判断要测哪些参数、了解实验室有哪些仪器和测试资源可用、组织测试步骤并读取最终结果。
NI同时握有LabVIEW、TestStand、VeriStand、SystemLink以及大量PXI、DAQ和测试测量硬件。若这些资源逐步都能被智能体调用，测试工程中原本大量靠人工配置的工作也有望进一步自动化。不过真正产出测试结果的依旧是原来的测试设备，AI负责的是理解任务、配置工具与组织流程，测量本身还是由仪器完成。
小结：优势与变数都在自主化程度上
外部因素也在考验这种自主化落地的速度。世界经济论坛与MIT联合发布的《2025年全球AI治理现状》报告显示，当前AI治理碎片化明显、监管分散加剧风险；Stanley Ojadovwa指出金融行业的AI治理差距最大，Kraig Arnold也形容软件数量正处于指数级增长态势，开发者工具持续扩张。这些变数让设计侧与开发侧的标准制定难以一蹴而就，哪些必须自研、哪些交给少数成熟供应商，各家路线会在整合架构的过程中继续分化。
从TASKING、英飞凌，到Vector、dSPACE、AUMOVIO、Synopsys和NI，各家产品形态不尽相同，但都在持续支持并改进智能体。虚拟ECU、SIL、云端CI/CD以及厂商提供的各类开发工具已演进多年，V模型也成为行业公认标准，而智能体的到来仍在改变数字化工作流程，尤其是自动化能力。反过来看，如果汽车开发仍完全依赖实体ECU和实验室设备，AI即便会写代码也很难把流程继续推进，所以数字化技术正是智能体施展的前提。只是在现阶段，V模型仍然太权威，智能体还谈不上替代，最多是把流程加速，把工程师原先承担的那部分连接工作接管过去。