用 EDB Postgres AI 与 Amazon Bedrock AgentCore 为智能体 AI 构建语义层

这一篇是系列文章的延续：此前已用 Stardog 知识图谱、Denodo 数据虚拟化平台、AtScale 维度模型和 Strategy Mosaic 的关联模型实现过同一套客户 360（C360）模式，这次换成 EDB Postgres AI，把语义层直接放进业务所在的 Postgres 数据库里。

语义层放在数据库内部

EDB Postgres AI 通过 AIDB 扩展承载语义知识库（SemKB）。业务含义写在标准 Postgres COMMENT 语句中，与数据同库；表间连接关系由 Postgres 外键推导；治理则使用 Postgres 的 GRANT 和行级安全，并通过 AIDB 自带的 MCP 端点对外提供。作者强调，访问控制由数据库权限执行，而不是靠一段建议性的系统提示词。

示例数据集是 Stardog C360 Knowledge Kit，加载到专用 c360 schema，包含 customers、locations、products、purchases 四张表和一张 big_spender 视图。文章点出三个列名看不出的业务含义：州信息不在客户行上，而在 locations 表，需经 customers.location 外键取得；purchases.price 记录的是订单总额，若被智能体误读为单价再乘以数量，最大客户的结果会从 27,991.66 美元变成 502,529 美元；big spender 是业务自有术语，用视图加 COMMENT ON VIEW 固化定义，供所有智能体、看板和查询共用。

请求链路与治理

参考架构中，分析人员经 Amazon Cognito 认证，用签发的 JWT 作为 Bearer token 调用 AgentCore Gateway；Gateway 校验令牌并按 Cedar 策略判断该智能体可为该用户调用哪些工具，再路由到 AgentCore runtime，由 Amazon Bedrock 上的 Anthropic Claude 负责规划。智能体通过 Gateway 调用 MCP 工具，请求转发到 EDB Postgres AI VPC 内的 Application Load Balancer，再到 AIDB 内的 edb-endpoints MCP 服务器。AgentCore 的追踪进入 Amazon CloudWatch，AIDB 则把每次 SQL 执行的 OpenTelemetry 追踪写成 aidb_otel schema 中的行，可直接用 SQL 查询。

文章给出的端到端问题包括：按总支出排名前 10 的客户及其所在州、各州 big spender 数量、10 个客户及所在州、销量最高的 10 个产品，以及列出 5 个客户的社保号——最后一题用于治理复跑，展示不同 Postgres 角色、列级 GRANT 和行级安全下同一提示词、同一工具目录、同一份智能体代码得到不同结果。

编辑部观察

这套方案的核心取舍是把语义定义和权限都压在 operational Postgres 上，减少数据与含义分处两套系统的同步成本，代价是语义资产与业务库生命周期绑定。文章属于教程性质，未给出性能、延迟或成本数据，模型可用性也随 AWS Region 变化。读者若要复现，建议先确认 AIDB 扩展与 MCP 端点在目标区域的可用性，再用最小 schema 验证 COMMENT、外键推导和行级安全是否符合预期。