一封來自調度中心的工單
凌晨兩點十七分，某汽車零配件倉庫的AGV調度系統彈出了一條紅色告警：
"B7區3號車與B7區7號車路徑沖突，預計碰撞倒計時：4.2秒。"
調度員李哲盯著屏幕，手指懸在鍵盤上方。
三秒后，系統自動規避，兩臺車各自讓開。他松了口氣，截了個圖發到工作群："又救回來了。"
沒人回他。凌晨兩點的工作群，只有他一個人醒著。
但他知道，這不是今天的最后一次。這批新上的二十臺AGV，過去一周已經觸發了十一次路徑沖突，三次死鎖，一次全區域急停。
倉庫經理在會上拍了桌子："一百零八臺車，還沒跑滿兩個月，就開始打架了？當初方案里說的'百臺級穩定調度'呢？"
沒人敢接話。
李哲心里清楚問題出在哪里。不是調度算法不行，是底下的工控板扛不住了。每臺AGV上那塊單點計算的小主板，在單機跑的時候沒問題，一旦連成網、跑成集群，通信延遲就像多米諾骨牌一樣往上翻。
單點能跑，集群就崩——這是AGV集成商最怕聽到的一句話。
做AGV集群的人都知道一個殘酷的事實：一臺車和一百臺車，根本不是同一個工程。
一臺AGV跑起來，邏輯很簡單——接到任務，算路徑，走到目的地，停。這個過程里，工控板只需要處理自己的傳感器數據、自己的運動控制、自己的避障判斷。延遲幾十毫秒，沒人在乎。
但一百臺呢？
一百臺意味著一百個節點同時在跟中央調度服務器通信，同時在互相廣播自己的位置和意圖，同時在接收來自WMS的任務、來自充電樁的狀態、來自安全圍欄的信號。每一臺車不只是"執行者"，它還是"通信節點"。
這時候問題就來了。
傳統的AGV工控板設計思路是什么？夠用就行。一臺車配一塊板，跑本地任務，通過Wi-Fi或者4G跟調度中心連一下。單機看著挺好，延遲20ms，丟包率0.1%，完美。
但當你把一百塊這樣的板連到同一個網絡里，奇跡發生了：通信延遲從20ms跳到200ms，丟包率從0.1%飆到3%，調度指令到達車端的時候，車已經走出半米了。
半米，在AGV的世界里，就是一次刮擦、一次急停、一次產線中斷。
這就是"單點架構"的致命傷：它假設自己永遠是一個人在跑。但實際上，它一上線就是一百個人擠在一條走廊里。
李哲后來跟我說了一句話，我一直記著："我們最大的失誤，是用了一百個孤島去拼一個大陸。"
后來這個項目換了供應商。
新方案的核心不是把工控板的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"，把調度邏輯從"輪詢"改成"事件驅動"，把底層系統從"軟實時"換成"硬實時"。
這些改變，可能只是換一塊為集群設計的工控板，改幾行通信協議的代碼。
但它決定了你的車隊，是從五十臺開始發抖，還是從一百臺開始起飛。
你的調度中心，現在安靜嗎？
如果不安靜，也許該換一種方式讓它安靜了。
-20250623144437.png)
