EDB 语义层将智能体访问规则置于 Postgres 之中
AWS 发布了一份 EDB 语义层演示指南，借此让数据库权限而非提示词指令决定智能体能够读取哪些内容。该示例于 11 月 3 日发布，将 EDB Postgres AI 连接至 Amazon Bedrock AgentCore——一组用于托管和连接软件智能体的 AWS 服务。其核心主张很明确：将业务定义保留在运营数据附近，并在查询执行的位置实施访问控制。
语义层将业务语言与数据库结构及计算逻辑连接起来。在这里，智能体使用 Strands Agents——一个用于构建可调用工具的智能体的框架——回答有关客户活动的问题。核心矛盾在于灵活的查询生成与可靠控制之间的平衡。助手需要足够的自由来理解问题，而数据库所有者则需要对其访问范围实施可预测的限制。
与数据虚拟化平台 Denodo 的比较，有助于定位 EDB 的方法；Denodo 可查询分布式数据源。两者都为智能体提供业务上下文，但围绕不同的数据架构组织这些上下文。对于开发者和企业采购方而言，眼前的问题是：定义与权限应置于何处，以及由谁维护它们。
EDB 语义层让数据库含义可被发现
这项变化是一种集成模式，使外部智能体能够使用既有数据库定义。
这份 智能体语义层 演示指南结合了 EDB 的 AIDB 数据库扩展与运行在 AWS 上的智能体。其客户示例使用四张表和一个派生视图，即作为数据库对象呈现的已保存查询。业务描述来自数据库注释，而外键——连接相关记录的约束——则提供联接关系。
AWS 表示，该示例在仅更换数据库凭据的同时保持提示词和智能体代码不变。受限角色无法检索受保护的社会保障号码列。这一区别很有价值：数据库会在助手组织答案之前拒绝该访问尝试。
这仍是供应商撰写的参考示例。它提出了一种实现方案并报告了示例行为，而非提供企业范围可靠性的独立证据。读者在就部署准备度得出结论之前，应区分这些主张。
EDB 的文档介绍了其底层的语义知识库，即数据库结构与描述的可搜索索引。它为表、视图、列和注释建立索引，而非嵌入客户记录。嵌入向量——用于相似性匹配的数值表示——帮助智能体通过自然语言问题找到相关数据库对象。
这一区别对评估至关重要。找到正确的结构，并不能证明生成的计算是正确的。它只是为模型构建查询提供了更好的材料。团队仍需将答案与认可的业务结果进行比对。
对于任何希望了解 EDB semantic layer explained 的人而言，一个有用的起点是区分发现与执行。描述帮助智能体判断数据的含义；权限决定其拟议查询能否访问该数据。
这种放置方式也改变了所有权。数据库注释成为智能体工作上下文的一部分，而不再只是开发者偶尔查阅的文档。不准确的描述应获得与误导性应用界面同等的重视。
设想一个假定的采购字段，其名称无法表明其中存储的是单件金额还是订单总额。两种解释都支持有效的算术计算。只有一种符合业务定义，因此，仅凭成功执行无法识别错误。
这使该架构的意义超越其示例数据集。其价值取决于团队能否将模糊的数据库惯例转化为可维护、可发现的定义。智能体连接将这项工作暴露为前提条件，而不是让它消失。
数据库所有者承担部分智能体工作负担
将含义迁入 Postgres，使数据库团队直接参与答案质量。
直接压力落在负责模式、报表定义和访问策略的人身上。应用团队可以改进助手的指令，但仅靠措辞无法解决尚未达成一致的业务定义。
假设销售和财务对活跃客户有不同的定义。一方按近期采购计算，另一方则要求账户状态良好。智能体若未经说明便选择任一解释，给出的答案会显得比组织内部实际情况更有定论。
将定义保留在数据附近，为解决该分歧提供了位置。但这并不能决定哪个部门是正确的。仍然需要有人有权批准定义、解释其适用范围并管理变更。
这正是为何在关注架构的同时，也应重视运营负担。采用这一模式的团队应预期需要持续开展有关数据库含义的编辑工作。审查描述将成为维护软件智能体所使用接口的一部分。
表之间的关系也是如此。技术上有效的连接，并不会自动表达某个问题所需的业务关系。采购方应询问：其现有数据库结构是否反映报表需求，还是仅仅支持应用交易。
当一位客户拥有多个地址、账户所有者或历史分类时，这种差异就会显现。关于当前区域的问题，与关于订单发生时所在区域的问题，需要不同的解释。任何一种答案都不应依赖未经记录的假设。
这些是评估场景，而非关于 EDB 实现失败的报告。它们表明，即使模式发现能力更强，仍然需要业务判断。一个有价值的试点应刻意纳入那些会随着这些假设变化而改变答案的问题。
人员配置的含义很直接。智能体团队需要接触那些原本就负责解决报表争议的人。否则，应用开发者可能会成为他们无权定义的指标的非正式负责人。
因此，企业采购方应将维护流程与智能体演示一并评估。谁批准变更后的定义？哪些应用依赖它？组织如何发现助手正在使用过时的解释？
对于工程团队而言，一个可搜索知识库可以保留这些决策背后的推理过程。数据库定义与支撑文档承担相近的作用，即使它们存在于不同系统中。
短期压力是准备一个可信的试点。长期压力则在组织层面：随着应用、报表要求和人员的变化，保持业务定义一致。该架构让这项责任更加可见，而这只有在有人接受责任时才有用。
经审查的查询为灵活智能体提供稳定参照
反复出现的业务问题值得采用可复用的查询逻辑，即便用户用不同措辞提问。
EDB 记录了语义别名，即与可搜索自然语言描述及已定义参数配对的命名查询。别名必须包含单个只读 SELECT，即检索结果的查询。EDB 表示，它会在创建和执行别名时验证这一限制。
其架构含义是在固定报表界面与不受限制的查询生成之间提供一条中间路径。用户可以通过对话表达熟悉的请求，而系统则有一个可作为参照的既有查询。
对于假定的区域销售报告，经审查的逻辑可能已明确规定报告期、客户分类及取消订单的处理方式。这些决策应在用户表达请求方式变化时保持不变。
这不同于每次都要求模型重建所有决策。重建熟悉的逻辑会带来额外的变化机会。复用让审查者面对更小、更具体的检查对象。
不过，已保存查询本身无法解决解释问题。智能体仍必须识别合适的查询并提供恰当参数。对季度活动的请求不应悄然变成对最近一个日历季度的请求。
这带来不同的评估问题。系统是否识别了预期的业务问题？是否选择了正确的期间与范围？返回的说明是否准确描述了查询所衡量的内容？
有利的数据库结果只覆盖这条链条的一部分。助手可以检索正确记录，却给出错误摘要。反之，流畅的说明也可能掩盖一个回答了相邻问题的查询。
实际应对方式是为重复性请求保留参考答案。团队可在改变措辞、日期和用户权限的同时，将生成答案与这些参考答案比较。这能测试用户实际会遇到的行为。
经审查的逻辑也形成更清晰的变更流程。如果业务改变定义，维护者可以识别相关查询并评估受影响的输出。缺少共同参照时，等效定义可能在不同智能体应用中逐渐偏移。
这种益处存在边界。高度探索性的问题仍将要求超越既有查询目录的解释。采购方应评估系统在没有相近匹配项时的表现，包括它是否会要求澄清。
重要的产品行为是诚实地表达不确定性。能够识别模糊请求的工具，会给用户机会纠正其方向；自信地选择不合适定义的工具，则隐藏了这一决策。
因此，评估 EDB 方法的最佳视角，是将其视为组织可复用含义和查询逻辑的一种方式。其有用性取决于检索质量、参数处理和审查实践是否协同运作。没有任何一项应从另一项的成功演示中被推断出来。
Denodo 彰显数据库本地含义的边界
EDB vs Denodo 的比较取决于数据放置与运营责任。
AWS 先前的数据虚拟化架构使用 Denodo 跨 Amazon Aurora、Amazon Redshift 和本地 PostgreSQL 数据库连接客户信息。数据虚拟化通过共享查询层呈现分布式数据源。该演示指南将业务视图和访问策略置于 Denodo 中。
相比之下，EDB 示例将含义置于其运营 Postgres 数据库内部。这一比较并不能证明谁在性能上胜出。它展现了在决定业务定义应归属何处时，两种不同的起始条件。
对于相关数据已集中存放的团队而言，值得考虑将定义保留在数据库本地。其组织层面的吸引力很直接：现有数据库维护人员可以在熟悉的位置检查那些决定答案形成方式的对象。
对于客户信息分布在独立系统中的团队，核心问题则更为广泛。它必须协调这些系统之间的标识符、含义和权限。增加一个 agent 界面并不会消除这些集成决策。
因此，EDB 与 Denodo 的关键问题在于业务问题的边界。组织能否从其已运营且受治理的数据库中回答该问题？还是答案需要协调多个来源？
设想一位客户经理想知道哪些客户需要关注续约。仅凭购买历史可能不足以判断。合同状态、未解决的支持案例和客户归属都可能影响答案。
如果这些记录存放在其他地方，以数据库为中心的试点应当让这一局限清晰可见。否则，基于可用记录得出的成功答案可能被误认为是完整的客户评估。缺失的数据源会成为伪装成技术成功的业务风险。
分布式方法也面临自身的评估负担。连接数据源并不能自动证明它们的定义一致。买方仍需检查系统如何协调冲突的标识符和报告周期。
两种方法的核心张力始终相同：灵活的 agents 需要得到维护的语义和可强制执行的访问控制。架构选择决定了这些责任汇聚在哪里，而不是消除它们。
这也是为什么连接器数量并不是完整的采购标准。连接器建立了通往信息的路径，但并不能证明某个特定问题在每个已连接来源中都具有一致认可的含义。
团队应使用具有代表性的业务请求及其完整依赖关系来比较架构。应包括数据源负责人、获批的计算方式、访问限制和预期解释。这比泛泛讨论 agent 能力更能揭示问题。
对于 EDB，机遇在于让现有数据库结构成为 agents 可靠的基础。其边界也同样明确：组织必须确定这一基础能够覆盖用户实际提出的问题到何种程度。
权限仍取决于到达 Postgres 的身份
只有当查询以适当角色执行时，数据库访问规则才能保护预期用户。
EDB 的 MCP server 使用 Model Context Protocol，这是一种让 agents 调用外部工具的标准接口。其文档说明，工具调用会以经过认证的 Postgres 角色执行。随后，数据库权限决定该角色能够执行哪些操作。
这为生产团队提供了一个具体的审查点。在应用边界对人员进行认证，以及选择下游数据库身份，是两项独立的责任。审查人员在接受有关用户专属访问的说法前，应追踪两者。
一个假设的共享报告账户可以说明这个问题。如果每个请求都以该账户身份到达数据库，数据库规则就会评估该账户的权限。个性化的应用界面本身并不能建立个性化的数据库执行机制。
这并不意味着共享账户在所有情况下都不合适。这意味着其权限必须与预期的服务边界相匹配。一个权限范围狭窄的报告助手，与一个服务于拥有不同访问权限用户的助手，要求并不相同。
PostgreSQL 的行级安全策略会限制角色能够访问哪些记录。在启用但没有适用策略时，行级安全默认拒绝访问。然而，超级用户和拥有 BYPASSRLS 的角色会绕过这些限制；表所有者通常也会绕过它们，除非被强制遵守。
在测试 agent 连接时，这些文档化的例外非常重要。使用管理账户进行的演示无法证明普通用户之间的隔离。评估人员需要验证实际请求路径中的有效角色及其权限。
列级限制和行级限制回答的也是不同问题。隐藏敏感字段，并不能证明另一位客户的记录无法被访问。有说服力的评估应测试应用所承诺的各种访问维度。
该评估还应包括通过替代问题进行的尝试访问。直接询问敏感字段很有用，但业务请求可能以意外方式组合被允许的属性。审查人员应检查应用返回的内容，以及它如何解释限制。
权限执行也不能证明答案正确。某个角色可能有权读取记录，但 agent 可能错误地将这些记录组合起来。安全评估和分析评估应保持区分，并分别提供证据。
只读访问同样需要精确界定。阻止写入限制了 agent 能够通过该路径更改的内容。但这并不能决定一个获授权的结果是否包含应用在特定上下文中应展示的信息。
这些限定界定了主张的范围，而不是否定它。数据库执行机制为审查人员提供了可具体检查的对象。他们可以检查角色、权限、策略和实际执行的查询，而不是仅依赖助手声称的意图。
剩余工作是验证应用是否始终以预期身份到达该执行点。这是部署责任，应在验收证据中清晰体现。
关注身份隔离、定义变更和可重复的答案
接下来有价值的证据将显示，治理是否能经受用户、定义和请求量变化的考验。
在未来几个月中，买方应关注将这些维度关联起来的评估。相比围绕架构边界设计的测试，对熟悉问题的更多演示所提供的信息较少。
第一个信号是已部署请求路径中的身份隔离。应寻找证据证明，拥有不同权限的用户会获得恰当不同的结果。证据应标明有效的数据库角色，而不仅仅是在界面上展示不同名称。
隔离测试应包括一次超出用户权限范围的尝试操作，以及由此产生的数据库行为。一致的执行将加强该架构的论据。无法解释的凭据共享则会削弱有关用户专属治理的主张。
第二个信号是定义变更如何影响答案。业务指标在应用生命周期中很少始终保持不变。团队应寻找这样的演示：更新一个定义，然后验证助手后续的解释。
有意义的证据包括变更过程本身。助手是否采用了修订后的含义？审查人员能否识别支持较早答案的是哪项定义？受影响的参考答案是否通过明确流程得到更新？
成功处理变更将强化将语义保留在受维护数据库对象附近的理由。所有权不清或解释过时则会表明，仅仅共置并不能带来一致性。
第三个信号是在具有代表性的使用情境下可重复实现的正确性。评估应变化问题措辞、用户权限以及同时发生的活动量。买方需要了解，当条件不同于最初演示时，系统是否仍然有用。
这并不要求将每个业务问题都视为基准竞赛。它要求一组已声明的预期行为。正确计算、恰当拒绝、可理解的限制和可接受的响应时间，都应分别具有证据。
对于希望以运营视角理解 EDB semantic layer 的团队而言，这些信号提供了实用的决策框架。它们将一项架构主张转化为试点可以回答的问题。
它们也避免了对哪个平台获胜作出缺乏依据的预测。最强的实施方案将取决于数据存放位置、身份要求以及组织维护定义的能力。应根据这些条件评判以数据库为中心的方法。
从团队已经能够可靠回答的业务问题开始，然后记录其定义、预期结果和访问边界。向审查人员提供足够的信息，使其无需信任助手的解释也能复现结果。通过适当受限的身份运行同一请求，并同时检查数据库行为和响应。接着，修改一项相关定义，并验证答案是否遵循获批变更。使用 EDB semantic layer 测试一项具体的运营主张：组织能够维护共享语义，同时在查询时执行访问控制。在扩展试点之前，先问自己是否能够解释每个重要答案和每个重要拒绝。
