KubeSummit 2026 現場觀察：當 Kubernetes 走向 AI Native，企業真正的下一場基礎工程在資料

由
商傳媒 提供
-
KubeSummit 2026 現場觀察：當 Kubernetes 走向 AI Native，企業真正的下一場基礎工程在資料
KubeSummit 2026 現場觀察：當 Kubernetes 走向 AI Native，企業真正的下一場基礎工程在資料
圖／KubSummit 2026 現場

商傳媒｜產業記者林文宏／台北報導

9 月 10 日至 11 日，iThome KubeSummit 2026 在臺北文創舉行。今年大會的主題是「從 Cloud Native 到 AI Native，定義 AI 原生時代的基礎架構」。如果只看標題，很容易把它理解成 Kubernetes 因應生成式 AI 熱潮的一次技術擴張：GPU 要如何調度、模型如何部署、推論服務如何擴充。然而從兩天的議程內容來看，真正值得注意的並不只是 AI 工作負載開始進入 Kubernetes，而是企業 IT 的「使用者」正在發生變化。

過去十年的 Cloud Native，核心是讓應用程式逐步與底層基礎設施解耦。容器和 Kubernetes 把運算、網路與儲存抽象成可以宣告、調度與自動化管理的資源，開發者不再需要知道服務最後落在哪一臺實體機器。到了 Agentic AI 時代，企業面對的是另一種新的抽象化需求：一個可以自行拆解任務、尋找資訊、呼叫工具甚至執行動作的 Agent，不應該被迫理解企業底下每一套資料庫、每一條 ETL Pipeline、每一個 Legacy System 的細節。

這也是今年 KubeSummit 變化最明顯之處。議程中除了大規模叢集、平台工程與雲原生安全，也出現 AI Agent、GPU 資源治理、自主維運與多 AI 應用等議題。Kubernetes 的角色，開始從「承載應用程式的平台」，往「承載 Agent 與 AI 服務的平台」延伸。但當 Agent 真正開始工作，企業很快就會發現，算力與模型只是第一層問題；更棘手的，是如何讓 AI 進入公司自己累積數十年的資料世界。

圖／活動現場

Data Agent 把企業資料的老問題重新暴露出來

通用大型語言模型掌握的是公開世界的知識，真正形成一家企業差異化能力的資訊，卻大多存在企業自己的系統裡。客戶資料在 CRM，訂單在 ERP，交易可能存在 Oracle 或大型主機，營運資料散落於 PostgreSQL、SQL Server、Data Warehouse、Data Lake，製造業還有 MES、IoT、設備與工廠系統。這些系統多半不是為 AI 而設計，卻正是企業最希望 AI 能理解與使用的資料來源。

於是，「Data Agent」開始從研究議題走進企業市場。2025 年，Zhaoyan Sun、Jiayi Wang、Xinyang Zhao、Jiachi Wang 與 Guoliang Li 在論文 〈資料代理：協調 Data+AI 生態系統的整體架構〉（Data Agent: A Holistic Architecture for Orchestrating Data+AI Ecosystems） 中，將 Data Agent 定義成一種用來協調 Data+AI 生態系統的完整架構，涉及資料、查詢、環境與工具的理解，也包含工作流程規畫、執行、最佳化與反思。這與市場上常見的「自然語言轉 SQL」並不是同一個層次。

2026 年，Yuyu Luo、Guoliang Li、Ju Fan 與 Nan Tang 在 〈資料代理：能力分級、技術現況與開放問題〉（Data Agents: Levels, State of the Art, and Open Problems） 中進一步提出 L0 至 L5 的能力分級，試圖區隔簡單的查詢助手與高度自主的資料代理。這套分級之所以重要，是因為它揭露目前產業語言中的模糊地帶：會回答資料問題的聊天介面，與真正能夠自行探索資料、規畫工作、選擇工具、驗證結果的 Agent，仍有很長距離。

OpenAI 今年公開的內部 Data Agent，則讓這個問題第一次有了更具體的企業尺度。根據 OpenAI 2026 年 1 月發表的 〈OpenAI 內部資料代理實戰〉（Inside OpenAI’s in-house data agent），其資料平台服務超過 3,500 名內部使用者，涵蓋超過 600PB 資料與 7 萬個 datasets。在這樣的規模下，最困難的工作有時甚至不是分析，而只是找到正確的資料表。名稱相近的資料表可能代表不同用途，欄位互相重疊，卻具有不同業務定義；即使資料表找對，錯誤的 Join、Filter 或 Null 處理，也可能得到一份看似合理、實際卻錯誤的結果。

因此，OpenAI 建置 Data Agent 時投入的重要工作不是單純強化 SQL 生成，而是替 Agent 建立足夠的 Context。除了 Schema metadata，還包括 table lineage、歷史 query、領域專家對欄位與資料表留下的描述、程式碼、組織知識、使用者記憶與 runtime context。OpenAI 甚至特別指出，一張表真正的意義經常存在產生它的程式碼與 pipeline logic 裡，而不只存在 Schema。

這正是企業資料與 AI 之間最容易被低估的一道斷層。模型可以理解 customer_id 這個欄位名稱，卻無法憑空知道哪一種客戶才算財務部門認定的正式客戶；它可以知道 revenue 的英文意義，卻不知道一家公司的「實際營收」是否需要扣除退貨、折讓或特定內部交易。模型知道 SQL，不代表模型理解一家企業。

資料語意與 Context 因而開始被重新視為基礎設施。Gartner 在 2026 年一系列研究中，把 Context 提升到「Critical Infrastructure」的層次，認為 AI Agent 要可靠運作，需要受到治理且具有語意脈絡的資料，而傳統只描述欄位與 Schema 的資料模型已不足以支撐 Agentic AI。Gartner 5 月發布的 研究 直接指出，缺乏 semantics 會增加 Agent 不準確與低效率的風險；到了 8 月，又進一步提出 AI-Ready Data Needs to Expand to Agent-Ready Data，要求企業不只確認資料是否適合 AI 使用，也要能評估 Agent 是否以正確、合規的方式使用這些資料。

研究端也開始反映相同問題。Ruiying Ma 等人在 2026 年提出的 〈AI Agent 能回答你的資料問題嗎？Data Agent 基準測試〉（Can AI Agents Answer Your Data Questions? A Benchmark for Data Agents），刻意把評估場景放到異質企業資料環境，涵蓋 12 組資料集、9 個領域與 4 種資料庫管理系統；論文發表時，測試中的最佳 frontier model 第一次嘗試成功率仍只有 38%。這個數字未必能直接代表所有企業場景，但至少說明一件事：Data Agent 的可靠性問題，遠不是換上一個更大的模型就會自動消失。

AI Ready 走向基礎架構，臺灣業者也開始從資料層切入

在這股從 AI Ready 進一步走向 Agent Ready 的趨勢下，臺灣市場也開始出現相應的技術布局。重新觀察今年 KubeSummit 上的 寬橋 Brobridge，值得注意的並不只是它提出一套 AI Ready 資料平臺，而是這家公司過去數年在 Kubernetes Summit 所留下的技術軌跡，恰好反映企業 IT 從 Cloud Native、資料架構一路走向 Agentic AI 的變化。

對不熟悉臺灣 Cloud Native 產業的讀者而言，寬橋是一家 2016 年成立的臺灣技術公司，早期從微服務、Cloud Native、Kubernetes 與企業資料技術切入，也是 CNCF 認可的 Kubernetes Certified Service Provider（KCSP）。此次參與 KubeSummit 議程與工作坊的技術講師，也都具備 CNCF Kubestronaut 或 Golden Kubestronaut 資格。這類資格並非單一產品認證，而是建立在多項 Kubernetes、Cloud Native 與 Linux Foundation 技術認證之上的專業認可，因此更適合作為觀察團隊技術廣度與長期投入程度的參考，而不是單純的品牌頭銜。與其從公司自我定位理解寬橋，更值得參考的，是它過去幾年在 iThome Kubernetes Summit 上持續出現的技術主題。

2020 年，寬橋在 Kubernetes Summit 2020 聚焦企業導入 Kubernetes 之後如何真正走向微服務；2021 年，寬橋與台灣微軟合作，在 「以 GRAVITY 輕鬆擴展資料上雲 on Microsoft Azure」 工作坊中，已經開始把 AKS、異質資料庫同步、資料上雲與去識別化放到同一個實作場景；到了 2022 年，寬橋的議程進一步轉向 Data Mesh 與 Kubernetes 環境中的資料供應，並以 near real-time ETL、讀寫分離與快取管理處理企業應用取得資料的問題。

如果把這幾年的議題連起來，可以看出一條相當清楚的發展脈絡：早期處理的是應用程式如何 Cloud Native 化，接著開始處理微服務如何取得資料，再往後走到資料如何在分散式架構中被即時供應。到了 2026 年，當企業應用的下一種使用者開始變成 Agent，問題自然進一步轉成「AI 要如何取得企業資料」。

因此，寬橋今年在 KubeSummit 2026 談 AI Ready Data Platform，與其說是追隨生成式 AI 熱潮跨入新市場，不如說更像是其原有技術路線的延伸：從 Kubernetes 與企業系統底層一路往上，碰到資料，再碰到 Agent。

這一點也反映在寬橋今年於 KubeSummit 的議程安排。三個主要主題分別落在基礎設施（Infrastructure）、安全（Security）與資料（Data）：自動化私有雲基礎設施處理資源如何被快速供應；K8s Workload 零信任防護處理工作負載在執行階段究竟做了什麼；AI Ready 資料平台則進一步處理 Agent 與 AI 應用如何取得企業資料。三個議題分開看各自屬於不同技術領域，放在 Agentic AI 的企業架構中，卻恰好形成從運算資源、執行安全到資料存取的一條完整鏈條。

其中，「用 Kubernetes 打造 AI Ready 的資料平台」 工作坊直接把場景放在 Oracle、MySQL、PostgreSQL 等異質資料來源共存的企業環境。寬橋提出的 Plasma 並不要求企業先把所有資料搬到新的儲存平臺，而是嘗試在既有資料來源之上建立跨系統查詢、資料整理與治理能力，再把這些資料提供給 AI 使用。這個出發點之所以值得注意，不在於「資料不用搬」本身有多新，而在於它對應了大型企業最現實的限制：企業不可能因為 AI 出現，就把數十年的資料基礎建設全部推翻重來。

圖／台灣業者

AI Ready 的重點，可能不再是把資料集中到同一個地方

過去二十多年，企業資料架構的演進，很大程度圍繞著「集中」這件事。Data Warehouse 希望建立一致的分析來源，Hadoop 與 Data Lake 試圖容納更多類型與規模的資料，Lakehouse 再嘗試整合不同工作負載。每一代架構都有其合理性，但大型企業發展到今天，真實環境通常不是單一架構取代另一個，而是多代系統並存。

一家金融機構可能同時有大型主機、Oracle、DB2、SQL Server、Data Warehouse、Data Lake 與近年的雲端分析環境；製造業則還要加上 ERP、MES、IoT 與不同工廠的資料庫。這些系統有些確實老舊，卻同時承載最關鍵的客戶、交易、製造與供應鏈資料。生成式 AI 並不會讓它們失去價值，反而讓企業更迫切地想使用其中的資料。

若每一個新的 AI Use Case 都要求先建立新的資料副本、新的 ETL Pipeline 與新的 AI Data Store，最後很可能只是在既有資料孤島旁邊，再建立另一座 AI 孤島。從這個角度看，Plasma 真正值得觀察的並不是它能不能再建立一座新的資料平臺，而是它是否有機會成為既有 Data Estate 與上層 Agent 之間的中介層。

依照寬橋目前公開的 Plasma 產品資訊，平台提供跨資料來源存取、View、Materialized View、排程、Data Product、Data Catalog 與 Atomic 資料流程等能力。這些功能放在傳統 Data Engineering 市場並不陌生，但在 Agentic AI 的脈絡下，可以被重新理解成另一個問題：如何把散落在底層系統中的資料，逐步整理成上層 Agent 能發現、理解與使用的「企業資料能力」。

這與「把哪些資料搬給 AI」是不同的架構思考。前者以複製和集中為中心；後者關注的是 Agent 在特定身分、任務與權限下，可以使用哪些企業資料，以及這些資料代表什麼。這也意味著 AI Ready 不一定等於把所有資料集中到同一個地方，真正重要的可能是資料能否在不破壞既有系統的前提下，具有足夠的邏輯通透性。

但這條路仍有相當多工程問題尚未解決。跨來源查詢可以解決 Access，卻不會自動產生 Context；Data Catalog 可以列出資料表，卻不代表 Agent 已經理解其中的商業語意；MCP 等標準協定可以讓 Agent 更容易呼叫工具，卻無法替企業判斷某個數字究竟是不是正式營收。OpenAI 的實務與 Gartner 今年的研究都指向相同方向：當資料消費者開始從人和應用程式增加到 Agent，Metadata、Semantic、Lineage、Identity、Permission、Data Contract，以及散落在程式碼和流程中的 Business Logic，都必須逐漸進入資料基礎架構。

對 Plasma 而言，這也會是下一階段能否真正形成差異化的關鍵。若平台只停留在跨資料源查詢與資料整合，它面對的是一個早已成熟且競爭激烈的市場；但如果能進一步把企業資料的來源、關係、語意、規則、權限與使用脈絡逐步轉化成機器可理解的 Enterprise Context，它才有可能從 Data Integration Platform 往 Agent-ready Data Infrastructure 移動。

從 Cloud Native 到 AI Native，下一個被抽象化的可能是企業能力

回頭看 KubeSummit 2026，今年真正值得留意的變化，或許並不是 Kubernetes 又多承載了一種工作負載，而是企業 IT 抽象化的邊界再次往上移。

Cloud Native 時代解決的是應用程式與基礎設施（Infrastructure）的關係。伺服器（Server）、儲存（Storage）、網路（Network）被逐步包裝成平臺能力，開發者不再需要理解所有底層細節。Agentic AI 時代，企業接下來面對的，可能是類似但更複雜的工程：如何把散落在資料庫、Data Lake、API、文件與 Legacy System 裡的資料與業務邏輯，逐漸抽象成 Agent 可以安全理解與使用的企業能力。

未來一個成熟的企業 Agent，理想上不需要知道資料實際存放在 Oracle、PostgreSQL 還是哪一套 Data Lake；它真正需要知道的是企業提供哪些可信任的資料能力，這些能力代表什麼，在目前的身分與任務下能否使用，以及應該透過什麼方式取得。

這也是寬橋這次在 KubeSummit 2026 所呈現的技術路線值得觀察之處。從早年的微服務與 Kubernetes，到 Data Mesh、即時資料供應，再到今天的 AI Ready Data Platform，它所面對的問題其實沒有完全改變：都是在處理「上層的新型態應用，如何在不推翻底層既有系統的情況下，取得需要的基礎能力」。

只是到了 Agent 時代，這個問題的範圍已經從運算（Compute）擴大到資料（Data），並開始觸及企業知識與治理。

AI Native 因此不只是 Kubernetes 能不能跑模型，也不只是企業有沒有導入某一套 LLM。真正的考驗，是企業能否把今天仍在運作、也仍然創造價值的 IT 與資料資產，逐步轉化成明天的 Agent 可以可靠使用的能力。

從 KubeSummit 2026 可以看到，這場競爭已經開始從模型與算力往下移動。最後決定企業 AI 能不能真正進入核心營運的，很可能不是誰先取得下一個更大的模型，而是誰先把最難整理、卻也最不可能放棄的那一層企業資料「準備好」。

參考連結：