AI Agent 開始學會「改企業系統」：新研究讓 LLM 提方案、跑實驗，再用 KPI 決定能不能上線

大型語言模型已經很會回答問題，也越來越會寫程式。

但企業真正想知道的下一個問題可能更加危險：

如果主管直接告訴 AI 一個營運目標，它能不能自己判斷該修改哪一套企業系統，改完之後還確認公司真的運作得更好？

這正是 arXiv 論文《Adapting to Evolving Requirements: Agentic AI for Retail Supply Chain Operations》試圖回答的問題。

研究團隊來自香港科技大學、中國科學技術大學與新加坡國立大學，並與一家大型零售企業合作，從實務人員訪談中取得 100 個真實情境導向的倉儲需求。

但這篇研究最值得注意的地方，不是它又做了一個『WarehouseGPT』。

相反地，研究者花了大量力氣限制 AI。

LLM 不可以自由修改整個企業系統。

它只能從工程師事先批准的修改介面中挑選可能方案，再把這些方案真正放進倉庫決策流程裡執行，最後用營運 KPI 判斷：

這次修改到底只是程式可以跑，還是真的讓企業變得更好？

這個差別，可能正是 AI Agent 未來能不能真正進入企業核心系統的關鍵。

一個修改正確，不代表整間倉庫會變好

零售倉庫並不是一套單一演算法。

從補貨訂單進入 Distribution Center 開始，商品可能需要依序經過資料整理、分配、Packing、設備排程與 Dispatching，最後才送往各門市。

每一層甚至可能採用完全不同的技術。

例如 Packing 可以使用數學最佳化模型與 Heuristic；Dispatching 則可能依靠 Scheduling Algorithm；另外一些決策可能只是 Ranking Policy 或 Configuration Parameter。

問題是這些模組彼此不是獨立的。

上游做出的結果會直接變成下游的輸入。

假設主管突然要求：

『今天第三家門市的貨一定要優先送出去。』

最直覺的方法可能是把第三家門市移到 Packing Queue 最前面。

可是 Packing 順序一改，可能造成 Roll Cage 數量、Pallet Arrangement、AMR 排程、搬運距離與後續 Dispatch Sequence 全部跟著改變。

所以一個修改可能同時符合三個條件：

程式合法。

可以執行。

確實改到主管要求的位置。

但整體營運結果反而變差。

論文因此刻意區分兩件事：

Local Correctness，也就是修改本身是否正確；

以及 System-level Effectiveness，也就是修改經過整套下游流程之後，真正的營運結果是否改善。

這個區分其實非常重要。

因為很多 AI Agent Demo 的終點是：

『程式成功修改，而且沒有 Error。』

但企業真正關心的是：

『改完之後，公司到底有沒有比較好？』

研究者沒有給 AI Root 權限

如果直接讓 LLM 面對一整套企業系統，它可能需要同時決定：

要改哪一個模組？

要改哪一個演算法？

要修改數學模型、程式邏輯還是參數？

數值要改多少？

哪些下游系統會受到影響？

這個搜尋空間不只很大，也非常危險。

因此研究者建立了一套 Graph-Constrained Agentic Framework。

核心是一張在 AI 收到需求以前就已經定義完成的 Reformulation Graph。

這張圖共有四層節點：

Intent ↓ Domain Agent ↓ Coarse Modification ↓ Fine-grained Interface

例如主管提出：

『優先處理某家門市。』

系統可能先解析成：

Intent = prioritize store processing

接著判斷哪些 Domain Agent 和這個目標有關，例如 Packing Agent 與 Dispatching Agent。

再往下選擇：

Store Priority Processing Order Dispatch Sequence Score Weight

等已被工程師批准的修改方式。

最關鍵的限制是：

Reformulation Graph 在需求到來以前就已經固定。

如果某項操作不存在於 Graph 裡，Central Processor 就不能自己創造一個新的操作方式。

換句話說，這不是：

『AI，幫我想辦法改公司系統。』

而比較接近：

『這裡有一組工程師認為安全而且合理的控制桿，你可以判斷該拉哪一根，但不能拆掉控制台。』

一個主管需求，可以同時產生好幾套修改方案

這篇研究另一個很重要的設計，是 One-to-Many Candidate Generation。

因為現實企業問題往往不存在唯一正確答案。

假設目標是：

讓某間門市更快完成出貨。

可能的方法包括：

提高 Packing Priority。

改變 Store Processing Order。

提高 Dispatch Priority。

調整 Scheduling Weight。

或者同時修改 Packing 與 Dispatching。

其中每一種方案在 Local Level 都可能是合理的。

但實際跑完整個 Warehouse Pipeline 之後，結果可能完全不同。

研究中的 Central Processor 因此會保留一條 Primary Route，以及最多兩條 Alternative Routes。

如果最後選到的是 Numerical Interface，例如某個 Priority Weight，系統還會先產生三種強度：

Low Medium High

假設某個 Priority Parameter 原本是 1.0，Agent 可能提出數個在允許範圍內的值。

於是原本只有一個自然語言需求，最後可能變成一組 Candidate Portfolio。

真正有意思的是，研究者沒有再問 LLM：

『你覺得哪個 Candidate 最好？』

而是直接全部執行。

LLM 負責想辦法，Reality Check 交給真正的系統

每個 Candidate 接下來會被送往對應的 Domain Agent。

Domain Agent 根據指定 Route 產生：

Mathematical Reformulation

Code Patch

Configuration Patch

但這些修改不能直接進入執行環境。

它們首先需要通過 Deterministic Validation。

系統會檢查：

修改是否使用合法 Interface。

Parameter 是否仍在事先定義的範圍內。

Hard Constraint 是否被破壞。

產生的 Configuration 或程式是否可以執行。

如果第一次 Validation 失敗，Agent 最多得到一次 Local Repair 機會。

值得注意的是，Repair 不能重新選擇整條 Route。

它只能修正原本 Candidate 的 Patch。

如果第二次仍然失敗，Candidate 就被丟棄。

通過檢查後，系統才真正重新執行被修改的模組，以及所有受到它影響的 Downstream Modules。

所以整個架構更接近：

LLM ↓ Generate Candidates ↓ Deterministic Validation ↓ Real System Execution ↓ Measure KPI ↓ Select Candidate

這和讓 LLM 自己『推理哪個方案效果最好』有本質上的不同。

研究者其實承認一件很現實的事情：

複雜營運系統具有太多耦合關係，LLM 很難只靠文字推理可靠預測一項修改最後會造成什麼結果。

既然如此，不如讓 AI 負責縮小搜尋範圍，再讓真正的執行環境告訴它答案。

還有一道紅線：其他 KPI 最多只能惡化 10%

只最佳化單一 KPI 其實非常危險。

假設主管要求某間門市必須提早出貨，Agent 最簡單的方法可能是把所有資源都讓給它。

目標門市確實會快很多。

但其他 30 間門市可能全部延遲。

如果只看目標 KPI，這仍然會被判定成一次『成功最佳化』。

因此研究設定了一套 System-level Guardrail。

在實驗中，任何受到監控的 System-level KPI 都不能因為修改而惡化超過 10%。

也就是：

Target KPI 必須改善 + 其他重要 KPI 不能超過可接受損失

才算是一個可以被接受的 Candidate。

如果沒有任何 Candidate 同時滿足 Validation 與 Guardrail，系統不會勉強選一個比較不差的答案。

它會保持原始 Configuration 不變，並回傳 Validation 與 Execution Diagnostics。

這一點對企業 AI 特別重要。

因為『什麼都不做』本身應該永遠是一個合法結果。

一個無法安全拒絕修改的 Autonomous Agent，本身就是風險來源。

數值到底該調多少？再交給 Bayesian Optimization

如果主管明確指定：

『把這個值改成 20。』

Agent 當然不需要繼續搜尋。

但更多企業需求是：

『盡量縮短等待時間。』

『提高這家門市的優先度。』

『降低搬運距離。』

這些目標並沒有告訴系統 Parameter 最佳值究竟是多少。

因此論文在候選方案選出後，對符合條件的 Numerical Fine Modification 還可以啟動 Constrained Bayesian Optimization。

前面 Low、Medium、High 三種 Candidate 加上原始設定，會先形成幾個實際測量點。

系統再利用 Gaussian Process 建立一個 Surrogate Model，估計不同 Parameter Value 對 KPI 的影響。

接著使用 Constrained Expected Improvement 決定下一個最值得測試的數值。

它同時考慮兩件事情：

這個 Parameter 有多大機會讓 Target KPI 進一步改善？

以及它有多大機率仍然符合其他 KPI 不得惡化超過 10% 的 Constraint？

然後新數值仍然需要回到真正 Warehouse Pipeline 執行。

觀察結果再加入 Bayesian Optimization 的資料集，持續迭代。

這裡其實形成了一個很有趣的混合架構：

LLM 負責理解自然語言與提出結構性修改。

Operations Research 負責數學與營運問題。

Deterministic Rule 負責安全邊界。

Simulation / Execution 負責 Reality Check。

Bayesian Optimization 則負責搜尋更好的 Numerical Setting。

它不是單純『Multi-Agent』，而比較像 AI、最佳化與傳統企業軟體的混合控制系統。

研究實際測了什麼？

研究使用一套由三個 Domain Agent 組成的 Warehouse Decision Pipeline：

Preprocessing Agent：整理與抽取下游模組需要的營運資料。

Packing Agent：處理 3D Roll-cage Packing 等 Packing 決策。

Dispatching Agent：負責 Equipment Scheduling 與出貨相關決策。

研究團隊與一家大型零售業者合作，透過 Practitioner Interview 取得 100 個 Warehouse Requirements。

這 100 個需求分成 10 類，每類 10 個案例。

Benchmark 中同時包含：

修改路徑很明確的 Requirement；

以及具有多種合理 Reformulation 方法的 Requirement。

研究比較兩套方法。

第一套是 Direct LLM Reformulation。

LLM 看到同樣的 Requirement、System Information、Current Configuration 與可用 Interface，但直接產生 Mathematical、Code 或 Configuration Modification。

第二套則是論文提出的 Graph-Constrained Agentic Framework。

兩者使用完全相同的 Warehouse Instance 與 Downstream Pipeline 執行，所以最後可以直接比較營運結果。

Base LLM 則包含：

GPT-5.5 Qwen-3.8-flash DeepSeek-v4-flash

三個指標：CR、ΔKPI 與 ESR

研究並沒有只看 Code 能不能跑。

第一個指標是 Correctness Rate，CR。

要被判定 Correct，需要同時滿足：

Legal Executable Placement Correct

也就是修改是否合法、能否執行，而且有沒有真的改到應該修改的 Component。

第二個指標是 Normalized KPI Improvement，ΔKPI。

它比較原本 Configuration 與 Reformulation 執行之後的 Requirement-relevant KPI。

如果 KPI 是越小越好，例如 Completion Time，就會調整公式方向，讓正的 ΔKPI 永遠代表改善。

第三個也是最重要的指標，是 End-to-End Success Rate，ESR。

它要求：

Correctness = 1 AND ΔKPI > 0

才算成功。

因此一個程式修改即使完全合法而且執行成功，只要最後沒有改善主管真正想改善的 KPI，ESR 就會判定失敗。

這也是這篇研究真正想修正的 Agent 評估方式。

整體成功率大約提高 7 個百分點

使用 GPT-5.5 時：

Direct LLM： CR 89% Mean ΔKPI -0.310% ESR 72%

Agent Framework： CR 91% Mean ΔKPI +0.319% ESR 79%

使用 Qwen-3.8-flash 時：

Direct LLM： CR 91% Mean ΔKPI +2.886% ESR 76%

Agent Framework： CR 96% Mean ΔKPI +0.149% ESR 82%

使用 DeepSeek-v4-flash 時：

Direct LLM： CR 93% Mean ΔKPI -0.407% ESR 75%

Agent Framework： CR 96% Mean ΔKPI +0.659% ESR 83%

因此三個模型的 ESR 都提高，平均增加約 7 個 Percentage Points。

不過這裡有一個非常值得注意的細節。

Qwen 的 Direct LLM Mean ΔKPI 高達 +2.886%，反而遠高於 Agent Framework 的 +0.149%。

這代表不能簡單說 Agent Framework 在所有指標上都全面勝利。

作者指出，Qwen Direct LLM 的較高平均值似乎主要由少數改善幅度特別大的 Reformulation 拉高，而不是整體案例都更穩定。

換句話說：

Direct LLM 有時可能押中一個非常好的方案。

Agent Framework 則比較像控制波動，讓更多 Requirement 能穩定取得正改善。

對企業系統而言，後者往往比偶爾出現一次超高收益更加重要。

最有價值的結果藏在 Group A 與 Group B

如果只看到『ESR 平均提高 7%』，其實還沒有看到這篇論文最重要的結果。

研究者把 Requirement 按難度進一步分成兩種。

Group A 是 Single Modification Requirement。

主管已經說得很明確，Intent 與應該修改的位置相對清楚。

例如：

『把某個 Parameter 改成這個值。』

這類問題根本不需要太複雜的 Agent Search。

Group B 則不同。

主管只描述 Business Goal，但存在多個合理的 Fine-grained Modification。

例如：

『讓這家門市更早完成出貨。』

這時候到底應該調 Packing、Dispatching、Priority Weight，還是同時改兩層，並沒有唯一答案。

使用 DeepSeek 作為 Base LLM 時，Group A 的結果是：

Direct LLM：CR 96%、ESR 96%

Agent Framework：CR 94%、ESR 94%

Agent 不只沒有比較好，甚至略低。

這個結果非常重要。

它證明 Multi-Agent 或複雜 Agent Architecture 並不是任何問題都值得使用。

如果答案已經很明確，Direct LLM 已經足夠好，多加一層 Routing 與 Candidate Generation 反而可能增加新的 Failure Point。

真正的差距出現在 Group B。

Direct LLM： CR 90% ESR 54%

Agent Framework： CR 98% ESR 72%

Correctness 很有意思。

Direct LLM 已經有 90% 的修改在技術上是正確的。

可是只有 54% 最後真的改善了 Operational KPI。

也就是大量修改呈現：

Code 沒錯。

位置沒錯。

邏輯合法。

結果不好。

Agent Framework 則透過產生多個合理 Candidate 並實際執行比較，把 ESR 從 54% 推到 72%，提高 18 個百分點。

這可能才是整篇研究最有價值的發現：

AI Agent 的優勢未必是它能比普通 LLM 更聰明地寫 Code。

它可能是能夠在『有很多答案都看似合理』的問題裡，多測幾條路，然後讓環境決定哪條真的有效。

論文還真的展示了一次「主管講人話，Agent 改倉庫」

研究提供了一個完整 Case Study。

主管要求：

『倉庫 8:00 開始工作，第三家門市的 Packing 和 Dispatching 必須在 10:30 前完成。』

這句話看起來很簡單。

但 AI 第一件事情甚至不是改程式。

它必須先理解：

『第三家門市』究竟是誰？

當時 Store Sequence 是：

402 484 473 310 ...

所以 Central Processor 先把自然語言中的『第三家』Ground 成 Store 473。

接著它把營運目標解析成：

讓 Store 473 在 Deadline 前完成。

然後發現 Completion Time 同時受到上游 Packing 與下游 Dispatching 影響，因此一次啟動：

Packing Agent + Dispatching Agent

Routing 最後落在 Store Processing Priority 這組已被允許的 Interface 上。

Packing Agent 做了什麼？

原本順序：

[402, 484, 473, 310, ...]

被重新排列為：

[473, 402, 484, 310, ...]

也就是直接把 Store 473 移到 Processing Sequence 最前方。

但研究特別強調，它沒有修改原本 Packing Model 的 Objective Function、Hard Constraints 或 Extreme-point Heuristic。

AI 改的是已被允許的控制介面，而不是把整個最佳化模型拆掉重寫。

Dispatching Agent 也一起提高 473 的優先權

接著 Store 473 在 Dispatching 系統裡取得最高 Priority Rank。

它相關的 Roll Cage 因此會在多個 Decision Point 得到優先處理，包括 Initial Assignment、Pair Replacement 與 Online Execution。

但這個 Priority 並沒有凌駕真正的營運限制。

例如：

Precedence Constraint Pallet Capacity AMR Availability

仍然不能被繞過。

所以這比較像：

在規則允許的範圍裡盡量幫 Store 473 插隊。

而不是：

Store 473 最大，其他 Safety Constraint 全部取消。

207.6 分鐘，直接降到 52.7 分鐘

Warehouse 從 8:00 開始運作。

因此 10:30 Deadline 等於 150 分鐘。

Baseline Configuration 下，Store 473 完成時間約為：

207.6 分鐘。

也就是大約 11:27 才完成，明顯超過 Deadline。

經過 Priority Reformulation 後：

Store 473 Completion Time 降至 52.7 分鐘。

大約 8:53 就完成。

Deadline 因此成功滿足。

但這個優先權不是免費的。

其他 System KPI 也發生了一些改變。

Number of Roll Cages： 284 → 284

Average Pairwise Distance： 12.84 → 12.84

Makespan： 12,915 → 13,710

Pallet Switches： 4,279 → 4,296

Makespan 約增加 6.2%。

也就是為了讓 Store 473 大幅提前，整體作業完成時間確實付出了一些代價。

但因為這個惡化幅度仍然低於研究設定的 10% Guardrail，其他 KPI 也沒有超標，因此系統接受這項 Reformulation。

這個案例非常漂亮地呈現了企業 Optimization 和一般 Benchmark 最大的不同。

真正的問題通常不是：

『找到全世界最佳的 Schedule。』

而是：

『現在商業需求變了，我願意犧牲多少其他效率來滿足它？』

這還遠遠不是「AI 自己管理整間倉庫」

雖然結果有意思，但這篇研究仍然有很明顯的限制。

首先，Benchmark 只有 100 個 Requirements。

而且都來自同一類 Warehouse Decision Environment。

因此不能直接把 83% ESR 解讀成：

『AI 已經有 83% 機率可以安全修改任何企業系統。』

研究完全沒有證明這件事。

第二，實驗主要只有三個 Domain Agents：

Preprocessing Packing Dispatching

真正的大型 Supply Chain 還可能包含 Demand Forecasting、Inventory、Procurement、Picking、Labor Scheduling、Transportation、Returns 等大量模組。

模組數量上升後，Reformulation Graph 與 Downstream Interaction 都會快速變複雜。

第三，也是最重要的限制之一：

Reformulation Graph 是由人事先建立的。

這套系統之所以安全，很大程度正是因為 Domain Expert 已經先替 AI 定義：

哪些 Interface 可以碰。

Parameter Range 是多少。

哪些 Route 合法。

哪些 Hard Constraint 不能破壞。

哪些 KPI 需要監控。

所以這不是把 Agent 接到公司的 ERP，隔天它就會自行理解全部 Architecture。

前期仍然需要大量 Domain Engineering。

KPI 自己選錯，也可能最佳化錯方向

論文裡還有另一個值得警戒的地方。

Managerial Requirement 最後需要對應一個 Requirement-relevant KPI。

研究使用 Judgment LLM 從預先定義好的 KPI Set 中判斷哪一個最符合主管需求。

也就是說，真正的最佳化目標仍有一個 LLM Interpretation Layer。

如果 Manager 說：

『我要讓門市更穩定地收到貨。』

到底應該對應 Average Completion Time、Worst-case Delay、On-time Rate，還是另一個 KPI？

如果 Judgment LLM 一開始就選錯，後面的 Candidate Search 可能非常努力地最佳化錯誤目標。

論文用 predefined KPI set 限制範圍，已經比讓 LLM 自己創造 KPI 安全很多，但 Goal Alignment 仍然不是完全解決的問題。

ESR 83% 也不能理解成「83% 都帶來巨大改善」

End-to-End Success Rate 的定義是：

修改正確 + ΔKPI > 0

所以只要 KPI 比原始 Configuration 有任何正向改善，就算 ESR Success。

理論上 +0.01% 也符合條件。

因此論文的 79～83% 應該理解為：

約八成 Requirement 能產生合法、可執行、位置正確，而且 Target KPI 至少朝正方向移動的 Reformulation。

而不是：

八成 Requirement 都取得巨大的商業效益。

這個差別非常重要。

這篇研究真正指出的，也許是企業 Agent 的未來長相

現在談 Autonomous Agent，很容易讓人想像一個 AI 擁有完整權限：

收到目標。

自己分析。

自己改 Code。

自己 Deploy。

但這篇研究呈現的路線幾乎相反。

越接近企業核心系統，AI 的自由度反而越小。

可能真正可行的企業 Agent 架構是：

Human defines boundaries ↓ LLM interprets intent ↓ Graph constrains possible actions ↓ Agent proposes several candidates ↓ Deterministic rules verify legality ↓ Real system / simulation evaluates consequences ↓ KPI decides whether it helped ↓ Guardrail checks collateral damage ↓ Only then accept the change

也就是說，AI Agent 最重要的能力不一定是『一次猜對答案』。

而是：

知道哪些事情可以試。

提出少量合理方案。

把實際結果拿回來比較。

錯了就不要動 Production。

這和很多人想像的 AGI 式 Autonomous System 很不一樣，卻可能更接近企業真的願意採用的形式。

從 Supply Chain 再往外看，這個架構可以套到很多領域

雖然論文只測試 Warehouse Operation，但它的 Architecture 具有更廣泛的意義。

例如 Cloud Infrastructure。

主管說：

『降低這個服務的 Cloud Cost，但 P95 Latency 不能增加超過 5%。』

Agent 可以提出：

調整 Instance Type。 修改 Autoscaling Threshold。 改變 Cache Policy。 調整 Replica Count。

然後放進 Staging / Simulation 執行，用 Cost、Latency、Error Rate 等 KPI 判斷結果。

製造系統也類似。

主管說：

『讓這條產線提高 Throughput，但 Defect Rate 不能惡化。』

Agent 不需要自由重寫 PLC，而是只能調整工程師批准的 Parameter 與 Scheduling Policy，再經 Simulation 或 Digital Twin 驗證。

甚至金融風控、資料中心能源管理與大型 Logistics Network 都可以採用相同概念。

這也讓這篇論文真正有趣的地方超出 Retail Supply Chain。

它提供了一種企業 AI Agent 很可能需要的設計哲學：

不要要求 LLM 成為 Oracle。

讓它成為 Candidate Generator。

真正的答案交給可以測量的世界。

Tech English 專有名詞

1. Reformulation Graph（重構圖／重新表述圖）：事先定義哪些營運意圖、Domain Agent、修改類型與具體 Interface 可以互相連接的結構圖。它限制 LLM 可以選擇的修改範圍，避免 Agent 自行發明未被批准的操作。

2. Domain Agent（領域代理）：負責特定企業模組的 Agent，例如 Packing Agent 或 Dispatching Agent。它保留該模組的數學模型、執行方法、可修改介面與 Validation Rules，而不是讓中央 LLM 直接控制全部系統。

3. Deterministic Validation（確定性驗證）：不依賴 LLM 主觀判斷，而使用固定規則檢查 Parameter Bounds、Hard Constraints、Interface Legality 與 Executability。相較於再問另一個 LLM『這樣安全嗎』，結果更可預測。

4. End-to-End Success Rate, ESR（端到端成功率）：本研究的重要指標。只有 Reformulation 技術上正確，而且經完整下游流程執行後 Requirement-relevant KPI 確實改善，才算一次成功。

5. Guardrail（護欄／安全限制）：預先設定不可突破的營運邊界。本研究要求受監控的 System-level KPI 不得惡化超過 10%，避免為了最佳化單一目標造成嚴重副作用。

6. Constrained Bayesian Optimization（受限制貝葉斯最佳化）：對無法直接求導或成本很高的 Black-box Function，用歷史測試結果建立 Surrogate Model，再挑選最值得測試的下一個 Parameter，同時估計它符合安全 Constraint 的機率。