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

智能体 AI 回答业务问题需要三个核心层次：负责规划与生成查询的模型层、向智能体解释数据含义的语义层，以及托管智能体并管控身份与访问的运行时层。本方案中，模型层采用 Amazon Bedrock 上的 Anthropic Claude，运行时层使用 AgentCore Runtime，而语义层则是本次方案的核心创新——一个直接运行在运营级 Postgres 数据库内部的语义知识库（SemKB），将数据模式与业务定义索引在一起，由 Postgres 原生机制而非外部系统负责访问控制。

语义层的构建以 EDB Postgres AI 的 AIDB 扩展为基础。开发者通过标准 COMMENT ON 语句为表、列和视图添加业务含义，再调用 aidb.create_semantic_alias 创建语义别名，AIDB 则自动从外键关系中提取表间连接路径，形成完整的语义知识库。以 C360 数据集为例，客户所在州并不直接存储在 customers 表中，而是通过外键关联到 locations 表，AIDB 依据列注释即可自动推断出正确的连接路径，避免智能体因误读字段含义而产生错误计算结果。

在架构层面，分析师通过 Amazon Cognito 完成身份认证后，携带 JWT 令牌调用 AgentCore Gateway。Gateway 验证令牌并依据 Cedar 策略决定该智能体可调用哪些工具，随后将请求路由至 AgentCore Runtime。智能体的工具调用以 MCP 请求形式发出，经由 Application Load Balancer 转发至 EDB Postgres AI VPC 内的 edb-endpoints MCP 服务器。AgentCore Identity 凭证提供程序负责注入 Postgres 角色凭证，智能体代码本身无需感知数据库密码，实现了凭证的安全隔离。

访问治理是本方案的重要亮点。通过为不同 Postgres 角色配置列级 GRANT 权限与行级安全策略，同一智能体代码、同一提示词、同一工具目录，在不同调用者身份下会返回截然不同的结果。例如，当智能体被要求列出客户的社会安全号码时，拥有相应权限的角色可以获取数据，而受限角色则会被数据库层面直接拒绝，而非依赖提示词中的软性约束，从根本上保障了数据安全合规。

在可观测性方面，AIDB 为每次 SQL 执行捕获 OpenTelemetry 追踪记录，并以行的形式存储在 aidb_otel 模式中，可直接用普通 SQL 查询分析。AgentCore 侧的追踪数据则同步发送至 Amazon CloudWatch。这种双轨追踪机制使运维团队既能在 Postgres 内部审计智能体的每一次数据访问，也能在 CloudWatch 中监控整体调用链路，为生产环境的智能体部署提供了完整的审计与调试能力。

要点

• EDB Postgres AI 的 AIDB 扩展将语义层直接内嵌于运营数据库，业务含义、连接路径与访问控制均由 Postgres 原生机制管理，无需额外的语义中间件。
• Postgres GRANT 与行级安全策略在数据库层面强制执行访问控制，不同角色调用相同智能体代码可获得差异化查询结果，安全性远优于依赖提示词的软性约束。
• AgentCore Identity 负责向外部工具注入凭证，智能体代码与数据库密码完全解耦，实现了凭证的安全隔离与集中管理。
• AIDB 通过 OpenTelemetry 将每次 SQL 执行记录为可查询的数据库行，结合 CloudWatch 追踪，为智能体数据访问提供完整的审计与可观测能力。