2026 年 10 月 20 日，AWS 喺佢哋嘅機器學習博客（Machine Learning Blog）刊出「語義層系列」第三篇技術文章，主題係點樣喺 Amazon Redshift 上用 AtScale 建一個受治理嘅「客户 360」（Customer 360，即將客户資料分散喺唔同系統嘅數據整合埋）模型，再將佢暴露俾跑喺 Amazon Bedrock AgentCore 上面嘅 Strands 代理（agent，即能規劃、呼叫工具嘅 AI 系統）使用。
呢個係 AWS 同一系列嘅第三篇。第一篇用 Stardog 嘅知識圖譜（knowledge graph）做語義層，第二篇換咗 Denodo 嘅數據虛擬化平台，第三篇換入 AtScale。三篇都跟同一個 C360 範式，但 AtScale 嘅模型形態同前兩篇唔同：唔係三元組（triple）圖譜，亦唔係一組視圖，而係「維度化」（dimensional）模型——包含維度（dimensions）、層級（hierarchies）同度量（measures）。
值得留意嘅係 AtScale 將模型用「語義建模語言」（Semantic Modeling Language，SML）寫成——係一個開源、基於 YAML 嘅規格，可以用 Git 做版本管理——再將同一個已部署嘅模型，同時透過三種協定暴露：SQL、XMLA（XML for Analysis）同 MCP（Model Context Protocol，模型上下文協議）。呢個意思係 Strands 代理同企業原本喺用嘅 BI 工具，都從同一套定義攞到同一個計算結果，唔會因為「AI 問」同「人問」而對唔上數。
喺同一套架構入面，跑喺 Amazon Bedrock 上嘅基礎模型（示範用 Anthropic Claude Sonnet 4.6）負責規劃同寫查詢；AgentCore 負責託管 Strands 代理同管理佢向 AtScale 呈現嘅外發憑證（credential）。而 join（表關聯）、指標定義、行同欄位過濾，全部都喺語義層入面，唔喺 prompt（提示詞）入面。
文章仲講明咗幾個重點：AtScale 點樣規劃維度化查詢並用「自主聚合管理」（autonomous aggregate management）加速代理生成嘅查詢模式；點樣將 AtScale MCP server 註冊入 AgentCore Gateway（AgentCore Gateway 係 Amazon Bedrock AgentCore 嘅一個功能）；點樣將人類用户嘅身份，由企業身份供應商（identity provider）透過 AgentCore Identity（亦係 Amazon Bedrock AgentCore 嘅功能）傳遞到 AtScale，由 AtScale 喺查詢時執行基於角色嘅存取控制（RBAC）、行級安全同「視角」（perspectives）；最後係點樣用 AtScale Helm chart 同 K8S Blueprints 儲存庫將 AtScale 部署喺 Amazon EKS（Elastic Kubernetes Service）上面。文章聲明以 AtScale C2026.7 release 為示範依據。
阿調搞兩下：呢篇文章唔係講新模型，亦唔係講新產品，而係講「AI 代理點樣安全地攞數」呢個具體工程問題。AWS 用三篇系列文，將語義層同 AI 代理嘅整合示範咗三種唔同形態嘅技術路線（知識圖譜、數據虛擬化、維度建模）。對企業嚟講，真正有價值嘅唔係「用邊個語義層」，而係「join 同過濾喺邊度執行」呢個問題——文章明確講明呢啲邏輯喺語義層入面而唔喺 prompt，即係數據治理權限唔會因為加咗個 AI 代理而鬆散。呢個係好實際嘅架構決策。
阿調｜深度調教
