2026 年，Vibe Coding、AI Coding Agent 與各種 Agentic Workflow 快速進入企業。AI 不再只是回答問題，而是開始規劃任務、反覆推理、呼叫工具、存取知識，甚至調度其他 Agent。
當 Agent 能做的事情愈來愈多，一個新的管理問題也開始浮現：
企業究竟要用多少 AI 資源，才能完成一項工作？
Gartner 在 2026 年 8 月提出「Inference Paradox」，預測到 2028 年，每個 Agentic Workflow 的 AI inference cost 可能增加超過五倍。
值得注意的是，這個弔詭並不只是因為模型價格變化。新一代模型不只單價下降，也能用更少的 Token 完成同樣的工作，單位工作的 Token 成本因此持續改善，過去成本過高而難以落地的複雜工作流開始變得可行；但企業一旦大量導入，多次推理、工具調用與 Agent 之間的協作，又會快速放大整體資源消耗。真正的問題因此不是單次推論多少錢，而是一項工作究竟需要多少次推論與多少資源才能完成。
這裡消耗的也不只是 Token。AI Agent 真正進入企業流程之後，牽動的是模型、Memory、Compute、Network、Storage，甚至進一步延伸到 Power 與 Cooling。
所以企業真正需要回答的問題，正逐漸從：
「我們要用哪一個 AI？」
轉變成：
「什麼工作，值得配置什麼樣的 AI 資源？」
這不只是成本問題，而是一個 Architecture Decision。
從企業效用往下反推 AI 資源
過去企業談 AI 架構，經常從技術開始：要用 GPT、Claude 還是 Gemini？要不要導入 RAG？是不是應該部署 Local LLM？需要多少 GPU？
但企業導入 AI 的目的不是使用模型，也不是購買 GPU，而是解決企業問題、改善流程或創造新的服務。
因此，本文把這組提問順序稱為 AI Architecture Map，希望從另一個方向思考 AI 架構：先確認企業需要產生什麼效用（商業目的），再一層一層往下反推需要的 AI 能力、運算與基礎資源，也希望藉此協助 CIO 做更適用的架構規劃。
AI Architecture Map 分成五層：
|
層級 |
主要內容 |
回答的問題 |
|
L5 應用 |
Business Scenario、Decision、Automation、Service |
AI 要產生什麼企業效用？ |
|
L4 AI 流程規劃 |
Platform、Agent、Orchestration、Routing、Policy |
Agent／AI 如何協作？ |
|
L3 AI 能力資源 |
Frontier Model、LLM、SLM、Knowledge、RAG |
需要哪些模型、知識與 RAG？ |
|
L2 運算資源 |
Compute、GPU、ASIC、FPGA、NPU、Memory |
需要多少 Compute / Memory？ |
|
L1 基礎資源 |
Power、Cooling、Network、Storage |
基礎資源能否支撐？ |
這五層建立的是一條從 Business Value 到 Resource 的因果鏈。
先從 L5 問企業到底想產生什麼價值；到了 L4，再設計需要什麼流程、多少 Agent，以及哪些工作其實可以由 Workflow、RPA 或企業系統完成。接著到 L3，才決定需要 Frontier Model、LLM、SLM、企業 Knowledge 或 RAG；再往下判斷 L2 所需要的 Compute 與 Memory，以及應該部署在 Cloud、Local 或 Edge；最後確認 L1 的 Power、Cooling、Network 與 Storage 能不能支撐。
即使企業以 Cloud 為主，L1 也不會消失，只是換一種形式出現：Network 決定資料能不能即時送到模型面前，Storage 則隨著 Knowledge 與 RAG 的累積持續膨脹。真正會讓 Power 與 Cooling 變成限制條件的，是決定自建 GPU，或把推論放進廠區、機房與終端設備的時候。換句話說：
不是先買 AI 資源，再尋找應用；而是先確認企業想達到的效用，再反推需要多少 AI 資源。
不是每一個工作都需要最強模型
Agent 時代尤其需要重新思考這件事。
如果一條企業流程同時有數個 Agent，而每個 Agent 又需要多次推理、查詢知識、呼叫工具與交換資訊，一項工作很容易產生大量模型呼叫。
但每一個步驟真的都需要付費的 Frontier Model 嗎？
例如客服流程中的問題分類，可能小模型就能處理；查詢訂單只需要 API；企業知識搜尋可以使用 RAG；只有遇到跨資料來源、規則衝突或複雜例外時，才真正需要 Frontier Model。
把同一條客服流程一路往下推，五層才會從概念變成可操作的東西。L5 要的是把首次回覆時間與人工轉接率降下來；L4 決定由幾個 Agent 分工，以及哪些步驟其實交給既有的工單系統就好；L3 把分類與摘要交給 Local SLM、知識查詢走 RAG、跨來源的複雜例外才上 Frontier Model；到了 L2，就要估算這些工作在尖峰時段需要多少推論算力與 Memory，以及應該部署在 Cloud 還是 Local；如果選擇自建，L1 的電力、散熱與網路頻寬，就會直接決定這個架構做不做得起來。
所以 AI Architecture Map 在 L4 與 L3 之間有一個重要原則：
先判斷工作，再決定模型。
而不是先選一個最強模型，再把所有工作都交給它。
而這個原則還必須往下延伸。把複雜任務對應到成本效率最合適的能力層級，是 L4 與 L3 的工作；但工作怎麼分派，最終會落在 L2 需要多少 Compute 與 Memory，以及 L1 撐不撐得住。分派與承載，其實要放在同一張圖上一起看。
未來不是 Cloud 或 Local，而是 Hybrid
這也讓 Local LLM / SLM 有了更清楚的位置。
Local Model 在企業有兩個很實際的用途。
第一，是企業內部知識管理。大量 SOP、技術文件、產品資料、規章與內部知識，可以依資料敏感性與能力需求，以 Knowledge、RAG 搭配 Private Model 處理。
第二，是處理大量、重複、相對簡單的 AI 工作。某些分類、摘要、資訊擷取與固定判斷，小模型就已經足夠，不必每一次都呼叫外部大型模型。
但 Local AI 並不是為了取代 Cloud AI。
Frontier Model 的推理、多模態、Coding、工具使用與 Agent 能力仍會持續進步。真正複雜、低頻但高價值的工作，Cloud Frontier Model 仍具有很大的價值。
所以未來合理的企業架構，並不是：
Cloud AI 還是 Local AI？
而是：
哪一個工作應該在哪裡跑？
高複雜度、高價值、低頻工作，可以使用 Frontier Model；高頻、固定、敏感、可標準化的工作，可以評估 Private 部署的 SLM / LLM；中間再透過 Routing 與 Orchestration，依工作需求決定使用哪一種能力。
因此，Hybrid AI 不是折衷方案，而是一種資源最佳化策略。
而且這個配置不是一次決定就永遠不變。
模型的能力、價格、Context Window、推理效率與工具使用能力都會持續改變。今天適合 Local 的工作，未來可能轉到 Cloud；今天需要 Frontier Model 的工作，隨著 SLM 能力提升，也可能回到企業內部。
所以值得及早建立的是：
模型可替換、工作可路由、資源可重新配置的 Architecture。
模型會變，Architecture 不能綁死。
看得見、管得住、調得動
AI Architecture Map 不只是描述五層資源架構，更重要的是讓企業在每一層都能做到三件事：
看得見、管得住、調得動。
例如在 L3，企業首先要知道有哪些模型、Knowledge 與 RAG 資源，以及不同流程目前使用哪些能力，這是「看得見」。
接著要能控制哪些流程可以使用哪些模型、資料與知識，以及不同工作的使用邊界，這是「管得住」。
最後，當 Cost、Performance、Risk 或模型能力改變時，可以把工作重新配置到其他模型，而不必重建整條流程，這是「調得動」。
到了 L2，同樣要看得到 GPU、NPU、Memory 與 Compute 的使用量；能透過 Priority、Quota 與 Allocation 管理資源；並在 Cloud、Local 或 Edge 之間重新調度 Workload。
這三件事也需要具體機制支撐。「看得見」要能以工作或流程為單位，追蹤 AI 成本、Token 用量與 Agent 執行步數；「管得住」則要為 Agentic Workflow 設定成本上限、最大步數、逾時中止與人工介入等邊界；「調得動」需要 Model Gateway 或 Router，讓流程與特定模型解耦。
否則，一條會反覆推理、重試與呼叫工具的 Agent 流程，很可能在無人察覺的情況下持續放大資源消耗。治理如果只知道花了多少，就沒辦法在超過邊界時把流程停下來。
因此，AI Architecture Map 的治理原則可以濃縮成三句：
看得見，才知道資源花在哪裡。
管得住，才知道資源應該用在哪裡。
調得動，才能隨技術、成本與需求重新配置。
必須說明的是，這張圖不是成熟度模型，也還沒有可以公開引用的跨產業驗證。企業如何配置 AI 資源，牽涉成本結構與採購決策，向來不是會對外揭露的資訊，這類題目的公開案例本來就稀少。它想提供的因此不是標準答案，而是一組提問順序：在編列 AI 預算、決定要不要投資 GPU、評估一個 Agent 專案值不值得做之前，先把這五層由上往下問過一遍。問完之後決策未必改變，但至少會知道自己是根據什麼做的決定。
結語：AI Governance 的下一題，是 Resource Governance
過去談 AI Governance，我們通常想到資安、隱私、幻覺處理、資料、權限與法遵。
但 Agent 時代還增加了一個重要問題：
Resource Governance。
當 Agent 能自主呼叫模型、工具與運算資源，企業不只要問「AI 能不能做這件事」，還要進一步問：
「這件事值得使用多少 AI 資源？」
因此未來真正重要的問題，不是哪一家模型最強，而是企業有沒有能力持續回答：
什麼工作，現在最適合在哪裡跑？
AI Architecture Map 希望把企業效用、工作流程、AI 能力、運算與基礎資源放在同一張地圖上，再透過「看得見、管得住、調得動」治理每一層。
先設計 Agent 怎麼工作，再設計支撐這些 Agent 的資源，最後治理整個系統。
這就是在 Agent 時代需要 AI Architecture Map 的原因。
沒有留言:
張貼留言