架構

資料倉儲獲得智能體控制面:Snowflake 的 thinking_effort、stage_mounts 與 dbt 的 Agents Schema

作者：IdeaBosque最後更新：2026年10月29日

2026 年 10 月 28 日,Snowflake 在 Cortex Agents 的 agent:run API 上發布了三項新控制:thinking_effort、instructions.system 與 stage_mounts(Snowflake 發布說明)。一個新的倉儲執行環境,如今把傳統上留給智能體平台自身的三件事暴露了出來 —— 模型思考多用力、執行環境執行哪些內部規則、以及智能體可以掛載哪些版本化產物。同一個月,Fivetran 與 dbt Labs 完成合併,「為可信賴的 AI 智能體打造資料基礎設施」,合併後的平台帶有 Agents Schema,讓智能體取得倉儲原生的脈絡,而不是臨時拼湊的擷取(Fivetran 新聞稿)。

本文梳理這三張 Snowflake 控制面、伴隨而至的脈絡層,以及它們沒有關上的邊界:審批、跨工具政策與稽核線仍屬於倉儲上方的協同運作層。對一個精簡團隊 —— 一個 Snowflake 帳號、兩名 dbt 開發者、智能體開始承接排程任務 —— 這是你第一次能在資料倉儲內部親手設定的控制項,而分清它們約束什麼、不約束什麼,正是治理與形式主義的分界線。

關鍵要點

Snowflake 於 2026 年 10 月 28 日發布三項智能體控制 —— thinking_effort(從 minimal 到 xhigh,因模型而異的取值子集)、instructions.system(在執行環境內部追加系統指令)與 stage_mounts(版本化暫存區掛載),全部落在 Cortex agent:run API 上(Snowflake 發布說明)。
stage_mounts 按版本而非分支綁定產物 —— 筆記本、Streamlit 應用、工作區與智能體均以版本化暫存區掛載;可寫的 workspace_mounts 保持不變,版本仍為 live(Snowflake 發布說明)。
dbt 與 Fivetran 完成合併後推出 Agents Schema —— 合併平台的自我定位是「為可信賴的 AI 智能體打造資料基礎設施」,把受治理的脈絡列放到智能體消費它們的位置(Fivetran 新聞稿)。
dbt × Amazon Redshift 資料共享(dbt 於 10 月 9 日、AWS 於大數據部落格先後發布文件)讓多叢集管道無需搬移一個位元組 —— 受治理的共享加上 SVV_* 中繼資料 API 與 datasharing 設定,取代「先擷取再拷貝」(dbt 部落格;AWS 大數據部落格)。
這些旋鈕約束的是推理力度、指令與掛載 —— 不是政策 —— 覆蓋資料倉儲、NetSuite、HubSpot 以及智能體觸達的其餘系統的審批、撤銷與稽核,仍留在協同運作層。

10 月 28 日發布了什麼,以及每項控制落在哪一層

thinking_effort 是推理力度旋鈕:取值範圍從 minimal 到 xhigh,並帶有因模型而異的取值子集,限制給定模型接受哪些值。實務上,它把模型算力從 API 側預設值變成了倉儲在每次執行中記錄的每次執行設定。讀取新鮮度表的排程智能體,並不需要和對帳發票明細的智能體相同的算力預算;在 10 月 28 日之前,這一區分住在呼叫模型的工作框架裡,如今則作為執行的一次性宣告參數由倉儲執行。

instructions.system 在執行環境內部追加系統指令。這是內部政策的插槽:你想附加到每一次智能體執行上的組織規則 —— 智能體可以彙整什麼、必須把什麼標記給人審、如何處理缺席的脈絡 —— 隨呼叫一同傳遞,而不是躺在某人的提示模板裡。這裡要誠實地說清楚:追加的指令不是一個權限系統。它們塑造執行環境內部的行為;它們不撤銷任何東西。

stage_mounts 是產物邊界。agent:run API 現在接受版本化暫存區掛載 —— 筆記本、Streamlit 應用、工作區,以及智能體本身 —— 而可寫的 workspace_mounts 保持不變,版本仍為 live。綁定到版本化暫存區的智能體,看到的是一組釘定的產物,而不是分支上此刻的任意狀態。這與智能體堆疊中其他地方管線釘定、清單釘定出自同一種直覺,只是落在了產物真正所在的倉儲邊界上。

下圖把三張控制面對照其上下兩層展開 —— 上面是政策留駐的協同運作層,下面是正在到來的脈絡與資料移動層。

脈絡層先到了

控制項只能對照著某個東西才有意義,而那個東西先在脈絡一側到位。Fivetran 與 dbt Labs 完成合併時給出了明確的論題:合併後的公司存在的意義是「為可信賴的 AI 智能體打造資料基礎設施」(Fivetran 新聞稿)。Agents Schema 把這個論題帶進了倉儲 —— 受治理、被建模的列,智能體消費它們的方式,就像儀表板消費指標表一樣,而不是智能體對著一個 SQL 端點反覆試錯拼湊出的臨時擷取。

資料移動的問題得到了同樣的處理。dbt 現已支援 Amazon Redshift 資料共享,AWS 的大數據部落格記錄了多叢集模式 —— SVV_* 中繼資料 API 與 datasharing 設定,在不複製一個位元組的前提下建構多叢集管道(dbt 部落格;AWS 大數據部落格)。對智能體而言,這就是「環境由受治理的共享組裝 —— 血緣與存取規則仍然成立」與「環境由擷取組裝 —— 每個副本都是新的存取問題」之間的區別。Dagster 圍繞同一論題的自我重新定位("Data your team trusts. AI that runs on it.")從協同運作器一側說了同一件事(Dagster)。

把三張面放在一起讀,就得到同一個模式:脈絡在它被建模的地方被治理,移動在它被共享的地方被治理,而推理力度、指令與掛載在執行發生的地方被治理。這是對一個問題「倉儲優先」的回答,而這個問題此前一直由智能體平台用各自的客製程式碼來回答。

這些旋鈕沒有關上的門

這些控制項不約束的是跨系統的政策。一個讀取倉儲定價模型、查詢 BigCommerce 庫存、再把獲批報價寫回 NetSuite 的智能體,跨越了三條廠商邊界和一條協定邊界。Snowflake 的參數恰好只治理其中一條邊界;發布說明裡沒有任何東西撤銷 BigCommerce 的權杖,instructions.system 也產生不了 NetSuite 裡的稽核記錄。審批、撤銷以及那條跨工具稽核線,必須留在協同運作層 —— 也就是把每個系統包裝成帶各自認證與日誌的型別化工具的模組模式(MCP 模組程式碼標準)。

有一個誠實的邊界要點明:發布說明記錄的是參數,不是保證。agent:run 呼叫的稽核行為 —— 記錄什麼、保留什麼、可否查詢 —— 我們審閱的說明中並沒有給出,而且因模型而異的取值子集意味著,一個團隊的 xhigh 是另一個團隊的不可用設定。把這三項控制當作宣告式輸入,在你的帳號上驗證稽核線,並把總開關(急停)留在資料倉儲上方(AI 治理清單)。

精簡團隊視角

對一個剛開始把排程智能體跑到資料倉儲上的中型市場團隊,10 月 28 日改變了開局對話的五個地方。盤點哪些智能體在觸碰資料倉儲 —— 排程的優先。按工作負載有意識地設定 thinking_effort:新鮮度檢查用 minimal,對帳用更高力度,並把哪個任務用了哪檔預算記錄下來 —— 這份映射就是你按單位計成本的故事。把組織政策一次性放進 instructions.system,而不是散落在每份提示模板裡各自維護。把排程智能體綁定到版本化暫存區掛載,讓智能體讀取的 Streamlit 儀表板,是有人測過它的那個版本,而不是今天早上變了樣的那個。並且把審批與撤銷留在協同運作器的清單裡 —— 資料倉儲控制的是一次執行長什麼樣;協同運作器控制的是一次執行被允許做什麼、留下了什麼。