萬聖驚奇夜襲來！這桌派對極致「搞怪」！到 Mia C'bon 鎖定限時異國食材 秒造萬聖儀式感
商傳媒｜記者林展鴻／綜合報導萬聖節倒數，除了變裝討糖，近年不少家庭、親子族群、朋友聚會甚至辦公室，都把萬聖節列入秋季必搞事的節慶！想讓派對不只熱鬧，更要刷爆朋友圈，挑選「不一樣」的食材與零食成為關鍵所在。Mia C'bon頂級超市今年特別以「萬聖驚奇夜」為主題，一站式集結豐富多樣的異國限定零食、質感微醺飲品與派對創意料
11 小時前・商傳媒
從 Agent-Centric 到 Data-Centric，人工智慧與企業資料平台的關係正在重新定義。隨著 AI Agent 深入企業核心業務，Google、Microsoft 與 Anthropic 等科技業者的技術發展，逐漸揭示企業 AI 的下一項關鍵挑戰：如何讓資料平台提供可信、完整且具備業務語意的資料能力，而非持續要求大型語言模型自行理解與處理所有資料。
過去幾年，生成式人工智慧的技術競爭主要集中在大型語言模型的規模、推理能力與多模態處理表現。隨著模型逐漸具備工具呼叫、程式生成與多步驟任務規劃能力，產業發展的焦點開始從如何讓 AI 正確回答問題，轉向如何讓 AI 實際完成工作。AI Agent 的興起，正是這項技術轉變最具代表性的發展之一。
相較於傳統的聊天機器人，AI Agent 不再只是根據使用者輸入產生文字，而是能夠分析任務需求、選擇外部工具、取得資料，並透過多次操作完成特定目標。這種能力使企業開始嘗試將人工智慧應用於財務分析、供應鏈管理、客戶服務、營運監控及資訊系統維護等領域，期望藉此降低人工操作成本，並提升跨系統業務流程的自動化程度。
然而，企業資訊環境與一般網際網路服務存在本質上的差異。企業資料往往分散於 ERP、CRM、關聯式資料庫、資料倉儲、雲端平台及大量內部應用程式之中，各系統不僅採用不同的資料結構，也承載著長期累積的業務規則與組織管理邏輯。即使企業已建立資料湖或資料倉儲，也不代表這些資料能夠直接被人工智慧正確理解與使用。
這項挑戰已經獲得學術研究的實證支持。2025 年國際學習表徵會議（International Conference on Learning Representations，ICLR）發表的研究《Spider 2.0：評估大型語言模型處理真實企業 Text-to-SQL 工作流程的能力》（Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows），針對真實企業環境中的資料查詢任務建立評估基準。研究涵蓋 632 項企業資料工作流程問題，涉及複雜的資料庫結構、不同 SQL 方言及多步驟資料處理需求，顯示真實企業資料環境的難度遠高於一般自然語言轉 SQL 測試。
研究所評估的特定 Agent 方法，在其設定的任務與評估條件下，成功率僅達 21.3%。這項數據並不代表所有大型語言模型的企業資料查詢能力，但它揭示了一個重要問題：即使模型已經具備程式生成與工具使用能力，面對真實企業資料環境時，仍可能受到資料結構複雜性與業務上下文不足的限制。
當人工智慧從資訊查詢工具轉變為企業工作流程的參與者，如何建立可信任的資料存取與業務理解機制，便成為比單純提升模型能力更加複雜的系統工程問題。這也促使產業重新思考 AI Agent 與企業資料平台之間的責任分工。
目前許多 AI Agent 系統採用以模型為中心的 Agent-Centric 架構，由大型語言模型根據使用者意圖決定需要使用哪些工具，並在執行過程中動態產生查詢、程式或 API 呼叫。這種設計延續了大型語言模型擅長處理非結構化需求與未知問題的特性，使 Agent 能夠在缺乏預先定義工作流程的情況下，探索可用資源並嘗試完成任務。
Anthropic 在 2024 年 12 月發表的技術文章《如何建立有效的 AI Agent》（Building Effective Agents）中，將 Agent 與預先定義的工作流程加以區分，指出 Agent 的重要特徵在於由大型語言模型動態決定執行流程與工具使用方式。這種架構提供高度彈性，但也可能伴隨較高的執行成本、延遲與錯誤累積風險，因此系統設計必須依據任務的複雜程度，選擇適當的自主性。
Agent-Centric 架構的重要價值，在於它降低了自動化系統對固定流程的依賴。傳統企業應用通常必須事先定義使用者操作路徑、資料處理程序與系統整合方式，而 AI Agent 則能根據任務需求，在執行階段組合不同工具與資料來源。對於探索性分析、軟體開發輔助及難以事先列舉所有情境的工作，這種高度彈性的架構具有明顯優勢。
不過，當企業嘗試將相同模式擴展至核心業務系統，原本由 Agent 自行處理的資料探索與執行工作，便可能成為可靠性與治理上的負擔。企業資料結構的複雜性，使 Agent 難以在有限的模型上下文中掌握所有資料來源及其關聯。即使透過資料庫 Schema、文件檢索或工具描述提供必要資訊，模型仍可能因欄位定義模糊、資料版本差異或業務規則不完整，而產生不符合實際需求的查詢。
Anthropic 在 2025 年 9 月進一步發表《如何為 AI Agent 設計有效的工具》（Writing Effective Tools for Agents），提出一項值得企業資料平台借鏡的設計原則：Agent 工具不應只是既有 API 的機械式包裝，而應根據 Agent 的實際任務與使用情境進行設計。文章指出，過多低階工具可能增加模型選擇與使用工具的負擔，適當整合相關操作，反而有助於提升工具使用效率。
這項觀點對企業資料架構具有重要啟示。如果資料平台只是將大量資料表、SQL 執行介面與底層 API 直接暴露給 Agent，實際上仍然要求模型自行理解資料關聯、組合查詢程序並處理各種例外情況。相較之下，若企業能夠事先將常用資料處理流程封裝為具有明確業務意義的工具，Agent 便能將更多資源投入任務理解與決策，而不必重複處理底層系統細節。
此外，當不同 Agent 各自負責理解與實作資料處理邏輯，企業容易面臨重複開發與規則分散的問題。例如，同一項營收指標可能在不同應用中採用不同的過濾條件與計算方式，使各部門取得的分析結果出現差異。這類問題過去已存在於傳統商業智慧與資料分析環境，而當 AI Agent 具備自主產生查詢及程式的能力時，資料定義不一致的風險可能進一步擴大。
這些限制並不意味著 Agent-Centric 架構缺乏實用性，而是顯示企業有必要重新評估，哪些工作應交由模型自主處理，哪些能力則應由共用資料平台集中維護。
相較於由 Agent 自行探索資料環境的設計，Data-Centric 架構將資料整合、語意定義、治理與執行等責任，更多地交由企業資料平台承擔。其基本理念是，企業應先將資料整理成具備明確業務意義、可重複使用且受治理的能力，再透過標準化介面提供給 AI Agent，由 Agent 根據任務需求進行選擇與組合。
這種架構並非單純增加資料庫 API 的數量，而是重新思考資料平台應該向人工智慧提供什麼樣的資訊。傳統資料存取介面主要描述資料位於何處、具有哪些欄位，以及如何執行查詢；面向 AI Agent 的資料能力服務，則需要進一步說明資料代表什麼業務概念、能夠解決哪些問題、適用於哪些條件，以及執行結果受到什麼限制。
Google Cloud 在 2026 年 8 月發表的《Looker 語意層如何為 Gemini Enterprise 提供可信任的資料治理》（Looker’s Semantic Layer Governs Gemini Enterprise Data for User Trust），便提供了這種架構思考的具體案例。Google 將 Looker 的語意層與 Gemini Enterprise 整合，使 AI 應用能夠利用預先建立的業務指標與資料模型，而不必完全依賴模型自行推測資料表之間的關係與計算邏輯。
這種設計的重要性，在於將資料的業務意義從個別 AI 應用中抽離，交由共用資料平台管理。例如，企業可以將銷售資料封裝為營收趨勢分析能力，並明確定義其支援的時間範圍、組織維度、貨幣換算方式及營收認列規則。對 AI Agent 而言，這不再只是需要自行理解與組合的資料表，而是一項具有清楚輸入、輸出及業務意義的可執行服務。
當使用者要求分析特定市場的營收變化時，Agent 可以透過資料能力目錄找到符合需求的服務，取得必要的分析結果，再視情況組合其他能力完成進一步判斷。資料平台則負責維護底層資料來源、查詢最佳化、業務規則與權限控制，使不同 Agent 能夠使用一致的資料定義。
值得注意的是，Data-Centric 並不代表 Agent 不再需要推理或程式生成。對於尚未被封裝的新型分析需求，Agent 仍可能需要建立臨時查詢、組合多項能力，甚至提出新的資料處理流程。真正的差異在於，這些操作可以建立在企業已經治理的資料基礎之上，而不必每次重新理解整個資料環境。
Data-Centric 架構能否真正發揮價值，關鍵不只在於資料是否完成整合，更取決於資料平台能否建立一致的業務語意。
傳統資料平台已經具備多種整合與查詢技術，包括資料倉儲、資料湖、Lakehouse、資料虛擬化及分散式 SQL 查詢引擎。這些技術可以降低跨系統存取資料的困難，但它們主要處理資料的儲存、運算與整合問題，並不必然提供完整的業務定義。
語意層（Semantic Layer）則試圖在底層資料與上層應用之間建立統一的業務描述，將資料表、欄位與運算邏輯轉換為企業能夠共同理解的指標、實體及關聯。例如，營收、毛利率、客戶留存率與庫存週轉率等指標，可以在語意層中建立一致的計算規則，避免不同應用各自解讀資料而產生結果差異。
Microsoft 在《Data Agent 語意模型的最佳實務》（Semantic Model Best Practices for Data Agent）技術文件中，也強調資料來源的準備程度與語意模型設計，會直接影響 AI Agent 產生查詢及回答問題的品質。對企業而言，建立清楚的資料描述、業務指標與模型關聯，不再只是改善報表開發效率的工作，也逐漸成為人工智慧應用的重要前置工程。
Google Cloud 則在 2026 年 4 月發表《Google Cloud Knowledge Catalog：從資料目錄走向企業知識目錄》（Introducing the Google Cloud Knowledge Catalog），提出進一步擴展傳統資料目錄角色的方向。相較於主要記錄資料位置、結構及技術中繼資料的傳統 Catalog，Knowledge Catalog 更重視資料資產的業務脈絡、語意關係與治理資訊，使資料不僅能被搜尋，也能更有效地被理解與使用。
這項發展反映出企業資料管理正在面臨新的使用者需求。過去資料目錄主要服務資料工程師、分析師與治理人員，協助他們尋找與理解資料資產；當 AI Agent 成為新的資料使用者，資料目錄也需要提供更完整的機器可讀描述，使模型能夠根據任務需求辨識資料的用途與限制。
若進一步將語意模型與可執行介面結合，便可以建立資料能力目錄（Data Capability Catalog）。這種目錄不僅記錄企業有哪些資料，也描述目前有哪些可供 Agent 使用的分析、查詢及業務操作能力，並提供必要的參數、回傳格式、權限條件與資料品質資訊。
從架構角度觀察，資料能力目錄有機會成為連結企業資料平台與多個 AI Agent 的共用服務層。企業不必讓每一個 Agent 分別學習所有資料來源，而是透過統一的能力描述，讓不同模型與應用能夠使用相同的業務服務。這也使資料平台的設計逐漸從面向資料分析人員，延伸至面向具有自主決策能力的軟體代理。
隨著 AI Agent 的工具整合需求增加，模型上下文協定（Model Context Protocol，MCP）的發展，為模型與外部系統之間的互動提供了標準化機制。透過 MCP，應用程式可以用較一致的方式向 AI Agent 提供工具、資源及相關描述，降低不同模型與服務之間重複開發整合介面的負擔。
對企業資料平台而言，MCP 提供了一條將既有資料服務轉換為 Agent 可呼叫工具的技術路徑。企業可以把參數化資料視圖、分析服務、資料查詢介面及特定業務操作封裝成工具，使 AI Agent 能夠透過標準化機制發現並使用這些功能，而不必直接連接所有底層資料來源。
Microsoft Fabric 的 Data Agent 產品，已經展現這類架構的實際應用方式。根據 Microsoft 官方技術文件《Fabric Data Agent 核心概念》（Fabric Data Agent Concepts），Data Agent 能夠使用 Fabric 環境中的 Lakehouse、Warehouse 與語意模型等資料資產，協助使用者透過自然語言取得企業資料中的資訊。
Microsoft 也在《將 Data Agent 作為 MCP Server 提供服務》（Data Agent as Model Context Protocol Server）文件中，介紹如何透過 MCP 將 Data Agent 的資料查詢能力提供給外部 AI 應用。這種設計使企業能夠將資料平台所提供的能力，進一步整合至其他 Agent 與應用程式之中，而不必要求每一個外部系統重新建立完整的資料連接與查詢機制。
不過，工具連接標準與企業資料治理屬於不同層次的問題。MCP 可以描述工具如何被呼叫，但不會自動確保工具所使用的資料具有一致的業務定義，也無法單獨解決跨系統權限、資料品質、查詢成本與執行結果驗證等問題。企業仍然需要透過資料平台建立完整的治理與控制機制，才能使工具具備長期穩定使用的條件。
因此，MCP 與 Data-Centric 架構更適合被視為互補關係。前者提供 AI Agent 與外部服務之間的標準化互動方式，後者則負責建立可被使用的資料能力及其背後的語意、治理與執行環境。當兩者結合，企業便有機會在不暴露大量底層系統細節的情況下，向不同 AI Agent 提供一致且受控的資料服務。
Data Agent 並不是一個具有單一技術定義的產品類別。現階段市場上以 Data Agent 為名的系統，涵蓋自然語言資料查詢、資料分析、資料工程自動化，以及跨系統工作流程協調等不同功能。然而，隨著企業資料能力逐漸標準化，這些系統可能出現更清楚的架構分工。
在以自然語言查詢為主的應用中，Data Agent 通常需要理解使用者提出的問題，將其轉換成 SQL 或其他查詢語言，再根據取得的資料產生分析結果。這種模式改善了使用者操作資料系統的方式，但 Agent 仍然需要承擔相當程度的資料探索、查詢生成與結果解讀工作。
當資料平台能夠提供完整的能力目錄，Data Agent 便可以將更多資源投入任務規劃與跨能力協調。例如，當企業管理者要求評估某項產品是否適合擴大生產，Agent 可以先透過銷售分析能力取得需求趨勢，再結合庫存查詢、供應商交期及成本分析等服務，依照企業既有的業務規則建立評估結果。
Microsoft 近一步將企業知識本體（Ontology）整合至 Fabric Data Agent。根據官方文件《以企業知識本體作為 Fabric Data Agent 的語意基礎》（Use Ontology as Context in Fabric Data Agent），企業可以透過實體、屬性與關係描述業務領域，再將這些語意資訊與實際資料來源建立對應，協助 Agent 理解資料的業務脈絡。
這項技術方向顯示，Data Agent 的設計正在從單純依賴資料庫 Schema 與自然語言產生查詢，逐步納入更完整的企業語意模型。當系統能夠理解客戶、產品、訂單與供應商等實體之間的關係，便有機會在執行查詢之前，更準確地判斷哪些資料來源與業務能力適合目前任務。
在這個過程中，Data Agent 並非取代資料平台，而是利用資料平台提供的能力完成更高層次的工作。其價值也不再僅以能夠產生多少查詢或連接多少資料庫衡量，而是取決於能否正確理解任務、選擇適當能力、安排執行順序，並將多個結果整合成可供決策參考的資訊。
當企業開始將資料轉換成可供 AI Agent 使用的能力，另一個值得關注的技術方向，是如何讓資料平台不僅提供查詢與運算服務，也能保存並執行企業的知識與業務規則。
目前企業資料平台大多擅長處理結構化資料與分析運算，但企業的實際業務運作往往包含大量難以直接從資料表辨識的知識。例如，客戶與供應商之間的關係、產品與零組件的相依性、特定交易的審核條件，以及不同營運狀態下應採取的處理程序，都可能需要額外的知識描述機制。
知識圖譜（Knowledge Graph）提供了一種描述實體及其關係的方式，使企業能夠將分散在不同系統中的資訊，組織成具有明確關聯的知識結構。當這些關係與資料能力目錄整合，AI Agent 便有機會根據業務概念尋找相關資料，而不必完全依賴資料表名稱或文字相似度進行探索。
形式化邏輯（Formal Logic）與規則引擎則提供另一種可能性。企業可以將部分業務規則、約束條件與判斷程序轉換為機器可執行的形式，使系統能夠根據已知事實進行規則驗證與邏輯推導。相較於完全依賴語言模型生成判斷結果，這種方式有機會在規則明確且資料完整的情境中，提供更容易重現與稽核的處理程序。
例如，在供應鏈管理中，系統可以根據庫存水位、預估需求、交貨時間與採購限制，判斷特定補貨計畫是否符合既定條件。語言模型可以負責理解管理者的自然語言需求，資料平台提供即時營運資訊，而規則引擎則負責檢查計畫是否違反已定義的限制。不同技術分別處理語意理解、資料存取與邏輯驗證，使整體系統不必將所有責任集中於單一模型。
不過，知識圖譜與形式化邏輯也無法涵蓋所有企業決策情境。對於資訊不完整、條件模糊或需要開放式判斷的問題，仍然需要統計模型、機器學習與大型語言模型協助處理。因此，更具實際可行性的發展方向，可能是將語言模型的彈性推理能力，與資料平台的確定性運算及規則驗證能力結合，建立分工明確的混合式智慧系統。
回顧企業資料技術的發展，從早期資料庫、資料倉儲，到後來的資料湖、Lakehouse 與資料虛擬化，各階段的技術創新都試圖解決資料規模、整合效率與分析需求持續增加所帶來的挑戰。這些技術的共同目標，是讓企業能夠更有效率地儲存、管理及使用資料。
AI Agent 的興起，則可能為企業資料平台帶來不同於過去的新要求。當資料的使用者不再只有人類分析師與傳統應用程式，而是包含能夠自主規劃與執行任務的智慧代理，資料平台便需要提供更完整的機器可理解描述、能力發現機制及執行治理環境。
Google Cloud 在 2026 年提出的 Agentic Data Cloud 發展方向，也反映出這項技術趨勢。根據其官方文章《Agentic Data Cloud 的最新技術發展》（What's New in the Agentic Data Cloud），Google 正試圖將企業資料平台從傳統的資料管理與分析環境，進一步擴展為支援 AI Agent 進行資料探索、分析與行動的基礎設施。
這類發展顯示，企業資料平台的競爭可能逐漸從資料儲存容量、查詢效能與連接器數量，延伸至語意模型完整性、資料能力重複使用程度，以及能否支援不同 AI Agent 的工作需求。資料平台不再只是等待應用程式提出查詢的被動系統，而可能逐步成為提供業務能力與執行服務的共用基礎設施。
從技術發展的角度觀察，Data-Centric 架構的價值不在於完全取代 Agent-Centric，而是重新界定哪些工作應由大型語言模型處理，哪些能力應該沉澱在企業長期維護的資訊系統之中。對於高度探索性、需求不確定的工作，Agent 仍然需要保留動態規劃與產生程式的能力；對於經常重複、涉及核心資料或需要嚴格治理的業務操作，則更適合透過標準化資料能力提供服務。
兩種模式的結合，可能成為企業 AI Agent 逐步成熟的重要路徑。企業可以先將高頻率、高價值的資料操作封裝為受治理的能力，再隨著使用情境擴大，逐步增加能力目錄的涵蓋範圍，並透過受控的擴充程序將新的資料處理邏輯納入共用平台。這不僅能降低重複開發成本，也有助於建立可持續累積的企業數位能力。
從 Anthropic 對 Agent 工具設計的研究，到 Google Cloud 將語意層與企業知識目錄納入 AI 資料架構，再到 Microsoft Fabric 將 Data Agent、Ontology 與 MCP 整合為可供企業使用的服務，可以觀察到國際科技業者正從不同方向處理相似的問題：如何降低 AI Agent 對底層資料結構的依賴，並讓企業既有的資料與業務知識，成為能夠重複使用的智慧服務基礎。
這些發展尚不足以證明 Data-Centric 已經取代 Agent-Centric，卻顯示企業 AI 的架構設計正在超越單純的模型與工具整合。當智慧代理開始參與需要一致性、可稽核性與長期維運的核心業務流程，資料品質、業務語意、治理機制與執行可靠性，將與模型的推理能力同樣重要。
對企業而言，這代表 AI 導入策略需要從單純評估模型與 Agent Framework，延伸至資料架構本身的準備程度。能否將分散的資料、業務知識與處理程序轉換為可被人工智慧理解及使用的標準化能力，可能成為企業擴大 AI 應用規模的重要條件。
當智慧代理逐漸成為企業資訊系統的新一代操作入口，真正具有長期價值的技術投資，將不只是讓 AI 學會如何連接更多資料來源，而是建立一套能夠持續累積、管理與提供企業資料能力的基礎架構。從這個角度來看，Data Agent 的下一場技術變革，或許並不發生在模型本身，而是發生在模型背後的企業資料平台。
