一封来自调度中心的工单

凌晨两点十七分，某汽车零配件仓库的AGV调度系统弹出了一条红色告警：

"B7区3号车与B7区7号车路径冲突，预计碰撞倒计时：4.2秒。"

调度员李哲盯着屏幕，手指悬在键盘上方。

三秒后，系统自动规避，两台车各自让开。他松了口气，截了个图发到工作群："又救回来了。"

没人回他。凌晨两点的工作群，只有他一个人醒着。

但他知道，这不是今天的最后一次。这批新上的二十台AGV，过去一周已经触发了十一次路径冲突，三次死锁，一次全区域急停。

仓库经理在会上拍了桌子："一百零八台车，还没跑满两个月，就开始打架了？当初方案里说的'百台级稳定调度'呢？"

没人敢接话。

李哲心里清楚问题出在哪里。不是调度算法不行，是底下的工控板扛不住了。每台AGV上那块单点计算的小主板，在单机跑的时候没问题，一旦连成网、跑成集群，通信延迟就像多米诺骨牌一样往上翻。

单点能跑，集群就崩——这是AGV集成商最怕听到的一句话。

一百台AGV的真相：不是一百个问题，是一个问题的一百次放大

做AGV集群的人都知道一个残酷的事实：一台车和一百台车，根本不是同一个工程。

一台AGV跑起来，逻辑很简单——接到任务，算路径，走到目的地，停。这个过程里，工控板只需要处理自己的传感器数据、自己的运动控制、自己的避障判断。延迟几十毫秒，没人在乎。

但一百台呢？

一百台意味着一百个节点同时在跟中央调度服务器通信，同时在互相广播自己的位置和意图，同时在接收来自WMS的任务、来自充电桩的状态、来自安全围栏的信号。每一台车不只是"执行者"，它还是"通信节点"。

这时候问题就来了。

传统的AGV工控板设计思路是什么？够用就行。一台车配一块板，跑本地任务，通过Wi-Fi或者4G跟调度中心连一下。单机看着挺好，延迟20ms，丢包率0.1%，完美。

但当你把一百块这样的板连到同一个网络里，奇迹发生了：通信延迟从20ms跳到200ms，丢包率从0.1%飙到3%，调度指令到达车端的时候，车已经走出半米了。

半米，在AGV的世界里，就是一次刮擦、一次急停、一次产线中断。

这就是"单点架构"的致命伤：它假设自己永远是一个人在跑。但实际上，它一上线就是一百个人挤在一条走廊里。

李哲后来跟我说了一句话，我一直记着："我们最大的失误，是用了一百个孤岛去拼一个大陆。"

架构级的答案：不是换更快的CPU，是换一种思考方式

后来这个项目换了供应商。

新方案的核心不是把工控板的CPU从四核换成八核，也不是把内存从4G加到8G。那些都是单点思维——你在孤岛上盖高楼，岛还是那个岛。

新方案做了一件根本性的事：重新设计了工控板的通信架构。

具体来说，三个改变：

第一，从"星型通信"变成" mesh自组网"。

以前一百台车都直接连调度中心，调度中心就是瓶颈。一百条路汇成一个口，堵是必然的。新架构让每台AGV的工控板不只连调度中心，还跟相邻的三到五台车保持直连。任务不用全部经过中心，局部路径协商在车与车之间直接完成。调度中心只负责全局策略，不管微观调度。

这相当于把一条高速公路改成了网格状的城市路网。堵点少了，因为路多了。

第二，从"被动轮询"变成"事件驱动"。

旧架构里，调度中心每隔100ms问一次每台车："你在哪？你要去哪？"一百台车就是每秒一万次查询。工控板的CPU有一半时间在回答"我在这里"，真正干活的时间被挤没了。

新架构改成事件驱动：车不动的时候，不说话。只有状态变化——遇到障碍、到达节点、电量告急——才主动上报。平时静默，有事才喊。通信量直接降了70%。

李哲跟我说，改完之后，调度中心的CPU占用率从85%降到了30%。"以前调度中心像个客服，一天接一万个电话。现在像个经理，只处理异常。"

第三，从"软实时"变成"硬实时"。

这是最关键的一点。AGV避障不是"差不多就行"的事。两台车相距半米的时候，你必须在10ms内做出决策，没有"差不多"的余地。

传统工控板跑Linux，任务调度是软实时的——理论上10ms能响应，但偶尔会被别的进程抢走，变成30ms、50ms。在单机场景下，这种偶尔可以容忍。但在百台集群里，这种"偶尔"会被放大成"经常"。

新方案用的工控板底层跑的是实时操作系统，通信栈走的是优先级调度。避障指令永远排在最前面，不管别的任务多忙，它先走。

这不是性能问题，是架构问题。你不能靠跑得更快来解决堵车，你得重新设计道路。

落地那天：一百零八台车，第一次同时跑满

改造完成那天，李哲没告诉仓库经理。他自己先跑了一次满负载测试。

一百零八台车，全部上线，全部接单，全部同时跑。

他盯着监控大屏，数着冲突告警的次数。

零。

不是"很少"，是零。连续跑了四个小时，零次路径冲突，零次死锁，通信延迟稳定在8ms以内，丢包率0.02%。

他后来跟我说，那天晚上他在调度中心坐了很久，没走。不是因为有事，是因为太安静了。以前这个点，告警声此起彼伏，他得不停地处理。现在屏幕上一片绿色，所有车都在安安静静地跑。

"那种感觉，"他说，"就像你带了一百个人的团队，第一次发现所有人都知道自己该干什么，不用你喊。"

回到那块板：它到底做了什么不一样的事

很多人问，这个方案的核心是那块工控板吗？

是，也不是。

说"是"，因为这块板确实不一样。它不是一块通用的嵌入式主板，而是从通信架构层就为集群场景设计的。比如USR-EV系列工控板，原生支持多路CAN Bus、RS485和千兆以太网的并发处理，板载通信芯片做了硬件级的优先级队列，不是靠软件模拟的。这种板卡级别的通信优化，是你在通用平台上堆软件解决不了的。

说"不是"，因为真正的改变不在硬件，在架构。那块板只是新架构的载体。如果你拿一块USR-EV系列的板，还是用旧的星型轮询通信，那它跟普通工控板没有区别。

好的硬件是必要条件，但不是充分条件。充分条件是：你得用集群的方式去思考每一块板的角色。

以前的思路是：每台车一块板，每块板管好自己。

现在的思路是：每台车一块板，每块板管好自己，同时跟邻居保持默契，同时知道什么时候该沉默、什么时候该说话。

一块板，从"孤岛"变成了"节点"。这才是架构级的升级。

写给正在"数车"的你

如果你现在正在管一个AGV车队，十台、三十台、五十台，你可能已经开始感觉到一些不对劲了——

调度指令偶尔会慢半拍，两台车在交叉路口"犹豫"了一下才让开，通信日志里偶尔冒出几个超时包，你告诉自己"还能用"，但心里隐隐觉得，再加十台可能就撑不住了。

你的直觉是对的。

AGV集群的瓶颈从来不在第一百台车上线的那一天爆发，它在第五十台的时候就已经开始了。只是那时候你还有余量可以扛，等到第八十台、第九十台，余量吃完了，问题就全出来了。

你现在需要做的，不是等问题爆发了再换方案，而是在第五十台的时候，就把架构想清楚。

单点能跑不叫能力，集群能跑才叫能力。

一块板能算不叫本事，一百块板能协同才叫本事。

你不需要把现有的车全部拆了重来。你需要的是，在下一批车上线之前，把通信架构从"星型"改成"mesh"，把调度逻辑从"轮询"改成"事件驱动"，把底层系统从"软实时"换成"硬实时"。

这些改变，可能只是换一块为集群设计的工控板，改几行通信协议的代码。

但它决定了你的车队，是从五十台开始发抖，还是从一百台开始起飞。

你的调度中心，现在安静吗？

如果不安静，也许该换一种方式让它安静了。