微軟 Fabric 這一年多在產(chǎn)品定位上的變化我剛開始是持保留態(tài)度的——又是一個想搶占企業(yè)數(shù)據(jù)入口的云服務(wù)而已。但真把幾個智能體項目跑下來之后我發(fā)現(xiàn)自己之前低估了它。智能體或者說 AI Agent 這幾年最大的瓶頸根本不是模型能力不夠而是它“不懂業(yè)務(wù)”。你讓一個大模型分析銷售下滑它連你們公司“有效銷售額”到底怎么定義都不清楚怎么可能給出靠譜判斷微軟 Fabric 被越來越多團隊當成智能體學(xué)習業(yè)務(wù)運作的平臺核心就是它把一個企業(yè)里散落的數(shù)據(jù)、口徑、實時事件整理成了一套智能體可以查詢、理解、持續(xù)修正的“業(yè)務(wù)事實層”。這篇文章我不打算泛泛介紹功能而是結(jié)合我實際搭建的經(jīng)驗聊清楚這么幾件事智能體為什么需要平臺級的業(yè)務(wù)語義Fabric 里哪些能力真正派上了用場我是怎么一步步把一個“會讀數(shù)據(jù)、懂業(yè)務(wù)規(guī)則”的智能體跑起來的以及這個過程中踩過卻很少被寫進文檔的坑。如果你正在企業(yè)里做數(shù)據(jù)平臺或者要給智能體項目找一個不會把口徑搞亂的數(shù)據(jù)基座這篇應(yīng)該能給你省不少試錯時間。1. 智能體為什么需要“業(yè)務(wù)運作學(xué)習”Fabric 恰好干了這件事1.1 只靠 Prompt 調(diào)優(yōu)的智能體根本學(xué)不會業(yè)務(wù)過去一年我觀察到的智能體項目凡是做到一半卡住的問題幾乎都不在大模型本身而在“模型對業(yè)務(wù)的理解太淺”。你可以把提示詞寫得再花哨把工具定義得再詳細但模型始終缺少一個東西一套和企業(yè)真實運作完全對齊的數(shù)據(jù)事實。舉個例子。一個零售客戶想讓我做“門店經(jīng)營診斷智能體”我一開始拿到的問題清單是這樣的門店毛利為什么比上周低了庫存周轉(zhuǎn)突然惡化是哪幾個 SKU 導(dǎo)致的哪些門店退貨率異常這些問題的答案全部藏在底層數(shù)據(jù)里分布在訂單系統(tǒng)、庫存系統(tǒng)、門店主數(shù)據(jù)里。更麻煩的是每個系統(tǒng)的字段命名、更新節(jié)奏、統(tǒng)計口徑都不一樣“訂單金額”在 CRM 里和在財務(wù)系統(tǒng)里的含義就不同。反過來想一個合格的業(yè)務(wù)分析師是怎么回答這些問題的他會先打開報表看一眼指標定義再下鉆到明細最后結(jié)合自己對業(yè)務(wù)的理解給出分析。分析師之所以能做這件事是因為他腦中有“業(yè)務(wù)語義”和“數(shù)據(jù)模型”。智能體如果只拿到一個數(shù)據(jù)庫連接串沒有一個語義模型它就像被蒙著眼睛派進一個巨大的倉庫讓它找一件它連長相都不知道的東西。所以我越來越傾向于把“業(yè)務(wù)運作學(xué)習”這四個字拆成這樣學(xué)習 數(shù)據(jù)事實 語義口徑 實時狀態(tài) 反饋修正。缺任何一個環(huán)節(jié)智能體都只是接了一個數(shù)據(jù)源的“高級聊天框”。1.2 Fabric 把數(shù)據(jù)湖、語義層、事件流拼成了業(yè)務(wù)學(xué)習底座微軟 Fabric 的定位恰好是覆蓋了這四個環(huán)節(jié)。它不是一個單純的數(shù)據(jù)倉庫或者 BI 工具而是一個把存儲、加工、分析、實時事件、治理收攏在同一套管理體系里的 SaaS 平臺。我給它總結(jié)了三層能力對應(yīng)智能體學(xué)習的三個需求統(tǒng)一的事實存儲層OneLake 把結(jié)構(gòu)化表格、半結(jié)構(gòu)化日志、非結(jié)構(gòu)化文檔放進同一個湖里形成智能體的“記憶體”可計算的語義層指標口徑、維度層級、業(yè)務(wù)關(guān)系在語義模型里定義清楚智能體查詢時拿到的是“有效銷售額”這樣有業(yè)務(wù)含義的結(jié)果而不是讓模型自己拼字段實時事件通道通過實時智能模塊接入訂單、庫存、設(shè)備事件讓智能體能感知“當下正在發(fā)生什么”而不只是事后翻舊賬。在這個結(jié)構(gòu)里智能體不再是一個直接連庫的“裸查詢器”而是一個站在業(yè)務(wù)語義之上的推理者。你問它“為什么華東區(qū)周轉(zhuǎn)天數(shù)上升了”它不是先去猜哪張表里有什么字段而是先定位到“庫存周轉(zhuǎn)天數(shù)”這個指標的定義再按模型下鉆到區(qū)域、品類最后結(jié)合實時補貨事件給出解釋。我實際做完一個項目之后的體會是Fabric 并不能讓模型一夜之間變聰明但它給了模型一個不扭曲業(yè)務(wù)真相的“參考系”。智能體給出的結(jié)論一旦有異議你可以回溯到它查詢的指標、數(shù)據(jù)源、時間范圍整個判斷過程是可驗證的。這一點對于要上生產(chǎn)環(huán)境的智能體來說價值甚至比準確率還重要。2. 我實際用到的 Fabric 核心組件與選擇邏輯2.1 OneLake 湖倉一體讓散落的業(yè)務(wù)數(shù)據(jù)先住進同一個倉庫智能體學(xué)業(yè)務(wù)的第一步是先解決“數(shù)據(jù)在哪”的問題。我在項目里最常見的數(shù)據(jù)環(huán)境是銷售在 SQL Server庫存在一個老舊的 ERP 系統(tǒng)客戶主數(shù)據(jù)又在另一套 CRM偶爾還有手工維護的 Excel 表。過去我們做數(shù)倉第一步就是寫一堆 ETL 把數(shù)據(jù)“抽”到統(tǒng)一存儲。Fabric 里的 OneLake 給了我一個更省事的答案它依托云對象存儲但對外暴露的是一個邏輯數(shù)據(jù)湖。這意味著你既可以物理搬數(shù)據(jù)進來也可以用快捷方式指向外部存儲讓數(shù)據(jù)看起來都住在同一個湖里實際上沒有產(chǎn)生冗余拷貝。我自己最常用的做法有這么幾個用 Data Factory 管道把 SQL Server 的業(yè)務(wù)表按增量策略復(fù)制為 Delta 表CSV 和 Excel 這種小數(shù)據(jù)源直接扔到 Notebook 里清洗后寫回湖里對于已經(jīng)存在其他數(shù)據(jù)湖的歷史數(shù)據(jù)用快捷方式直接掛載避免重復(fù)遷移在 Data Hub 里做好表登記和描述讓智能體工具能“看到”有哪些表可用。有一個實際體驗值得單獨拎出來說OneLake 里的每張表都會自動暴露一個 SQL 分析端點這意味著智能體可以用標準 SQL 直接查詢湖里的數(shù)據(jù)不需要你再去封裝一套 HTTP API。我項目里給智能體配查詢工具時幾乎沒寫后端接口客戶端就是對著分析端點跑 SQL。這讓整個鏈路清爽了一個量級。2.2 語義模型與指標庫把“口徑”變成智能體能直接復(fù)用的資產(chǎn)數(shù)據(jù)進了湖下一道坎是口徑。這一步是智能體能不能“說人話”的分水嶺。什么叫口徑問題我舉一個具體例子。業(yè)務(wù)那邊說“門店毛利”聽起來簡單。但實際算起來要不要扣掉后臺分攤成本租金和人工是算在總部還是算在門店退款訂單的毛利是紅沖還是忽略促銷贈品的成本算不算進去如果這些口徑不統(tǒng)一你問智能體“華東和華南哪個毛利高”它可能因為雙方的算法不同給出一份完全錯誤的對比。Fabric 里的語義模型本質(zhì)上就是把這類口徑問題固化下來變成可復(fù)用、可審計的指標資產(chǎn)。我通常在模型里做這樣幾件事用計算列和度量值把有效銷售額、毛利、庫存周轉(zhuǎn)天數(shù)等核心指標定義好建好維度層級比如大區(qū)→城市→門店→柜臺讓智能體可以逐層下鉆把指標描述寫清楚在語義模型的描述字段里說明“適用于什么場景、排除哪些數(shù)據(jù)”相當于給智能體一本指標說明書。這里有個細節(jié)我特別想提醒語義模型的描述文本質(zhì)量直接決定智能體能否正確選指標。模型會讀這些描述來判斷“當前問題該用哪個指標”。如果你只在度量值里寫一行公式?jīng)]有任何業(yè)務(wù)說明智能體很可能把“現(xiàn)金流量”和“營業(yè)收入”混著用。我在項目上花了大量時間打磨描述文本收益比繼續(xù)調(diào) Prompt 大得多。2.3 實時智能與事件通道讓智能體感知“正在發(fā)生的業(yè)務(wù)”大部分企業(yè)的分析場景是 T1 的昨天的數(shù)據(jù)今天看這沒有錯。但智能體要做的很多事并不適合等一天。比如庫存預(yù)警、門店客流異常、訂單積壓告警這些都是分鐘級的問題等到第二天再發(fā)現(xiàn)損失已經(jīng)造成了。Fabric 的實時智能模塊本質(zhì)是一個托管式的 Kusto 分析環(huán)境。我可以把訂單事件流、庫存變動流、門店打卡流接進去再讓智能體通過 KQL 查詢實時表。我自己實驗時接了兩路模擬事件流一路是訂單創(chuàng)建一路是退換貨然后給智能體加了一個工具“查詢最近 15 分鐘退貨率超過 10% 的門店”。效果很直觀智能體給出的答案不再是延遲半天的舊數(shù)據(jù)而是剛剛發(fā)生的事實。但我要坦白一句實時事件流是要花錢的吞吐量越大成本越高。所以我的建議不是“所有數(shù)據(jù)都上實時”而是按需分層。普通經(jīng)營分析繼續(xù)走 T1運營監(jiān)控走準實時只有真正需要秒級響應(yīng)的風控、告警才上事件流。智能體在工具描述里標明數(shù)據(jù)延遲讓模型自己判斷該查哪一層這是我在項目里用起來最順的折衷方案。2.4 Copilot 與開發(fā)鏈降門檻可以別指望全自動Fabric 平臺內(nèi)置的 Copilot在 Notebook 和 SQL 編輯場景里確實能幫忙。比如我寫管道清洗邏輯時讓它先生成一段 Dataflow 表達式或者在一個長 SQL 里讓它補全一段 Window 函數(shù)的寫法這些場景它發(fā)揮得不錯能省掉不少查文檔的時間。不過我基本不指望 Copilot 直接幫我把整個智能體鏈路搭好。原因很簡單智能體項目最大的復(fù)雜度不在“寫代碼”而在“理解業(yè)務(wù)”。業(yè)務(wù)口徑、權(quán)限邊界、事件路由這些問題Copilot 看不到也猜不出來它們需要的是人去梳理和定義。所以我的定位是Copilot 當副駕駛用主干工程還是自己來。把助手當主力容易在項目收尾時發(fā)現(xiàn)一堆隱性問題。3. 搭建“業(yè)務(wù)學(xué)習智能體”的完整實操鏈路零售門店診斷場景3.1 選場景先找一個邊界清晰、容易見效的業(yè)務(wù)問題智能體學(xué)業(yè)務(wù)我不建議一上來就做一個“全知全能”的超級智能體。邊界越寬不可控因素越多最后往往連及格都很難。我做第一個驗證項目時刻意選了一個邊界很窄的場景零售連鎖門店的經(jīng)營異常診斷。選擇它有三個原因。第一數(shù)據(jù)邊界清楚門店銷售、庫存、客流事件都是相對標準的數(shù)據(jù)不需要跨十幾個系統(tǒng)。第二判斷規(guī)則可以明確定義比如毛利波動、庫存周轉(zhuǎn)、退貨率這些指標都能預(yù)先設(shè)置閾值。第三動作可審計智能體輸出的結(jié)論只是“建議”最終由門店運營人員確認不會造成不可逆的后果。如果你也想復(fù)制這條路我建議用這四個標準篩選場景數(shù)據(jù)可得且穩(wěn)定、業(yè)務(wù)規(guī)則可以描述、判斷結(jié)果可以驗證、失敗不會造成大損失。滿足這四個條件就能作為第一個智能體項目落地。3.2 數(shù)據(jù)管道落地從 SQL Server 和 CSV 匯入 OneLake我的數(shù)據(jù)源主力是一套 SQL Server 業(yè)務(wù)庫外帶幾張手工維護的 CSV。整個匯數(shù)過程分四步在 Fabric 里建好工作區(qū)按業(yè)務(wù)域拆出銷售域、庫存域、門店域三個子域用 Data Factory 管道把 SQL Server 的訂單表、退貨表、產(chǎn)品表、門店表復(fù)制到 OneLake格式選 Delta并設(shè)置增量刷新手工 CSV 在 Notebook 里讀取做字段標準化、去重后寫出到湖里并在 Data Hub 登記歷史數(shù)據(jù)本來有一部分在外部數(shù)據(jù)湖里我直接建快捷方式掛載沒有重復(fù)搬遷。這個環(huán)節(jié)最常見的坑有三個我逐個說。第一個坑是時間字段時區(qū)混亂。門店分布在多個時區(qū)時如果統(tǒng)一用本地時間存做跨區(qū)域匯總就會亂。我的處理方式是清洗層統(tǒng)一存 UTC展示時再按門店時區(qū)轉(zhuǎn)換。智能體查詢時時間篩選條件一律用 UTC安全性會高很多。第二個坑是增量同步的機制。訂單表一旦量大每天全量復(fù)制既慢又費錢。我后來在源表加了水印字段管道按“大于上次最大水印值”增量拉取才算把這個坑填平。第三個坑是臟數(shù)據(jù)攔截。比如訂單金額為負數(shù)、日期早于門店開業(yè)日期這類問題如果不在一開始攔截后面會污染所有指標。我在管道出湖前加了數(shù)據(jù)質(zhì)量斷言不符合規(guī)則的行直接進異常表方便后續(xù)處理。3.3 定義語義模型讓智能體知道毛利到底怎么算數(shù)據(jù)進湖之后我花了一天時間建語義模型這是整個項目里性價比最高的一天。我建了一張“門店經(jīng)營指標”語義模型核心指標大概是這樣的指標計算口徑使用說明有效銷售額訂單金額 - 退款金額 - 贈品金額所有銷售額分析的基礎(chǔ)排除測試訂單門店毛利有效銷售額 - 已售商品成本 - 門店分攤租金及人工僅用于含分攤成本的經(jīng)營分析庫存周轉(zhuǎn)天數(shù)平均庫存 / 日銷售成本按 30 天滾動窗口計算門店退貨率退貨訂單數(shù) / 有效訂單數(shù)退貨率分析統(tǒng)一用此口徑這個表的價值不在于公式本身而在于它成了智能體和業(yè)務(wù)之間唯一的“契約”。業(yè)務(wù)人員說“毛利下降”智能體第一時間就通過語義模型知道這個毛利是扣了分攤成本的不是一個簡單的賬面數(shù)字。這樣雙方討論的才是同一件事。在語義模型描述里我還標注了指標適用的邊界條件比如“新店開業(yè)前三個月不參與同比分析”。這個細節(jié)在后來的反饋環(huán)節(jié)起了很大作用它是“學(xué)習”的起點。3.4 接智能體工具調(diào)用 SQL 端點 結(jié)果解讀有了數(shù)據(jù)有了語義接下來就是把智能體接上。我采用的是目前最主流的 LLM 工具調(diào)用方案整體結(jié)構(gòu)是這樣的給智能體配一個工具函數(shù)名query_sql_endpoint參數(shù)是標準 SQL 查詢語句System Prompt 里寫清楚業(yè)務(wù)摘要、指標定義、常用維度層級用戶提問進來后模型自己判斷該查哪些指標、生成什么 SQL、調(diào)用工具、拿到結(jié)果、再結(jié)合規(guī)則輸出結(jié)論。我給智能體的提示詞里有一段類似下面這樣的定義簡化后你是門店經(jīng)營診斷助手?？刹樵冎笜税?- effective_sales有效銷售額訂單金額-退款-贈品排除測試訂單 - store_gross_margin門店毛利扣除貨品成本、門店分攤租金及人工 - inventory_turnover_days庫存周轉(zhuǎn)天數(shù)平均庫存/日銷售成本30天滾動 - return_rate門店退貨率退貨訂單數(shù)/有效訂單數(shù) 規(guī)則新店開業(yè)前3個月不參與同比分析所有結(jié)論必須標注數(shù)據(jù)來源時間窗口如果查詢結(jié)果為空回答“暫無足夠數(shù)據(jù)”。這個設(shè)計有個關(guān)鍵點我想強調(diào)三遍查詢要拆碎不要寫大而全的 SQL。我一開始也試過讓模型一次把“各地區(qū)銷售、毛利、周轉(zhuǎn)率”全查出來結(jié)果它經(jīng)常寫出一大段 JOIN不是性能差就是結(jié)果錯。后來改成一次只查一張明細或一個指標模型分析錯誤率明顯下降速度也快很多。工具層我做了兩個保護一是查詢限定到指定 schema 視圖不允許它掃整表二是單次查詢最多返回 200 行避免結(jié)果集過大。這兩個限制看起來簡單但能擋掉大多數(shù)性能事故。3.5 反饋閉環(huán)把人的糾正“喂”回語義層這節(jié)我想聊“學(xué)習”這個詞因為這是最容易被忽視的一步。智能體上線兩星期后我發(fā)現(xiàn)它對“新店”這個場景還是會誤判。新店沒有歷史銷量但模型不知道這一點經(jīng)常會拿新店和成熟店做同比得出“異常下滑”的結(jié)論。這其實不是模型笨而是我漏掉了重要的業(yè)務(wù)知識。后來我在語義模型里加上“是否新店”標記并在提示詞里寫明“新店前 3 個月不參與同比分析”問題就明顯緩解了。這件事讓我意識到智能體的“業(yè)務(wù)學(xué)習”不是模型自己長出來的而是要有一個反饋機制把人的糾正持續(xù)灌回語義層和規(guī)則層。我的做法是在業(yè)務(wù)端加了一個簡單入口運營人員可以對智能體回答點“有用”“沒用”“口徑不對”。這些動作記錄會寫回 OneLake每周做一次復(fù)盤把高頻錯誤轉(zhuǎn)化為語義模型或規(guī)則調(diào)整。跑了一個多月之后智能體在常見問題上的表現(xiàn)肉眼可見地變好。沒有反饋閉環(huán)的智能體本質(zhì)上只是一個查詢工具有了它才談得上“學(xué)習業(yè)務(wù)運作”。4. 智能體學(xué)業(yè)務(wù)時最容易踩的四個坑4.1 權(quán)限邊界智能體只準看它該看的很多團隊在給智能體配數(shù)據(jù)權(quán)限時圖省事直接給一個高權(quán)限賬號。這在我這里是要堅決攔住的做法。智能體的查詢路徑是可被攻擊的你給了它全局讀取權(quán)限就等于讓任何能調(diào)用它的人都越權(quán)讀數(shù)據(jù)。Fabric 這塊我推薦的做法是三步走。第一調(diào)用的數(shù)據(jù)連接統(tǒng)一走固定身份啟用行級安全性第二語義模型按組織架構(gòu)配置 RLS 規(guī)則數(shù)據(jù)行自動帶區(qū)域標簽第三在智能體工具層做二次過濾只暴露預(yù)先定義好的視圖讓模型沒有機會去查模型之外的內(nèi)容。另外一個容易被忽略的地方是審計。智能體的每一次查詢、每一個建議最好都落日志。我在 Fabric 里開了操作審計把智能體的查詢 SQL、返回結(jié)果、時間點都記錄下來。做到這一步權(quán)限和追溯才算閉環(huán)。4.2 新鮮度分層實時數(shù)據(jù)不是免費的實時很好但每個實時事件流都有成本而且不是所有問題都需要秒級響應(yīng)。我?guī)蜆I(yè)務(wù)把數(shù)據(jù)分成三層T1 的離線層用于月度趨勢和戰(zhàn)略分析5 到 15 分鐘的準實時層用于運營監(jiān)控和異常預(yù)警秒級實時層用于訂單風控和設(shè)備告警。這個分層的核心是讓智能體在回答問題時能根據(jù)問題性質(zhì)選擇正確的數(shù)據(jù)源。具體到落地我會在工具描述里寫明“本工具數(shù)據(jù)延遲約 X 分鐘”讓模型自己判斷。比如“本月華東區(qū)銷售趨勢”就沒必要查實時流離線層足夠而“現(xiàn)在哪些門店排隊異常”必須走實時層。模型讀工具描述做選擇比人在代碼里寫死路由要靈活也更不容易出錯。4.3 幻覺治理讓結(jié)論帶著來源說話LLM 的幻覺問題在智能體里會被放大因為模型會用非常自信的口吻給你一個不存在的數(shù)字。我在項目里實測最有效的四條辦法如下強制結(jié)論標注來源智能體每次回答都必須寫“數(shù)據(jù)來源XX分析端點時間窗口XX”沒有來源的結(jié)論視為無效空結(jié)果回退查詢結(jié)果為空或行數(shù)過少時明確讓模型回答“暫無足夠數(shù)據(jù)”禁止它腦補規(guī)則優(yōu)先明確的業(yè)務(wù)規(guī)則放到提示詞或校驗函數(shù)里模型只做判定不做規(guī)則發(fā)明人工復(fù)核標記當某指標波動超過預(yù)設(shè)閾值系統(tǒng)自動給結(jié)論打上“需人工復(fù)核”標簽。第四點是我最想分享的。它的思路是既然模型的不確定性沒法完全消除那就把不確定性顯式地變成產(chǎn)品的一部分。當智能體說“華東區(qū)毛利率異常下降需人工復(fù)核”的時候業(yè)務(wù)人員知道這個時候要謹慎而不是無條件信任。這個設(shè)計比反復(fù)調(diào)試提示詞有用得多。4.4 別把智能體當決策者先讓它做有腦子的分析師最后一個坑也是最常見的坑項目做一半就想著讓智能體自動做決策自動下采購單、自動改價。我的態(tài)度很明確有腦子的分析師是當前最務(wù)實、最安全的階段。智能體真正自主決策需要極其嚴苛的校驗、回退和審計機制而大多數(shù)企業(yè)的數(shù)據(jù)質(zhì)量和系統(tǒng)連接根本撐不起這個目標。與其在一開始就追求“無人化”不如先實現(xiàn)“人機協(xié)同”智能體負責發(fā)現(xiàn)問題、給出建議、生成方案人負責確認和拍板。這個階段的價值一點不少而且風險小、容錯高。等你積累一段時間的數(shù)據(jù)反饋和信任再逐步擴大智能體的自主范圍這條路才走得通。5. 實測感受、局限和后續(xù)可以擴展的方向5.1 一周跑完鏈路后的真實體感從數(shù)據(jù)導(dǎo)入到智能體上線我差不多花了一周。給我最大工作量的不是智能體框架而是數(shù)據(jù)整理和口徑定義這個結(jié)論我說過好幾次但每次項目都會再驗證一次。跑完整個鏈路我最滿意的部分是“語義模型 SQL 端點”的組合。它讓智能體回答問題時基于的是企業(yè)真實指標而不是模型的內(nèi)部記憶。相比我之前做的純文檔 RAG這種結(jié)構(gòu)化語義檢索的方式在數(shù)字、比例、時間窗口這些容易出錯的點上準確率要好不少。當然它也遠沒到完美。比如有幾個情況它依然處理得不夠好一個模糊的問題里同時涉及多個指標和多個維度的復(fù)雜下鉆模型生成 SQL 的成功率會下降首次出現(xiàn)的新業(yè)務(wù)場景它依然會因為缺少知識而給出比較泛的結(jié)論。這些都需要靠持續(xù)的反饋積累來改善急不來。5.2 從“讀數(shù)據(jù)”到“做動作”的延伸思路如果后續(xù)想進一步有幾個方向我覺得值得關(guān)注。一是 Fabric 工作流和自動化的聯(lián)動。如果智能體判斷某門店需要補貨它可以觸發(fā)一個 Data Factory 管道把補貨明細清單生成好再由業(yè)務(wù)人員在系統(tǒng)里確認。這相當于給智能體接上了執(zhí)行的手腳但每一步依舊可以審計。二是多智能體協(xié)同。等數(shù)據(jù)域足夠規(guī)范可以拆出銷售智能體、庫存智能體、客服智能體各管一攤再由一個主智能體做匯總決策。這個方向很誘人但它對 Fabric 各域之間的血緣關(guān)系和指標一致性要求極高一旦兩個域?qū)ν恢笜丝趶讲灰恢轮悄荏w之間的對話就會變成雞同鴨講。三是和 Copilot 的融合。平臺本身也在持續(xù)強化自然語言能力比較理想化的前景是業(yè)務(wù)人員直接說“把華東退貨異常門店列出來”平臺自動完成取數(shù)、摘要、推送建議的全流程。這個體驗如果能做好智能體學(xué)習業(yè)務(wù)運作的成本會被進一步壓到極低。5.3 關(guān)于這類項目我最后想說的建議如果讓我給一個還沒開始做智能體數(shù)據(jù)平臺的人一句話我會說把“審計”放在“智能”前面。智能體每做一次查詢、每給一個建議都要留下完整日志。將來你糾錯、復(fù)盤、優(yōu)化提示詞靠的全是這些日志。我見過太多團隊興致勃勃做智能體結(jié)果數(shù)據(jù)鏈路混亂、口徑?jīng)]有收斂、日志丟失最后整個項目變成一個黑盒——誰都不知道智能體為什么這么回答那才是真正的災(zāi)難。微軟 Fabric 在這里承擔的不只是數(shù)據(jù)存儲或者報表平臺的角色。它更像是一張可以持續(xù)生長的“業(yè)務(wù)事實網(wǎng)絡(luò)”而智能體只是在這張網(wǎng)上爬行、推理、學(xué)習的乘客。把網(wǎng)織好比換一個更聰明的乘客更重要。