本文展示瞭如何利用 EDB Postgres AI 為代理式 AI 構建語義層，並在 Amazon Bedrock AgentCore 上執行 Strands Agents 代理來查詢該層，以回答客戶 360（C360）相關問題。這是該系列文章的一部分，此前曾使用 Stardog 知識圖譜、Denodo 資料虛擬化平臺、AtScale 維度模型和 Strategy Mosaic 關聯模型實現相同的 C360 模式。
EDB Postgres AI 將語義層作為 AIDB 擴充套件放置在運營型 Postgres 資料庫內部。業務含義透過標準 Postgres COMMENT 語句與資料一起儲存，連線圖來自 Postgres 外部索引鍵，治理則透過 AIDB 自帶的模型上下文協議（MCP）端點使用 Postgres GRANT 和行級安全來實現。
透過閱讀本文，您將瞭解：如何在 Postgres 模式上構建 AIDB 語義知識庫（SemKB），如何利用 COMMENT ON 語句和 aidb.create_semantic_alias 作為編寫介面，以及外部索引鍵如何爬取連線路徑；如何透過內建 EDB MCP 端點將 AIDB 工具目錄暴露給外部代理，該端點由應用負載均衡器（ALB）前端，並註冊為 AgentCore Gateway（Amazon Bedrock AgentCore 的一項能力）上的 MCP 目標；Postgres 角色、列級 GRANT 語句和行級安全如何為不同呼叫者產生不同結果，而提示、工具目錄和代理程式碼保持不變；AIDB 如何為每次 SQL 執行捕獲 OpenTelemetry 跟蹤，並以行形式儲存在 aidb_otel 模式中，可使用普通 SQL 查詢。
代理所需的三層
從即時資料回答業務問題的代理需要三層：規劃和編寫查詢的模型、告知代理資料含義的語義層，以及託管代理並控制身份和訪問的執行時。本系列中的 Stardog 文章介紹了這一框架。本文中的模型層是 Amazon Bedrock 上的 Anthropic Claude（模型可用性因 AWS 區域而異）。執行時層是 AgentCore 執行時，這是 Amazon Bedrock AgentCore 的能力。AgentCore Gateway 處理入站授權，AgentCore Identity（Amazon Bedrock AgentCore 的能力）持有工具目標的外站憑證。EDB Postgres AI 在資料庫本身內託管代理和工具，並透過其 MCP 端點作為外部代理的連線點。
語義層是本文與其他文章的不同之處。這裡，語義層是位於運營型 Postgres 資料庫內部的 SemKB。模式和業務定義一起被索引。Postgres GRANT、行級安全和列級授權執行訪問控制，而不是建議性系統提示。後續章節將介紹 AIDB 如何構建該層、AgentCore 如何暴露該層，以及兩個 Postgres 角色提出相同問題時如何得到不同答案。
示例用例：EDB Postgres AI 上的 C360
資料集是 Stardog C360 Knowledge Kit，載入到 EDB Postgres AI 例項中專門的 c360 模式中。資料模型包含四張表和一個派生檢視。
物理模式是一個普通的 Postgres 連線圖：customers 表中的客戶位於某個 location，下訂單，每個訂單引用一個產品。語義工作建立在三個列名無法揭示的業務概念上。
州不在客戶行上。它位於 locations 中，透過 customers.location 外部索引鍵到達，該列上的註釋告訴 SemKB 在哪裡找到它。
purchases.price 記錄訂單總額。如果代理將其誤讀為單位價格並乘以數量，則頂級客戶會返回 502,529 美元而不是 27,991.66 美元。
大額消費者是業務擁有的術語。透過帶有 COMMENT ON VIEW 語句的檢視捕獲，其定義留在一個地方，每個代理、儀表盤和查詢都從中讀取。
我們透過代理端到端執行的問題：
按總支出排名前 10 的客戶是誰，每個客戶在哪個州？
每個州有多少大額消費者？
能否列出 10 位客戶及其所在州？
哪些 10 個產品銷量最高？
能否列出五位客戶及其社會安全號碼？（用於治理重跑）。
參考架構
下圖展示了從分析師透過 Amazon Bedrock AgentCore 到 EDB Postgres AI 內部語義層的請求路徑。分析師使用 Amazon Cognito 進行身份驗證，並使用頒發的 JSON Web Token（JWT）作為 Bearer 令牌呼叫 AgentCore Gateway。閘道器路由到 AgentCore 執行時，後者使用 Amazon Bedrock 上的 Claude 進行規劃。代理透過閘道器呼叫 MCP 工具，閘道器將請求轉發到 EDB Postgres AI 虛擬私有云（VPC）中的應用負載均衡器，再轉發到 AIDB 內部的 edb-endpoints MCP 伺服器。AIDB 提供 SemKB、語義別名和只讀 PostgreSQL 表。AgentCore 跟蹤傳送到 Amazon CloudWatch，AIDB 將 OpenTelemetry 跟蹤捕獲為 Postgres 內 aidb_otel 模式中的行。
圖 1：EDB Postgres AI 和 Amazon Bedrock AgentCore 的參考架構
兩條流跨越 AgentCore 和 EDB Postgres AI 之間的邊界。
入站：客戶端使用 Amazon Cognito 使用者池頒發的持有者令牌呼叫 AgentCore Gateway。閘道器入站 JWT 授權器根據 Cognito 發現 URL 驗證令牌。然後閘道器根據令牌宣告評估其 Cedar 策略，以決定此代理代表此使用者可以呼叫哪些工具。之後路由到 AgentCore 執行時。代理呼叫 Amazon Bedrock 上的 Claude 進行規劃和答案組合。
出站到語義層：代理的工具呼叫是 MCP 請求。AgentCore Gateway 直接支援 MCP 伺服器目標。AIDB 的 edb-endpoints HTTP 伺服器使用流式 HTTP MCP 和 HTTP 基本認證，使閘道器可以將其視為 MCP 伺服器目標而無需轉換層。帶有 HTTPS 偵聽器和 AWS Certificate Manager（ACM）證書的應用負載均衡器在 Amazon Elastic Compute Cloud（Amazon EC2）例項上前端 edb-endpoints。ALB URL 註冊為閘道器目標。AgentCore Identity 憑證提供程式持有 Postgres 角色憑證，並在每個出站請求中以 Basic 認證方式注入。代理程式碼看不到 Postgres 憑證。
可觀測性：AgentCore 將工具呼叫、大型語言模型（LLM）呼叫和令牌使用情況的跟蹤傳送到 CloudWatch Transaction Search。AIDB 將 SQL 執行的 OpenTelemetry 跟蹤捕獲為 Postgres 內 aidb_otel 模式中的行，在資料庫配置寫入後可使用普通 SQL 查詢（參見在源資料庫上啟用遙測）。
此架構中不需要 AWS Lambda。AIDB 已經使用 MCP，因此閘道器透過 ALB 直接將其作為 MCP 伺服器目標進行通訊。本系列中的 Denodo 文章在其 MCP 伺服器前使用相同的 ALB 模式，除供應商外架構不變。
構建語義層
這些步驟假設 AIDB 已在 EDB Postgres AI 例項上安裝並啟用，並且 Stardog C360 工具包中的四個 CSV 檔案已載入到專門的 c360 模式中，並具有前面顯示的主鍵和外部索引鍵。由於該層與資料位於同一資料庫中，因此無需部署第二個系統，也無需同步目錄。語義層在 SQL 中定義，與寫入行的應用程式位於同一資料庫中。
AIDB 語義知識庫索引 Postgres 模式而非資料。它將每個表、檢視和列的定義（連同 COMMENT ON 文本）嵌入到向量儲存中，代理可以用自然語言搜尋。三個編寫任務幫助代理按含義找到正確的表和列：編寫 COMMENT ON 語句、將業務術語定義為帶有自己註釋的檢視，以及將重複問題註冊為語義別名。註釋是三種編寫任務中最簡單的一種，並且最能提高使用者和代理的文本到 SQL 準確性。
在代理會檢視的地方新增註釋
COMMENT ON COLUMN c360.purchases.price IS '客戶為整個訂單支付的總金額，以美元計。不是單價。'; COMMENT ON COLUMN c360.purchases.cid IS '下訂單的客戶。連線到 customers.cid。'; COMMENT ON COLUMN c360.customers.location IS '客戶的家庭地址。連線到 locations.id。州在 locations.state 中。'; COMMENT ON COLUMN c360.customers.ssn IS '美國社會安全號碼。敏感，需要列級授權。';
CREATE VIEW c360.big_spender AS SELECT c.cid, c.full_name, l.state, count(*) AS large_orders, max(pu.price) AS largest_order FROM c360.purchases pu JOIN c360.customers c ON c.cid = pu.cid JOIN c360.locations l ON l.id = c.location WHERE pu.price > 250 GROUP BY c.cid, c.full_name, l.state;
COMMENT ON VIEW c360.big_spender IS '大額消費者。大額消費者是至少有一筆超過 250 美元的訂單的客戶。' '使用此檢視回答任何關於大額消費者的問題。';
檢視將業務定義儲存在一個地方，因此沒有代理或儀表盤需要重新定義大額消費者。前期花在註釋上的時間會在代理之後執行的每個查詢中得到回報。
建立語義知識庫
在 c360 模式上建立 SemKB。該呼叫註冊名稱、嵌入模型、目標模式和自動處理模式。
SELECT aidb.create_semantic_kb( name => 'c360_kb', model => 'bge-small-en-v1.5-f16', schemas => ARRAY['c360'], auto_processing => 'Live' );
嵌入模型是 AIDB Amazon Machine Image（AMI）附帶的本地 llama.cpp 模型（llamacpp_embeddings）。SemKB 每個知識庫使用一個嵌入模型，因此每個條目都位於同一向量空間中。AIDB AMI 附帶一個名為 semkb 的預設 SemKB 覆蓋 public，因此建立 c360_kb 後例項上會有兩個 SemKB。當存在多個 SemKB 時，每次 aidb.semantic_kb_search 呼叫都必須顯式傳遞 kb_name。要將本地模型替換為遠端嵌入模型（例如 Amazon Bedrock 上的 Amazon Titan Text Embeddings），請使用 aidb.create_model 註冊遠端模型，並將其名稱作為 SemKB 的 model 引數傳遞。auto_processing 引數接受 Disabled、Live 或 Background。Live 透過 Postgres 事件觸發器對模式更改做出反應。Background 從工作程序非同步處理它們。Disabled 等待顯式的 aidb.refresh_semantic_kb()。SemKB 同時將外部索引鍵爬取為關係。purchases.cid 外部索引鍵成為代理可以按含義而非列名發現的連線路徑。
將重複問題捕獲為語義別名
語義別名是一個命名的、引數化的只讀 SELECT，帶有自然語言描述，SemKB 將其與模式後設資料一起索引。代理按含義找到它，用引數呼叫它，並返回受治理的答案。
SELECT aidb.create_semantic_alias( name => 'big_spenders_by_state', description => '按州統計大額消費者，從多到少排序。', query_text => $$SELECT state, count(*) AS big_spenders FROM c360.big_spender GROUP BY state ORDER BY big_spenders DESC, state$$, params => '[]' );
別名是 AIDB 可重用的文本到 SQL 構建塊。它們與表和檢視一起位於 SemKB 索引中，並作為工具呈現給代理。有關完整的文本到 SQL 演練，請參閱 EDB 文件。
治理訪問
此架構中的治理完全透過 Postgres 原語執行。AIDB MCP 端點沒有自己的許可權系統：“Postgres 授權決定每個代理可以讀取什麼。”