arXiv 在 11 月 5 日刊出論文 2611.05392，題為《Uncertainty-Aware Resource Orchestration for Agentic AI Systems》。論文第一句就點明：由大型語言模型驅動的代理式系統，會動態呼叫工具、把觀察寫入記憶、反覆迭代，直至任務完成或資源預算耗盡。這類流程的需求，在派發的一刻仍是未知數。

問題的核心並非模型不夠強，而是排程器假設流程圖完全已知。論文指出，現有排程器要求完整的流程圖，邊緣資源管理方法則依賴參數化或平穩需求模型，兩者都對不上代理式流程的未知、非平穩需求。論文把這個缺口形式化，但未提供實測數據。

派發時未知的算力需求

論文把代理式流程與傳統固定流程圖的工作流明確區分。傳統工作流的結構在派發前已經寫死，算力與頻寬可以按圖估算；代理式流程則在執行中才逐步展開，中間觀察與隨機抽樣共同決定下一步動作。同一個任務，兩次執行的資源消耗可以相差很遠。

論文指出，這類流程的總體運算、頻寬與端到端延遲需求，在派發時並未知曉，而是在執行時由中間觀察與隨機抽樣逐步形成，呈現重尾、多峰的隨機變數。重尾意味着偶爾出現極端長的執行；多峰則意味着需求會在多個水平之間跳動，而非圍繞平均值波動。

這種不確定性對基礎設施編排器構成直接壓力。論文稱，編排器要在派發時決定預留多少運算與頻寬，但手上的資訊只有任務描述，並無執行軌跡。排程器愈假設需求平穩，愈容易在真實負載下失準。

預留不足與預留過剩的兩難

論文把取捨講得很直白：預留不足，執行中途會被限流，甚至違反截止時間；預留過剩，則浪費稀缺的邊緣或雲端容量。對成本敏感的部署而言，兩種浪費都會直接反映在帳單上，差別只在於一是服務質素受損，二是資源白白閒置。

論文將這個取捨定義為「不確定性感知的代理式編排問題」，目標是在派發時預留運算與頻寬分配。形式化的價值在於把「幾多才夠」由經驗判斷變成可計算的目標函數，但論文只給出問題框架，未披露實際調度演算法或基準測試結果。

反面意見在此：把問題形式化，距離可落地的調度方案仍遠。論文未提供實測數據，亦未說明在真實雲端環境下，不確定性感知編排相對現有排程器的成本差距。香港企業若在雲端跑代理式流程、按固定規格買預留算力，採購合約能否加入彈性調整條款，內部排程工具是否支援執行中重新分配資源，都是論文未回答、但採購前必須問清楚的問題。

現有排程器為何接不上

論文點名兩類現有工具都對不上代理式流程。第一類是常規排程器，要求派發前拿到完整流程圖，但代理式流程的下一步動作要等中間觀察回來才決定，根本無法預先畫出全圖。第二類是邊緣資源管理方法，靠參數化或平穩需求模型做估算，前提是需求分佈穩定、可參數化，與代理式流程的未知、非平穩特性直接衝突。

這個錯配不是調參可以解決。排程器的輸入格式本身就假定「任務圖已知」，代理式流程交不出這張圖；邊緣方法的模型假定「需求平穩」，代理式流程的資源曲線偏偏是重尾、多峰。兩邊的假設與現實之間隔着一道結構性缺口，換算法、加緩衝都補不上。

論文因此把目標定在派發時就預留運算與頻寬分配，而非等到執行中途才補救。這個方向等於承認：代理式流程的資源需求無法在執行中準確追蹤，只能在派發一刻用不確定性模型做概率性預留。問題是，預留的依據本身也是估算，估算錯了照樣限流或浪費。

形式化之後仍欠實測

論文把問題形式化為不確定性感知的代理式編排問題，但素材未見真實負載下的基準測試，也無與現有排程器的對比數字。形式化定義了變量與約束，卻未回答關鍵一問：在實際雲端或邊緣環境中，這套預留策略比現有做法好多少？沒有實測，企業無法判斷是否值得改動排程基建。

代理式流程的隨機性來自語言模型抽樣，同一個任務每次執行的資源曲線可以不同。論文將此描述為重尾、多峰隨機變數，但重尾到什麼程度、多峰有幾個峰值，摘要均未披露。這些分佈參數直接決定預留模型要多複雜，也決定它在生產環境中是否站得住腳。

反面意見值得認真對待：若企業把流程改為更嚴格的步驟上限與預算封頂，不確定性會收窄，論文的複雜模型未必必要。步驟上限等於把開放式代理流程拉回接近固定圖的形態，資源需求變得可估，用簡單的靜態預留加少量緩衝可能已足夠。論文未討論這個折衷，但對成本敏感的部署而言，這可能是更務實的出路。

對香港企業而言，論文的價值在於把「按固定規格買預留算力」的風險講清楚：代理式流程的資源需求在派發時未知，預留不足會被限流，預留過剩則閒置。本地數據中心用地與電力成本高，兩種浪費都直接推高單位推理成本。採購合約能否加入彈性調整條款、內部排程工具是否支援執行中重新分配資源，是資訊科技部門要問的具體問題。

但論文未提供實測數據，香港團隊暫難直接照搬。更現實的做法，是先盤點哪些代理式流程可以加上步驟上限與預算封頂，把不確定性收窄到可管理範圍，再考慮是否引入不確定性感知的預留模型。形式化是第一步，距離可落地的調度方案仍遠。