先放一个可能跟主流教程唱反调的结论：用 CarSim 做强化学习路径跟踪仿真，我建议直接跳过 Simulink 联合仿真那条默认路线，走 VS Solver API 让 Python 全程接管仿真的启动、步进、数据交换和重置。这不是标新立异，而是我在实际训练过程中被 Simulink 的编译开销和耦合问题反复折磨之后，踩出来的更顺的一条路。这篇文章就围绕这套方案展开，讲清楚 CarSim 如何以独立求解器的方式与 Python 通信，如何把它封装成 Gym 风格的强化学习环境，以及在路径跟踪任务里真正影响训练效果的关键细节。如果你正在配置 CarSim + Python 环境，或者准备做车辆控制方向的强化学习课题，又或者已经被"每次修改参数都要重新编译 Simulink 模型"搞得失去耐心，这篇文章应该能给你一个更高效的替代方案。

1. 为什么RL训练要先绕开Simulink：VS Solver API的选型逻辑

很多教程默认 CarSim 必须配合 Simulink 使用，因为 Simulink 里有现成的 CarSim S-Function 模块，拖进去连线就能跑。对于做一次两次仿真验证的人来说，这条路确实起步快。但对于强化学习这种动辄上千个 episode、每次 episode 都要重置环境并重新初始化车辆状态的场景，Simulink 联合仿真有非常明显的结构性劣势。

1.1 Simulink联合仿真在RL训练中的三个软肋

第一个软肋是编译和模型加载开销。Simulink 里的 CarSim 模型本质是一个 S-Function 封装，每次修改车辆参数、道路场景或者初始化条件，都要经过模型编译、库加载、内存分配这一整套流程。我在普通工作站上实测，一次干净的模型加载加编译耗时在 30 秒到 2 分钟之间。强化学习训练中，你至少需要几千个 episode，就算每个 episode 只启动一次模型，累计等待时间也是以天为单位。更别提你在调参阶段经常要改动环境代码，这种开销几乎是致命的。

第二个软肋是步进控制权分散。Simulink 联合仿真时，仿真时钟由 Simulink 调度器掌控，CarSim 的求解器被当作一个被调用模块。强化学习环境要求在固定频率下发送控制量、读取状态量，比如 100Hz 决策周期。当 Simulink 的变步长求解器为了数值精度自动缩短步长时，外部决策节奏会被打乱；而 CarSim 内部又是固定步长积分，两套时钟协调不好，就会出现状态重复、数据跳变甚至步进卡死。你可以加各种锁步机制去规避，但代码复杂度会上一个台阶。

第三个软肋是环境随机化困难。强化学习非常需要"每个 episode 初始状态不完全相同"这个特性，否则训练出来的策略泛化性极差。在 Simulink 路线里，你要重置车辆位置、速度、航向，往往需要往模型里塞一堆复位逻辑端口，或者在 MATLAB 工作区里改变量再重新初始化整个模型。每改一次初始条件就重新来一遍编译加载，完全违背了 RL 环境"轻量快速重置"的设计哲学。

1.2 VS Solver API的工作机制与定位

VS Solver API 做的事情，简单说就是把 CarSim 从"必须挂在一个宿主环境里才能运行的模块"变成"可以独立运行的求解器进程"。你在 CarSim 图形界面里配置好整车参数、轮胎模型、转向系统、空气动力学等一整套模型之后，导出一个 simfile 文件。这个文件包含了模型结构、参数值、求解器配置和输入输出变量定义。运行时，CarSim 自带的求解器进程加载这个 simfile，然后通过进程间通信接口对外提供数据读写和仿真控制能力。

这套机制的独特之处在于，它跳过了外部仿真环境这一层。求解器内部的积分步长仍然由 CarSim 自己控制，但"什么时候推进一个控制周期、什么时候停止、什么时候重置"由外部 Python 程序决定。也就是说，仿真控制权真正掌握在你的 RL 环境代码手里，你不必关心 Simulink 的调度器在想什么。同时，你修改参数时不需要重新编译任何东西，直接通过数据接口改写对应变量即可，非常契合 RL 训练中高频重置、高频调参的使用模式。

可以这么类比：Simulink 联合仿真的交互方式像"打电话遥控另一个人办事"，每次办事都要先接通、说明需求、等对方执行；VS Solver API 则更像是"拿到了钥匙直接开车"，启动、加速、刹车、停下来检查车辆状态，全部由你自己完成，效率自然不在一个量级。

1.3 什么场景下仍然需要保留Simulink

这套方案也不是银弹。如果你的目标不是 RL 训练，而是做整车控制策略的离线验证、控制器逻辑和汽车电子系统的联合测试，或者你有大量基于 MATLAB 的现成控制算法要复用，那么 Simulink 联合仿真依然是非常合理的选择。尤其是当你需要调试复杂的 Simulink 控制逻辑并配合车载总线仿真时，CarSim 在 Simulink 里的接口反而更便于集成。

我的建议是：做强化学习训练环境时，优先考虑 VS Solver API；做传统控制器开发验证、HIL 测试时，保留 Simulink 联合仿真路线。两条路线之间共享同一套 CarSim 车辆模型文件，切换成本并不高。

2. 搭建CarSim + Python仿真环境：版本、通信与最小闭环

这一节说点具体的落地步骤。我会结合我自己的踩坑经历，把环境清单、通信选型和一个能跑通的最小示例都放在这里，方便你照着复现。

2.1 环境清单与两个版本兼容问题

先说清单：一台 Windows 机器、CarSim 2019 及以上版本（我用过 2019 和 2020，接口差异不大，但以你安装版本的实际 API 为准）、Python 3.7 到 3.9（我建议 3.8，兼容性最好）、PyTorch 1.10 以上用于 RL 训练、NumPy、PyYAML（用于解析 simfile 或配置文件）。

第一个版本兼容问题是 Python 位数。CarSim 自带的 Python 通信库在 Windows 下通常分为 32 位和 64 位版本，必须和你安装的 Python 解释器位数一致。很多人在 import 报错时才发现自己装了 64 位 Python，但系统里残留了 32 位 CarSim 库，结果接口加载失败。装环境之前先确认好两边的位数，能省下大量排查时间。

第二个兼容问题是路径和权限。CarSim 的 simfile 里如果使用了相对路径，求解器启动时会以当前工作目录为基准查找资源文件。如果你从 Python 代码里启动求解器，务必将工作目录切换到 simfile 所在目录，或者干脆在 simfile 里使用绝对路径。我早期就是因为在项目根目录调用求解器，CarSim 一直报无法加载扩展名为 pars 的文件，折腾了半天才意识到是路径问题。

2.2 共享内存通信与TCP通信怎么选

CarSim 求解器与 Python 之间有两条常见通信通道：共享内存和 TCP。这两条通道的适用场景差异很大，选错会让训练效率大打折扣。

共享内存方式要求求解器进程和 Python 进程运行在同一台机器上。它的最大优势是延迟极低，因为数据通过内存直接交换，不需要经过网络协议栈。我实测在普通工作站上，一次"发送动作 + 读取状态"的完整往返延迟大约在 0.2 到 0.5 毫秒，非常稳定。

TCP 方式则支持跨机器通信，你可以把 CarSim 求解器跑在一台专门的仿真机上，Python 训练脚本跑在另一台 GPU 服务器上。这种分布式结构听起来很美好，但实际训练中，每个 step 的往返延迟会上升到 1 到 3 毫秒，而且网络波动可能导致个别数据包延迟升高，RL 环境对时间一致性要求很高，偶尔的延迟尖峰会让训练曲线出现莫名其妙的抖动。

我的建议很明确：训练初期永远优先共享内存，先把整套算法逻辑跑通，再去考虑分布式部署。CarSim 本身是高精度车辆动力学仿真，单核求解速度有限，在普通机器上已经能跑出足够的训练数据，没必要为了形式上的分布而引入通信不确定性。

2.3 最小可运行示例：Python拉起CarSim求解器

下面给一个最小化的 Python 代码骨架，展示从启动求解器到逐步进仿真、读写变量的完整闭环。具体 API 名称在不同版本里略有差异，但整体流程是通用的，你需要以本地安装的 CarSim Python 接口为准。

import os import time import numpy as np # 假设这是CarSim安装目录下的Python接口 # 实际import语句以你本地版本为准 from vs_api import CarSimSolver class MinimalCarSim: def __init__(self, simfile_path, dt=0.01): self.dt = dt os.chdir(os.path.dirname(simfile_path)) self.solver = CarSimSolver(simfile_path) self.solver.start() time.sleep(2.0) # 等待求解器完成初始化 def step(self, steer_angle, throttle): # 写入控制量 self.solver.set_variable("Steer_SW", steer_angle) self.solver.set_variable("Throttle", throttle) # 推进一个控制周期 self.solver.step(int(self.dt * 1000)) # 读取状态量 x = self.solver.get_variable("Position_X") y = self.solver.get_variable("Position_Y") yaw = self.solver.get_variable("Yaw") vx = self.solver.get_variable("Vx_SM") return x, y, yaw, vx def close(self): self.solver.stop() if __name__ == "__main__": sim = MinimalCarSim("path/to/your/simfile.sim") for _ in range(100): x, y, yaw, vx = sim.step(0.05, 0.3) print(f"x={x:.3f}, y={y:.3f}, yaw={yaw:.3f}, vx={vx:.2f}") sim.close()

这段代码的几个要点说一下。第一，求解器启动后要留 1 到 2 秒的初始化时间，不要立刻写数据，否则部分变量还没有就绪，写入会被忽略。第二，每次 step 之前先设置控制量，再调用步进行，这个顺序不要颠倒。第三，读取状态量的变量名必须和 simfile 里定义的输出变量完全一致，否则会静默返回零值，这个坑我后面专门展开讲。

3. 把CarSim封装成强化学习环境：状态、动作、重置与时间管理

有了通信链路之后，下一步就是把 CarSim 包装成一个标准强化学习环境，也就是 Gym 风格的 Env 类。这一层的设计质量直接决定训练效果，绝不能只是把 API 调一遍就完事。

3.1 状态空间和动作空间的工程定义

路径跟踪任务的状态空间，我推荐包含以下两个维度。第一类是"误差信息"，也就是车辆相对于参考路径的横向偏差和航向偏差，这两个量是任务目标本身，必须进状态。第二类是"车辆自身动态信息"，包括纵向车速、横向车速、横摆角速度和当前方向盘转角。这些量让策略网络能感知车辆当前的运动趋势，仅凭误差信息做决策的话，策略会显得非常"迟钝"，因为误差变化是滞后的。

我实际用的状态向量是：

• 横向偏差 e_lat，单位米，取正负号表示偏向路径左侧还是右侧
• 航向偏差 e_yaw，单位弧度，归一化到 [-π, π]
• 纵向车速 vx，单位 m/s
• 横向车速 vy，单位 m/s
• 横摆角速度 yaw_rate，单位 rad/s
• 前方 5 米处的参考路径曲率 kappa

最后一个前瞻曲率项非常关键。路径跟踪本质上是一个跟随时延系统，车辆从打方向盘到横向位置发生变化需要时间，如果状态里没有提前量信息，策略只能靠试错产生补偿动作，收敛会很慢。

动作空间的维度和你要做的路径跟踪任务复杂度直接相关。如果只做转向控制，单维动作就够了，我用的上限是方向盘转角范围 ±2 弧度，送入 CarSim 前做一次 clip 限制。如果要做完整的循迹控制，动作维度需要扩展为方向盘转角、油门踏板开度、刹车踏板开度三个值。从实验对比来看，纯转向控制在路径跟踪这个任务上已经能取得很好的效果，而且稳定性更好，我建议新手先从单维动作做起，跑通整个 pipeline 之后再逐步扩展。

所有状态量在送入网络之前必须归一化。我踩过的坑是：横向偏差量级在 0.01 到 1 米之间，横摆角速度量级在 0.01 到 0.5 rad/s，车速量级却可以达到 10 到 30 m/s，三者直接拼接进状态向量时，数值大的变量会完全主导网络梯度，训练收敛极慢。归一化到 [-1, 1] 之后，训练曲线明显平滑很多。

3.2 参考路径生成与横向偏差、航向偏差的计算

参考路径有两种来源。第一种是 CarSim 内置道路编辑器里绘制的道路中心线，仿真时从 CarSim 里把中心线坐标读出来。第二种是在 Python 侧用参数方程生成参考轨迹，比如双移线、正弦波、圆弧与直线拼接。

我强烈推荐第二种。原因只有一个：随机化便利性。强化学习训练需要泛化能力，每个 episode 用不同的参考路径训练策略，泛化性会远好于在固定的 CarSim 道路上反复训练。我在实践中会在每个 episode 开始前，随机生成一条由低速段和高速段拼接的参考路径，并把正弦段的幅值和相位设为随机值，这样策略模型见到的道路风格足够多样，测试时换到没见过的道路上也不至于失效。

偏差计算是环境代码里最容易写错的地方。核心思路是：把参考路径离散成密集点列，每个点包含位置和切向方向，然后对车辆当前位置寻找最近的路径点，以该点作为投影点。横向偏差的计算公式是车辆位置到最近点连线与路径切向的叉积，带正负号；航向偏差是车辆航向减去最近点的切向角，并归一化到 [-π, π]。

def compute_errors(x, y, yaw, path_points): # path_points: (N, 3) 数组，每行是 (x, y, theta) dx = x - path_points[:, 0] dy = y - path_points[:, 1] dist2 = dx * dx + dy * dy idx = np.argmin(dist2) px, py, ptheta = path_points[idx] # 横向偏差：叉积 e_lat = -np.sin(ptheta) * dx[idx] + np.cos(ptheta) * dy[idx] # 航向偏差：角度差归一化 e_yaw = np.arctan2(np.sin(yaw - ptheta), np.cos(yaw - ptheta)) return e_lat, e_yaw, idx

搜索最近点的复杂度是 O(N)，N 是路径点数，在我的场景下不超过 500，单次计算在 0.1 毫秒以内，完全够用。如果路径点数很多，可以考虑 KDTree 加速，但路径跟踪场景基本不需要。

3.3 reset逻辑和仿真时间管理

reset 是 RL 环境里很容易被敷衍但实际上非常重要的部分。CarSim 求解器内部状态很多，包括悬架位移、轮胎滑移率、发动机转速等。简单的做法是直接让求解器进程关闭重启，这个方案稳定可靠，但代价是每次 reset 都要等 1 到 2 秒的初始化时间，训练几千个 episode 下来浪费不少。

更高效的做法是使用求解器提供的重新初始化接口，直接把车辆位置、航向、速度等初始状态写入对应变量，然后让求解器从零时刻重新开始积分。这样 reset 耗时可以从秒级降到毫秒级。你需要给环境增加一个方法，在初始化时读取车辆状态变量的名字和对应的初始值变量名，然后按映射关系写入。

初始化位置我建议设置在参考路径起点后方 3 到 5 米处，让车辆有充分距离从初始状态收敛到跟上参考路径。同时在这个位置上叠加少量随机扰动，比如横向偏差 ±0.5 米、航向偏差 ±0.1 弧度、车速 ±2 m/s，避免策略网络过拟合到固定的起点条件。

每个 episode 的最大仿真时长也要设计。路径跟踪任务的典型设置是 20 到 30 秒仿真时间，控制周期 0.01 秒，也就是一个 episode 最多做 2000 到 3000 个 step。中间如果车辆横向偏差绝对值超过 3 米，我认为车辆已经彻底偏离路径，继续训练没有意义，直接终止 episode 并施加一个较大的终止惩罚。这个终止条件必须加，否则策略会探索出"往路边开但不出界"这种钻空子的行为。

4. 路径跟踪训练实践：奖励函数设计、算法选型与收敛经验

环境搭好之后，真正决定训练效果的是奖励函数和算法配置。这一节是全文最花心思的部分，我尽量把权衡逻辑讲清楚。

4.1 奖励设计的核心权衡与推荐公式

路径跟踪的奖励函数，表面看是一个简单的"惩罚误差"问题，但实际操作中你会发现在跟踪精度和驾驶品质之间存在明显矛盾。如果你把横向偏差的惩罚系数设得非常大，策略网络会倾向于高频小幅调整方向盘，来保持横向偏差极小，结果是车辆轨迹抖动明显，舒适性很差。反过来，惩罚系数过小的话，车辆会长时间稳定偏移在路径的一侧，跟踪精度上不去。

我最终使用的奖励函数是如下形式：

r = -w1 * e_lat^2 - w2 * e_yaw^2 - w3 * delta_delta^2 - w4 * (vx - v_ref)^2

其中 delta_delta 表示当前方向盘转角与上一时刻方向盘转角之差，即控制增量。这里的关键细节是：控制增量惩罚项用差值而不是绝对值。用绝对值的惩罚会限制方向盘在稳态时保持较大转角，这在弯道里是有害的；用增量惩罚则允许方向盘在需要时保持任意角度，只是不允许快速大幅度摆舵，既能抑制抖动又能保证过弯能力。

四个权重系数初始值可以参考 w1=1.0，w2=0.5，w3=5.0，w4=0.2。需要注意，w1、w2 和 w4 的量纲不同，真实数值大小直接和状态量归一化后的尺度耦合。我在实际调整中通常是先固定 w3，再逐步增大 w1，直到车辆在直线段不再抖动为止。

另一个非常实用的技巧是加入"阶段性稀疏奖励"。如果整个 episode 结束时的最大横向偏差小于 0.5 米，额外给 +10 的正奖励。这个奖励信号不常出现，但一旦出现就会给策略一个很强的引导，告诉它"你刚才那样全程平稳跟线的做法是对的"。我实测加入这个稀疏奖励后，收敛速度大约提升了 30% 到 40%。

4.2 DDPG、TD3、SAC在路径跟踪上的实测表现

路径跟踪是连续动作问题，常用的强化学习算法是 DDPG、TD3 和 SAC。三个算法我都跑过，可以说各有各的脾气。

DDPG 是最容易复现出效果的算法，代码简单，训练初期 reward 下降很快。但它的致命缺点是超参数敏感，而且训练后期策略网络容易出现突发的性能崩坏，表现是在曲线上先稳定下降，然后突然在某一个 episode 全体 reward 涨回初始值，之后再也收敛不回来。这个"突然掉点"的现象我遇到多次，每次都需要重新调整学习率或者噪声参数才能恢复。

TD3 在 DDPG 上做了三个改进：双重 Q 网络、目标策略平滑、延迟更新。实话说，这三大改进在路径跟踪任务上的收益非常明显。TD3 的训练过程要稳定得多，即便偶尔有 episode 出现异常高奖励，下一轮也会自然回归正常，不会出现 DDPG 那种全线崩溃的情况。如果你现在准备开始做这个项目，我的首选建议直接是 TD3。

SAC 的最大熵特性让它探索更加充分，收敛到最终的跟踪精度也是三者中最好的。但代价是计算开销高出不少：要维护两个 Q 网络、一个策略网络、一个温度系数，训练时还需要存储大量的熵估计量。在我的工作站上，SAC 单 step 的训练耗时比 TD3 多出约 70%，而最终横向偏差 RMSE 只比 TD3 低约 10%。如果不是追求极致精度，我倾向于 TD3。

三个算法的对比可以简单列一个表：

4.3 影响训练收敛稳定性的几个配置

第一个是随机种子的固定。PyTorch、NumPy、Python 随机库的种子都要固定，此外还要关注 CarSim 求解器本身是否引入了随机因素。车辆模型内部如果不随机，就只需要管好 Python 侧的种子。固定种子最大的好处是让每次训练结果可复现，调参时你才能确定改善效果来自参数变化还是运气。

第二个是探索噪声的衰减策略。训练初期需要较大的探索噪声让策略充分探索可能的动作空间，训练后期则需要噪声降低让策略稳定执行已经学到的好行为。我用的做法是高斯噪声，标准差从 0.15 线性衰减到 0.02，大概在训练进度达到一半时完成衰减。不要用固定噪声，固定噪声会让策略永远学不到精确控制能力，因为它的每个动作都带着不确定性。

第三个是经验回放池的大小。路径跟踪环境单个 episode 会产生 2000 到 3000 条经验，经验池容量建议至少 20 万个样本。如果容量太小，较早的优秀经验会被后续的平庸经验挤出去，导致策略遗忘已经学到的东西。我的实践值是 50 万条经验，训练一个完整任务大约需要 2 到 3 小时。

第四个是目标网络更新系数。TD3 和 SAC 都需要软更新目标网络，τ 取 0.005 是常规值，我在实践中尝试过更小的 0.001，收敛更慢但更稳定。在路径跟踪这种奖励信号连续密集的任务里，0.005 是一个比较省心的默认值。

5. 实操中的故障排查链路与踩坑记录

最后这部分，我想完整复盘几个我在训练过程中真实遇到过的故障，重点不是直接给解决方案，而是把排查过程捋清楚，让你以后遇到类似问题时有排查思路可以遵循。

5.1 仿真步长与控制周期不匹配的同步问题

现象是 Reward 曲线表现正常，但把车辆实时轨迹画出来时，发现轨迹点有周期性锯齿，尤其在车辆进入弯道后更明显。

排查过程是这样的。我先把 Python 侧控制周期固定为 0.01 秒，然后用 CarSim 自带的后处理工具查看仿真结果，发现 CarSim 内部求解步长是 0.001 秒，也就是求解器每 10 个内部步长才与外部交互一次。理论上这是一个倍频关系，应当同步良好，但轨迹锯齿提示交互发生了错位。

进一步检查发现，我使用的 CarSim 版本里，外部数据同步发生在求解器步进的正中间。也就是说，外部发送控制量之后，求解器只前进半个控制周期就开始等待，然后读取状态。这导致每次读取到的状态实际上是控制量生效前半步的状态，相当于动作与状态之间存在半个步长的错位。

解决办法是把通信层的同步逻辑改成"先等待步进完成，再发送控制量，然后推进一个完整控制周期，再读取状态"，也就是保证读取状态时动作已经完全生效。修改后锯齿消失。如果你们用的 CarSim 版本同步行为不同，建议先用一个简单的"正弦转向输入"测试用例，对比 Python 端记录的控制量和 CarSim 后处理曲线之间的时间关系，确认同步逻辑正确。

5.2 动作执行顺序导致的滞后问题

现象是训练中 Reward 曲线正常下降，但车辆轨迹明显走内侧，进入弯道时转向不足，而且这个偏差是稳定的时间滞后。

这个故障的典型原因是"动作-读取"顺序颠倒。我最初的 step 函数写成：先读取车辆状态，再发送本轮控制，然后等待一个控制周期。问题在于，CarSim 收到控制量后，需要到下一个控制周期才开始执行这个动作。于是，读取到的状态对应的是上一轮控制量执行完的结果，而新发送的控制量要到下一轮才生效。在这个机制下，策略网络的决策实际上总是慢一拍生效，车辆自然总是"晚半步"过弯。

排查这类问题的一个有效方法是做开环测试：给环境输入一个固定的正弦转向信号，记录车辆横向位置随时间的响应曲线，然后和步进逻辑对照，看信号与响应之间的延迟是否是整数个控制周期。如果是，就需要调整 step 函数里的读写顺序。我调整成"先发送本轮控制量，再推进步进，最后读取状态"之后，轨迹偏差立即减小。

5.3 状态越界与NaN发散的处理

这个故障是我见过最"吓人"的：训练到第 1800 个 episode 左右，突然奖励变成 NaN，而且之后所有 episode 都输出 NaN。刚开始我怀疑是网络梯度爆炸，在 PyTorch 里加了梯度裁剪，问题依然存在。这说明 NaN 来自环境侧而不是网络侧。

我把环境的所有状态量打日志后发现，车辆在某个 episode 开出道路边界后，CarSim 的某些内部状态量如轮胎滑移率发散成了 NaN，这些 NaN 通过状态向量传入网络，导致网络训练崩溃。更糟糕的是，求解器内部一旦进入 NaN 状态，不重启不会自行恢复，所以后�续所有 episode 都受影响。

解决思路分三层。第一层是防御：状态读取层在做归一化之前，先对原始值做一次合法性检查，任何一个值为 NaN 或 Inf，直接判定该 episode 失败并返回一个较大的负奖励。第二层是限制动作幅度：动作送入 CarSim 前必须 clip 到合法范围，防止过大转向或油门导致车辆冲出物理极限。第三层是重置时把初始扰动限制在安全范围内，避免车辆以过高的初始横向速度冲入弯道。

加了这三层防御之后，NaN 问题再没出现过。这个故障给我的教训是：RL 环境代码中，防御性检查和数值合法性校验不是可选项，而是刚需，尤其在连接外部物理引擎时，外部引擎发散的后果会传导到你的训练流程里。

5.4 一个定位到参考路径曲率计算缺陷的完整案例

最后分享一个比较有意思的排查案例，因为它最终定位到的问题既不在 CarSim，也不在强化学习算法，而是一个看起来很普通的路径预处理逻辑。

当时我用 TD3 训练了一个 20 米双移线路径跟踪任务，训练 2000 个 episode 后横向偏差 RMSE 稳定在 0.8 米左右，之后就再也不下降了。这个结果不能算失败，但离我的预期差很多。

我首先排查了算法超参数：网络结构从两层 256 改为三层 512，学习率从 3e-4 调整到 1e-4，都没有明显变化。接着检查奖励函数，尝试把横向偏差惩罚加大到原来的两倍，结果精度反而下降了。这时候我开始怀疑环境里存在某个系统性的偏差。

我把车辆轨迹和参考路径画在同一张图里，发现一个规律：车辆在曲率较大的弯道段，总是稳定走在参考路径的内侧，且偏差几乎是恒定偏置。这说明车辆进入弯道时总是转向不足，系统性地少转了一个角度。我把注意力转向参考路径的曲率计算，发现我的代码里曲率是用相邻路径点之间的方向角差分计算得到的。当参考路径点间距较大时，离散差分会让曲率在曲率变化剧烈的位置被低估。策略网络看到的"前方弯道曲率"比实际值小，自然转得不够。

解决方法是把参考路径点先做高密度插值，把相邻点间距压缩到 0.5 米以内，再重新计算曲率，并在状态空间中保留那个 5 米前瞻曲率项。修改之后，同样训练 2000 个 episode，横向偏差 RMSE 降到了 0.25 米左右。

这个案例最值得记住的一点是：当强化学习训练结果看起来"已经不错但不够好"时，不要急着调算法，先怀疑环境里那些不起眼的数值计算环节。路径预处理、坐标变换、角度归一化这些简单逻辑，往往藏着影响全局的系统性误差。

我个人在这些项目里反复体会到，CarSim 与 Python 的深度集成本身并不是一个"能跑就行"的事，它对环境封装的质量、通信时序的理解、以及数值安全性的重视程度，直接决定了后面强化学习训练是顺风顺水还是步步惊心。如果你正打算走这条路，建议先花半天时间把共享内存通信和最小仿真闭环跑通，再开始写训练代码——这套底子打好了，后面所有环节都会快很多。