看到一篇研究把 LLM 用在生產排程，我覺得最值得記住的不是多 agent 這個流行詞，而是它把一個常被混為一談的問題拆開了：數學 formulation 是否正確，和程式能不能真的執行，是兩個不同的驗證階段。

研究比較 direct LLM、single agent 加 MCP，以及 multi agent 加 MCP，在六個工業排程問題上共生成 162 次，涵蓋 GPT 5、Gemini 2.5 Pro 和 DeepSeek V4 Pro。若標準是「模型正確而且程式可執行」，direct LLM 只有 14.8%，single agent 是 33.3%，multi agent 提升到 59.3%；在前四個較不複雜的問題，multi agent 達到 80.6%。數字看起來很漂亮，但嚴格來說，改善的主要來源不一定是模型突然更會做數學，而是流程降低了 implementation 和 execution error。直接呼叫模型時，常會得到夾雜說明文字、重複版本或無法執行的 Python。

這個區分對台灣製造和營運團隊很實用。很多導入討論先問「要不要上 multi agent」，卻沒有先定義每個階段的輸出契約。比較穩健的做法是把流程切成三關。第一關只產出變數、目標函數、限制式與假設，並要求逐項對應現場規則。第二關只負責把已核准的 formulation 寫成指定 solver 的程式，不能自行改動商業邏輯。第三關用測試資料執行，檢查語法、solver status、限制式是否被滿足，以及結果是否符合人工可解釋的基本條件。每一關都要有固定格式，讓下一關不必猜測上一關的意圖。

如果是工廠或物流團隊，我會先做一個低風險實驗，而不是直接把整個排程交給 agent。挑一個已有人工解法、範圍小且可回溯的問題，例如單一產線的一週排程。保留目前規則和基準解，建立兩組流程：一組是單 agent 直接產程式，另一組把建模、文件查詢和 coding 分開。MCP 的價值在這裡也很具體，它可以讓 coding agent 讀到 solver documentation，而不是依賴模型記憶 API。比較時不要只看最佳目標值，還要記錄一次成功執行率、人工修改行數、錯誤類型、token 成本和驗證所需時間。

這篇研究也提醒我們不要把 59.3% 解讀成「已經可以自動化排程」。難度較高的 intralogistics 仍然是開放問題，multi agent 也會增加 token 與協調成本。對實務而言，最合理的第一步可能是讓 agent 產生候選 formulation 和測試案例，由工程師核准後才進入正式求解。換句話說，agent 的價值不只在多一個角色，而在於把不可驗證的文字生成，改造成有文件、有規格、有測試的工程管線。這個觀念通常比換哪個模型更能決定最後能不能上線。