Google Data Agent Kit：不懂 SQL 也能直接查資料庫，一個 CFO 的客單價問題怎麼被 AI agent 查到底

「我們的客單價好像在掉，你查一下為什麼。」

老闆丟完這一句就走了。你手上的訂單資料在一個地方，會員資料在另一個地方，行銷檔期的活動設定在第三個地方，可能還是行銷同事自己上傳的一份檔案。而你，不會寫 SQL。

Google Cloud Tech 的「Hands on AI」節目有一支影片，示範的就是這個情境。主持人是 Annie Wang（軟體工程師，她自己說沒什麼資料背景）跟 Jeff Nelson（Google Cloud 的 Developer Advocate，專做資料分析與資料工程）。他們用新的 Data Agent Kit，讓 coding agent 直接連上三個不同的資料來源，六句自然語言問到底，破了案。

我看完第一個念頭不是「太強了」。

我想的是另一件事：這支影片最值錢的一段，是 AI 差一點算錯，然後被一個測試擋下來。

Data Agent Kit 到底是什麼？兩個東西而已

先把名詞講清楚，不然後面會亂。

一句話講完：Data Agent Kit 是讓 coding agent 安全連上 Google Cloud 資料產品的一組 MCP 連接器加上 Agent Skills。它幫你把 SQL 的門檻降到零，但不會幫你補上商業定義、join 驗證跟權限治理。

Data Agent Kit 是 Google 官方推出的統一資料工具包，拆開來只有兩塊：

第一塊是 Agent Skills（代理技能），本質上就是一堆 markdown 檔，裡面寫著「在 BigQuery 該怎麼寫語法」「Spark 的 ML 任務長什麼樣」這類最佳實踐。

第二塊是 MCP servers（模型上下文協定的連接器），一鍵啟用之後，agent 就能安全連上 BigQuery、Cloud SQL、AlloyDB、Spanner、Knowledge Catalog。

Jeff 在影片裡的比喻是「地圖」跟「工具箱」。我換一個生意人聽得懂的講法：

你請了一個很會查資料的工讀生。MCP 是你發給他的門禁卡，決定他走得進哪幾個房間；Skills 是你塞給他的員工手冊，告訴他「我們公司退貨的訂單不算業績」這種規矩。

門禁卡不給，他寸步難行。手冊不給，他跑得飛快，然後把退貨也算進業績裡。

Skills 這個概念如果你還沒接觸過，我之前整理過 Andrew Ng 課程的 Agent Skills 重點，可以當背景補充，這裡就不重複展開。至於 MCP 該怎麼部署，也有另一篇對照表可以看。

比較有意思的是可攜性。VS Code 系（Antigravity IDE、Cursor 這類）裝擴充套件，CLI 系（Claude Code、Codex、Gemini CLI、Antigravity CLI）裝 plugin。影片裡他們刻意把同一個問題在 Antigravity 跟 Claude Code 各跑一次，兩邊答案一樣。

這代表它不綁 IDE，只綁你的資料在不在 Google Cloud 上。這句話後面會再回來咬人。

六句話破案：實際走一遍

案例公司叫 Cymbal Pets，賣寵物食品、玩具、用品，同時做 B2C 零售跟 B2B 批發。這是 Google 用來示範的虛構公司，底下所有數字都是示範資料，不是真實企業財報。

資料散在三個地方，而且各有各的道理：訂單放 BigQuery（orders 表將近 200 萬筆，欄位式資料庫，擅長大量聚合）；客戶、寵物檔案、商品放 Cloud SQL（交易型資料庫，擅長高並發的單筆更新）；行銷團隊的活動設定是一份 JSON 檔，丟在 Cloud Storage，因為那個團隊根本不用資料庫。

熟悉嗎？這就是你家的樣子。

接著是那六句話：

第一句：算出 2024 年 8 月到 2025 年 1 月每月的平均訂單金額。Agent 呼叫 BigQuery MCP 去列 dataset、列 table。結果出來：AOV 平常大約 110 美元，2025 年 1 月掉到大約 103 美元。

第二句：1 月比前幾個月低，拆解一下訂單類型。Agent 先跑 dry run 確認語法對不對，再真的執行查詢。結果：1 月開始冒出一種新的訂單類型「B2B wholesale」，在那之前只有 online 跟 offline 兩種。

第三句：這些 B2B 客戶是誰，把他們的 profile 拉出來。這次 agent 轉頭去查 Cloud SQL，找到數百個被標記為 business 的帳號，附上地理分布、公司清單、範例檔案。

第四句：這些人用了什麼促銷碼？回到 BigQuery，答案是 92% 的 B2B 訂單都用同一組碼「BIGORDER25」，折 25%。

第五句：這波活動是誰辦的？Agent 直接用 gcloud CLI 去翻 Cloud Storage 裡行銷團隊那份 JSON，確認這是一波刻意打 B2B 批發的推廣。

第六句：所以到底發生什麼事？

答案是：什麼壞事都沒發生。

客單價下降，是因為公司多了一條原本沒有、單價本來就比較低的批發通路，把整體平均拉下去了。原本的線上跟線下零售通路，健康得很。

過程中有兩個設計我覺得該給掌聲。一是每次 MCP 呼叫都會跳出授權確認，你可以選這次允許或永遠允許，Jeff 說得很白，他不想讓 agent「拿一堆他不同意的查詢去轟炸資料倉儲」。二是 dry run，先驗語法再花錢跑，畢竟 BigQuery 是按掃描量收費的。

人還在 loop 裡。這點做對了。

台灣電商版的同一齣戲，你一定看過

Cymbal Pets 的劇本，換成台灣的名字重演一次，你會發現自己演過。

你的「B2B wholesale」可能叫：開了團購通路、上了蝦皮商城、接了企業採購或經銷、做了福委會團訂、導入分期跟滿額贈、檔期加碼買三送一。

共同點是什麼？

新增的那條線，單價天生就比較低，但它的量體不小。於是總營收往上，平均客單價往下。老闆看報表只看到後面那個數字，然後你就被叫進去了。

我在雨傘產業待過七年，做過工廠業務，也站過百貨專櫃。這兩件事最大的差別，不在賣的東西不一樣，在價格結構根本是兩個世界。批發是走量的生意，專櫃是走毛利的生意。同一家公司、同一支傘，這兩個通路的單價本來就不該放在同一個平均值裡看。

以前我們是靠人腦記得這件事，記得「這個月有走批發，平均會被拉低」。現在你可以叫 agent 幫你拆，但它會不會主動想到要拆，取決於你有沒有問。

任何一個「平均值」型的指標，都有這個病。客單價、轉換率、CPA、平均停留時間，全部都是。平均值最擅長的事情，就是把兩群完全不同的人藏在同一個數字底下。

真正的重點：那個差點讓營收灌水三倍的 join

破完案之後，Jeff 做了一件很實務的事：要 agent 把這套分析 productionize，用 dbt（Data Build Tool，一個把 SQL 轉換納入版本控制與自動測試的開源框架）建成可以重複跑的 pipeline。

Agent 當場在本機裝了 dbt、自己寫 YAML 跟 SQL、跑 build、跑測試。這段很順。順到 Jeff 自己講了一句話，我聽到笑出來：agent 產出實作計畫請他確認的時候，他說「I'm not even going to read this. Click Proceed and hope for the best.」（我根本不打算讀，按下去，祈禱一切順利。）

然後就出事了。

下一步他要求把客戶跟寵物檔案併進來，並且特別交代一句：保留 order_id 的唯一性測試。

為什麼要交代這句？因為訂單表 join 寵物檔案表是一對多的關係。一筆訂單背後可能有三隻寵物。如果直接 join，一筆 100 美元的訂單會被複製成三筆 100 美元，帳面營收瞬間變成 300 美元。

這叫 fan-out join，資料圈的經典陷阱。

接下來的順序很重要，我照著逐字稿講：agent 寫出來的第一版，真的觸發了 fan-out，唯一性測試直接掛掉。是測試失敗之後，agent 才回頭讀 error log、自我診斷，改成先把寵物資料聚合成每張訂單一列、維持一對一關係再 join，重跑才通過。

看到了嗎？

抓到這個錯的，不是 AI 的聰明，是那句「保留唯一性測試」。

而那句話，是一個做過資料的人的肌肉記憶。Jeff 想得到，因為他被這種 bug 咬過。換成一個沒碰過資料的人坐在同一個位子上，這句話大概就不會出現，那份灌水三倍的報表就會一路長到老闆桌上。你如果是被叫進去查客單價的行銷主管，老實說，你也不會想到要交代這句。

台灣電商的同型陷阱，換三個更貼身的場景給你：

• 訂單表 join 訂單明細：一張單有三個品項，營收 ×3
• 會員表 join 標籤表：一個會員身上五個標籤，人數 ×5
• 訂單表 join 物流包裹：拆兩箱出貨，訂單數 ×2

不是我說，這三個坑，多數電商團隊都在某份報表裡踩過至少一個。差別只在有沒有被抓到。

這也呼應我之前寫過的柏克萊 DAB 基準測試：現成的前沿模型直接接上資料庫問問題，第一次答對率只有 38%，而調校過鷹架的方案能到 84.5%。差距不在模型，在你給它的東西。

Data Agent Kit 的 Skills、MCP 權限控制、dbt 的自動測試，本質上就是那個鷹架。

所以它真正在賣的東西是護欄，不是聰明。

順手做完的三件事，以及一個提醒

破完案、pipeline 也建好之後，影片還示範了三件事，前兩件我快速帶過。

一是預測。用 BigQuery 的 AI.FORECAST 函數推估下一季走勢，底層是 Google 的 TimesFM，一個預訓練的時間序列基礎模型，不用拿你的歷史資料重新訓練就能做零樣本預測。二是視覺化。要一份 Jupyter Notebook，agent 幾秒鐘生完，跑起來比人手動捲畫面還快，圖表涵蓋 AOV 趨勢、通路量體、各品類毛利率，順帶驗證了 B2B 批發的毛利率確實比直接面對消費者低。

第三件事才是電商該注意的：它不只會讀，還會寫。

在一個電商展示網站上，用自然語言要求新增商品，agent 呼叫 BigQuery 的 ML.GENERATE_TEXT（背後打 Gemini）生出商品描述、寫進資料庫，網站即時上架。接著發現搜不到這個新商品，因為語意搜尋需要的 embedding（向量）還沒生成。再一句話補上之後，用「my cat has a urinary issue」（我的貓有泌尿問題）這種完全不含商品關鍵字的說法，也能搜到相關商品。

全程沒寫一行 code。

第三件事最好用，也最危險。查詢做錯了，你拿到一份錯的報表；寫入做錯了，你的正式資料庫就髒了。而且是在一個「按下去、祈禱一切順利」的節奏裡髒的。

Google 自家人示範自家產品，要打幾折？

我一向的原則：有料才寫，有懷疑就講懷疑。這支影片是 Google 的 Developer Advocate 示範 Google 的產品，該打的折我列三個。

折扣一：示範資料太乾淨。 Cymbal Pets 的 schema 整齊、欄位有意義、order type 好好地填在該填的地方。你家的資料呢？欄位叫 col_3、日期格式三種混用、同一個通路在不同表裡有兩個名字、退貨用負數還是另開一張單沒人講得清楚。DAB 測試裡模型最常犯的錯，就是卡在這種地方。

折扣二：有一段根本不是這個套件做的。 讀 Cloud Storage 那份行銷 JSON，用的是 gcloud CLI，Jeff 自己在影片裡明說「this wasn't even part of the data Agent Kit」。所以「一個套件全包」的印象要修正一下，它包的是 Google Cloud 的資料產品。

折扣三：你的資料多半不在上面。 這是對台灣電商最實際的一刀。你的訂單在 91APP、Shopline 或 Cyberbiz 的後台，會員在 EDM 工具裡，廣告數據在 Meta 跟 Google Ads，檔期表在 Google 試算表。Data Agent Kit 接的是 BigQuery、Cloud SQL、AlloyDB、Spanner，不是這些。

所以工具你現在可能用不上。但這篇講的教訓，跟你用哪個工具無關。

還有一件事必須提醒。你給 agent 開了資料庫權限，它讀到的東西就會出現在它的產出裡。那份看起來只有三張圖的報表，背後可能夾帶著它一路讀過的客戶名單。這個破口我單獨寫過一篇：AI agent 資安風險最大的破口不在模型，開權限之前值得先看。

給台灣電商團隊的 5 個行動建議

► 第一，先問「這個平均被什麼混在一起了」，再問「是不是變差了」。 客單價、轉換率、CPA、ROAS，任何均值型指標，一律先按通路、客層、檔期拆開再說。很多「危機」拆完就消失了。

► 第二，下 prompt 的時候，把驗證條件跟問題一起講。 不要只說「算一下上個月客單價」，要說「算上個月客單價，排除取消跟退貨訂單，按通路拆開，訂單編號不能重複」。Jeff 那句「保留唯一性測試」，就是把驗證條件寫進需求。

► 第三，任何 join 完的數字，先對總額。 join 之前的營收總和跟 join 之後一不一樣？不一樣就是灌水了。這一步三十秒，能救掉一整場會議的誤判。

► 第四，查過一次的分析，固化成可重跑的東西。 不管是 dbt、排程 SQL 還是一張固定的報表。每個月重問一次 AI，你會拿到每個月都有點不一樣的答案，然後你分不清楚是生意變了還是模型今天心情不同。

► 第五，開權限之前先問三個問題：這個 agent 讀得到哪些表？它的產出會轉給誰？出事了查得到是誰讓它做的嗎？

如果這五條你只做得動一條，做第三條。今天就挑一張有 join 的既有報表，把 join 前後的營收總額對一次。

常見問題

Data Agent Kit 跟一般的 MCP server 差在哪？

它把 Google Cloud 幾個資料產品的 MCP 連接器（BigQuery、Cloud SQL、AlloyDB、Spanner、Knowledge Catalog）打包成一鍵啟用，另外多附一層 Agent Skills 教 agent 怎麼寫對語法。單一個 MCP server 只給你連線，這套多給了規矩。

Agent Skills 跟 MCP 到底差在哪？

MCP 是連接器，讓 agent 有能力執行查詢、列表、寫入。Skills 是知識指南，讓 agent 知道在這個環境裡該怎麼做才對。門禁卡跟員工手冊的差別。

不會寫 SQL，真的能查資料庫嗎？

能。影片裡的六個問題全部是白話中文等級的自然語言。但你必須知道該問什麼、該驗什麼，這部分沒有被自動化掉。

AI 查出來的數字可以直接給老闆嗎？

不要。至少做兩件事：join 前後對一次總額，以及請它把用的 SQL 印出來，確認時間區間跟排除條件符合你的定義。影片裡那個 fan-out bug，就是靠測試失敗才被發現的。

客單價下降一定是壞事嗎？

不一定。新增一條低單價高量體的通路，會同時讓總營收上升、平均客單價下降。先拆通路再下結論。

我的資料不在 Google Cloud 上，這篇還有用嗎？

工具用不上，方法用得上。「把驗證條件寫進 prompt」「join 完先對總額」「分析固化成 pipeline」這三件事，你用任何 AI 工具查任何資料庫都適用。

最後

以前你要會寫 SQL 才能碰資料，門檻卡在語法，卡在你會不會 join、懂不懂 group by。現在你只要會問問題，語法那關 agent 幫你過了。

門檻沒有消失。它搬家了。

從「會不會寫 SQL」，搬到「知不知道該驗什麼」。

而且搬家之後其實更兇險。以前你不會寫 SQL，你就跑不出東西，你會知道自己不會。現在你什麼都跑得出來，格式漂亮、有表格、有結論、還附一段執行摘要。一份正確的報表跟一份營收灌水三倍的報表，在螢幕上長得一模一樣。

如果你問我，這波工具真正拉開差距的地方在哪？

不在誰的 AI 比較強，在誰知道該對它的答案問第二個問題。

資料來源

• Data agent kit: Your coding agent can now query your data，Google Cloud Tech「Hands on AI」系列，2026 年 8 月 15 日。主講：Annie Wang、Jeff Nelson。文中 Cymbal Pets 相關數字（AOV 110/103 美元、92% 促銷碼比例、近 200 萬筆訂單）皆為影片中的示範資料。
• 柏克萊 DAB 基準測試數據引自本站文章柏克萊 DAB 基準測試解讀

協作聲明與免責

這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 [來源名稱](URL) 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。

內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。