1. 项目概述从“人驾”到“智驾”的最后一公里最近和几个在自动驾驶和边缘计算领域深耕的朋友聊天大家不约而同地提到了一个共同的痛点大模型LLM在车端或机器人端的部署正卡在一个尴尬的“中间态”。模型在云端表现惊艳能理解复杂指令、进行多轮对话甚至做出看似合理的决策。但一旦要把它塞进一个拥有特定计算架构比如标题里提到的 Spatial NPU空间神经处理单元的嵌入式设备里让它真正接管从感知到决策再到控制的“端到端”链条时问题就全来了。延迟、功耗、确定性、还有那要命的“黑盒”不可解释性每一个都是拦路虎。这恰恰是“From Human Guidance to Autonomy”这个标题直击的核心。它描述的不仅仅是一个技术部署更是一个范式转变的工程实践我们如何设计一套系统让原本需要大量人类规则和干预Human Guidance的智能体能平滑、可靠地过渡到完全自主Autonomy这里的“自主”在自动驾驶或具身智能的语境下意味着模型能直接处理传感器原始数据理解三维空间Spatial并在专为这种计算优化的硬件NPUs上输出低延迟、高可靠的控制信号。而“Agent Skill System”则是实现这一转变的“操作系统”或“中间件”它负责将大模型泛化的能力拆解、固化、优化成一个个可调度、可验证、可保障的“技能”Skill。结合热搜词“AMD XDNA 2”和热词“enhancing end-to-end autonomous driving with latent world model”这个项目的轮廓就更清晰了。它很可能是在基于AMD最新的自适应计算平台如Versal系列内含XDNA AI引擎进行探索。XDNA这类Spatial NPU的特点是其阵列式结构非常适合执行并行度高的张量运算但如何让以序列生成为核心的LLM高效映射到这种架构上并融入一个预测未来状态的“隐世界模型”就是整套Agent Skill System要解决的核心问题。简单说这不是单纯做模型压缩或量化而是为空间计算硬件从头设计一套让大模型“安全上岗”的机制。如果你正在苦恼于如何将ChatGPT般的能力真正赋能给一台自动驾驶汽车或移动机器人而不仅仅是做一个车载语音助手那么这套关于技能抽象、硬件协同与确定性保障的体系化思考正是你需要的。它适合算法工程师、嵌入式AI工程师、以及任何关注边缘大模型落地可行性的技术决策者。2. 核心设计思路为何“技能系统”是必由之路在深入细节之前我们必须先统一思想为什么在端到端LLM部署中不能直接把模型当做一个“整体”扔进NPU而必须引入“Agent Skill System”这个概念这背后是理想与现实、学术与工程之间的巨大鸿沟。2.1 端到端LLM的诱惑与现实的骨感理想很丰满一个庞大的多模态LLM输入激光雷达点云、摄像头图像、导航地图经过若干Transformer层“思考”后直接输出方向盘转角、油门和刹车信号。这就是纯粹的“端到端”它最大限度地保留了信息的完整性理论上能发掘出所有数据中的关联性。学术界的一些工作如热词提到的“latent world model”方向正致力于此试图让模型内部隐式地学习物理规律和世界状态预测。但现实极其骨感。首先计算复杂度爆炸。一个能处理高分辨率图像和稠密点云的视觉Transformer参数量轻易达到数十亿。即使经过极致优化其计算量对车载或机器人平台的功耗和散热也是不可承受之重。其次确定性缺失。自动驾驶对安全的要求是“功能安全”FuSa级别的需要系统在指定时间内给出有界延迟的确定输出。LLM的自回归生成特性天然带有不确定性每次推理的token生成时间都有微小波动这在控制环路中是致命的。再者调试与验证地狱。当一个由数万亿参数做出的驾驶决策导致事故你如何回溯如何定位是哪个注意力头“分心”了现有的汽车安全标准如ISO 26262几乎无法对这样一个“黑盒”进行认证。因此直接部署“单体巨无霸”LLM的端到端方案在可预见的未来内都不具备工程化的可行性。我们必须寻找一条折中但实用的路径。2.2 Skill System将“通才”分解为“专才”的架构哲学Agent Skill System的核心思想就是解耦与重构。它承认LLM作为一个“通才”在理解、规划和推理方面的强大能力但不让它直接处理高频率、低延迟的原始信号控制。具体来说这套系统通常包含以下几层设计高层任务规划与调度LLM作为“大脑”LLM在这里扮演指挥官的角色。它接收自然语言指令如“导航到最近的充电站”、结合上下文环境信息进行高层次的任务分解和规划。例如它会输出一个技能序列[Skill_ LaneChangeRight, Skill_ MergeIntoRoute, Skill_ FollowLane, Skill_ DecelerateForTurn]。这个层面对实时性要求相对宽松几百毫秒甚至秒级可以在性能较强的SoC的CPU或通用AI加速核上运行。中层技能抽象与接口Skill作为“标准动作”这是系统的关键。“技能”是一个个封装好的、功能明确的、经过充分验证的原子行为单元。例如Skill_LaneKeep: 输入车道线感知结果输出横向PID控制参数。Skill_ObjectAvoidance: 输入动态障碍物轨迹预测输出一条局部避障路径。Skill_TrafficLightCompliance: 输入交通灯状态和停止线位置输出go/stop决策。 每个技能都有严格定义的输入输出接口、性能指标最大延迟、功耗和功能安全等级。它们由传统的、确定性的、轻量化的算法或小型神经网络实现。底层技能执行与加速NPU作为“执行器”这里就是Spatial NPU如AMD XDNA的主场。那些计算密集、适合并行化的技能核心算法如视觉感知中的CNN backbone、路径规划中的优化求解器被精心优化、编译并映射到NPU的阵列结构上执行以获得极致的能效比和确定性延迟。这样设计的好处是显而易见的安全可控每个技能都可以独立进行测试、验证和认证符合功能安全流程。性能可期关键路径技能执行由专用硬件保障延迟和功耗可精确预算。灵活可扩展新的驾驶能力可以通过增加新的技能来获得无需重新训练或部署整个巨模型。调试透明当系统出错时可以快速定位是哪个技能失效还是LLM的任务规划不合理。所以这个项目标题的精髓在于它描述的是一个协同系统LLM提供智能和适应性Skill System提供可靠性和执行力Spatial NPU提供效率。从“人类指导”到“自主”就是LLM通过学习人类驾驶数据或人类反馈逐渐学会在复杂环境中调用和组合这些基本技能的过程。3. 核心组件深度解析Skill、NPU与LLM的三角协同理解了宏观架构我们再来拆解三个核心组件是如何具体协作的。这部分的工程细节决定了项目的成败。3.1 Agent Skill的设计与实现要点定义一个“好”的技能远比实现一个算法要复杂。它需要具备以下特征原子性与可组合性一个技能应只完成一件明确的事情。Skill_DecelerateToStop和Skill_SteerForCurvature应该是分开的这样它们才能被灵活组合如过弯时同时减速和转向。原子性也便于复用和测试。确定性接口技能的输入输出必须是结构化的、类型严格的数据。例如输入可能是一个PerceptionFrame结构体包含车辆姿态、障碍物列表、车道线方程输出是一个ControlCommand包含加速度、前轮转角。禁止传递自然语言文本或模糊的语义信息。资源与性能契约每个技能在部署时必须声明其最坏情况执行时间WCET、内存占用、NPU计算单元如AIE Array的使用比例。这是系统进行实时调度的依据。降级与容错机制技能内部必须包含对异常输入的处理逻辑。例如当车道线检测置信度过低时Skill_LaneKeep应能平滑地切换到一个基于惯性导航的兜底策略并向上层报告“技能降级”而不是直接输出一个危险的控制量。实操心得技能库的建立是一个长期过程。我们团队的做法是先从最基础、最关键的技能开始如车道保持、跟车确保每一个都达到车规级的可靠。然后通过与LLM的交互日志统计出人类驾驶员或安全员最常干预的场景将这些场景的应对策略固化成新的技能如“处理加塞车辆”、“通过无标线路口”。这是一个数据驱动的技能挖掘过程。3.2 Spatial NPU以AMD XDNA 2为例的适配与优化AMD XDNA 2是一种典型的空间架构NPU。它与我们熟悉的GPU大规模并行但控制逻辑相对简单和CPU强控制流但并行度低都不同。XDNA的核心是一个个可编程的AI引擎AIE阵列每个AIE包含标量单元、向量单元和本地存储器引擎之间通过高性能片上网络NoC互联。将技能映射到XDNA上不是简单的“跑一个PyTorch模型”而是一场软硬件协同设计算法重构许多在GPU上高效的算法如某些基于CUDA核函数实现的几何计算在XDNA上可能并非最优。我们需要将技能的核心计算模块用数据流Dataflow的思维重新描述使其能分解为多个并行流水线阶段映射到AIE阵列上。数据流编程使用AMD Vitis™统一软件平台下的数据流编程模型。你需要用C描述一个计算图Graph其中每个节点Kernel代表一个计算函数运行在特定的AIE核心上节点间的数据通过“流”Stream或“内存”Memory进行传递。这要求开发者对硬件拓扑有深刻理解。静态调度与确定性XDNA的优势在于其静态或半静态的调度能力。在编译时工具链就能确定每个数据块在AIE阵列中的流动路径和计算时序从而保证了最坏情况下的延迟是确定的。这对于安全关键技能至关重要。与PS处理系统的协同XDNA通常作为FPGA或自适应SoC的一部分与ARM CPU核心PS端共存。技能中控制逻辑强的部分如状态机、异常处理放在PS上运行而计算密集的数据通路部分则放在XDNAPL端上。两者通过高效的AXI总线进行数据交换这里的DMA配置和带宽管理是性能瓶颈点之一。注意为XDNA开发技能初期学习曲线陡峭。强烈建议从官方提供的AIE内核库如DSP库、视觉库中的优化函数开始搭建而不是从头手写所有内核。同时要充分利用Vitis Analyzer等性能分析工具持续进行迭代优化。3.3 LLM的角色从“生成代码”到“调度技能”在这个体系中LLM不直接“开车”而是“写剧本”和“当导演”。它的输出不再是方向盘角度而是一系列技能调用指令及其参数。实现这一点主要有两种技术路径基于Function Calling的规划器这是目前更成熟、更可控的方案。你将所有技能的函数签名名称、功能描述、输入参数格式以Schema的形式提供给LLM如作为System Prompt的一部分。LLM根据当前环境理解生成一个符合该Schema的JSON调用序列。例如{ plan: [ {skill: activate_turn_signal, args: {direction: right}}, {skill: check_blind_spot, args: {side: right}}, {skill: lane_change, args: {target_lane: right, aggressiveness: normal}} ] }后端有一个执行引擎负责解析这个JSON依次调用对应的技能。这种方式将LLM的创造力限制在了一个安全的、可验证的框架内。基于潜世界模型的序列预测这更贴近“end-to-end”的终极理想。LLM或一个专门的世界模型内部维护一个对周围环境未来状态的潜在表示latent representation。它直接预测未来多帧的“技能激活状态”序列。这要求LLM在训练时不仅学习语言和图像还要学习技能执行结果与状态变化的关联。这种方法潜力巨大但如何保证其预测的可靠性和可解释性是当前的研究难点。在实际项目中我们采用了一种混合策略在结构化场景高速巡航、泊车下使用高度优化的、基于规则的技能调度器保证效率和安全在非结构化、长尾场景施工区、特殊交通参与者下则唤醒LLM-based的规划器利用其泛化能力进行应对但其输出仍需经过一个“安全护栏”模块的校验才能转化为技能调用。4. 端到端部署工作流实操拆解理论说再多不如看看具体怎么干。假设我们要在基于AMD Versal含XDNA 2的硬件平台上部署一个包含“车道保持”和“动态避障”技能的演示系统并与一个云端微调的LLM规划器对接。以下是关键步骤4.1 阶段一技能开发与NPU映射技能算法选型与拆分Skill_LaneKeep选择轻量化的LaneNet分割网络CNN进行车道线检测再用一个小的MLP拟合曲率到方向盘转角的映射。将CNN的backbone部分剥离出来作为NPU加速的候选。Skill_DynamicAvoidance使用一个轻量化的PointPillar类网络处理激光雷达点云检测障碍物并预测轨迹。其3D卷积和稀疏卷积部分计算密集适合NPU。XDNA内核开发与优化使用Vitis™ AI对选定的CNN、MLP、PointPillar模型进行量化、编译生成用于AIE阵列的.xmodel文件。对于自定义的几何计算部分如车道线拟合、轨迹优化需要用C编写数据流内核Dataflow Kernel。这里的一个技巧是尽量使用“窗口”Window和“流”Stream的方式处理数据避免全局内存访问。例如处理图像行时使用滑动窗口流水线。编写连接这些内核的AIE计算图Graph并利用Vitis工具进行时序约束和资源分配Place Route。这个过程可能需要多次迭代以平衡各个AIE核心的负载。PS端技能框架搭建在ARM CPU上使用C开发一个轻量级的技能管理框架。每个技能是一个继承自BaseSkill的类实现initialize(),execute(const Input in, Output out),degrade()等虚函数。execute函数内部负责将输入数据格式转换为NPU内核所需的格式通过AXI DMA发起数据传输触发NPU计算并取回结果进行后处理。框架需要提供技能的状态管理、执行时间监控、以及向LLM规划器上报状态的能力。4.2 阶段二LLM规划器集成与通信LLM服务化与技能工具包定义将微调好的LLM例如基于Llama 3或Qwen 2.5在驾驶行为数据上进行了指令微调部署为一个gRPC或ROS 2服务。考虑到车端算力这个LLM可能运行在域控制器的高性能CPU集群上甚至在某些阶段仍需云端协同。严格定义技能工具包的OpenAPI格式的Schema作为LLM系统提示词的一部分。这个Schema要详细描述每个技能的前提条件、效果、以及参数范围。规划-执行闭环构建在车端主控节点上运行一个“认知引擎”。它周期性地例如每500ms收集车辆状态、环境感知结果、导航目标打包成一个规划请求发送给LLM服务。LLM返回一个技能调用序列JSON。“认知引擎”解析后将其压入一个时间戳对齐的执行队列。底层的技能调度器与技能框架紧密集成以更高的频率例如50Hz从队列中取出当前时刻该执行的技能调用其execute方法并将控制命令发送给线控底盘。关键机制设立一个“执行监控器”。它实时比对技能的实际执行结果如车辆轨迹偏移与LLM规划的预期。如果偏差超过阈值或某个技能执行超时立即触发降级如切入最小风险状态MRM并同时向LLM反馈此异常使其在下一轮规划中调整策略。4.3 阶段三系统联调与性能评测这是最耗费精力的阶段需要搭建完整的仿真和实车测试环境。在环仿真测试使用CARLA、LGSVL等仿真平台注入各种复杂场景cut-in jaywalking construction zone。重点测试LLM规划器在“认知”层面的表现它是否选择了合理的技能序列参数是否恰当同时在仿真中可以对XDNA上技能的WCET进行压力测试例如模拟传感器数据抖动看技能是否能按时完成。实车数据闭环在测试车上记录所有LLM的规划决策、技能执行状态、车辆反馈以及人类驾驶员的接管信号。这些数据是宝贵的财富。一方面可以用于发现LLM规划的“盲区”或错误模式进而构造新的数据对LLM进行迭代微调。另一方面可以分析哪些场景下现有技能库无法满足需求从而驱动新技能的开发。一个重要的实操技巧建立“场景-技能-性能”的关联数据库。每当发生一次接管或性能降级就记录下当时的场景片段、激活的技能链、以及NPU的资源占用情况。长期积累下来这个数据库能帮你快速定位系统瓶颈。5. 常见挑战与实战避坑指南这条路充满荆棘以下是我们团队踩过的一些“坑”以及总结出的应对策略。5.1 延迟与同步问题问题LLM规划周期~500ms远慢于技能执行周期~20ms。当LLM规划出一个“立即左变道”的指令时车辆可能已经驶过了最佳变道点。解决预测性执行LLM的规划应具有一定的时间前瞻性。例如输出的是“在接下来3秒内完成向左变道”并给出参考路径。技能调度器根据当前车辆状态实时解算出一系列的控制指令。分层异步架构将规划层和执行层彻底解耦。规划层LLM异步地提供“策略意图”而执行层由一个高速的“行为状态机”接管。这个状态机根据LLM的意图和实时环境动态选择并微调技能的执行。LLM的意图更像一个“目标”而非“每一步的指令”。5.2 LLM规划的不确定性与安全校验问题LLM可能会生成不合理甚至危险的技能调用比如在实线区域要求变道或要求以不合理的速度过弯。解决强规则校验层安全护栏在LLM输出和执行之间必须插入一个基于规则和物理模型的校验模块。这个模块检查技能序列的可行性例如变道技能是否在虚线区域激活目标车速是否超过道路限速与障碍物的预估距离是否安全任何违反硬性安全规则的指令都会被拦截并替换为安全兜底行为如减速。基于价值的过滤在LLM微调阶段除了指令跟随更要强化“安全驾驶价值观”的对齐。使用RLHF基于人类反馈的强化学习或RLAIF基于AI反馈的强化学习方法让模型学会给安全、舒适、合规的驾驶行为打高分。5.3 Spatial NPU开发效率瓶颈问题为XDNA等架构开发优化内核调试周期长对工程师硬件知识要求高。解决拥抱高层次综合HLS和领域特定语言DSL对于算法团队不要强求所有人都去写RTL或底层数据流C。可以尝试使用AMD Vitis HLS或类似的开源DSL如Meta的AITemplate用类似Python或特定计算描述的方式编写算法由工具链自动生成较优的硬件实现。虽然性能可能不是极致但能极大提升开发效率。建立可复用的IP库将常用的操作如图像预处理、后处理、特定算子封装成经过充分验证的AIE内核IP。在新技能开发时优先组合这些IP而非从头开始。5.4 技能组合的“涌现”问题问题单个技能都经过测试是安全的但LLM将它们以某种顺序快速组合时可能会产生意想不到的、不安全的“涌现”行为。例如连续快速切换“加速”和“转向”技能可能导致车辆失稳。解决技能间兼容性检查在技能元数据中不仅定义其功能还定义其“后效状态”如执行后车辆处于加速状态和“资源占用”如是否占用横向控制权。在执行前调度器检查前后两个技能是否存在状态冲突或资源争用。引入“技能平滑”层在底层控制指令发送之前增加一个平滑滤波器或轨迹优化器。它接收来自不同技能的离散指令生成一条在物理上连续、平滑、可执行的轨迹速度曲线、路径曲线从根本上避免指令跳变。这条路远未到终点但“From Human Guidance to Autonomy”的蓝图已经清晰。它不是一个一蹴而就的端到端黑箱而是一个精心设计的、人机协同演进的系统工程。Agent Skill System是这个工程化的核心框架它既释放了大模型的认知潜力又用确定性的技能执行牢笼约束了其不确定性。而像AMD XDNA 2这样的Spatial NPU则为这个框架提供了高效、可靠的算力基石。最终的自动驾驶系统很可能就是这样一个由“神经”与“反射”共同构成的混合智能体而我们现在所做的正是在为它搭建通往完全自主的桥梁。