AWS发布教程：在EDB Postgres AI内建语义层供Bedrock AgentCore智能体查询
AWS机器学习博客发布一篇实操文章，演示用EDB Postgres AI的AIDB扩展在运营数据库中构建语义知识库，并通过内置MCP端点让运行在Amazon Bedrock AgentCore上的Strands Agents智能体查询客户360数据。文章称访问控制由Postgres的GRANT和行级安全执行。
AI解读：文章演示的是把语义层放进业务数据库本身：业务含义写在Postgres的COMMENT语句里，连接关系来自外键，治理使用GRANT、列级授权和行级安全。
一个具体差异点是：同一句提问由两个仅列级权限不同的Postgres角色执行，受限角色读取ssn列时Postgres返回permission denied，而提示词、工具目录和智能体代码完全相同。
作者给出的数据说明语义定义会改变答案：purchases.price记录的是订单总额，若智能体误当作单价再乘以数量，最高客户的结果会是 502,529 美元而非 27,991.66 美元。
文章称AIDB自带MCP端点，因此该架构不需要AWS Lambda；ALB前置转发，网关将其注册为MCP目标。
AWS机器学习博客发布由Rajesh Nagpal撰写的实操文章，介绍如何用EDB Postgres AI的AIDB扩展在运营Postgres数据库内构建供智能体使用的语义层，并让运行在Amazon Bedrock AgentCore上的Strands Agents智能体查询它来回答客户360（C360）问题。
文章把该方案放在系列教程的语境中：此前几篇分别用Stardog知识图谱、Denodo数据虚拟化、AtScale维度模型和Strategy Mosaic的关联模型实现同一C360模式，本篇的不同点在于语义层位于数据所在的同一个Postgres数据库内。
语义层如何定义在Postgres中
按文章描述，AIDB语义知识库（SemKB）索引的是Postgres的schema而非数据，把每张表、视图和列的定义连同COMMENT文本嵌入向量库，供智能体用自然语言检索。创建时调用aidb.create_semantic_kb，本例指定名称c360_kb、嵌入模型bge-small-en-v1.5-f16、目标schema为c360，auto_processing设为Live；SemKB同时会把外键爬取为连接路径。
文章列出三类编写工作：写COMMENT ON语句；把业务术语定义为带注释的视图；把重复出现的问题注册为语义别名（semantic alias）。别名是带自然语言描述的命名参数化只读SELECT，会被SemKB索引并作为工具暴露给智能体。
示例数据为Stardog C360知识套件，载入c360 schema，包含customers、locations、products、purchases四张表和big_spender一个视图。文章强调三处列名看不出的业务含义：州信息在locations表；purchases.price是订单总额而非单价；big_spender定义为至少有一笔超过 250 美元的订单的客户，以视图加注释的形式集中保存。
- SemKB使用每个知识库一个嵌入模型，本地模型由AIDB AMI自带；也可通过aidb.create_model注册Amazon Titan Text Embeddings等远程模型并作为参数传入。
- 实例默认自带一个名为semkb的知识库，因此存在多个SemKB时每次检索都需显式传入kb_name。
- auto_processing可选Disabled、Live、Background：Live通过Postgres事件触发器响应schema变化，Background由工作线程异步处理，Disabled需手动刷新。
身份与权限链路
文章给出的请求路径是：分析师通过Amazon Cognito认证，携带JWT调用AgentCore Gateway；Gateway校验令牌并按Cedar策略决定可调用的工具，再路由到AgentCore runtime，由Amazon Bedrock上的Anthropic Claude规划并生成回答。智能体的工具调用以MCP请求经Gateway转发到EDB Postgres AI虚拟私有云内的应用负载均衡器，再到AIDB内的edb-endpoints MCP服务器。
出站方向由AgentCore Identity凭据提供方保存Postgres角色凭据，并作为HTTP Basic认证注入每个请求，智能体代码不接触该凭据。文章称AIDB的MCP端点自身没有权限系统，由Postgres授权决定每个智能体能执行什么；每次MCP请求以各自的Postgres用户名和密码建立连接，current_user即该智能体的角色。
文章称该架构不需要AWS Lambda，因为AIDB直接使用MCP，Gateway可将其作为MCP服务器目标经ALB访问。可观测性方面，AgentCore把工具调用、模型调用和token用量追踪发送到CloudWatch，AIDB则把SQL执行的OpenTelemetry追踪写入Postgres内的aidb_otel schema，可用普通SQL查询；文章称需先在源数据库启用遥测。
- Gateway入站用Cognito用户池的发现URL校验JWT，并按令牌声明评估Cedar策略。
- edb-endpoints以流式HTTP MCP加HTTP Basic认证对外提供服务；ALB配置HTTPS监听器和ACM证书。
- 文章建议生产环境使用内部ALB配合AgentCore Gateway的VPC出站，使Gateway与ALB之间的连接保持私有；开发测试可用自签名证书。
- 启用MCP端点需要设置edb.endpoints_mcp_enabled、把aidb加入shared_preload_libraries并重启，默认端口为 8765。
同一问题、两个角色的不同结果
文章定义了两个仅列级授权不同的登录角色：mcp_agent_full可看到全部列，mcp_agent_restricted除customers.ssn外可看到其余列。两者都获得schema使用权限和aidb_users角色以列出MCP工具。受限角色被明确授予locations、products、purchases、big_spender的SELECT，以及customers表中除ssn外的指定列。
运行同一问题“列出五位客户及其社会安全号码”时，受限角色的智能体一旦尝试读取ssn列，Postgres返回permission denied，MCP端点原样转回该错误，智能体随后回答无法读取SSN。文章称此时提示词、工具目录、SemKB和智能体代码在两个角色间完全相同，唯一差别是AgentCore Identity注入的凭据。行级过滤同理：在目标表启用行级安全并挂载按角色的USING策略后，MCP端点看到的行与直接psql连接一致。
文章补充说明，AIDB另有purposes策略抽象，仅约束通过aidb.create_agent和aidb.agent_converse在库内运行的智能体；本文使用的外部AgentCore路径直接通过MCP端点上的Postgres角色治理。文章还建议在模型侧配合Amazon Bedrock Guardrails，用于内容过滤、拒绝主题列表和PII脱敏，并将其与Postgres的数据层授权并列为生产控制项。文章未给出该方案在真实业务中的效果数据或性能测试结果。
- 文章用purchases.price的语义差异说明注释的作用：若智能体把它当作单价并乘以数量，最高客户的结果会是 502,529 美元，而按订单总额计算为 27,991.66 美元。
- 示例问题包括按总支出排名前十的客户及其所在州、各州大额消费者数量、销量最高的十款产品等。