EDB Postgres AI把语义治理嵌进数据库：一条COMMENT改变代理答案，一条GRANT改变代理权限

做企业级AI代理分析时，一个反复出现的问题是：代理能写SQL，但它不知道列名背后的业务含义，也不知道自己有权读什么。常见解法是搭一个独立的语义层——知识图谱、数据虚拟化平台、维度模型——再让代理去查询那个层。AWS机器学习博客2026年11月3日展示了一条不同的路径：把语义层直接放进操作型Postgres数据库本身，用数据库原生的COMMENT、GRANT和行级安全来实现含义定义和访问控制，不需要第二个系统。

具体机制分三层。第一层是含义：AIDB扩展的语义知识库（SemKB）把每张表、每个视图、每列的定义连同COMMENT ON文本一起嵌入向量索引，代理用自然语言搜索就能找到正确的表和列。第二层是关系：Postgres外键被SemKB自动爬取为join路径，代理不需要靠列名猜关联。第三层是治理：AIDB的MCP端点本身没有权限系统，它把每个请求的Postgres用户名和密码作为HTTP Basic认证传入，数据库的GRANT和RLS策略决定这个连接能看到什么。

博客用一个具体例子说明了含义层的作用。C360数据集中，purchases.price列记录的是订单总额，不是单价。如果没有COMMENT ON说明这一点，代理会把它当单价乘以quantity，给排名第一的客户Carolyn Inworth算出约502529美元——这个数字是错的。加上一条注释：'Total amount the customer paid for the entire order, in US dollars. Not the unit price.'，同一模型、同一提示、同一工具目录，答案变成27991.66美元。模型没换，提示没改，工具没变，变的只是SemKB里索引的那条注释。

治理层的验证更直接。博客定义了两个Postgres登录角色：mcp_agent_full能看到所有列，mcp_agent_restricted看不到customers.ssn。对两个角色跑完全相同的提示——列出五名客户的SSN。full角色返回五名客户的SSN值；restricted角色的工具调用在Postgres层被拒绝，返回permission denied for column ssn，代理随即告知用户无法读取SSN。提示、工具目录、SemKB、代理代码全部相同，唯一区别是AgentCore Identity注入的Basic认证凭证不同。

架构上，代理运行在Amazon Bedrock AgentCore runtime上，用Claude做规划，通过AgentCore Gateway调用MCP工具。Gateway把请求转发到EDB Postgres AI VPC内的应用负载均衡器，再到达AIDB的edb-endpoints MCP服务器。不需要Lambda，不需要翻译层——AIDB本身就说streamable HTTP MCP协议。审计也留在同一个数据库里：AIDB把每次SQL执行的OpenTelemetry trace写入aidb_otel schema，可以用普通SQL查询。

这个模式的适用边界值得注意。它依赖EDB Postgres AI的AIDB扩展，数据必须在Postgres里。对于分析型工作负载超出操作库的场景，博客提到PGAA（Postgres Analytics Accelerator）可以读Apache Iceberg、Delta Lake和Parquet表，以及Postgres foreign data wrappers可以联邦外部关系源——两种情况下语义层定义不变，因为业务含义、列注释和语义别名都住在Postgres里。但对于非Postgres环境或需要跨多种数据库统一语义层的情况，这个模式不直接适用。

博客还建议把Postgres GRANT（控制代理能执行什么）与Amazon Bedrock Guardrails（控制代理能生成什么）配合使用。前者在数据层阻止SSN被读出，后者在模型输出层过滤PII模式。两层互补，单独任何一层都不够。

对正在构建代理分析系统的团队，这篇博客提供的可迁移认识是：如果数据已经在Postgres里，语义治理可以不需要独立系统。一条COMMENT ON决定代理算不算得对，一条GRANT决定代理能不能看到。正确性和安全性都是数据库原语层面的确定性行为，不是提示工程层面的概率性行为。