Amazon Quick Live Data 取代静态快照，但治理决定规则

Amazon Quick Live Data 现可让 AI 构建的应用在每位读者打开应用时查询受治理的数据集，摆脱对构建时冻结数据的依赖。AWS 于 2026 年 10 月 1 日以 Live Data in Apps 的名称推出了这一功能。

这一变化弥补了 Amazon Quick 中一个影响深远的缺口。其 AI 智能体可通过自然语言提示构建和发布内部 Web 应用，但结构化的 Quick Sight 数据在这些应用中仍保持静态。销售额或支持指标在发布后可能立刻过时。

Live Data in Apps 以按应用查看者身份执行的查询取代了快照模式。现有的行级安全和列级安全规则决定该用户能够获得哪些记录和字段。

这一机制比无代码界面更重要。它使 AI 生成的应用从展示昨日获批数据的界面，转变为受治理业务系统之上的实时界面。

Microsoft 正通过 Copilot、Power Apps 和 Dataverse 走一条相关路径。其系统同样会依据当前用户的授权限制所检索的业务数据。Amazon 的新功能进一步加大了将对话式应用创建与既有治理机制连接起来的压力，而不是把安全性视为后续集成任务。

结果并不是不受限制的应用构建。用户需要经过身份验证的 Amazon Quick 账户、对底层数据集的访问权限以及明确同意。查询限制、源限制和架构变更也会影响生成的应用能够可靠完成哪些工作。

Amazon Quick Live Data 改变了已发布应用能够看到的内容

已发布的 Quick 应用现在可获取当前的结构化数据，无需在构建时将数据复制进应用。

Quick Apps 允许用户用自然语言描述一个内部 Web 应用。智能体构建界面、发现集成，并在用户通过对话不断完善需求的过程中生成应用。

AWS 已支持在查看时访问 Slack、Jira、Google Drive、Web 搜索、Spaces 文档和 AI 推理等来源。用户使用应用时，这些连接可以检索信息。

受治理的 Quick Sight 数据集此前是例外。在构建过程中，智能体可以使用其中的值来生成应用。但最终应用展示的是在构建或发布期间捕获的快照。

这种差异带来了显而易见的可靠性问题。设想一个基于续约数据构建的区域销售应用。它可能在预览时展示当前商机，但在新的交易记录进入源系统后，仍保留这些结果。

界面依然能够运行，但其中的数字可能会在不知不觉间不再反映底层业务。

根据 Live Data 发布公告，智能体现在会在构建过程中发现相关 Quick Sight 数据集，并编写所需的 SQL。构建者会审核并批准每个选定的数据集。

发布后，应用会在获授权用户每次打开时重新运行该 SQL。数据集仍是受控来源，而生成的应用则成为查询界面。

该功能同时支持 SPICE 和 Direct Query 数据集。SPICE 是 Amazon Quick Sight 的内存数据引擎，在导入数据完成刷新后提供数据服务。Direct Query 则在需要数据时向连接的来源发送请求。

这种差异仍会影响数据新鲜度。Direct Query 应用无需单独刷新数据集即可检索当前源数据。由 SPICE 支持的应用则展示最新导入 SPICE 的信息。

AWS 在其刷新行为文档中说明了这一差异。Direct Query 会在关联数据集、分析或仪表板打开时刷新数据，而 SPICE 则遵循配置的摄取流程。

因此，Live Data in Apps 并不会让每个数据源都持续保持最新。它让应用相对于所查询的 Quick Sight 数据集保持最新。

这是一个重要边界。即使应用在查看时运行查询，陈旧的 SPICE 摄取仍会产生陈旧结果。这项新功能移除了一个快照层，而不是消除数据路径中所有可能的延迟。

这一变化也不同于嵌入仪表板。Quick Apps 已可在应用中放置交互式 Quick Sight 可视化内容。Live Data in Apps 则让生成的应用能够在自身工作流和界面中使用数据集结果。

一个续约应用可以列出账户、响应筛选条件、展示收入明细，将这些结果与产品策略文档结合起来，并准备客户行动方案。数据成为应用行为的一部分，而不再是孤立的可视化内容。

AWS 在其 Quick Apps 指南中介绍了对话式创作、发布、共享和嵌入式可视化内容。实时数据集查询将这一模式扩展至更多运营场景。

这是此次事件的核心变化。Amazon 正在将 AI 生成的界面直接连接到受治理的分析数据，同时让数据集保持在生成应用之外。

按读者执行的查询将治理置于运行时之中

决定性的设计选择在于，每项查询都以查看者身份运行，而不是以应用构建者或共享服务账户身份运行。

内部应用通常继承其创建者、后端或集成凭据的权限。除非开发者额外添加一层授权机制，否则这种设计可能暴露超出单个用户应有范围的数据。

Amazon Quick 为 Live Data in Apps 采取了不同做法。当读者打开已发布的应用时，其数据集查询会以该读者的身份执行。

行级安全，即 RLS，限制用户或群组可检索的记录。列级安全，即 CLS，限制哪些字段仍可对指定用户或群组可见。

一名区域经理可能获得美洲地区的记录，另一名经理可能获得欧洲、中东和非洲地区的记录。二者都可使用同一已发布应用，但不会获得相同结果。

AWS 表示，Quick Sight 查询引擎负责作出授权决定。生成的前端并不决定用户是否可检索某一行或列。

这种分离减少了对 AI 生成应用代码的信任要求。应用可以请求数据，但既有治理层决定请求会返回什么。

Amazon 的行级安全文档说明，读者只能获得与适用权限规则匹配的行。未被纳入限制性规则集的用户不会获得匹配数据。

列限制增加了第二道边界。用户可能可以访问客户记录，但仍无法查看其利润率、个人信息或其他敏感字段。

这些控制此前已存在于 Quick Sight 中。Live Data in Apps 会复用它们，而不是为生成的应用引入单独的权限模型。

这一选择能够缩短从原型到可在内部共享工具的路径。构建者无需在每个生成的界面中重新创建区域筛选条件或字段权限。

它也使治理继续附着于数据集。管理员可以通过 Quick Sight 管理权限，同时由多个应用查询同一个受控来源。

这一架构解决了 AI 应用生成中一个更棘手的问题。生成界面相对容易；当界面接触不断变化的企业数据时保留授权则更难。

许多组织分别维护源权限、分析访问、应用角色和 AI 检索系统。每增加一层，就增加一次政策发生漂移的机会。

Amazon 的做法并未消除整个组织范围内的复杂性。它通过使用当前查看者和现有数据集规则，在 Quick 的范围内缩小了问题。

同意机制增加了另一项控制。构建者必须批准构建期间使用的数据集。每位查看者在首次使用应用时，也必须对每个数据集提供一次性同意。

AWS 表示，后端会在每次查询时验证同意状态。已保存的批准并非只是生成应用可以忽略的前端提示。

系统还要求使用经过身份验证的 Quick 用户。使用实时数据集的应用不提供匿名和公开访问。

这一限制缩小了分发范围，但也强化了产品的企业边界。Live Data in Apps 面向内部应用，在这些场景中 AWS 能够建立具名用户、数据集访问权限和授权上下文。

最低访问要求构成了另一项实际边界。AWS 表示，构建者和查看者都至少需要 Reader Pro 或 Professional 角色。

因此，该治理模式是继承而来的，而非自动产生。组织仍必须正确配置数据集、身份分配、群组和安全规则。

如果数据集授予宽泛访问权限，生成的应用也会反映这种宽泛访问。实时执行无法修复薄弱的数据源权限。

这正是为何该公告与其说关乎自然语言开发，不如说关乎受治理的运行时身份。应用构建者提供意图，但数据平台仍是权威。

实时查询将 AI 应用构建变成数据平台之争

Amazon 的竞争焦点在于 AI 构建的应用能否安全使用运营数据，而不只是智能体能否生成界面。

自然语言应用构建器可以快速生成表单、仪表板、筛选器和工作流页面。当原型连接到每小时都在变化的业务记录时，更严峻的考验才刚刚开始。

一个有用的内部应用需要的不只是美观的输出。它还需要当前数据、可预测的身份处理、受控操作、可理解的错误信息，以及在共享后仍然有效的权限。

Live Data in Apps 让 Amazon Quick 更接近这一标准。它将应用生成与公司现有的商业智能数据集和治理规则结合起来。

主要对手是静态快照模式。该模式在生成过程中很方便，因为智能体可以基于已知样本进行推理，并创建稳定的预览。

但当用户将冻结结果误认为实时运营视图时，它就会变得危险。再精致的界面也未必会提示用户，其中的收入、库存或工单数量已经过时。

在查看时重新查询数据集改变了这种关系。应用不再携带历史答案，而是依赖受治理的数据服务。

这种依赖为 AWS 创造了价值。Quick Sight 数据集不再只是分析和仪表板的输入，也成为应用的可复用运行时资产。

这也给竞争平台带来了压力。Microsoft Dataverse 已为 Power Apps 和 Copilot 体验提供受治理的记录。Microsoft 表示，Copilot 仅检索当前用户获授权访问的数据。

其 Dataverse 集成支持跨表、关联记录以及多种 Microsoft 365 体验提问。结果取决于现有表访问权限和数据建模。

这种比较并不完全对等。Microsoft 将其方法核心放在 Dataverse 和更广泛的 Power Platform 上。Amazon 则将此次发布聚焦于 Quick Apps 和受治理的 Quick Sight 数据集。

两种方法都揭示了相同的市场方向：AI 界面正成为企业数据的另一层访问入口，而现有权限必须在检索时继续生效。

这一方向给依赖导入文件、复制记录或广泛集成凭证的独立 AI 应用生成器带来了压力。当安全团队必须在事后重建授权机制时，快速生成的吸引力便会下降。

它也对传统的商业智能工作流程构成压力。仪表板回答的是预先定义的分析问题，而应用程序则可以将这些答案与筛选器、文档、消息传递及其他操作连接起来。

AWS 以续约工作流程说明了这一差异。销售负责人可以请求创建一款应用，列出即将到期的续约项目，展示营收和利润率，并将这些指标与产品战略内容结合。

随后，该工作流程可支持客户触达。生成的应用程序将分析结果拉近到实际运营决策，而不是止步于一张图表。

这并不意味着仪表板已经过时。仪表板仍适用于标准化监控、高管报告和经过验证的可视化分析。

这一变化扩展了受治理分析数据可以呈现的位置。如今，它可以支撑由业务用户通过自然语言创建的定制界面。

这种更广泛的访问提升了维护良好的组织知识层的重要性。结构化指标需要明确的责任归属，而文档则需要可靠的采集与检索机制。

可搜索的团队知识库可以帮助团队理解应用程序数字背后的政策与上下文。它并不能取代数据集治理。

因此，竞争的关键不在于哪个平台能根据最短的提示词生成应用，而在于哪个平台能在发布后保留身份、数据血缘、新鲜度和管理控制。

Amazon 的优势在于其与 Quick Sight 成熟数据集模型的连接。它的局限也正是该模型本身的边界。

使用不同分析平台、身份系统或应用环境的组织，可能并不希望 Quick 成为其运行时层。当受治理的 Quick Sight 数据集已经存在时，这项功能最具吸引力。

Apps 中的 Live Data 强化了 Amazon Quick 的内部逻辑。但它并未证明每家企业都会将应用生成和分析整合到 AWS 内部。

Amazon Quick Live Data 仍存在运营限制

实时执行消除了冻结的结果，但也引入了查询、架构、同意与可用性等依赖，构建者必须围绕这些因素进行设计。

AWS 为 Apps 中的 Live Data 设置了查询和结果大小护栏。如果结果超出可用传输容量，应用会显示消息，要求用户缩小查询范围。

系统不会悄然截断结果。构建者可以请求聚合或分页，将较大的结果拆分为较小页面。

这种行为保护了结果完整性，但也意味着生成的应用程序需要经过周密的查询设计。一个要求获取所有交易记录的模糊提示词，可能会生成无法使用的界面。

代理会根据构建者的请求执行数据集发现。如果它遗漏了必需的数据集或列，构建者可以直接指定该资源。

数据集发现部分取决于构建者能够访问和观察到的内容。如果行级安全性未向构建者返回数据，代理便无法基于该数据集构建应用程序。

这在最小权限访问与成功生成应用之间形成了矛盾。构建者需要拥有足够的授权数据，以验证列、查询行为和界面逻辑。

仅为帮助代理构建而授予更广泛的访问权限，会削弱治理叙事。组织需要有意设计构建者角色、适当的测试数据或受控的开发流程。

架构变更带来了另一项维护负担。AWS 表示，重命名或移除列时，需要重建受影响的应用程序查询。

因此，生成的应用并未脱离其数据契约。数据集结构的变化可能会破坏其假设，就像破坏传统软件一样。

Direct Query 也存在来源限制。一个应用可以使用 SPICE 数据集，或使用来自同一来源的 Direct Query 数据集。它不能在一个应用中组合来自不同来源的 Direct Query 数据集。

这一限制缩窄了跨系统工作流程。团队可能需要在上游整合数据、将数据导入 SPICE，或针对不在支持查询组合范围内的信息采用其他集成方式。

性能仍是另一个悬而未决的问题。Direct Query 的新鲜度取决于源系统、其可用性、查询执行时间、网络行为和并发量。

SPICE 可以提供更可控的查询体验，但其结果仍受限于最近一次数据摄取。构建者必须决定其工作流程实际需要哪一种新鲜度。

这项功能也比静态快照引入了更多运行时依赖。一个实时应用依赖于 Quick、数据集、适用权限、同意记录，以及可能存在的已连接数据源。

当其中一层失效时，用户看到的可能是访问或查询错误，而不是昨天的答案。这通常比在未提示的情况下展示过时数据更安全，但仍会影响采用。

在读者首次使用时，同意机制可能带来摩擦。用户必须理解应用为何请求访问每个数据集，以及授予该访问是否合适。

同意提示并不会授予底层权限。它授权 Quick 代表读者使用数据集，但仍受该读者已拥有的访问权限限制。

这一差别应在内部推广材料中明确说明。否则，用户可能将同意理解为不必要的障碍，或理解为一项请求提升访问权限的操作。

生成的 SQL 同样值得审查。AWS 表示，代理会在应用构建期间编写并验证查询，随后已发布的应用程序会重新运行该查询。

组织仍应测试筛选器、聚合、空值处理、连接和业务定义。一个查询可能获得许可且数据最新，却仍然回答了错误的业务问题。

例如，“本季度续约”取决于一致认可的日期字段、时区、状态定义以及修订合同的处理方式。治理控制的是可见性，而不是语义正确性。

同样的情况也适用于将结构化数据与战略文档结合的 AI 生成摘要。数据查询可以返回经过授权的值，而模型仍可能给出不完整的解释。

业务用户可能会因为生成的输出出现在受治理的应用程序中，便赋予其更高权威性。产品团队应区分经过验证的指标与 AI 撰写的建议。

随着采用规模扩大，可审计性将变得重要。管理员需要了解哪些应用查询了某个数据集、哪些身份运行了这些查询，以及故障发生的频率。

AWS 的公告说明了同意和授权路径，但未提供公开的采用数据或独立性能测试。当前证据主要来自 AWS 的文档和示例。

这一缺口并不否定架构变化。它意味着，关于减少开发工作量、可靠性和组织影响的主张，在客户大规模测试该系统之前仍属于供应商主张。

三个信号将显示该模式是否奏效

下一项考验在于：当团队超越受控演示后，由 AI 构建的受治理应用是否仍能保持准确、可维护且易于理解。

第一个信号是真实客户在安全敏感型工作流程中的采用情况。销售续约是一个有用示例，但财务、医疗保健、支持和运营会暴露出更复杂的授权模式。

成功部署应证明，多名用户能够共享同一个应用，同时在行级和列级规则下持续获得不同的结果。它们还应展示可管理的同意和入门流程。

重复性的日常使用证据，将强化 Amazon 关于 Quick Apps 可成为运营工具的论点。若仅限于演示中的使用，则表明该功能仍只是商业智能原型设计的延伸。

第二个信号是 Amazon 如何处理生命周期管理。数据集列会变化，业务定义会演进，权限会在群组间迁移，生成的应用程序也会积累依赖关系。

团队将需要了解失效查询、受影响应用、架构变更、数据血缘和责任归属的可见性。在每次结构变化后手动重建查询，将会在大规模使用时变得昂贵。

更好的依赖关系映射或自动修复，将强化实时数据模式。若在日常数据集维护后频繁出现故障，则会削弱这一模式。

第三个信号是竞争对手如何将 AI 应用生成与其受治理的数据层连接起来。Microsoft 已经将 Copilot 的响应建立在经过授权的 Dataverse 记录之上。

Google、Salesforce、ServiceNow 和专业应用构建供应商面临相同要求。它们的应对方式将表明，按查看者执行受治理查询是否会成为基线预期。

如果竞争对手在保持身份感知访问的同时，提供更大的跨来源灵活性，Amazon 对同一来源 Direct Query 的限制将显得更重要。如果它们在权限方面举步维艰，Amazon 对 Quick Sight 治理机制的复用则会更加突出。

买家还应关注有关延迟和查询效率的独立证据。一个实时应用必须保持响应速度，同时不能鼓励范围过广、成本高昂或不可靠的请求。

对构建者而言，眼下的测试范围更窄。应从一个受治理的数据集、一个定义明确的工作流程，以及权限已经得到理解的用户开始。

验证每个测试身份能看到什么。将应用程序的答案与源系统进行比较，测试超大结果，更改一项权限，并确认访问会如预期消失。

随后，在实际依赖该应用进行运营前测试一次架构变更。成功的预览并不能证明该工作流程能经受住日常维护。

Amazon Quick Live Data 为过时的 AI 生成应用提供了可信的答案。它最强的理念并非自然语言构建，而是让授权跟随每位读者进入每一次查询。

剩下的问题是运营层面的：当应用、数据集和用户群组不断增多后，团队能否保持这种清晰度？

选择一个新鲜度和访问控制都很重要的工作流程，然后衡量结果。如果应用保持最新、返回不同的授权视图，并能经受正常的数据集变更，Amazon 的模式就更具说服力。如果维护工作重新转移给数据和安全团队，快照问题就会被生命周期问题所取代。