📚 课程目录第2章自动驾驶智能体概述

2. 自动驾驶智能体概述

自动驾驶系统并不是单一模型，而是一个持续与环境交互、不断做出动作并接收反馈的智能体（Agent）。理解智能体的定义与闭环结构，是后续讨论车端部署与实时推理工程的前提。本节从智能体基本概念出发，梳理感知—决策—规划—控制的闭环，并重点分析车端部署面临的约束与实时推理需求。

一、什么是自动驾驶智能体

在人工智能领域，智能体通常被定义为：能够通过传感器感知环境，依据内部策略做出决策，并通过执行器作用于环境，从而在环境中实现目标的实体。其核心要素包括感知、决策、行动、环境反馈四个部分。自动驾驶汽车正是这一范式的典型代表：摄像头、激光雷达、毫米波雷达构成感知通道，计算平台承载决策与规划，底盘线控系统执行转向、油门与制动，而道路、车辆、行人、交通信号则构成动态环境。

与传统的规则式控制系统不同，现代自动驾驶智能体越来越多地采用数据驱动模型，例如基于深度学习的感知网络、基于强化学习或模仿学习的决策策略，以及基于优化或学习的轨迹规划器。这使得智能体具备更强的泛化能力，但也带来了模型规模大、计算需求高、行为难以完全解释等新问题。

智能体的本质是“感知—思考—行动”的循环。自动驾驶的难点不在于单点算法，而在于让这个循环在真实车辆上以足够低的延迟、足够高的可靠性持续运行。

二、感知—决策—规划—控制闭环

自动驾驶智能体的运行可以拆解为四个相互衔接的环节，它们构成一个闭环：

感知（Perception）：从多传感器原始数据中提取目标、车道线、可行驶区域、交通标志等环境信息，并估计自车状态。
决策（Decision）：根据感知结果与任务目标，判断当前应采取的行为，例如跟车、变道、让行、超车或紧急制动。
规划（Planning）：将决策转化为具体轨迹，包括路径规划与速度规划，满足安全性、舒适性与交通规则约束。
控制（Control）：将轨迹转化为转向角、油门开度、制动压力等执行指令，通过线控底盘作用于车辆。

这四个环节并非单向流水线，而是带有反馈的闭环。控制执行后车辆状态发生变化，感知再次观测环境，决策与规划随之更新。任何一个环节的延迟都会影响整个闭环的稳定性。例如，感知延迟 100 ms，可能导致规划基于过时环境做出判断；控制延迟过大，则会造成轨迹跟踪误差甚至失稳。

上图展示了自动驾驶智能体的闭环结构。可以看到，感知、决策、规划、控制四个模块串联，但通过车辆运动与环境变化形成反馈回路。工程上必须为整个闭环设定延迟预算，通常要求从传感器曝光到执行器响应控制在 100 ms 量级，才能保证高速场景下的安全裕度。

三、车端部署的挑战

将上述智能体部署到车端，与在数据中心运行有本质区别。车端环境带来一系列硬性约束：

算力受限：车载计算平台受功耗、散热与成本限制，算力远低于服务器 GPU 集群。
功耗与散热：整车功耗预算有限，高功耗芯片需要复杂散热设计，影响可靠性与续航。
实时性要求：感知、规划、控制必须在确定的时间窗口内完成，不能出现长尾延迟。
功能安全：系统需满足 ISO 26262 等功能安全要求，具备故障检测、降级与冗余能力。
环境恶劣：振动、温度变化、电磁干扰都会影响计算与传感器稳定性。
模型更新与 OTA：模型迭代频繁，需要安全、可回滚的远程升级机制。

常见误区：把车端部署简单理解为“把模型搬到车上”。实际上，车端部署是算力、功耗、实时性、安全性与模型精度之间的多目标权衡，往往需要模型压缩、算子优化与调度策略协同设计。

四、实时推理需求与关键指标

实时推理是车端部署的核心。这里的“实时”不仅是平均延迟低，更强调确定性与最坏情况延迟可控。下表列出车端实时推理的关键指标与典型要求：

指标	含义	典型要求	影响
端到端延迟	从传感器采集到执行器输出的总时间	≤ 100 ms	决定闭环稳定性与安全裕度
推理帧率	感知模型每秒处理帧数	≥ 10～30 FPS	影响环境更新频率
最坏情况延迟	P99 或最大延迟	不超过预算 1.5 倍	避免偶发失效
算力利用率	实际算力 / 峰值算力	60%～80%	平衡性能与功耗
功耗	计算平台总功耗	依车型而定，通常 < 300 W	影响散热与续航
内存占用	模型与中间张量占用	受限于板载内存	决定可部署模型规模

为满足这些指标，工程上通常采用模型量化、剪枝、知识蒸馏、算子融合、TensorRT 等推理加速手段，并结合多线程流水线、零拷贝、内存池等技术降低系统开销。例如，使用 TensorRT 对感知模型进行 FP16 或 INT8 量化，可以在精度损失可控的前提下显著提升吞吐：

# 以 TensorRT 为例的简化构建流程
trtexec --onnx=perception.onnx \
        --saveEngine=perception_fp16.engine \
        --fp16 \
        --workspace=2048 \
        --minShapes=input:1x3x320x800 \
        --optShapes=input:1x3x640x1600 \
        --maxShapes=input:1x3x720x1920

上述命令将 ONNX 模型编译为 FP16 引擎，并指定动态输入尺寸。实际部署中还需结合具体芯片的 DLA、GPU、CPU 资源进行任务划分，把感知、规划、控制分配到合适的计算单元，避免相互抢占导致延迟抖动。

五、案例与复盘：一次延迟抖动排查

某项目在实车测试中发现，车辆在夜间高速场景下偶发跟车距离过近。日志显示感知帧率正常，但端到端延迟从平均 80 ms 突增到 160 ms。排查后发现两个原因：一是夜间图像预处理分支增加了额外的色彩空间转换，未做算子融合；二是规划模块与感知模块共享同一 GPU 流，存在资源竞争。优化措施包括：将预处理融合进推理引擎、为规划分配独立 CUDA 流、设置推理优先级。优化后端到端延迟回落至 85 ms，P99 延迟从 160 ms 降至 110 ms。

复盘要点：车端实时性问题往往不是单一模型慢，而是系统级资源竞争与数据搬运造成的。定位时应同时观察各模块耗时、GPU 利用率、内存拷贝次数与线程调度情况。

综上，自动驾驶智能体是一个感知—决策—规划—控制的闭环系统，其车端部署必须在算力、功耗、实时性与安全性之间取得平衡。理解闭环结构与实时推理需求，是后续模型压缩、推理加速与系统调度等工程实践的基础。