Amazon QuickSight 与 Amazon Quick：功能、价格与选型指南

Amazon Quick Suite 现已更名为 Amazon Quick，延续了 Amazon QuickSight 的分析能力。如果运营团队需要在同一工作流程中使用公司知识、查看仪表板并执行跨应用操作，它值得试点。Amazon Web Services（AWS）目前提供六种订阅方案，因此，选对部署方式与选对助手同样重要。

最适合尝试 Quick 的，是已经信任自家 AWS 分析体系、希望从数据异常一路推进到有依据的应对措施的运营团队。仅仅因为公司的应用运行在 AWS 上，并不意味着 Quick 就是所有员工的最佳助手。

本文依据公开文档进行评估，并于文章发布当日对照文中链接的厂商页面核验。本文未进行登录后的产品实测。

Amazon Quick Suite 是什么？与 Amazon QuickSight 有何关系？

Amazon Quick 是 AWS 的工作助手，以对话为入口，连接研究、商业智能和自动化。可以把它想象成一座配有分析台和调度室的企业图书馆：查找制度、解释业务指标、修改记录彼此相关，但各自需要不同的资源和权限。AWS 产品概览介绍了目前的产品形态。

理解旧名称，有助于看清它的基础。Amazon QuickSight 原本是商业智能产品，如今以 Amazon Quick Sight 的名称继续存在于 Quick 中，注意当前功能名称中多了一个空格。AWS 表示，现有 QuickSight API、软件开发工具包和集成仍可使用。另一条产品脉络来自企业知识助手 Amazon Q Business：AWS 将 Quick 称为它的下一代形态，并允许现有客户将 Q 索引接入 Quick。Q Business 已不再向新客户开放。这些信息意味着企业应该评估已有资产，不能据此认定迁移已经完成。参见 Quick 文档与 Q Business 概览。

对运营负责人而言，真正有用的变化，是依据与执行之间的衔接。一个采购问题可能同时涉及交付指标、供应商协议，以及经过批准的后续任务。Quick 为这些工作提供了共同的环境，但可用的数据、访问规则和明确的流程负责人，仍需企业自己落实。

各项功能分别解决什么问题？

这些组件分别承担业务任务中的不同环节。先分清职责，才能选出有价值的试点，也能避免为只需查看结果的员工购买内容创建能力。

Amazon Quick Research：查资料，也要能追溯依据

Amazon Quick Research 可以从网页、上传的文件、已连接的 Spaces 和知识库等来源收集、综合信息，输出附有引用、可追溯来源的研究报告。参见 AWS Research 文档。

采购经理可以把供应商公开披露的情况与内部供应商记录放在一起研究。价值在于形成一条可供审核者追查的证据链。引用让结论有据可查，却不能证明来源仍然有效、合同适用于当前情形，或结论本身正确。应请审核者重点核对那些会影响决策的原文段落。

Amazon Quick Sight：围绕业务指标开展分析

Amazon Quick Sight 提供商业智能（BI）能力，包括经过准备的数据、交互式可视化、仪表板和报告。它既可直接查询数据源，也可使用内存分析引擎 SPICE。参见 AWS Quick Sight 文档。

运营经理调查交付延迟时，仪表板首先应明确：什么算延迟，哪些订单纳入计算。之后，Research 才能补充背景。只有底层数据集的含义与业务认知一致，让一个表达流畅的助手解释指标才有意义。

对于现有 QuickSight 客户，这正是 Quick 最突出的适配点：企业已有可带入对话的分析资产。尚未统一指标口径的公司，仍然需要先完成数据准备和定义工作。

Amazon Quick Flows 与 Amazon Quick Automate：任务不同，负责的人也不同

Amazon Quick Flows 处理个人和团队的重复性任务，例如生成报告、起草回复。Amazon Quick Automate 面向更完整的业务流程，包括需要脱离单个用户独立运行的工作。AWS 用控制流、案例管理、错误处理和自定义代码等能力来区分 Automate。参见 AWS 自动化指南。

定期生成供应商简报，适合尝试 Flow。涉及异常处理、人工审核和跨系统修改的供应商准入流程，则应评估 Automate。区别不仅在复杂程度，也在责任归属：原创建者调岗后由谁维护？某个步骤失败时由谁处理？

能使用 Flows，不代表也能使用 Automate。当前方案对照表中，只有 Enterprise 包含 Quick Automate。

聊天智能体与 Spaces：明确助手的任务，提供所需背景

聊天智能体将指令、知识和工具组合起来。Quick 提供系统智能体 My assistant，也允许拥有相应权限的用户创建自定义智能体。回答所使用的内容仍受调用者的访问权限约束。参见 AWS 聊天智能体文档。

Spaces 按团队或业务领域组织资源，包括文件、仪表板、知识库和应用操作。供应商运营团队可以用一个 Space 汇集相关资料，再通过指令告诉智能体如何使用。Space 负责汇集上下文，并不能替代其中各项资源自身的权限设置。参见 AWS Spaces 文档。

Amazon Quick Index 与连接器：接入知识，连接外部系统

Amazon Quick Index 为有据可依的回答提供可搜索的企业知识。知识库是对选定来源内容建立索引后形成的集合。AWS 将负责连接来源的数据访问集成，与负责让指定内容可供 AI 分析的知识库区分开来。支持的来源包括 Amazon S3、SharePoint、Google Drive 和 Confluence。索引内容按配置的同步计划更新。参见 AWS 知识库指南。

连接器可以实时调用外部服务并执行操作。支持的连接方式包括 Model Context Protocol（MCP）和 OpenAPI 规范，这些标准用于向外部提供工具和服务操作接口。扩展将 Quick 带入现有应用和浏览器；结构化数据连接则为 Quick Sight 分析提供数据。这些集成各有分工。参见 Quick 的工作原理。

AWS 明确指出，并非每个应用都支持所有集成类型。试点时要核对具体操作：读取文档、搜索已索引内容、更新记录，是不同的需求。仅仅在连接器列表里看到熟悉的应用名称，还不足以下判断。参见集成文档。

当前产品还包括 Apps in Amazon Quick，可用自然语言创建交互式 Web 应用；同时也提供桌面端，可结合本地文件、邮件和日历上下文开展工作。这些能力扩展了使用入口，但具体任务及其访问规则仍需验证。参见 AWS 组件概览。

先确定部署方式，再选择助手

由 IT 主导的部署，应先看组织版方案及其治理要求。AWS 将注册方式分为两类：Free、Plus 和 Max 可通过邮箱或社交账号注册；Essentials、Professional 和 Enterprise 则通过 AWS 账号部署。组织版方案包含基于角色的访问控制、单点登录和管理控制。在组织版内部，还应区分只查看仪表板的用户、创建仪表板的用户，以及搭建 Automate 流程的用户。参见 AWS 当前方案对照表。

Amazon Quick 价格一览

下表汇总了 AWS 当前定价页面的主要计费项目，金额均为美元。表中的年付价格为按年结算时折算的月费。

智能体小时衡量的是聊天、Research、Flows、Automate 及其他智能体功能中的 AI 活动量，并非员工打开窗口的时长。AWS 表示，推理模式和并行工作会影响消耗；交互之间的空闲时间不计入用量，但对外部工具的同步调用可能计入。估算持续运行的负载前，应先观察实际消耗。

对于 Essentials 和 Professional，管理员必须先配置 Limit Profile，用户才能超出所含额度。Enterprise 无需配置即可超额使用，但如果分配了 Limit Profile，就会受其约束。定时任务在无人持续关注的情况下运行时，这些控制尤其重要。定价页面还链接了仅包含 BI 的选项，适合需求仍集中在查看仪表板、无需完整助手能力的组织。

数据与权限如何管理？

知识访问、文档访问和执行操作的权限，应分别核查。能否分清这几层权限，决定了试点能否安全地扩展为全公司共享的服务。

先确认身份和资源访问权限。 通过 AWS 账号开通服务时，可使用 IAM Identity Center 或 IAM Federation，将组织身份与服务连接起来。Quick 智能体使用的是调用者有权访问的资源。虽然配置由服务托管，谁能获得访问权限、能使用哪些资源，仍由企业决定。参见 AWS 配置概览。

留意直接上传到 Space 的文件。 AWS 表示，通过链接接入的 Quick 资源会保留原有权限；直接上传到 Space 的文件，则向所有能访问该 Space 的人开放。因此，把受限文档复制到广泛共享的 Space，可能改变它的可见范围。参见 Space 访问规则。

知识库访问权限不等于文档级安全控制。 通用知识库文档描述的是集合层面的访问权限，部分集成则提供更细的控制。对于管理员管理的 SharePoint 知识库，文档级访问控制列表（ACL）是可选项。启用后，Quick 会依据同步的 ACL 过滤内容，并在将某份文档用于回答前，核实该用户当前在 SharePoint 中的访问权限。参见知识库控制说明与 SharePoint ACL 文档。

单独审核执行操作的权限。 对于 AWS 服务连接器，Quick 使用预先配置的 IAM 角色；AWS 文档说明，这类连接器只能通过 Quick Automate 使用。连接器归谁管理，与谁有权调用操作，是两项独立的授权。用户可以读取发票，并不意味着某个工作流就应该有权修改外部系统。参见 AWS 服务连接器文档。

模型训练与数据处理地点是两回事。 AWS 表示，所有 Quick 方案都不会使用客户数据训练模型，但这并不意味着每个请求都会留在所选的存储区域。对于美国境内的跨区域推理，AWS 文档说明：数据存储在主区域，而提示词和结果可能在美国境内的另一个区域处理。这一路由由 Quick 管理，客户无法通过该页面提到的 Bedrock 推理控制来配置。应根据自己的部署方式和所用功能，核对当前的区域处理行为。参见 AWS 关于数据使用的说明与区域处理文档。

与 Microsoft 365 Copilot、Gemini Enterprise 如何选择？

如果员工主要需要在 Microsoft 的办公应用中获得帮助，Microsoft 365 Copilot 应当是首先比较的对象。Microsoft 文档介绍了 Word、Excel 等应用中的 Copilot 体验；能否结合组织数据提供回答，以及具体的集成能力，取决于许可和租户配置。访问工作数据时遵循用户自身的权限。参见 Microsoft 概览与架构文档。

以 Microsoft 文档和沟通协作为核心的工作，应继续把 Copilot 作为首选评估对象。如果任务依赖经过治理的 Quick Sight 指标和相连的运营操作，再为 Quick 安排单独的试点。Quick 提供 Microsoft 应用扩展，并不能证明它能带来相同的应用内体验。在替换现有部署前，可先通过 Microsoft 365 Copilot 定价指南了解相关许可。

Gemini Enterprise 是 Google 的企业搜索、助手和智能体平台。其文档介绍了跨已连接来源、遵循权限的访问能力，来源包括 SharePoint、Confluence、Jira 和 ServiceNow，同时也支持自定义智能体。对于全公司的知识访问需求，它是直接的比较对象，适用范围并不局限于 Google 文档。参见 Google Gemini Enterprise 文档。

如果企业混用多套应用，应围绕员工需要的数据来源、必须执行的操作，以及 IT 团队能长期承担的管理工作，比较 Quick 与 Gemini Enterprise。现有 Quick Sight 资产处于任务核心时，Quick 值得多加关注。Gemini Enterprise 详解进一步讨论了该平台的采用决策。

如果 ChatGPT Business 已经是公司的通用工作助手，就应为 Quick 指定一项明确的业务流程，用结果说明为什么值得新增或替换。不要仅仅因为它能通过 AWS 获得，就再投入一次全公司部署。Glean 替代方案指南将这些选择放在更广泛的企业助手市场中进行比较。

哪些期待被夸大了？谁适合现在试点？

“接通数据，就能得到一个可靠的自主同事”，是被夸大的期待。连接带来的是对资料和操作的访问能力。回答是否正确，仍取决于来源质量；操作是否可靠，仍需要明确责任归属、异常处理和审核机制。

运营以 AWS 为中心，且分析体系成熟的团队，可以现在试点。 如果运营负责人已有可信的 Quick Sight 仪表板和成文流程，就具备了可供评估的具体资产。真正要验证的是：Quick 能否围绕一个实际异常，从寻找依据推进到提出有用的应对建议。

负责多套应用的 IT 团队，应有选择地试点。 需要证明具体连接器确实支持所需的知识访问和操作，受限用户的权限仍受到限制，管理员也能看懂用量。集成和权限工作本就是采用过程的一部分，不能留到全面部署时再处理。

流程没有明确负责人、数据定义尚未统一时，应先等等。 组织内部对仪表板含义的分歧，不会因为引入助手就消失。先把流程稳定下来，再决定助手应该读取什么、可以修改什么。

尚未满足的需求很少时，继续使用现有助手。 如果创始人或独立开发者主要需要写作和通用辅助，就不应在缺乏明确工作负载的情况下，引入面向整个组织的数据与自动化平台。同样，现有用户如果只需要 BI，也应先评估仅含 BI 的方案，再判断是否人人都需要完整的助手体验。

下一步怎么做：试点供应商异常复核

从一个范围明确、人已经清楚其输入与预期结果的流程开始。供应商异常复核就是合适的例子：发现交付问题、汇集相关制度，再准备一项经批准的后续措施。这是试点评估的设计示例，并非本文已经实测过的流程。

1. 1

   明确预期答案

   选择一个已发生的异常，写清一名合格运营人员会使用的仪表板、原始文档，以及应得出的处理结果。同时明确：证据相互矛盾或缺失时，助手应该怎么做。

2. 2

   加入操作前，先验证访问权限

   连接必要资源，分别用有权限的用户和不应看到受限资料的用户提问。对于受支持、由管理员管理且已启用 ACL 的知识库，AWS 在同步报告中提供 View Access Details 和 Permission Checker。应将这些工具与实际查询结果结合起来检查。参见 AWS 访问检查文档。

3. 3

   审核拟执行的操作

   先让助手起草后续处理方案。启用写入操作前，要确认连接器支持的具体操作、所用凭证、由谁批准变更，以及流程如何处理失败。再决定这项任务应由个人的 Flow 承担，还是交给集中管理的 Automate 流程。

4. 4

   评估完整工作流程

   记录证据是否支持答案、权限是否按预期生效、需要多少人工修正，以及 Mission Control 显示的智能体用量。只有完整任务带来的价值足以支撑持续管理成本时，才扩大使用范围。

想获取在工作中采用 AI 的实用建议，欢迎订阅邮件通讯。