EDB Semantic Layer 將代理存取規則置於 Postgres 之內
AWS 發布了一份 EDB semantic layer 操作指南，讓資料庫權限而非提示指令，決定代理可讀取哪些內容。這個於 11 月 3 日發布的示例，將 EDB Postgres AI 連接至 Amazon Bedrock AgentCore；後者是一組用於託管及連接軟件代理的 AWS 服務。其核心主張相當具體：將業務定義保留在營運資料附近，並在查詢執行的位置強制實施存取控制。
semantic layer 將業務語言與資料庫結構及計算方式連接起來。此處的代理使用 Strands Agents——一個用於建立可呼叫工具的代理框架——回答有關客戶活動的問題。當中的張力，在於靈活生成查詢與可靠控制之間的平衡。助理需要有足夠自由去理解問題，而資料庫擁有人則需要對其存取範圍設下可預測的限制。
與 Denodo——一個可查詢分散式來源的資料虛擬化平台——作比較，有助理解 EDB 的做法。兩者均為代理提供業務脈絡，但圍繞不同的資料架構來組織這些脈絡。對開發人員及企業買家而言，眼前的問題是：定義與權限應存放在哪裏，以及誰應負責維護它們。
EDB semantic layer 令資料庫含義更易被發現
這項改變是一種整合模式，讓外部代理可使用既有的資料庫定義。
這份 agentic semantic layer 操作指南，將 EDB 的 AIDB 資料庫擴充功能與運行於 AWS 的代理結合。其客戶示例使用四個資料表及一個衍生檢視表，即以資料庫物件形式呈現的已儲存查詢。業務描述來自資料庫註解，而外來鍵——連接相關紀錄的約束——則提供連接關係。
根據 AWS 的說法，該示例在更換資料庫憑證時，保持提示及代理程式碼不變。受限制的角色無法擷取受保護的社會保障號碼欄位。這是一項有用的區分：資料庫會在助理組織答案之前，拒絕嘗試存取的要求。
這仍然是一個由供應商撰寫的參考示例。它提出一種建議的實作方式並報告示範行為，而非提供企業範圍可靠性的獨立證據。讀者在對部署準備程度作出結論前，應先區分這些主張。
EDB 的文件說明了底層的 semantic knowledge base，即資料庫結構及描述的可搜尋索引。它為資料表、檢視表、欄位及註解建立索引，而非嵌入客戶紀錄。嵌入向量——用於相似度比對的數值表徵——有助代理透過自然語言問題尋找相關資料庫物件。
這項區分對評估十分重要。找到正確結構，並不代表生成的計算結果正確。它只是為模型構建查詢提供更佳素材。團隊仍需將答案與已認可的業務結果比對。
對任何想了解 EDB semantic layer 的人士而言，最有用的起點是理解發現與強制執行之間的分隔。描述有助代理判斷資料的含義；權限則決定其建議的查詢能否存取該資料。
這種安排亦改變了擁有權。一則資料庫註解會成為代理工作脈絡的一部分，而不再只是開發人員偶爾查閱的文件。不準確的描述應獲得與誤導性應用程式介面同等的重視。
設想一個假設的採購欄位，其名稱未能表明內容是單位金額還是訂單總額。兩種理解均可支援有效的算術運算，但只有其中一種符合業務定義，因此單憑成功執行無法識別錯誤。
這使這套架構的相關性超越其示範資料集。其價值取決於團隊能否將含糊的資料庫慣例，轉化為持續維護且可被發現的定義。代理連接將這項工作揭示為先決條件，而非令它消失。
資料庫擁有人承擔部分代理工作量
將含義移入 Postgres，讓資料庫團隊直接影響答案質素。
即時壓力落在負責 schema、報告定義及存取政策的人員身上。應用程式團隊可以改進助理的指示，但不能只靠措辭解決尚未釐清的業務定義。
假設銷售及財務部門對活躍客戶有不同定義：一方計算近期購買，另一方則要求帳戶狀況良好。若代理未加說明便選擇其中一種理解，便會產生一個看似比組織內部實況更明確的答案。
將定義保留在資料附近，可提供一個解決這種分歧的位置。它並不會判定哪個部門正確。仍然需要有人有權批准定義、說明其適用範圍及管理變更。
因此，除了架構本身，也應留意營運負擔。採用這種模式的團隊，應預期需要持續處理資料庫含義的編輯工作。審核描述會成為維護軟件代理所使用介面的一部分。
資料表之間的關係亦然。技術上有效的連接，未必自動表達問題所需的業務關係。買家應詢問：現有資料庫結構反映的是報告需求，還是僅支援應用程式交易。
當客戶擁有多個地址、帳戶擁有人或歷史分類時，這種差異便會浮現。關於現時地區的問題，與關於訂單發生時所屬地區的問題，需要不同理解。兩種答案都不應依賴未記錄的假設。
這些是評估情境，並非 EDB 實作方式的已報告故障。它們展示了即使 schema 發現能力更強，仍需要業務判斷的地方。一項有用的試點應刻意加入那些會因假設改變而答案不同的問題。
人手配置上的含義很直接。代理團隊需要接觸那些本已負責解決報告爭議的人員。否則，應用程式開發人員可能會成為他們無權界定的指標的非正式擁有人。
因此，企業買家應在評估代理示範的同時，評估維護流程。誰批准變更後的定義？哪些應用程式依賴它？組織如何發現助理正在採用過時的理解？
對工程團隊而言，可搜尋知識庫可保留這些決策背後的理據。資料庫定義與支援文件具有相關用途，即使它們存在於不同系統之中。
短期壓力是準備一個可信的試點。長期壓力則在於組織層面：隨着應用程式、報告要求及人員變動，持續維持業務定義的一致性。這套架構令這項責任更明顯，但只有在有人承擔時才有用。
經審核的查詢為靈活代理提供穩定參考
經常出現的業務問題值得採用可重用的查詢邏輯，即使用戶以不同措辭提出問題。
EDB 文件介紹了 semantic aliases，即配對可搜尋自然語言描述及已定義參數的命名查詢。別名必須包含單一唯讀 SELECT，即用於擷取結果的查詢。EDB 表示，它會在建立及執行別名時驗證這項限制。
從架構角度而言，這是在固定報告介面與不受限制的查詢生成之間的中間路線。用戶可透過對話方式表達熟悉的要求，而系統則有一個既有查詢可作參考。
以假設的地區銷售報告為例，經審核的邏輯可能已明確訂定報告期間、客戶分類及已取消訂單的處理方式。這些決策應能在用戶改變提問方式時維持不變。
這有別於要求模型每次重新建構所有決策。重新建構熟悉的邏輯，會帶來另一個產生差異的機會。重用則讓審核人員有一個更小、更具體的對象可供檢視。
不過，已儲存查詢本身不能解決理解問題。代理仍須識別合適的查詢，並提供適當參數。對季度活動的要求，不應悄然變成要求最近一個曆法季度。
這帶來不同的評估問題。系統是否辨識出預期的業務問題？它是否選擇了正確期間及範圍？傳回的說明是否準確描述該查詢所衡量的內容？
有利的資料庫結果只處理了這條鏈的一部分。助理可能擷取正確紀錄，卻錯誤地總結它們。相反，流暢的說明亦可能掩蓋一個回答了相鄰問題的查詢。
實際做法是為經常出現的要求保留參考答案。團隊可在改變措辭、日期及用戶權限的同時，將生成答案與這些參考資料比較。這能測試用戶實際會遇到的行為。
經審核的邏輯亦會建立更清晰的變更流程。若業務改變其定義，維護人員便可識別相關查詢並評估受影響輸出。沒有共享參考時，等同的定義可能在不同代理應用程式間逐漸偏離。
這項優點亦有界限。高度探索性的問題仍需要超越既有查詢目錄的理解。買家應評估系統在沒有接近匹配項目時的表現，包括它是否會要求澄清。
重要的產品行為是坦誠面對不確定性。能識別含糊要求的工具，可讓用戶有機會修正方向；自信地選擇不適用定義的工具，則會掩藏這個決策。
因此，評估 EDB 的做法時，最好將其視為一種組織可重用含義及查詢邏輯的方式。其效用取決於擷取質素、參數處理及審核做法能否共同發揮作用。任何一項均不應由另一項的成功示範推斷得出。
Denodo 突顯資料庫本地含義的界限
EDB 與 Denodo 的比較，取決於資料放置位置及營運責任。
AWS 早前的 資料虛擬化架構 使用 Denodo，連接分布於 Amazon Aurora、Amazon Redshift 及本地 PostgreSQL 資料庫的客戶資訊。資料虛擬化透過共享查詢層呈現分散式來源。該操作指南將業務檢視表及存取政策置於 Denodo。
相反，EDB 示例將含義集中在其營運 Postgres 資料庫之內。這項比較並未確立效能優勝者，而是展示了判斷業務定義應放置何處時，不同的起始條件。
對於相關資料已經集中在一起的團隊，值得考慮在資料庫本地定義語意。其組織層面的吸引力很直接：現有的資料庫維護人員有一個熟悉的位置，可檢視塑造答案的物件。
對於客戶資訊橫跨多個獨立系統的團隊，核心問題則更廣泛。系統必須協調這些系統之間的識別碼、定義與權限。加入代理介面不會消除這些整合決策。
因此，EDB 與 Denodo 之間值得探討的問題，在於業務問題的邊界。組織能否僅從其現時營運並受管治的資料庫回答問題？還是答案需要協調多個來源？
設想一位客戶經理想知道哪些客戶需要跟進續約。單靠採購歷史或許不足夠。合約狀態、尚未解決的支援個案及客戶歸屬，都可能影響答案。
若這些紀錄存放在其他地方，以資料庫為中心的試點應讓這項限制清晰可見。否則，根據現有紀錄得出的成功答案，可能被誤認為完整的客戶評估。缺失的資料來源會成為偽裝成技術成功的業務風險。
分散式方案亦有其評估負擔。連接資料來源不會自動證明其定義一致。採購方仍需檢視系統如何協調衝突的識別碼及報告期間。
兩種方案的核心張力仍然相同：靈活的代理需要持續維護的語意，以及可強制執行的存取控制。架構選擇決定這些責任集中在哪裏，而不是將其消除。
這亦是為何連接器數量並非完整的採購準則。連接器建立通往資訊的路徑，卻不代表某個特定問題在每個已連接來源中都有一致認可的定義。
團隊應以具代表性的業務請求及其完整依賴項比較不同架構。包括資料來源負責人、已核准的計算方法、存取限制及預期說明。這比泛泛討論代理功能更能揭示實情。
對 EDB 而言，機會在於讓現有資料庫結構成為可靠的代理基礎。其邊界同樣清晰：組織必須確定這個基礎能涵蓋其使用者實際提出問題的程度。
權限仍取決於到達 Postgres 的身分
只有當查詢以適當角色執行時，資料庫存取規則才能保護預期中的使用者。
EDB 的 MCP server 使用 Model Context Protocol，這是一個讓代理呼叫外部工具的標準介面。其文件指出，工具呼叫會以已驗證的 Postgres 角色執行。資料庫權限其後決定該角色可執行甚麼操作。
這為生產環境團隊帶來一個具體的審查重點。在應用程式邊界驗證某個人，以及選擇下游資料庫身分，是兩項不同責任。審查人員在接受任何關於使用者專屬存取的說法前，應追蹤兩者。
假設使用共用報告帳戶，便可說明這個問題。若每個請求都以該帳戶到達資料庫，資料庫規則便會評估該帳戶的權限。個人化的應用程式介面本身，並不能建立個人化的資料庫強制執行機制。
這並不代表共用帳戶在任何情況下都不適合。其含義是，帳戶的授權範圍必須符合預期的服務邊界。一個範圍狹窄的報告助理，與服務擁有不同存取權限使用者的助理，要求並不相同。
PostgreSQL 的 列安全性政策 限制角色可存取哪些紀錄。啟用後如沒有適用政策，列安全性預設會拒絕存取。然而，超級使用者及擁有 BYPASSRLS 的角色可繞過這些限制；除非被強制遵守，否則資料表擁有者通常亦可繞過限制。
在測試代理連線時，這些已記錄的例外情況相當重要。以管理員帳戶進行示範，無法證明一般使用者之間的隔離。評估人員需要驗證實際請求路徑中的有效角色及其權限。
欄位限制與列限制亦回答不同問題。隱藏敏感欄位，並不代表無法存取另一名客戶的紀錄。一項具說服力的評估，應測試應用程式所承諾的各個存取維度。
評估亦應包括透過其他問題嘗試存取。直接要求敏感欄位固然有用，但業務請求可能以意想不到的方式結合獲准的屬性。審查人員應檢視應用程式返回甚麼內容，以及它如何解釋限制。
權限強制執行亦不代表答案正確。角色可能獲授權讀取紀錄，但代理可能錯誤地組合這些紀錄。安全評估與分析評估應保持區分，並各自具備證據。
唯讀存取亦需要同樣精確的理解。防止寫入限制代理能透過該路徑改變甚麼，但不決定獲授權的結果是否包含應用程式應在特定情境展示的資訊。
這些限定是界定聲稱的範圍，而非否定其價值。資料庫強制執行機制為審查人員提供具體可檢視的內容。他們可檢查角色、權限、政策及已執行查詢，而不只是依賴助理所聲稱的意圖。
餘下工作是驗證應用程式是否始終以預期身分到達該強制執行點。這是部署責任，亦應在驗收證據中清楚呈現。
留意身分隔離、定義變更與可重複的答案
下一批有價值的證據，將顯示管治能否在使用者、定義及請求量改變時持續有效。
未來數月，採購方應留意能將這些維度連結起來的評估。就熟悉問題提供更多示範，所得資訊不及圍繞架構邊界設計的測試。
第一個訊號是已部署請求路徑中的身分隔離。尋找不同權限使用者獲得適當不同結果的證據。證據應識別有效的資料庫角色，而不只是顯示介面中的不同名稱。
隔離測試應包括嘗試執行超出使用者授權範圍的操作，以及資料庫的相應行為。一致的強制執行會加強對該架構的信心。無法解釋的憑證共用則會削弱使用者專屬管治的說法。
第二個訊號是定義變更如何影響答案。業務指標在應用程式的生命週期中，很少會一直維持不變。團隊應尋找展示定義更新，並驗證助理其後如何詮釋的案例。
有意義的證據包括轉換過程本身。助理是否採用修訂後的定義？審查人員能否辨識哪個定義支援先前的答案？受影響的參考答案是否透過明確程序更新？
成功處理變更，會強化將語意保留於已維護資料庫物件附近的論點。權責不清或過時的詮釋，則顯示僅僅共置並不足以帶來一致性。
第三個訊號是在具代表性的使用情況下，答案是否可重複地保持正確。評估應改變問題措辭、使用者權限及同時活動量。採購方需要了解在條件有別於原始示範時，系統是否仍然有用。
這並不要求把每個業務問題都當作基準競賽。它要求一組已聲明的預期行為。正確計算、恰當拒絕、可理解的限制及可接受的回應時間，各自都應有證據。
對尋求以營運角度理解 EDB semantic layer 的團隊而言，這些訊號提供實用的決策框架。它們將一項架構主張轉化為試點可回答的問題。
它們亦避免對哪個平台勝出作出缺乏支持的預測。最合適的實作將取決於資料放置、身分要求，以及組織維護定義的能力。應按這些條件評估以資料庫為中心的方案。
先從團隊已能可靠回答的業務問題開始，然後記錄其定義、預期結果及存取邊界。向審查人員提供足夠資訊，讓他們無須信任助理的說明亦能重現結果。以適當受限的身分執行相同請求，並連同回應一併檢視資料庫行為。接著，變更相關定義，並驗證答案是否遵循已核准的變更。使用 EDB semantic layer 測試一項具體的營運主張：你的組織可在查詢時強制執行存取控制的同時，維護共享語意。在擴展試點前，先問自己能否解釋每個重要答案及每個重要拒絕。
