当AI Agent进入汽车:下一代汽车软件架构该怎么变?

在往下走之前，得先把几个词钉死，不然后面全乱。

你可以先记住这一句话：

AI Agent = 会自己干活的 AI

Skill = 它会干什么

Loop Engineering = 它怎么一轮一轮地干活

Agent Harness = 负责把整个干活过程管起来，让它别乱来、能纠错、能验收

再加上大模型：

Model 是大脑，Skill 是手脚，Loop 是工作节奏，Harness 是整个工作台和管理系统。

Model（模型）是大脑：负责理解、推理、规划、决策。它擅长想，不擅长做。

Harness（驾驭框架）是身体，也是车间管理系统：负责组织、约束、监控、验证Agent的执行过程。它不负责让模型变聪明，它负责让模型有一个能真正干活的环境。

Harness让 AI Agent 稳定执行任务的工程框架

Harness 的核心组成

需要注意，Harness 并不是某个固定的软件产品，也没有唯一的标准架构。不同 Agent 框架会根据任务类型和风险等级，采用不同的实现方式。

Skill（技能）是专业能力：定义Agent能执行哪些具体任务。比如“读ARXML文件”“分析CAN配置”“生成诊断报告”。

Tool（工具）是原子操作：读文件、写文件、执行命令、调接口。

Loop（循环）是工作节奏：思考→行动→观察→再思考，一轮一轮跑下去，直到任务完成。

打个比方。你开了一家AI汽车维修厂。Model是那个刚毕业、脑子特别快但没碰过真车的工程师；Skill是他会用的各种专业能力——读故障码、标定、刷写；Tool是他手里的扳手、诊断仪、示波器；Loop是他“检查→判断→动手→再看结果”的工作节奏。

那Harness是什么？是这家维修厂本身：工位怎么排、工具怎么领、谁能进车间、谁不能动举升机、活干完了谁验收、出了事谁负责。

所以DeepSeek那句“Model is the soul of an agent”后面还跟着半句：Harness让它“understand its environment, use tools, and keep working in real-world settings”。灵魂归灵魂，没有身体，灵魂也只能在天上飘。

理解了这一层，你就明白为什么Harness Engineering这两年突然成了显学。它不是工具管理器，它是一整套工程方法：工具怎么注册、Skill怎么组织、Context怎么管理、Loop什么时候停、什么操作要审批、什么文件能改、怎么做沙箱、怎么做验证、怎么保存Session、怎么让Agent长时间工作。

这些事，在云端写代码的场景里已经够难了。把它搬进车里，难度还要再翻几倍。

为什么？因为云端Agent写崩了，最多回滚一次Git；车端Agent要是通过Capability调错了车窗、座椅、甚至能量管理，那可不是“重新生成”能解决的。云端Agent的失败是“体验问题”，车端Agent的失败可能是“安全问题”。这两者的工程要求，差着量级。

所以别被“Agent”这个词的轻盈感骗了。在汽车语境下，Harness不是锦上添花，是生死攸关。模型可以慢慢变聪明，但Harness必须一开始就建得足够硬。

很多人一聊“AI Agent进汽车”，脑子里只有一幅画面：车里坐着一个AI助手，帮你点歌、调空调、规划路线。

这只是最浅的一层。按Agent接触车辆的方式和风险等级，至少能分出四条路，每条路的工程难度差出一个数量级。

第一条路：软件工程Agent。它不进车，它进开发链。帮工程师读需求、写代码、跑测试、生成ARXML、做配置比对。这条路最现实，也最安全——因为它压根不碰车，碰的是开发环境。现在不少主机厂已经在用了，只是没大张旗鼓。

第二条路：车云协同与售后Agent。它在云端，但能远程访问车辆数据：读DTC、拉日志、做故障预诊断、生成维修建议。它接触的是“车辆信息”，不是“车辆控制”。风险中等，但已经要开始认真做权限和审计了。

第三条路：车内Service Agent。它跑在车端，能调用车辆服务：座舱、导航、能量管理、舒适性功能。它和用户直接交互，能影响体验，但通常不直接碰安全相关功能。这是接下来两年最热闹的战场。

第四条路：安全相关Agent。它参与或辅助安全相关功能——比如驾驶监督、冗余决策、安全状态判断。这条路最难，因为它要正面撞上ISO 26262、SOTIF（ISO 21448）、ISO/PAS 8800（道路车辆AI安全）这一整套功能安全体系。

这四条路，千万别混着聊。我见过不少PPT，把第三条路讲得像第四条路，把“能调车辆服务”说成“能控制车辆”，听着很震撼，真上车时会被功能安全工程师一票否决。

一个基本边界要记住：能调用车辆服务，不等于能直接控制安全功能。中间隔着一整套授权、策略和安全机制。

既然Agent和传统软件是两种东西，那它们在车里怎么共存？

我的判断是：汽车软件会演化出三个平面，而不是传统的一个平面。

第一个平面：Agent Plane（智能平面）。这是不确定性世界。LLM、Harness、Skills、Planning都在这层。它产生意图——“我想调低空调温度”“我想规划一条避开拥堵的路线”。但它不直接碰执行器。

第二个平面：Vehicle Service Plane（车辆服务平面）。这层把车辆能力包装成Capability API。空调、车窗、座椅、导航、能量管理，都变成一个个可被授权调用的能力接口。Agent想用，得通过这层。

第三个平面：Safety Control Plane（安全控制平面）。这是确定性世界。状态机、Watchdog、Fail-safe、ASIL相关的功能安全逻辑，都在这层。它按设计执行，不接受“动态决定”。

三个平面的关系是：Agent产生意图，车辆服务平面提供能力，安全控制平面决定这个意图能不能执行、怎么执行、执行不了怎么办。

关键点在于：Agent需要的不是底层ECU接口，而是Capability API。让它直接调CAN报文，就像让产品经理直接改生产环境数据库一样——技术上能做，工程上不能这么干。

这个三平面结构，是后面所有安全机制、权限模型、Agent OS讨论的地基。

聊到Agent和车辆控制之间的安全，很多人会提一个词：PEP，Policy Enforcement Point，策略执行点。

但要小心一个误解：PEP不是AUTOSAR或ISO标准里的某个组件，它是一种架构模式。它检查的是结构化的能力请求，不是自然语言。

也就是说，PEP不会去解析Agent说的“帮我把空调调低点”这种话。它处理的是已经经过Harness和Skill抽象之后的能力调用请求：Agent X，在状态S下，请求调用Capability C，参数P。

PEP要回答的是：这个请求，允许吗？

这和传统的文件权限模型不一样。传统问的是“这个进程能不能访问这个文件”，现在要问的是“这个Agent现在到底被允许做什么”。从File Permission到Capability Permission，这是权限模型的一次升级。

所以别把PEP想成一个万能安全闸门，往那儿一放就万事大吉。它只是整个安全架构里的一环——而且是靠后的一环。真正决定安全的，是它前面那一整套：Agent有什么身份、拥有哪些Capability、当前处于什么状态、策略引擎怎么判、安全机制怎么兜底。

说到Agent安全，很多人第一反应是“上沙箱”。沙箱当然重要，但在车里，它远远不够。

沙箱解决的是“Agent在哪运行”——隔离的运行环境、受限的资源访问。但它解决不了另外几个更要命的问题：Agent能调用什么车辆能力？它的输出是否合法？它是否满足当前的安全状态约束？

举个刺骨的例子：一个Agent在沙箱里跑得好好的，没越界。但它通过合法的Capability API，请求把车窗全降下来——而此时车正在高速行驶。沙箱拦不住这个，因为这是“合法调用”，问题在于“这个状态下不该允许这个调用”。

所以汽车Agent的安全边界，至少要叠七层：

每一层解决不同的问题，缺哪一层都有漏洞。沙箱只是起点，不是终点。

这也是为什么很多互联网背景的工程师做汽车Agent，第一版总是被功能安全团队打回来——他们习惯了“沙箱+权限”两层就交付，但在汽车语境里，这两层连门槛都没摸到。

为什么Agent现在才“有可能”进车，而不是五年前？

算力当然是一个原因。但更重要的，是中央计算架构让车里第一次出现了统一的软件资源池。

分布式EE架构时代，每个ECU各管一摊，算力碎片化，你根本没地方放一个需要长期运行、持续占用资源的Agent。中央计算把算力集中起来，Agent才有了栖身之所。

但中央计算也带来新问题：CPU、GPU、NPU、Memory、Network，现在是一群软件在抢。传统汽车软件虽然多，但行为相对可预测——每个App占多少、什么时候跑，基本能算清楚。

Agent不一样。一个“聪明的Agent”可能是中央计算里最不讲规矩的软件：它可能突然跑一轮长推理，把NPU占满；它可能持续维护一个大上下文，把内存吃掉一大块。如果资源治理没做好，它会拖累整车的实时性和安全性。

所以中央计算时代，光有VM和Container隔离不够，还需要Resource Governance——对Agent这类“不确定的软件”做资源配额、优先级调度、抢占保护。

让Agent能跑，和让Agent跑得不让别人没法跑，是两件事。

聊到AI和汽车，最容易搅在一起的就是智驾。这里必须把三个概念分开：AI、End-to-End（端到端）、Agent。

AI是个大筐，啥都能往里装。End-to-End是智驾的一种技术路线——感知到规划到控制，用神经网络一气呵成。Agent是能自主理解目标、选择能力、持续执行任务的软件实体。

这三个不是一回事。End-to-End智驾模型可以是一个Agent的Skill，但Agent本身不是End-to-End。把Agent和端到端混着说，是现在最容易闹笑话的地方。

按风险等级，智驾相关的Agent大致分三层：

第一层，驾驶辅助Agent。它只处理信息：帮你解读路况、提醒注意事项、生成行程摘要。不产生执行器控制量。

第二层，驾驶监督Agent。它监督智驾系统的状态，做冗余判断、异常检测、接管提醒。它本身不直接控制车辆，但它的判断会影响“要不要让人接管”。

第三层，安全相关驾驶Agent。它参与安全相关的驾驶决策。这一层直接进入汽车安全领域，要同时满足ISO 26262功能安全、SOTIF预期功能安全、ISO/PAS 8800 AI安全。

第三层是最难的。难在哪？难在安全论证的对象变了。以前你论证的是一段代码、一个模型；现在你要论证的是一整个Agent系统——它的Harness、它的Skill组合、它的策略引擎、它的失败模式，全都要纳入安全分析。

这不是把模型训好就完事的。这是工程体系的重构。

终于聊到Agent OS这个词。

先泼盆冷水：Agent OS目前不是AUTOSAR、ISO任何标准里的正式术语。它是一个架构概念，更准确的说法是Agent Runtime或Agent Platform。

那它到底要管什么？我梳理了八个职责：

这八件事，现在散落在不同地方：有的在云端平台，有的在车端中间件，有的根本没人管。Agent OS的意义，是把它们收拢成一个统一的运行时层。

其中最容易被低估的是第七条——Observability与Audit。传统汽车软件的日志，记的是“谁在什么时候调了什么接口”。Agent时代要记的可不止这些：它得记“Agent为什么决定这么做”——它的推理链是什么、它考虑了哪些选项、它为什么选了这个Skill、它为什么没选另一个。这叫“决策可追溯”，是Agent审计和事后分析的基础。没有它，出了事你连“Agent当时在想什么”都还原不出来。

第八条Verification也特别要命。传统软件验证的是“代码路径”，Agent要验证的是“行为空间”——它可能做出的所有决策，都要在安全边界内。这比测一段代码难得多，因为你测不完所有可能的推理路径。工程上的务实做法，是结合输出验证、策略约束、沙箱隔离和冗余兜底，把“不可穷举”变成“即便错也安全”。

它不取代AUTOSAR，它建在AUTOSAR之上。AUTOSAR管确定性，Agent OS管不确定性。两者各司其职。

一个形象的类比：AUTOSAR像是车的底盘和动力总成——它保证车能按设计跑。Agent OS像是车上的“驾驶策略层”——它决定这趟行程要去哪、走哪条路、什么时候停。底盘不会因为有了驾驶策略就被废掉，但驾驶策略会让底盘之上的软件形态彻底变样。

前面铺垫了这么多，现在可以说最核心的一个变化了：汽车软件的抽象单位，正在从“功能”向“能力”重构。

过去几十年的链条是：ECU → Application → Service → Function。每一层都是确定的、可预先定义的。传统软件说“我要调用Service X”，调用关系在设计阶段就写死了。

Agent来了之后，链条变成：Agent → Capability → Policy → Vehicle Service → AUTOSAR/Middleware → ECU。Agent不说“我要调用Service X”，它说“我要完成Goal Y”。具体调哪个Service、用什么参数、按什么顺序，运行时动态决定。

这个变化看着微妙，影响却很深。

它意味着车辆能力要被重新抽象：不是按“功能”切，而是按“能力”切。一个“空调”功能，可能拆成“调温能力”“风量调节能力”“模式切换能力”等多个Capability，每个Capability带自己的权限声明、状态约束、安全边界。

它也意味着权限模型要升级：从“谁能访问这个接口”变成“谁在什么状态下能调用这个能力”。权限变成动态的、上下文相关的。

这是Agent进汽车之后，软件架构真正会动的地方。不是AUTOSAR被推翻，是AUTOSAR之上长出了新的一层抽象。

顺着能力模型往下，Skill在汽车里会变成一个新的软件抽象层。

以后你可能会看到这样的Skill库：Vehicle Diagnosis（车辆诊断）、ARXML Analysis（ARXML分析）、CAN Configuration（CAN配置）、DLT Analysis（日志分析）、Calibration Management（标定管理）、OTA Verification（OTA验证）。每个Skill是一个可复用、可组合、带权限声明的专业能力单元。

Skill设计有个重要原则：原子化。别搞一个“超级Skill”——又改配置又编译又测试又部署，出了问题都不知道哪步炸的。拆成read_file、edit_file、build、run_test、deploy，Harness才能分别控制、分别重试、分别回滚。

聊到这，顺带说一个特别容易踩的坑：多Agent。

很多人学了Agent之后，第一反应是“一个不够就五个，五个不够就一百个”。Planner、Supervisor、Researcher、Coder、Reviewer、Tester、Evaluator、Manager、Sub-Agent、Sub-Sub-Agent……看着很高级，实际上可能已经把简单任务搞成了“AI官僚机构”。

让Agent读一个ARXML文件，结果Planner→Researcher→Analyzer→Reviewer→Evaluator跑了几十轮，Token烧了一堆，一个普通脚本一秒搞定的事，搞成了企业级流程。

多Agent不是不行，但每多一个Agent，就多一份身份、多一份权限、多一份状态、多一份通信、多一份故障模式、多一份审计对象。多Agent成立的前提，是角色隔离能显著降低复杂度和风险，而不是为了多而多。

Agent架构的目标不是复杂，是让复杂任务变得可控。