如何用 EDB Postgres AI 和 Amazon Bedrock AgentCore 为智能体 AI 构建语义层
Build a semantic layer for agentic AI with EDB Postgres AI and Amazon Bedrock AgentCore
AI 导读
文章演示了如何用 EDB Postgres AI 在运营 Postgres 数据库内构建语义层，并让运行在 Amazon Bedrock AgentCore 上的 Strands Agents 智能体通过该层回答客户 360（C360）问题。
摘要与补充说明
语义知识库（SemKB）以 AIDB 扩展形式存在，业务含义写在 Postgres COMMENT 语句中，连接关系来自外键，治理通过 GRANT 和行级安全实现，并经内置 MCP 端点暴露给外部智能体。
正文· AI 翻译
在这篇文章中，我们展示如何使用 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 模式里。数据模型有四张表和一个派生视图。
| 对象 | 关键列 |
customers |
cid、first_name、last_name、full_name、email、ssn、phone、picture、location（外键指向 locations.id） |
locations |
id、city、state、zip |
products |
id、name、brand、dept、price |
purchases |
id、cid（外键指向 customers.cid）、pid（外键指向 products.id）、date、quantity、price |
big_spender（视图） |
cid、full_name、state、large_orders、largest_order |
物理模式是一张普通的 Postgres 连接图：customers 表中的客户位于某个 location，会下 purchases，而每次购买都引用一个产品。语义层面的工作则依赖于三个列名无法揭示的业务概念。
州信息并不在客户行上。它存放在 locations 中，通过 customers.location 外键抵达，而该列上的注释告诉 SemKB 去哪里找到它。
purchases.price 记录的是订单总额。若智能体将其误读为单价并乘以 quantity，那么对最大客户返回的将是 $502,529，而非 $27,991.66。
Big spender 是业务方拥有的术语。以 COMMENT ON VIEW 语句将其捕获为视图后，其定义就集中在一处，供每个智能体、仪表盘和查询读取。
我们端到端通过智能体运行的问题：
- 按总支出排名，我们的前 10 大客户是谁，各自位于哪个州？
- 每个州有多少 big spender？
- 能否列出 10 位客户及其各自所在的州？
- 哪 10 款产品的销量最高？
- 能否列出五位客户及其社会安全号码？（用于治理重跑）。
参考架构
下图展示了从分析师经 Amazon Bedrock AgentCore 到 EDB Postgres AI 内语义层的请求路径。分析师通过 Amazon Cognito 进行身份验证，并以签发的 JSON Web Token（JWT）作为 Bearer 令牌调用 AgentCore Gateway。Gateway 将请求路由到 AgentCore 运行时，后者使用 Amazon Bedrock 上的 Claude 进行规划。智能体通过 Gateway 调用 MCP 工具，Gateway 将其转发到 EDB Postgres AI 虚拟私有云（VPC）中的 Application Load Balancer，再转发到 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。Gateway 的 入站 JWT 授权器根据 Cognito 发现 URL 验证该令牌。随后 Gateway 根据令牌的声明评估其 Cedar 策略，以决定该智能体代表此用户可调用哪些工具。然后它将调用路由到 AgentCore 运行时。智能体调用 Amazon Bedrock 上的 Claude 进行规划和答案撰写。
出站至语义层： 智能体的工具调用是一个 MCP 请求。AgentCore Gateway 直接支持 MCP 服务器目标。AIDB 的 edb-endpoints HTTP 服务器支持 带 HTTP Basic 身份验证的可流式 HTTP MCP，这使 Gateway 可以将其视为 MCP 服务器目标，无需转换层。带有 HTTPS 监听器和 AWS Certificate Manager（ACM）证书的 Application Load Balancer 位于 Amazon Elastic Compute Cloud（Amazon EC2）实例上的 edb-endpoints 前端。ALB URL 被注册为 Gateway 目标。AgentCore Identity 凭证提供程序持有 Postgres 角色凭证，并在每个出站请求中将其作为 Basic 身份验证注入。智能体代码看不到 Postgres 凭证。
可观测性： AgentCore 会将工具调用、大语言模型（LLM）调用以及 token 使用情况的追踪数据发送到 CloudWatch Transaction Search。AIDB 会将 SQL 执行的 OpenTelemetry 追踪作为行捕获到 Postgres 内的 aidb_otel schema 中，在数据库配置为写入这些追踪后，即可用普通 SQL 查询（参见在源数据库上启用遥测）。
此架构中不需要 AWS Lambda。AIDB 本身已支持 MCP，因此 Gateway 直接通过 ALB 将其作为 MCP 服务器目标进行通信。本系列中关于 Denodo 的文章在其 MCP 服务器前使用了相同的 ALB 模式，除供应商不同外，这里的架构没有变化。
构建语义层
这些步骤假设 AIDB 已在 EDB Postgres AI 实例上安装并启用，并且 Stardog C360 套件的四个 CSV 已加载到专用的 c360 schema 中，其中包含前面展示的主键和外键。由于该层与数据位于同一数据库中，因此无需部署第二个系统，也无需同步目录。语义层以 SQL 定义，与写入这些行的应用程序位于同一数据库内。
AIDB 语义知识库索引的是 Postgres schema，而不是数据。它将每个表、视图和列的定义（连同 COMMENT ON 文本一起）嵌入到向量存储中，代理可以用自然语言搜索该存储。三项编写任务可帮助代理按含义找到正确的表和列：编写 COMMENT ON 语句、将业务术语定义为带有自身注释的视图，以及将重复出现的问题注册为语义别名。注释是三项编写任务中最简单的一项，并且对用户和代理而言，都能最大程度地提升 text-to-SQL 的准确性。
在代理会查看的位置添加注释
COMMENT ON COLUMN c360.purchases.price IS
'Total amount the customer paid for the entire order, in US dollars. Not the unit price.';
COMMENT ON COLUMN c360.purchases.cid IS
'Customer who placed the order. Joins to customers.cid.';
COMMENT ON COLUMN c360.customers.location IS
'Home address of the customer. Joins to locations.id. State is in locations.state.';
COMMENT ON COLUMN c360.customers.ssn IS
'US Social Security number. Sensitive, column-level grant required.';
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
'Big spenders. A big spender is a customer with at least one order over 250 US dollars. '
'Use this view for any question about big spenders.';该视图将业务定义集中在一处，因此任何代理或仪表板都不必重新定义大额消费者。前期花在注释上的时间，会在代理之后运行的每一次查询中得到回报。
创建语义知识库
在 c360 schema 上创建 SemKB。该调用会注册名称、嵌入模型、目标 schema 以及自动处理模式。
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 事件触发器响应 schema 变更。Background 由工作进程异步处理这些变更。Disabled 等待显式的 aidb.refresh_semantic_kb()。SemKB 同时还会将外键爬取为关系。purchases.cid 外键会成为代理可按含义（而非按列名）发现的连接路径。
将重复出现的问题捕获为语义别名
语义别名是一个命名的、参数化的只读 SELECT，带有自然语言描述，SemKB 会将其与 schema 元数据一起索引。代理按含义找到它，用参数调用它，并返回受治理的答案。
SELECT aidb.create_semantic_alias(
name => 'big_spenders_by_state',
description => 'Count big spenders grouped by state, ordered from most to fewest.',
query_text => $$SELECT state, count(*) AS big_spenders
FROM c360.big_spender
GROUP BY state
ORDER BY big_spenders DESC, state$$,
params => '[]'
);Alias 是 AIDB 可复用的 text-to-SQL 构建块。它们与表和视图并列出现在 SemKB 索引中，并以工具的形式呈现给 agent。完整的 text-to-SQL 演练请参阅 EDB 文档。
管控访问
此架构中的治理自始至终都通过 Postgres 原语实现。AIDB MCP 端点本身没有权限系统：“Postgres 授权决定每个 agent 可以运行什么”（MCP 端点参考）。每个 MCP 请求都通过各自的连接使用 Postgres 用户名和密码进行身份验证，因此每次工具调用中的 current_user 就是该 agent 的角色，与其他连接一样可在 pg_stat_activity 中看到。
下图展示了身份如何从最终用户经由 AgentCore 流向评估 SQL 的 Postgres 角色，以及由此产生的追踪记录如何被捕获以供审计。该链路分为四个阶段：Gateway 处的入站信任、来自 AgentCore Identity 的出站凭证、Postgres 中通过 GRANT 和行级安全实施的强制执行，以及通过 aidb_otel schema 中的 OpenTelemetry 追踪进行的审计。
图 2：从最终用户到评估 SQL 的 Postgres 角色的身份传播链
Gateway 处的入站信任： 1. 最终用户通过 Amazon Cognito 进行身份验证，并获得 JWT 持有者令牌。2. 客户端在 Authorization 请求头中携带该令牌调用 AgentCore Gateway。3. Gateway 的 JWT 授权器根据 Cognito 用户池的发现 URL 验证该令牌。4. Gateway 根据令牌中的声明评估其 Cedar 策略，以决定该 agent 可以调用哪些工具。
发往 AIDB 的出站凭证： 5. Gateway 从 AgentCore Identity 凭证提供程序解析 MCP 目标的出站凭证。对于 AIDB，这是一个用作 HTTP Basic 认证的 Postgres 用户名和密码。6. Gateway 将 MCP 可流式 HTTP 请求转发到 ALB，ALB 再将其转发到 edb-endpoints。
Postgres 中的强制执行： 7. edb-endpoints 使用 Basic 认证头中的用户名和密码打开 Postgres 连接。Postgres 根据 pg_hba.conf 对登录角色进行身份验证，而工具调用中的 current_user 就是该角色。8. c360 表上的列级 GRANT 语句和行级安全策略会限制工具调用返回哪些行和列。拒绝会以受限表或列上的 Postgres 权限拒绝错误形式出现，MCP 端点会原样转发该错误。
审计。9. AIDB 将 SQL 执行的 OpenTelemetry 追踪捕获为 aidb_otel schema 中的行，可立即通过 SQL 查询。
两个 Postgres 角色，同一个问题，不同结果
定义两个 agent 登录角色，它们仅在列级 GRANT 上有所不同：mcp_agent_full 可以看到所有列，mcp_agent_restricted 可以看到除 customers.ssn 之外的所有列。
CREATE ROLE mcp_agent_full LOGIN PASSWORD '...';
CREATE ROLE mcp_agent_restricted LOGIN PASSWORD '...';
GRANT USAGE ON SCHEMA c360 TO mcp_agent_full, mcp_agent_restricted;
-- Both roles need aidb_users to list MCP tools
GRANT aidb_users TO mcp_agent_full, mcp_agent_restricted;
-- Full role sees every column
GRANT SELECT ON ALL TABLES IN SCHEMA c360 TO mcp_agent_full;
-- Restricted role sees every table and view, with customers.ssn withheld
GRANT SELECT ON c360.locations, c360.products, c360.purchases, c360.big_spender
TO mcp_agent_restricted;
GRANT SELECT (cid, first_name, last_name, email, phone, picture, location, full_name)
ON c360.customers TO mcp_agent_restricted;两个登录角色都需要在 pg_hba.conf 中为本地 edb-endpoints 连接路径配置密码认证条目，详见 配置你的 agent 角色。通过这两个角色运行同一个问题会产生不同的结果。以 mcp_agent_restricted 身份调用的 agent 无法投影 ssn 列：一旦尝试，Postgres 就会返回 permission denied for column ssn，MCP 端点会原样转发该错误。随后该 agent 会回应称它无法读取 SSN。两个角色之间的提示词、工具目录、SemKB 和 agent 代码完全相同。唯一的区别在于 AgentCore Identity 在出站 Basic 认证头上注入的凭证。
行级过滤遵循同样的模式。在目标表上启用行级安全（RLS），并附加按角色划分的 USING 策略。AIDB MCP 端点看到的行，与该角色在直接 psql 连接中看到的行相同。
关于 AIDB purposes 的说明。 AIDB 还提供了 purposes，这是一种策略抽象，可将数据库内代理（使用 aidb.create_agent 创建、通过 aidb.agent_converse 调用的代理）限制在指定的 Postgres 角色内。Purposes 适用于数据库内代理路径。本文使用的外部 AgentCore 路径则如前所述，在 MCP 端点处直接通过 Postgres 角色进行管控。如需审计外部 MCP 代理，请参阅 EDB Agent Governance，它会读取相同的 aidb_otel span，并将代理会话和策略决策可视化。
负责任 AI 方面的考量。 到目前为止展示的治理面控制的是代理在数据库层可以执行什么。请在模型侧配合使用 Amazon Bedrock Guardrails，以约束代理被允许生成什么：针对敏感话题的内容过滤器、拒绝话题列表以及 PII 脱敏。这两层互为补充。Postgres GRANT 阻止代理在数据层读取 SSN。Guardrails 则有助于防止 PII 模式通过模型响应中的其他路径泄露。对于基于客户数据回答业务问题的代理而言，两者都是生产环境中的控制措施。
暴露该层并运行代理
启用 AIDB MCP 端点需要设置两个 Postgres 参数并重启。在 postgresql.conf 中设置 edb.endpoints_mcp_enabled = on，将 aidb 添加到 shared_preload_libraries，然后重启（启用端点）。要从 EC2 实例外部访问该端点，请将 edb.endpoints_mcp_host 设置为非回环地址，例如 0.0.0.0。使用 edb.endpoints_mcp_port 选择端口（默认为 8765）。通过 edb.endpoints_mcp_tls_cert 和 edb.endpoints_mcp_tls_key 提供传输层安全（TLS）证书对，该端点在非回环绑定时需要此证书对（配置端点）。
带有 HTTPS 监听器和 ACM 证书的 Application Load Balancer 将 edb-endpoints 暴露给 AgentCore Gateway。ALB 目标组通过 HTTPS 连接到 EC2 实例的 8765 端口，并且不验证后端证书链，因此 edb-endpoints 上的自签名证书足以用于开发和测试。在生产环境中，请使用内部 ALB 配合 AgentCore Gateway VPC 出口，以保持 Gateway 与 ALB 之间的连接为私有。
创建一个带有 Cognito 授权方的 AgentCore Gateway，将 ALB URL 注册为 MCP 服务器目标，并将两个 Postgres 凭据存储在 AgentCore Identity 凭据提供程序中（凭据提供程序参考）。
该代理是一个简短的 Python 脚本。它使用 Strands Agents 将一个指向最新 Claude Sonnet 的 BedrockModel 连接到一个 MCPClient。MCPClient 通过 streamable HTTP MCP 传输连接到 Gateway URL，并将 Cognito 访问令牌作为 Bearer 请求头。系统提示指示代理首先调用 semantic_kb_search 以获取模式上下文，传入 kb_name => 'c360_kb'，然后调用 execute_sql 来运行生成的查询。带有 Strands 的 AgentCore 运行时入门工具包提供了一个在生产环境中托管此类代理的完整示例。
我们建议为代理的系统提示启用 Amazon Bedrock 提示缓存。相同的指令和相同的工具列表在每次调用时都会被复用，这正是提示缓存的用途。
示例查询与验证
通过代理提出四个问题，外加一次治理重跑，全部针对之前加载的 C360 数据。
查询 1：按总消费额排名，我们的前 10 大客户是谁，各自位于哪个州？
如果没有 purchases.price 上的注释，仅配置了 SQL 执行工具的 agent 会把 price 读作单价，再乘以 quantity。返回的第一行是 Carolyn Inworth 的约 $502,529，这是错误的。由 SemKB 索引的一条列注释，就是该答案与正确答案之间的全部差异：
full_name | state | spent
-------------------+----------------+----------
Carolyn Inworth | Wisconsin | 27991.66
Marlane Shadwick | Florida | 22677.05
Isaac Popping | Pennsylvania | 20085.96
Bria McKellar | Texas | 19588.80
Mike Laydel | Louisiana | 18651.28
Fayette Mor | Arizona | 17993.69
Reynard Perigoe | Florida | 17019.55
Humfrey Fores | California | 16811.16
Patrice Jakeway | California | 16656.72
Mord Pettus | North Carolina | 16604.37相同的模型、相同的提示词、相同的工具目录。语义知识库改变了答案。
查询 2：每个州有多少大额消费者？
agent 通过 semantic_kb_search 找到 big_spender 视图，因为其 COMMENT ON VIEW 与自然语言问题匹配。业务定义只存在于一个地方：
state | big_spenders
----------------------+--------------
Florida | 46
Texas | 46
California | 42
District of Columbia | 24
New York | 23
...如果业务后来将大额消费者重新定义为累计消费超过 $5,000 的客户，那么改动只是一条 CREATE OR REPLACE VIEW 语句。SemKB 下次刷新时，每个 agent 都会看到新定义。
查询 3：列出 10 位客户及其各自所在的州
州信息在 locations 中，而不是 customers 中。连接路径编码在 customers.location 外键和列注释中，二者都由 SemKB 索引。agent 生成：
SELECT c.cid, c.full_name, l.state
FROM c360.customers c
JOIN c360.locations l ON l.id = c.location
ORDER BY c.cid
LIMIT 10; cid | full_name | state
-----+-----------------------+----------------
1 | Jolynn Bithany | Texas
2 | Mord Pettus | North Carolina
3 | Lavinie Stannislawski | Florida
4 | Kimball Evenett | Alabama
5 | Linnie Meatcher | California
6 | Lorens Stoneley | Washington
7 | Juliane Gerhartz | California
8 | Jacob O'Lyhane | Utah
9 | Terrel Seller | Missouri
10 | Jannel Gawthrope | California查询 4：哪 10 款产品的销量最高？
一个在 Postgres 内、紧邻数据执行的普通聚合：
SELECT p.name, sum(pu.quantity) AS units
FROM c360.purchases pu
JOIN c360.products p ON p.id = pu.pid
GROUP BY p.id, p.name
ORDER BY units DESC, p.id
LIMIT 10; name | units
--------------------+-------
Markers | 160
Cleaning Wipes | 155
Playset (Girl's) | 146
Queen Sheet Set | 138
Mechanical Pencils | 137
Shot Glasses | 133
Parchment Paper | 127
American Cheese | 127
Pop Music | 127
Varnish | 125治理重跑：列出五位客户及其社会安全号码
同一提示词运行两次。在 mcp_agent_full 下，agent 返回五行客户记录，其 ssn 值已填充。在 mcp_agent_restricted 下，agent 的工具调用失败，并返回 Postgres 错误 permission denied for column ssn，agent 则回复一条简短消息，说明此调用方无法访问 SSN。该失败由列级 GRANT 强制执行，而不是由提示词或模型强制执行。AIDB 在 aidb_otel 中捕获 SQL 执行的 OpenTelemetry trace，因此审核人员之后可以查询该 trace 行来确认治理决策。
扩展到跨数据源
对于超出运营数据库能力的分析工作负载，EDB Postgres Analytics Accelerator (PGAA) 让 Postgres 通过 Iceberg REST catalog 读取对象存储中的 Apache Iceberg、Delta Lake 和 Parquet 表。EDB Postgres AI 分析概览 涵盖了端到端设置。PGAA 表在 Postgres 中显示为普通表，因此相同的 SemKB 描述可继续用于分析副本，agent 的工具目录也无需更改。
对于联合到外部关系型数据源，Postgres 外部数据包装器 使外部表像本地表一样可访问。无论哪种情况，语义层都保持不变，因为业务定义、列注释和语义别名都位于 Postgres 中。
部署
此架构有两种可行形态。
在 Amazon EC2 上自管理。 使用 AWS Marketplace 中的 EDB Postgres AI Agent Factory AMI。客户拥有 VPC、子网、版本节奏以及 EDB Postgres AI 软件升级。ALB 和 AgentCore Gateway 目标配置与前述架构相同。
在 Amazon EC2 上由 EDB 管理。 EDB Managed Database 是一项由 EDB 专家代表客户处理数据库管理的服务。AgentCore 侧保持不变。
结论
可靠的智能体分析需要三个部分协同工作：一个能够规划并生成查询的基础模型，一个提供受治理的数据业务视图的语义层，以及一个托管智能体并管理身份的智能体运行时。Amazon Bedrock 提供模型，Amazon Bedrock AgentCore 提供运行时，EDB Postgres AI 提供位于运营 Postgres 数据库内部的语义层。业务含义、连接路径和治理来自架构中已有的 Postgres 原语。AWS 侧与本系列其余部分相同：AgentCore Gateway、Runtime、Identity、Bedrock 和 CloudWatch。
数据、业务定义和访问规则都存放在同一个 Postgres 架构中，因此无需维护单独的目录来保持同步。审计也存放在同一个数据库中：aidb_otel 为每次工具调用保存一个 span，与其所针对的数据放在一起。
从哪里开始
要将此架构应用于你自己的数据，请按以下步骤操作：
- 选择一个你的智能体需要实时查询的 Postgres 数据库。范围越窄越好。
- 为智能体的数据创建一个专用架构，并将
GRANT USAGE限定到某个服务角色。 - 在列和视图上编写使用业务语言的
COMMENT ON语句。用COMMENT ON VIEW语句将业务术语捕获为视图。 - 使用
aidb.create_semantic_kb和auto_processing => 'Live'（或在写入量大时使用Background）在该架构上创建 SemKB。 - 将反复出现的问题注册为语义别名。
- 启用 AIDB MCP 端点，在其前端部署带 HTTPS 和 ACM 证书的 ALB，并将 ALB URL 注册为 AgentCore Gateway MCP 服务器目标。
- 通过智能体运行三个真实问题，然后在权限被缩减的角色下重新运行其中一个，以确认强制执行面能够端到端正常工作。
关于作者
Rajesh Nagpal
Rajesh 是 EDB 的 AI 产品副总裁，领导将 AI 原生引入 Postgres 的工作，从数据库内推理到使 EDB Postgres 成为 AI 智能体的坚实基础。在超过 25 年的时间里，Rajesh 曾在 Microsoft、Oracle、Compass 和 Meta 领导工程和产品组织。
Brady Paterson
Brady 是 EDB 的高级主任软件工程师，从事 AI Database（AIDB）的工作——这是一个将向量搜索、知识库和 MCP 服务器引入 Postgres 的 Postgres 扩展——并负责将其交付到 AWS。Brady 在云基础设施和 Kubernetes 平台领域拥有超过 12 年的经验，包括在 IBM 的八年以及在多家初创公司和孵化器的任职经历。
Ian Kinsey
Ian 是 EDB 的高级主任工程师，构建将 AI 引入 Postgres 中企业数据的系统。他此前曾担任初创公司 Mercator 的 CTO，并在超过 15 年的时间里在 Uber 和 LiveRamp 等公司构建大规模数据系统。
Henning Els
Henning 是 Amazon Web Services（AWS）的高级解决方案架构师。Henning 持有所有 AWS 认证。他拥有四项计算机网络专利，其职业生涯横跨欧洲、非洲和美国，为云架构和 AI 工作带来全球视野。工作之余，他将同样的构建者心态投入到 AI 项目、3D 设计和户外活动等个人项目中。
JP Boreddy
JP 是 AWS 的高级解决方案架构师，与 ISV 客户合作处理云架构、数据和 AI 工作负载。他专注于帮助组织实现数据平台现代化，并在生产环境中采用生成式 AI。
Sahil Thapar
Sahil 是 AWS 的首席解决方案架构师，他与 ISV 客户合作，在 AWS 云上构建高可用、可扩展且具备韧性的应用程序。他专注于容器、机器学习和生成式 AI，帮助企业设计生产级解决方案。
Saunak Chandra
Saunak 是 Amazon Web Services 的首席解决方案架构师兼全球合作伙伴数据与 AI 技术负责人，他与全球 AWS 合作伙伴团队合作，在 AWS 上构建并加速数据现代化计划。在其横跨企业数据库、云数据仓库、开放湖仓架构和智能体数据平台的职业生涯中，他帮助众多组织从专有封闭系统迁移到开放、可互操作的基础架构。Saunak 是 AWS 技术领域社区的分析专家，目前在 AWS 领导 Data-for-AI Fitness Model（DAFM）计划。工作之余，他会去徒步、练习瑜伽、打理花园、学习新语言，并关注一级方程式赛车。