简介：C#开发的基于分布式强化学习的多智能体路径规划源码包，附带sln解决方案，面向计算机、人工智能、自动化等专业的在校生与研发人员，可用于多智能体协同路径规划研究、课程设计或毕业设计。项目基于Unity引擎构建，以C#脚本实现分布式强化学习训练与推理逻辑，并辅以可视化场景。资源共2000个文件，压缩包约831.68MB，主要包含Unity场景与Prefab预制体（331个）、FBX模型（331个）、材质与Shader（56个mat与4个shadergraph）、C#工程文件（4个csproj及sln解决方案）、meta配置（886个）以及文档（139个md）等，结构完整，可直接打开运行。目前已有182人学习下载，代码经过测试，功能可用，并附有项目说明文档，便于理解分布式强化学习在多智能体路径规划中的应用。读者可基于现有框架替换奖励函数、神经网络结构或场景障碍布局，快速验证不同算法效果，也可直接用于项目立项演示或毕业设计。
1. C#写分布式强化学习多智能体路径规划：这个 sln 来了能直接用吗
拿到一个标着“C#开发基于分布式强化学习的多智能体路径规划源码+sln解决方案.zip”的工程包，多数人的第一反应是解压、双击 .sln、等编译通过，然后找不到训练入口。这个标题其实拆成三块看：算法是多智能体强化学习，训练方式是分布式采样与集中更新，工程形态是 C# 和 Visual Studio 解决方案。对做 AGV 调度、仓储机器人、园区无人车避障的团队来说，它的价值在于不用再从 Python 原形往 C# 生产环境硬翻译，打开解决方案就能在同一个代码库里改地图、调奖励、看收敛曲线。适合两类读者：一类是 C# 熟练但强化学习刚入门的工程师，想知道这些源码从哪里下手；另一类是强化学习熟悉但被 Python 和 C# 联调折磨过的从业者，想找一个能直接落地的工程范式。
2. 从 sln 开始拆工程：分布式强化学习路径规划解决方案的骨架
你拿到的是一个 .zip 压缩包，里面最重要的不是某一个算法文件，而是最外层那个 .sln。Visual Studio 解决方案的核心职责是告诉你“哪些工程属于同一个构建单元”，以及它们之间谁依赖谁。很多 C# 项目会默认把引用关系交给 IDE 自动管理，但在多智能体路径规划这种代码量不算特别大的项目里，合理的工程划分比注释更重要。
2.1 用一段 C# 解析 .sln，先看清解决方案里有哪些工程
我第一件做的事，不是直接双击打开，而是把 .sln 当作文本文件读一遍。.sln 本身是纯文本，包含 Project 行、全局配置和嵌套关系。下面这段 C# 小程序可以帮你快速列出解决方案里的所有工程名和相对路径，适用于任何 .sln：
// 解析 .sln 中 Project 行，输出每个工程的名称和相对路径 using System.Text.RegularExpressions; if (args.Length < 1) { Console.WriteLine("用法: SlnProbe <solution.sln>"); return; } string slnPath = args[0]; string[] lines = File.ReadAllLines(slnPath); var projectRegex = new Regex( @"^Project\(""\{[0-9A-Fa-f\-]+\}""\)\s*=\s*""(?<name>[^""]+)"",\s*""(?<path>[^""]+)"",\s*""\{[0-9A-Fa-f\-]+\}""$", RegexOptions.Compiled); foreach (string line in lines) { Match m = projectRegex.Match(line.Trim()); if (m.Success) { string name = m.Groups["name"].Value; string path = m.Groups["path"].Value; Console.WriteLine($"{name}\t=>\t{path}"); } }这段代码只做了两件事：按行读取 sln，并用正则匹配Project(开头的行；把捕获到的工程名和工程路径打印出来。args[0]是 sln 路径，如果文件路径含空格，命令行传参时要用引号包住。正则里的[0-9A-Fa-f\-]用于匹配 GUID，IDE 生成的 GUID 大小写都有，必须忽略大小写，否则解析会漏行。
用输出对照项目命名，基本可以看出解决方案是否健康。一个合理的多智能体路径规划方案通常包含四类工程：
| 工程名（常见命名） | 职责 | 关键依赖 |
|---|---|---|
| Xxx.Environment | 栅格地图、智能体移动、碰撞检测、回合重置 | Common |
| Xxx.Agents | 智能体状态机、动作采样、训练用的 Agent 逻辑 | Environment, Common |
| Xxx.Trainer | 训练循环、经验收集、分布式参数同步 | Agents, Environment |
| Xxx.Common | 日志、配置读取、通信消息定义 | 无 |
Environment 工程负责仿真，Agents 工程负责决策，Trainer 工程负责训练，Common 提供日志、配置和消息结构。如果某个下载包把所有类都塞进一个 Program.cs，那配置和训练逻辑大概率耦合严重，后续扩展地图很痛苦。
2.2 工程依赖与命名空间：Environment、Agent、Trainer 各自管什么
多智能体路径规划里最容易失控的是依赖方向。Environment 只应该知道自己和 Common，不关心策略是深度 Q 网络还是 PPO。这样地图一直在变，训练循环不用重新编译。一个最小地图接口可能长这样：
// 环境工程里的地图接口，保证 Trainer 不关心地图是来自 JSON 还是代码生成 public interface IGridMap { int Width { get; } int Height { get; } bool IsBlocked(int x, int y); bool IsInBounds(int x, int y); }看到这个接口你会注意到，地图只暴露宽高和占用判断，不暴露内部数组。这样 Trainer 拿到的只是“环境怎么看待地图”，而不是地图的实现细节。实际项目里，我会在 Environment 工程里再放一个GridMapJsonLoader，用于读取地图 JSON，但加载逻辑只属于 Environment，Trainer 不去引用它。
Agent 工程则更关心每个智能体的状态机：当前位置、目标位置、动作、是否到达、是否碰撞。这里的 Agent 不是神经网络，而是与环境交互的载体。真正可训练的策略网络通常放在 Trainer 或独立的 Algorithms 工程里，避免 Agent 工程引用深度学习库，否则一个 Agent 实例会背着一整个深度学习运行时。
依赖方向必须保持Trainer -> Agents -> Environment -> Common单向流动。如果我把 Environment 改成引用 Trainer，那以后调整训练循环里的日志格式，就得重新编译环境工程，这会让一次简单的日志改动牵扯到全部智能体代码。这是 C# 解决方案里最值得警惕的地方。
2.3 看懂“分布式”落在哪：Actor/ Learner 拆分与通信接口
“分布式强化学习”这个标题，在路径规划代码里最常见的落地形式，不是多机集群，而是多个环境并行采样、一个训练器集中更新。也就是 Actor 和 Learner 分离。
// 训练器与采样 Worker 之间的最小消息契约 public interface ITrainingMessage { int WorkerId { get; set; } int Episode { get; set; } float Reward { get; set; } float[] Observation { get; set; } int Action { get; set; } }这个接口定义了 worker 与 trainer 之间传递的原始数据。WorkerId标识来自哪个采样进程或线程，Observation是固定长度的 float 数组，Action是离散动作编号，Reward是环境返回的回报。你不需要把整条轨迹一次性发给 Trainer，通常是一个时间步一个消息，由 Trainer 端按Episode打包成完整轨迹。
这里要特别强调一个概念：多智能体路径规划里的“分布式”，和“多线程跑多个new Environment()”不是一回事。常见做法是每个 actor 内跑一个独立的 Environment 实例，各自维护一组智能体状态；Actor 只负责采样，不更新参数。Learner 统一计算 loss 并更新参数，再把新参数广播回各 actor。如果你在源码里看到所有 actor 共享同一个环境实例，那不是分布式，是一个全局共享状态的黑匣子，坚决要拆开。
实际拆解时还要决定是进程级并行还是线程级并行。.NET 里线程级并行实现成本低，但易被全局锁拖慢；进程级并行更干净，但跨进程通信需要引入消息序列化。基于 sln 的源码工程通常先做线程级并行，等训练规模上来再改进程级。因为路径规划这类任务环境单步计算量不大，线程级并行在 4 到 8 个 actor 范围内完全够用。
多智能体训练范式也需要在阅读源码时确认。现在主流有两种：一种是 independent learning，每个智能体各学各的策略，实现简单但非平稳问题严重；另一种是 CTDE（集中训练、分布式执行），训练时共享一个 critic，执行时每个智能体只带自己的 actor。C# 源码如果采用了 CTDE，你会看到 Trainer 里有一个全局观测拼接函数，而 Agents 工程里的执行代码却不会引用那个全局批评者。识别出这一点，你就知道这个 sln 的架构是不是为多智能体场景专门设计的。
3. 多智能体路径规划的核心建模：状态、动作、奖励在 C# 里怎么写
分布式训练只是加速手段，真正决定这个源码能不能跑出像样路径的，是环境建模三件套：状态、动作、奖励。这一节按我调多智能体路径规划的习惯，把 C# 里最容易出错的地方逐个拆开。路径规划强化学习本质上是一个马尔可夫决策过程，每一步都要让智能体知道“我在哪、目标在哪、周围有没有障碍”，然后决策“往哪走”。
3.1 栅格地图状态与多智能体观测：固定维度数组还是字典
很多第一次接触的人想把整个地图、所有智能体位置都塞进网络，于是用字典或可变长度 List 组织观测。这是路径规划强化学习里最常见的反模式。神经网络的输入维度必须固定，字典结构还得自己额外写序列化和 padding，调试时非常麻烦。
我一般按“局部观测 + 全局归一化坐标”组织状态。每个智能体只感知以自己为中心的一个局部窗口，比如 5x5 栅格，再加上自己的坐标、目标相对坐标。下面是一段能直接放进 Environment 工程的方法：
// 把局部观测压缩成固定 75 维向量：5x5 占用 + 自身x,y + 目标dx,dy + 朝向/ID public float[] BuildObservation(GridMap map, AgentState me, AgentState[] others) { var obs = new float[5 * 5 + 2 + 2 + 2]; int idx = 0; // 局部占用：以当前智能体为中心，向上/下/左/右扩展 2 格 for (int dy = -2; dy <= 2; dy++) { for (int dx = -2; dx <= 2; dx++) { int nx = me.X + dx; int ny = me.Y + dy; obs[idx++] = map.IsInBounds(nx, ny) && map.IsBlocked(nx, ny) ? 1f : 0f; } } // 全局归一化坐标，避免原始像素尺度影响网络训练 obs[idx++] = me.X / (float)(map.Width - 1); obs[idx++] = me.Y / (float)(map.Height - 1); // 目标相对位移，归一化到地图尺度 obs[idx++] = (me.TargetX - me.X) / (float)map.Width; obs[idx++] = (me.TargetY - me.Y) / (float)map.Height; // 预留朝向与智能体 ID，便于后续扩展协作信息 obs[idx++] = 0f; obs[idx++] = 1f; return obs; }代码里最值得关注的是那两个预留位。多智能体路径规划后期几乎一定会加入“其他智能体相对位置”或“任务优先级”等信息，提前在状态层留位置，好过后面改网络输入维度。这里的others参数这次虽然没用，但下一步加上“最近的其他智能体方位”时，不需要改方法签名。
参数怎么调：局部窗口 3x3 会让智能体像近视眼，刚看到障碍就撞；7x7 在 8x8 地图上几乎覆盖全图，信息冗余，训练慢。一般起点是 5x5，地图变大再扩到 7x7。obs 维度也要跟着网络输入层一起改，源码里如果看到观测维度和网络第一个全连接层维度对不上，检查点多半在这里。
3.2 动作空间与碰撞约束：离散五方向是多数场景的稳妥起点
连续动作空间适合需要平滑轨迹的无人机和车辆，但仓储 AGV 沿栅格移动时，离散动作更符合实际控制逻辑，也更容易施加碰撞约束。我建议先从“上、下、左、右、等待”五个离散动作开始。
public enum DiscreteAction : byte { Up = 0, Down = 1, Left = 2, Right = 3, Wait = 4 } public static bool TryMove(AgentState agent, DiscreteAction action, GridMap map, out int newX, out int newY) { newX = agent.X; newY = agent.Y; switch (action) { case DiscreteAction.Up: newY = agent.Y + 1; break; case DiscreteAction.Down: newY = agent.Y - 1; break; case DiscreteAction.Left: newX = agent.X - 1; break; case DiscreteAction.Right: newX = agent.X + 1; break; default: return true; // Wait 保持原位 } if (!map.IsInBounds(newX, newY) || map.IsBlocked(newX, newY)) { return false; // 撞墙或撞静态障碍，移动无效 } return true; }注意这里只处理了静态障碍。多智能体之间的冲突不能简单用“目标格子是否被占用”判断，因为两个智能体可能准备交换位置，各自的目标格子恰好是对方当前格。这时候两步都满足“目标格子为空”，但交换就会穿模。常见做法是环境先收集所有智能体的期望移动，再做一次两阶段落位：先移动不冲突的，再处理冲突；如果两个智能体请求进入同一个格子，随机让一个等待。这部分逻辑应该放在 Environment 的Step里，而不是 Agent 决策里。
返回布尔值的TryMove模式有一个好处：训练器判断动作是否合法时，不需要在奖励逻辑里再查一次地图。碰撞惩罚只在环境执行层判定，奖励层专注数值。动作空间还可以加“原地旋转”这样的动作，但栅格路径规划里旋转不影响位置，加了只会稀释有效动作的概率，初期不建议。
3.3 奖励塑形：到达奖励、冲突惩罚和时间步惩罚的数值比例
模型能不能收敛，一半靠状态，一半靠奖励。很多路径规划工程把碰撞惩罚设得特别大，比如 -10、-20，结果智能体为了不碰撞，学会原地等待，整个训练曲线卡死在低回报。下面是我调过多个栅格场景后觉得比较稳妥的初始值：
public static class RewardCalculator { public const float ArriveReward = 1.0f; public const float CollisionPenalty = 0.3f; public const float StepPenalty = 0.01f; public const float ProgressReward = 0.05f; public static float Compute(AgentState agent, bool arrived, bool collided, float distanceBefore, float distanceAfter) { if (arrived) return ArriveReward; if (collided) return -CollisionPenalty; float r = -StepPenalty; // 如果这一步比上一步更靠近目标，给一个小正奖励 if (distanceAfter < distanceBefore) r += ProgressReward; return r; } }数值设计的逻辑是：到达 1.0 是主目标，碰撞 0.3 只用于纠正危险动作，不能让智能体为了避撞而停止尝试。时间步惩罚 0.01 会促使智能体走更短路径，但它必须小于到达奖励，否则走出绕远路也不会被纠正。ProgressReward 0.05 是典型的密集奖励辅助项，但不能太大，否则智能体会在两点之间反复横跳薅奖励。
多智能体场景还有两个奖励陷阱。一是“集体到达才算成功”的稀疏奖励，训练初期几乎没有正样本，此时可以考虑给每个智能体单独算到达奖励，最后再加一个协同奖励；二是“奖励分配不均”，如果两个智能体争抢同一个目标点，会导致策略偏向某一个角色，这时候要引入 Shapley 值或简单按距离加权，但不要一开始就上复杂机制，先用上面这份常数表跑通。
4. 在 Visual Studio 里跑通最小训练：从打开 sln 到出现第一条收敛曲线
模型和环境设计完，接下来就是让代码跑起来。标题里的 sln 解决方案，本身就是为了让你在 Visual Studio 里一键生成。但下载源码包最常见的失败点不是算法，而是环境还原：.NET SDK 版本不匹配、NuGet 包没还原、启动项目设错。先明确最小目标：只跑两个智能体在 8x8 地图上到达目标的训练，不要一开始上 16 个智能体大图。
4.1 还原环境：.NET 版本、NuGet 依赖与启动项目
第一步在命令行确认 SDK：
dotnet --version如果安装了 Visual Studio 但 dotnet 命令不可用，说明没装 .NET SDK 工作负载，需要安装。一般这类工程会用 net6.0 或 net8.0，打开 sln 后用 IDE 的“还原 NuGet 包”即可。习惯上我喜欢用命令行先构建一次，错误信息比 IDE 弹窗更直接：
dotnet build src/PathPlanner.sln -c Release-c Release是因为训练迭代通常不关心 Debug 符号，Release 下推理性能更好。构建完成后，找到 Trainer 项目，右键设为启动项目，或者直接用命令行运行：
dotnet run --project src/Trainer -c Release -- --config config/benchmark_2agents.json这里--config后面的路径是 JSON 训练配置。如果源码包没有这个文件，你可以按下面的标准配置自己创建。注意dotnet run默认会执行当前目录下唯一的启动项目，如果解决方案里有多个可执行工程，必须用--project指明 Trainer，否则可能跑起来一个地图编辑器。
4.2 训练入口与配置文件：Actor 数量、学习率、回合长度这样设
一份最简训练配置大概长这样：
{ "scene": "grid_8x8", "maxAgents": 2, "maxEpisodeSteps": 50, "numActors": 4, "learningRate": 0.0003, "gamma": 0.99, "batchSize": 128, "targetUpdateInterval": 10 }numActors必须最先说明：它是分布式采样 worker 数量，不是智能体数量。maxAgents是场景里的智能体数量。maxEpisodeSteps和地图尺寸强相关，8x8 地图两个智能体 50 步比较合理，如果跑 20x20，建议 150 步起步。learningRate0.0003 是 PPO/AC 类算法常见安全值，初始不要超过 0.001。
在 C# 里加载配置时，我习惯用一个 record 类型对应 JSON：
using System.Text.Json; public sealed record TrainingConfig { public string Scene { get; init; } = "grid_8x8"; public int MaxAgents { get; init; } = 2; public int MaxEpisodeSteps { get; init; } = 100; public int NumActors { get; init; } = 4; public float LearningRate { get; init; } = 0.0003f; public float Gamma { get; init; } = 0.99f; public int BatchSize { get; init; } = 128; public int TargetUpdateInterval { get; init; } = 10; } // 在 Program.cs 里读取 string json = File.ReadAllText(configPath); TrainingConfig config = JsonSerializer.Deserialize<TrainingConfig>(json) ?? throw new InvalidOperationException("config parse failed");使用 record 的好处是属性只读，初始化后不会被训练循环误改。JsonSerializer.Deserialize默认要求属性名大小写敏感，如果配置里是 snake_case，需要再设PropertyNameCaseInsensitive = true，或者直接用 JsonPropertyName 特性。targetUpdateInterval只在 DQN 类算法里用到，如果你用的是 PPO，这个参数可以忽略，因为它每轮都在更新网络。
4.3 读取训练日志：episode reward、policy loss、collision rate 分别说明什么
训练跑起来后，日志输出要包含几个固定指标。建议每 100 个 episode 打印一次，而不是每步都打印，否则分布式 actor 的日志会把终端刷爆。典型输出：
[000100] episodes=128 avg_reward=0.412 collision_rate=0.087 policy_loss=0.203 value_loss=0.310怎么读这行日志：avg_reward上升说明策略整体在变好；collision_rate下降说明智能体开始学会避障；policy_loss和value_loss会波动，不必追求一直下降。真正要警惕的是 avg_reward 上升但 collision_rate 不降，这说明策略在靠绕路避开碰撞，而不是真正学会安全通行；以及 avg_reward 很高但 success_rate 很低，往往说明奖励塑形被钻了空子，比如原地等待攒 progress reward。
在训练过程中，我建议把碰撞率单独统计。多智能体路径规划完成任务只是“所有智能体都到达”，如果到达但途中撞了多次，产线方案是不能接受的。所以日志里collision_rate要按“episode 内至少发生一次碰撞的比例”统计，而不是撞多少步。这个指标可以在 Environment 的计时器里累加得到，也可以由 Trainer 从回放消息里统计。
如果训练的 sln 里已经内置了 TensorBoard 或自研日志面板，那额外加一个Console.WriteLine依然有价值。命令行日志是最低成本的排障手段，训练跑到一半发现某个 actor 回报异常，第一反应应该是看它的WorkerId是不是一直绑定同一个随机种子。
5. 避坑指南：分布式多智能体路径规划训练最常见的 5 个翻车现场
这里记录我调试这类工程时反复遇到的五个问题。每条都按“现象、原因、解决”的顺序写，你训练时如果遇到类似输出，可以直接对应处理。
5.1 多线程采样时环境状态不同步，智能体“穿墙”
现象：训练日志里两个智能体的坐标在同一回合出现重叠，甚至一个智能体穿过了另一个智能体所在栅格，但地图上的墙是好的。
原因：多个 actor 并行采样时，Environment 被当成了单例，所有线程共用同一个可变 AgentState 数组。一个线程执行 Reset，另一个线程正在 Step，数组里的坐标互相覆盖，碰撞检测自然失效。
解决：给每个 actor 单独 new 一个 Environment 实例，保证线程之间没有任何可变状态共享。常见错误写法是：
var sharedEnv = new GridEnvironment(map); Parallel.For(0, numActors, workerId => { var obs = sharedEnv.Reset(); // 多个线程同时修改 sharedEnv.Agents }); // 正确做法：每个 actor 一个环境实例 var envs = Enumerable.Range(0, numActors) .Select(_ => new GridEnvironment(map)) .ToArray(); Parallel.For(0, numActors, workerId => { var obs = envs[workerId].Reset(); });第二种写法里，每个 worker 拥有独立的随机种子和智能体数组。即使地图是同一个引用，只要 Environment 内部不修改地图，只修改自己的 Agent 状态，就可以安全并发。别小看这个坑，它不会让程序报异常，而是让碰撞检测静默失效，训练曲线还很漂亮。
5.2 单智能体收敛，两个智能体一起训练就发散
现象：单独训练一个智能体时，成功率和回报都很漂亮；加上第二个智能体，训练不到几千 episode，回报开始剧烈波动甚至崩到负值。
原因：多智能体环境本质是非平稳的。两个智能体同时在更新策略，某个智能体看到的“下一个状态”不仅由环境决定，还由另一个智能体的策略决定。如果两个策略同时大步更新，价值网络的估计会立刻失真。
解决：首选 CTDE（集中训练、分布式执行）框架，训练时所有智能体共享一个 critic，输入包含其他智能体观测，执行时只使用自己 actor。如果环境配置不方便，其次选法是让两个智能体交替更新，或者把学习率降到 1e-4 量级。伪代码：
// 每个 agent 单独计算 loss，但 Critic 的输入拼接了全局观测 for (int i = 0; i < batch.AgentCount; i++) { float actorLoss = ppo.ActorLoss(batch.ForAgent(i)); float criticLoss = ppo.CriticLoss(batch.GlobalObservation); float totalLoss = actorLoss + criticLoss; optimizer.ZeroGrad(); totalLoss.Backward(); optimizer.Step(); }不要天真地把多个智能体的 transition 全部堆进同一个 batch，然后当单智能体更新。那样 critic 看不到“是谁在做决策”，学出来的价值函数是几个策略的平均值，哪个都服务不好。
5.3 奖励值波动极大，loss 曲线像心电图
现象：avg_reward 上一轮 0.8，下一轮 -0.2；policy loss 在某些 update 瞬间放大十倍。
原因：reward 没有归一化。分布式训练里不同 actor 的 episode 长度差异很大，长 episode 的累积回报天然波动也大；如果再叠加多智能体奖励叠加，数值范围会失控。强化学习网络对奖励尺度非常敏感，不同 worker 回报差距大，梯度方向互相冲突。
解决：对每个 episode 的原始回报做 running normalization。具体做法是维护一个历史回报均值/标准差，然后用(r - mean) / (std + 1e-6)后 clip 到 [-10, 10]：
float normalizedReward = (rawReward - rewardMean) / (rewardStd + 1e-6f); normalizedReward = Math.Clamp(normalizedReward, -10f, 10f);1e-6f是为了防止标准差为零时除零错误。clip 的下限可以放到 -5，但不要剪得太平滑，否则智能体对碰撞不敏感。
5.4 训练时表现好，换一张地图策略几乎失效
现象：在训练用的 8x8 地图上成功率 99%，换成同为 8x8 但障碍位置改过的一张地图，成功率掉到 60%。
原因：训练过度拟合固定地图。多智能体路径规划里，智能体很容易记住“从某个起点到终点走哪条路”，而不是学会“避开障碍并到达目标”。特别是地图小、训练回合多的时候，网络把坐标当成了键值对。
解决：训练时引入地图随机化。常见做法是准备 10 到 20 张模板地图，每回合随机取一张，同时对障碍密度做轻微扰动，把地图泛化能力训练出来。代码：
public GridMap NextMap() { var template = templates[Random.Shared.Next(templates.Count)]; int wallNoise = Random.Shared.Next(-2, 3); return template.CloneWithWallNoise(wallNoise); }这个思路等价于强化学习里的 domain randomization。如果业务场景就是固定一张地图，那不用勉强泛化；但如果是产品化路径规划方案，随机化几乎是必需的。注意评估时要用单独的 holdout 地图，不能用训练模板。
5.5 扩大 Actor 数量后 GPU 利用率反而下降
现象：从 4 个 actor 扩到 8 个，训练速度没变快，GPU 利用率从 60% 掉到 30%。
原因：actor 数量增加，环境采样的 CPU 开销增大，每个 actor 往 Trainer 传观测和奖励的通信频次也跟着翻倍。如果训练循环是同步等待所有 actor 返回，那么最慢那个 actor 会成为瓶颈；如果还在同一线程内做模型推理，GPU 会间歇性空闲。
解决：把采样和训练解耦，actor 用异步 Task 跑，训练器只从队列里拿数据；同时把 batchSize 和每批采集步数增大，让 GPU 一次处理的样本量更足。简化示意：
Task<float>[] tasks = actors.Select(a => Task.Run(() => a.RunEpisode())).ToArray(); await Task.WhenAll(tasks); foreach (var reward in tasks.Select(t => t.Result)) { replayBuffer.Add(reward); optimizer.Update(batchSize); }Task.Run不一定能解决所有问题，还要检查 actor 内部是否有共享锁。用dotnet-trace或 Visual Studio 的并发分析器看锁等待时间，如果发现Monitor.Enter占了大头，优先去掉全局缓存或日志锁，再考虑增加 actor。
6. 进阶：用回放日志验证路径安全性，并把模型固化进 C# 推理
训练收敛只是第一步，真正决定方案能不能投入使用的是离线评估。这里讲两个在 C# 工程里落地最多、也最容易被忽略的技巧：用回放日志算安全指标，把训练好的 actor 导成 ONNX 直接推理。
6.1 轨迹回放与安全校验：冲突率和死锁率怎么算
别让训练脚本自己评估自己。训练器在更新参数时看到的是训练分布，评估结果会被过拟合掩盖。我习惯把训练时每一条 episode 的轨迹原样打到文件，再用独立评估程序重放，只关注三个数：success_rate、collision_rate、deadlock_rate。
success 是“所有智能体都到达”，collision 是“过程中至少发生一次碰撞”，deadlock 是“没碰撞但也没到达”。一段 C# 评估代码可以这样写：
int success = 0, collision = 0, deadlock = 0; foreach (var ep in replayLogs) { if (ep.AllArrived) success++; if (ep.AnyCollision) collision++; if (!ep.AllArrived && !ep.AnyCollision) deadlock++; } int total = replayLogs.Count; Console.WriteLine($"success={success / (float)total:P1} collision={collision / (float)total:P1} deadlock={deadlock / (float)total:P1}");如果 collision 超过 5%，即使 reward 再漂亮也不能放行；如果 deadlock 超过 10%，说明策略缺乏主动脱困机制，需要在奖励里加一个“连续 N 步不动给负奖励”的惩罚项。
6.2 把训练好的模型接入 C# 推理：ONNX Runtime 还是 TorchSharp
实际项目里，训练环境可能是 Python，但业务系统是 C#。你不用把整个训练框架挪到 C#，只要把 actor 网络导出成 ONNX，再在 C# 里用 ONNX Runtime 加载推理。下面是读取离散动作的标准写法：
using Microsoft.ML.OnnxRuntime; using Microsoft.ML.OnnxRuntime.Tensors; using var session = new InferenceSession("agent.onnx"); var input = new DenseTensor<float>(observation, new[] { 1, observation.Length }); var inputs = new List<NamedOnnxValue> { NamedOnnxValue.CreateFromTensor("obs", input) }; using var results = session.Run(inputs); var probs = results.First().AsTensor<float>(); int action = ArgMax(probs);这段代码里，observation必须与训练时的BuildObservation输出完全一致，包括归一化参数和特征顺序。最坑的就是训练时观测里坐标除以地图宽度，推理时忘了除，模型会直接输出错误动作。建议把BuildObservation方法复制到生产代码的公共库，并用单元测试保证训练和推理两端特征一致。
我做这类项目的最后一道工序，永远是固定随机种子重放 1000 条验证轨迹，然后把评估脚本和训练脚本分开提交。收到的教训很朴素：训练日志里看着成功的策略，不一定是安全策略；只有离线回放和产线环境同时接受，这个方案才算真正做完。希望帮到你。
本文还有配套的精品资源，点击获取
