當一萬個 AI Agent 工作 88 小時，企業還能只用模型能力評估 AI 嗎？
當一萬個 AI Agent 工作 88 小時，企業還能只用模型能力評估 AI 嗎？
InfoAI Decision Brief
OpenAI 的 Navier–Stokes 實驗提出一個新的企業 AI 問題：當模型、Agent、運算時間、工具與驗證機制組成一套系統，真正該衡量的可能不再只是模型有多強，而是整套系統最後能完成什麼。
OpenAI 的 Navier–Stokes 實驗提出一個新的企業 AI 問題：當模型、Agent、運算時間、工具與驗證機制組成一套系統，真正該衡量的可能不再只是模型有多強，而是整套系統最後能完成什麼。
企業評估 AI，長期以來有一個很自然的起點：先看模型。
哪個模型推理能力更強？哪個 benchmark 表現最好？速度多快？每百萬 token 成本多少？
這些問題仍然重要。但 OpenAI 最新公開的一項數學研究，讓另一個問題變得更難忽略：
如果 AI 可以被配置成大量 Agent，持續工作數十小時，使用工具、保留狀態並接受形式化驗證，企業還能只用模型本身來判斷 AI 能做什麼嗎？
如果 AI 可以被配置成大量 Agent，持續工作數十小時，使用工具、保留狀態並接受形式化驗證，企業還能只用模型本身來判斷 AI 能做什麼嗎？
9 月 8 日，OpenAI 公開一套由其內部 AI 系統產生的納維－斯托克斯方程（Navier–Stokes equations）存在性與光滑性問題解答，以及 Lean 形式化證明。這是克雷數學研究所（Clay Mathematics Institute）的「千禧年大獎難題」之一。
OpenAI 對這項成果使用的措辭是 proposes a solution，提出一套解答。目前仍有待數學界進一步獨立檢驗，因此不能直接說 AI 已經解決了這個難題。
但即使先不判斷最後的數學結論是否成立，這套研究方式本身已經值得企業決策者注意。
根據 OpenAI 的說法，這項工作使用一個仍在訓練中的下一代內部模型，動用約 10,000 個協作 AI Agent，持續運作約 88 小時，最後產生書面證明與 Lean 形式化證明。
這和我們熟悉的 ChatGPT 使用方式很不一樣。
它不是問 AI 一個問題，等幾秒鐘取得答案，而是給 AI 一個目標、足夠的運算資源與工作時間，讓整套系統持續探索，直到產生可以被檢查的結果。
這可能改變企業評估 AI 能力的基本單位。
模型能力，不再足以代表整套 AI 系統的能力
目前很多企業做 AI 選型，背後其實存在一個隱含假設：
Model Capability ≈ Usable AI Capability
Model Capability ≈ Usable AI Capability
因此企業會比較 GPT、Claude、Gemini 或其他模型的推理能力、benchmark、速度與價格。
但 OpenAI 這次的實驗提出另一種可能。
當模型被放進大量 Agent、長時間運算、工具使用與驗證機制組成的系統後，企業真正取得的能力，可能無法再從單一模型測試直接推估。
可以把它暫時理解成一個 Decision Model，而不是工程公式：
System Capability = Model × Agent Architecture × Runtime × Tools × Verification
System Capability = Model × Agent Architecture × Runtime × Tools × Verification
模型仍然重要，只是不再是唯一變數。
所以企業未來做 AI PoC，如果還只是把相同提示詞分別交給不同模型，看誰回答得最好，可能愈來愈不足以代表真正的 AI 系統能力。
更實際的問題會變成：
在我們願意提供的時間、成本、工具權限與驗證條件下，這套 AI 系統最後能完成什麼？
在我們願意提供的時間、成本、工具權限與驗證條件下，這套 AI 系統最後能完成什麼？
雲端平台已經開始為「長時間工作的 AI」改變
這並不只是研究實驗才會遇到的問題。
AWS 的 Amazon Bedrock AgentCore Runtime 已經開始支援需要持續數小時甚至數天的 Agent 工作，包括狀態保存、停止與恢復、工作階段管理，以及多 Agent 協作。
這反映出一個結構變化。
傳統生成式 AI 比較接近：
Request → Compute → Response
但 Agent 工作可能持續很久，而且會中斷、恢復、使用工具、重試與驗證。
一旦 AI 從「回答問題」進入「持續工作」，企業要管理的就不只是模型 API，而是整套執行環境。
因此未來評估 Agent 平台時，問題不只是模型多不多、API 好不好用，而可能還包括：
這個平台能不能可靠管理一個工作數小時甚至數天的 AI？
但 Agent 能做更多，不代表企業就得到更多
這也是最容易被忽略的一層。
MIT Sloan 針對超過 10 萬名 GitHub 開發者的研究發現，AI 工具可以大幅提高程式開發活動，但當成果進入專案完成與實際推出階段後，效果明顯減弱。
原因並不難理解。
AI 可以快速增加程式碼產出，但後面仍然存在程式碼審查、整合、測試、資安與部署流程。
如果 Agent 每天可以完成 50 個功能，但 QA、資安與部署只能驗證其中 10 個，Agent capacity 就不等於 business capacity。
AI 提高一段流程的產能後，瓶頸往往會移到下一個仍需要人類審核、整合或批准的環節。
這意味著，企業下一輪 Agent PoC 不應再只比較模型回答品質，而應同時測試三件事：
完成率、總成本、可驗證性。
完成率、總成本、可驗證性。
下一個 AI 成本單位，可能不是 Token
這也會改變企業衡量 AI ROI 的方式。
今天企業很習慣比較每百萬 token 成本。
對 Chatbot 或短時間推論而言，這仍然合理。
但如果一個 Agent 任務可能持續數小時或數天，中間包含大量推理、工具呼叫、重試與驗證，單純比較 token 價格就愈來愈難回答真正的商業問題。
企業真正想知道的可能是：
Cost per Completed Outcome
完成一個結果到底花多少錢？
Cost per Completed Outcome
完成一個結果到底花多少錢？
再往前一步：
Cost per Verified Outcome
產生一個已被確認、可以真正投入使用的結果，總成本是多少？
Cost per Verified Outcome
產生一個已被確認、可以真正投入使用的結果，總成本是多少？
這些目前還不是企業 AI 採購的通用指標，但對長時間自主 Agent 而言，它們可能比 token 單價更接近真正的經濟價值。
最先高度自主化的工作，可能不是最簡單的工作
這裡還有一個更重要的判斷。
數學有形式化證明。
軟體有測試。
財務有對帳。
製造有良率與量測數據。
這些工作的共同特性，是結果可以在相當程度上被客觀檢查。
但市場策略、品牌定位、組織管理或商業談判不同。AI 可以產生一個看起來很完整的答案，企業卻未必有一套同樣明確的機制判斷它究竟對不對。
因此，高度自主 Agent 最早真正產生企業價值的地方，未必是工作最簡單的地方，而可能是成果最容易被客觀驗證的地方。
這可能比「Agent 可以自主多久」更值得企業優先思考。
因為當 AI 自主性提高，真正限制規模化的問題，很可能從：
AI 能不能做？
逐漸轉成：
我們能不能知道它真的做對了？
所以，企業現在不需要因為 OpenAI 動用了約一萬個 Agent，就開始規劃自己的萬名 Agent 團隊。
比較值得做的是重新設計 AI PoC。
優先尋找具有明確驗證迴路的工作，測試 AI 能不能從頭完成、完成一次需要多少總成本、下游流程能不能承接，以及最後有沒有可靠的方法確認結果可以使用。
OpenAI 的 Navier–Stokes 解答最後能否獲得數學界正式認可，仍然需要進一步檢驗。
但它已經提出一個更實際的企業問題：
下一階段的 AI 競爭，可能不只是誰取得更強的模型，而是誰能建立一套讓 AI 持續工作，而且知道它什麼時候真的把工作做對的系統。
下一階段的 AI 競爭，可能不只是誰取得更強的模型，而是誰能建立一套讓 AI 持續工作，而且知道它什麼時候真的把工作做對的系統。
作者＝InfoAI 編輯部
你不需要讀完所有 AI 新聞。你需要掌握的是：哪些變化值得關注、哪些應用值得理解、哪些風險不能忽略，以及這些訊號可能如何影響企業決策。
訂閱 InfoAI 電子報，把全球 AI 訊號，轉化為更清楚的商業判斷。
InfoAI Line 群提供最新文章發佈通知，讓你不用每天上網查看，也能快速掌握新上線的 AI 產業解讀、應用案例與知識內容。
版權聲明與授權須知
本內容由 InfoAI 擁有著作權。如有引用、轉載或任何商業用途的需求，請來信聯絡： contentpower688@gmail.com。
AI 協作與人工編輯聲明
本文由 InfoAI 編輯部進行主題判斷、內容策劃、事實查核與文字編輯，並使用 AI 工具協助資料整理與內容製作。最終觀點、內容取捨與發佈版本均由人工編輯確認。
你不需要讀完所有 AI 新聞，你需要知道的是：
有哪些變化值得注意，可能會如何影響你的產業、工作與決策。