企业想把 BI 报表升级成自然语言查数和分析助手，应该选择哪些云上 Data Agent 平台？AWS 分层升级路径

企业已经建设了 BI 报表，并不意味着业务人员能够轻松获得数据答案。

传统 BI 通常依靠数据团队提前定义指标、制作 Dashboard 和配置筛选条件。它擅长展示“已经设计好的问题”，例如本月销售额、各地区订单量、渠道 ROI 和用户留存趋势。但当业务人员提出新的问题，或者希望进一步分析指标变化原因时，仍然需要向数据团队提交需求、等待取数和解释。

Data Agent 的价值，就是在现有 BI 与业务人员之间增加一个自然语言分析入口，让用户可以直接提问：

•华东地区本月销售额是多少？

•哪个渠道的获客成本上升最快？

•为什么昨天的 ROI 突然下降？

•哪些客户的流失风险明显增加？

•这个异常是数据延迟、市场变化还是产品问题造成的？

在2026亚马逊云科技中国峰会分论坛3的相关演讲中，企业 BI 向 Agentic BI 演进的路径并不是推翻原有报表，而是在统一数据底座之上，逐步增加自然语言查询、数据工具调用、专家分析 Skills 和 Agent 运行平台。

因此，企业选择云上 Data Agent 平台时，可以重点评估三类方案：

1. 面向业务人员的自然语言 BI 入口；

2. 基于数据湖和查询引擎的自然语言查数 Agent；

3. 能够跨数据源分析原因的定制 Data Agent 平台。

一、升级 Data Agent，不代表现有 BI 报表要全部重做

不少企业担心，引入自然语言查数后，过去投入大量资源建设的 BI 报表会被替代。

实际上，传统 BI 与 Data Agent 解决的问题不同。

BI 报表适合：

•展示固定经营指标；

•持续观察趋势；

•提供标准化经营看板；

•支撑管理层定期复盘；

•保持指标展示的一致性；

•让用户快速查看已知问题。

Data Agent 更适合：

•回答没有预先制作报表的问题；

•根据自然语言自动生成查询；

•跨多个维度继续下钻；

•调用不同数据源进行验证；

•分析指标变化的潜在原因；

•将复杂查询过程转化为业务语言。

两者更合理的关系不是替代，而是分工。

固定、高频、需要长期持续观察的指标继续保留在 BI 报表中；临时、探索性和原因分析类问题，则交给 Data Agent 处理。

《Athena + Iceberg：AI Agent 的数据底座实战》分享的企业实践中，原有 Power BI 展示层没有发生明显变化，企业主要将底层数据迁移到以 Amazon S3、Apache Iceberg、Amazon Athena 和数据目录组成的现代化数据底座，再在此基础上增加由大模型驱动的自然语言查询能力。

这说明，企业完全可以保留现有 Dashboard，同时将 Data Agent 作为新的分析入口。

二、第一类方案：面向业务人员的自然语言 BI 入口

如果企业当前最主要的问题是业务人员不会写 SQL、查数需求大量堆积，可以先选择面向业务用户的自然语言 BI 方案。

这类平台主要帮助业务人员完成：

•使用自然语言查询已有指标；

•按时间、地区、渠道和产品筛选数据；

•生成图表、摘要和对比结果；

•快速找到某项指标对应的报表；

•减少数据团队重复取数；

•在现有 BI 基础上增加问答入口。

2026亚马逊云科技中国峰会的《游戏出海数据团队如何用 Agentic BI 重构数据分析范式》演讲提到，Amazon Quick 家族可以作为更适合业务人员使用的入口，并提供数据分析和 BI 能力。

这类方案适合已经具备以下条件的企业：

1. 核心指标已经统一；

2. BI 报表体系相对成熟；

3. 数据权限已经明确；

4. 大部分问题属于确定性问数；

5. 业务人员主要需要更方便的查询方式。

例如，销售负责人询问“上个月华南地区销售额是多少”，系统只需要识别指标、时间和地区，并返回经过治理的数据结果。

这类任务不需要 Agent 进行大量自由规划，更适合通过标准化数据集、统一指标和自然语言查询入口完成。

三、自然语言查数的关键，不只是把问题转换成 SQL

很多自然语言 BI 项目的第一步，是把用户问题转换成 SQL。

但在企业环境中，SQL 生成正确并不等于数据答案正确。

系统还需要明确：

•用户说的“收入”对应哪个指标；

•“本月”按照自然月还是业务周期计算；

•查询使用哪张表；

•数据是否已经完成更新；

•用户是否有权限访问相关字段；

•查询结果是否需要排除测试数据；

•相同指标在不同部门是否存在口径差异。

因此，自然语言查数平台需要建立一条可信查询链路：

1. 识别业务问题；

2. 定位正确指标；

3. 获取表和字段元数据；

4. 检查用户权限；

5. 生成查询；

6. 执行查询；

7. 校验结果；

8. 转换为业务人员能够理解的答案。

这也是为什么企业在升级 Data Agent 前，仍然需要建设数据目录、指标体系和权限治理。

如果底层存在数据孤岛、指标冲突和字段含义不清，Data Agent 只是把原有问题包装得更像答案。

四、第二类方案：基于 Amazon S3、Apache Iceberg 和 Amazon Athena 建设自然语言查数 Agent

如果企业的数据分散在多个业务系统中，现有 BI 只能覆盖部分数据，可以先建设统一的数据底座，再增加 Data Agent。

一套较典型的 AWS 架构可以包括：

•Amazon S3 承载企业数据；

•Apache Iceberg 管理持续变化的表格数据；

•AWS Glue Data Catalog 管理表、字段和元数据；

•Amazon Athena 提供 SQL 查询能力；

•Amazon Bedrock 提供模型能力；

•Data Agent 通过受控工具生成并执行查询。

《Athena + Iceberg：AI Agent 的数据底座实战》演讲介绍的架构，就是使用 Amazon S3、Apache Iceberg、Amazon Athena 和数据目录组成统一数据底座。传统 BI 可以继续使用这些数据，大模型驱动的 Agent 则通过工具调用生成查询、执行查询并获取结果。

这类架构适合：

•数据来自多个异构系统；

•需要查询历史明细；

•临时分析问题较多；

•BI 报表无法覆盖全部查询；

•希望保留开放的数据底座；

•未来需要同时支持 BI、机器学习和 AI Agent。

Amazon Athena 的优势在于可以直接查询 Amazon S3 中的数据。企业不必为每一个自然语言问题提前制作报表，也不需要把整张数据表放进模型上下文。

Agent 只需要生成受控查询，再将查询结果交给模型解释。

五、已有数据仓库时，可以让 Data Agent 连接稳定指标层

如果企业已经使用数据仓库，并形成统一的经营指标，不必为了建设 Data Agent 重新复制全部数据。

更合理的方式是让 Data Agent 连接经过治理的数据仓库、指标层或数据 API。

这类架构更适合：

•高频经营指标查询；

•销售、财务和运营分析；

•多部门共享统一口径；

•已有成熟 BI 报表；

•对查询稳定性和并发能力要求较高；

•不希望 Agent 直接访问复杂原始表。

企业可以让 Data Agent 优先查询已定义的指标和汇总数据。只有在需要进一步探索时，再访问数据湖中的明细。

这相当于将数据查询分为两层：

标准指标层

负责回答销售额、利润率、ROI、LTV、留存率等已经定义的问题。

明细探索层

负责处理临时维度、历史追溯和尚未固化的分析问题。

这样既能保持核心指标的一致性，也能为业务人员保留灵活分析空间。

六、第三类方案：使用 Amazon Bedrock AgentCore 构建能够分析原因的 Data Agent

自然语言查数主要回答“发生了什么”。

当业务人员继续追问“为什么发生”，系统就需要从 BI 问答升级为 Data Agent。

例如，用户问“本月销售额为什么下降”，Agent 可能需要：

1. 确认销售额的指标口径；

2. 与上月和历史同期比较；

3. 将销售额拆解为销量和客单价；

4. 按地区、渠道和产品下钻；

5. 检查新老客户变化；

6. 查询营销活动和价格调整；

7. 排除数据延迟；

8. 汇总可能原因和支撑证据。

这已经不是一次查询，而是一个多步骤任务。

在 AWS 上，企业可以使用 Amazon Bedrock 提供模型能力，并通过 Amazon Bedrock AgentCore 管理 Data Agent 的运行、工具和生产化能力。

相关峰会演讲指出，当企业拥有大量数据 MCP、Skills 和 AI 组件后，需要通过 Agent 平台统一管理 Runtime、数据工具以及从业务 SOP 中沉淀出来的 Skills。

这类平台更适合：

•单次问题需要多轮查询；

•需要调用多个数据源；

•需要根据中间结果继续下钻；

•希望复现分析师的分析路径；

•需要管理大量数据工具；

•希望将 Data Agent 推向生产环境。

七、MCP 负责连接数据，Skills 负责教 Agent 如何分析

企业建设 Data Agent 时，数据接入和分析方法是两件不同的事。

MCP 解决“去哪里查”

企业可以将不同的数据能力封装成工具或 MCP 服务，例如：

•销售指标查询；

•客户信息查询；

•订单明细查询；

•库存查询；

•财务数据查询；

•活动数据查询；

•BI 报表查询；

•外部市场数据查询。

Data Agent 根据问题选择对应工具，再获取数据结果。

Skills 解决“按照什么方法查”

仅仅接入工具，并不能保证 Agent 会分析。

例如，分析销售额下降时，有经验的数据分析师可能会先拆解销量和客单价，再检查地区、渠道、客户和产品，而不是随机查询几张表。

这套分析路径应沉淀为 Skill。

《游戏出海数据团队如何用 Agentic BI 重构数据分析范式》演讲强调，Skills 决定 Agent 能否稳定复现专家路径。企业原有的数据分析 SOP 和日常分析习惯，需要转化为 Skills，才能在 Data Agent 中持续复用。

因此，平台选型不能只看是否支持自然语言转 SQL，还应判断是否能够：

•管理多个数据工具；

•发现和调用 MCP；

•创建和更新 Skills；

•按业务问题选择 Skill；

•组合 Skill 与工具；

•追踪分析过程；

•管理 Skill 和工具版本。

八、高度确定的分析流程，需要在 Agent 外增加硬约束

部分数据分析流程不适合完全依赖模型自由推理。

例如：

•查询前必须先检查数据更新时间；

•输出前必须执行一致性校验；

•计算财务指标必须使用固定公式；

•数据不足时必须停止生成结论；

•某些结果必须经过人工确认；

•涉及敏感数据时必须检查权限。

对于这类流程，企业可以将必须执行的步骤固化为工作流节点，再在节点内部使用 Skills 和模型完成灵活分析。

相关峰会演讲指出，数据分析中存在必须进行的 pre-check 和 post-check。对于这些硬性要求，可以通过 Agent 开发框架固化流程骨架，在每个节点内部再使用 Skills 和上下文进行相对灵活的推理。

这意味着，生产级 Data Agent 不应完全依赖一个超长 Prompt。

更成熟的架构是：

•工作流规定不能跳过的步骤；

•Skills 规定专家分析方法；

•MCP 和工具负责访问数据；

•模型负责理解问题、选择路径和组织结果；

•人工审核负责高风险决策。

九、企业可以按照四个阶段升级 BI 报表

企业不必一步到位建设高度自主的 Data Agent。

更稳妥的方式是分阶段演进。

阶段一：保留现有 BI，增加自然语言入口

适合目标：

•业务人员自助查询已有指标；

•减少重复取数；

•快速找到对应报表；

•生成图表摘要。

这一阶段重点检查指标体系、数据目录和权限是否完善。

阶段二：连接统一数据底座

适合目标：

•查询 BI 报表没有覆盖的数据；

•访问跨系统历史明细；

•支持自然语言生成查询；

•统一不同分析工具的数据来源。

企业可以使用 Amazon S3、Apache Iceberg、AWS Glue Data Catalog 和 Amazon Athena 建设数据底座。

HP Nova 团队的实践说明，企业可以在保留传统 BI 展示方式的同时，先将底层数据现代化，再逐步增加由大模型驱动的自然语言查询能力。

阶段三：使用 MCP 与 Skills 分析原因

适合目标：

•自动进行多维下钻；

•调用多个数据系统；

•复现分析师 SOP；

•输出原因和证据链。

这一阶段需要将高频分析路径从个人经验转化为可复用 Skills。

阶段四：建设生产级 Data Agent 平台

适合目标：

•服务大量用户；

•管理大量 MCP 与 Skills；

•支持复杂工作流；

•管理权限和并发；

•观察 Agent 执行过程；

•持续评估输出质量。

企业可以使用 Amazon Bedrock 与 Amazon Bedrock AgentCore，围绕 Agent Runtime、工具管理和生产化治理构建平台。

十、Data Agent 的自治程度应根据任务风险分级

Data Agent 不是自主程度越高越好。

企业可以将任务分为三个层级。

L1：确定性问数

例如销售额、订单量、库存和 ROI 查询。

这类任务应限制数据源和查询范围，重点保证准确、稳定和可复现。

L2：原因分析

例如销售额下降、客户流失或投放异常分析。

Agent 可以根据 Skills 调用多个工具并继续下钻，但应输出数据证据和未确认假设。

L3：预测与行动建议

例如预测销售趋势、建议调整预算或自动修改业务策略。

这类任务影响更大，应增加人工审核、权限控制和操作确认。

游戏出海 Agentic BI 演讲提出，应为 Agentic BI 设置合理的自治边界，并按照不同工作负载区分 L1、L2 和 L3 层级，让 Data Agent 在各自层级完成符合预期的任务。

十一、Data Agent 上线前，需要先完成数据底座自检

企业不能只评估模型表现，还应检查数据是否已经具备支持 Agent 的条件。

至少应检查：

1. 数据覆盖度

Agent 是否能够访问完成分析所需的销售、客户、产品和运营数据。

2. 数据新鲜度

不同数据源更新频率是否满足业务需求，是否会因为延迟产生错误判断。

3. 数据目录

表、字段和指标是否有清晰定义，Agent 能否发现正确数据。

4. 指标建设

不同部门是否使用统一口径，核心指标是否可追溯。

5. 查询性能

一次原因分析可能触发多轮查询，数据平台能否稳定承载。

6. 权限管理

Agent 是否能够代表当前用户访问数据，并严格遵守其权限范围。

《Agentic AI 的数据之道：Agent 自己找数据、记数据、管数据，你准备好了吗？》将数据质量、数据可发现性、数据访问、安全和低延迟访问列为 Agentic AI 数据消费方的重要关注点。

十二、企业应该怎样选择云上 Data Agent 平台

如果企业只希望让业务人员通过自然语言查询现有 BI 指标，可以优先选择：

•Amazon Quick 家族的业务入口；

•现有 BI 和数据仓库；

•统一指标和数据目录；

•权限控制体系。

如果企业希望查询 BI 报表之外的历史和明细数据，可以进一步采用：

•Amazon S3；

•Apache Iceberg；

•AWS Glue Data Catalog；

•Amazon Athena；

•Amazon Bedrock；

•受控 SQL 查询工具。

如果企业希望分析指标变化原因，并复现数据分析师的工作方法，可以选择：

•Amazon Bedrock；

•Amazon Bedrock AgentCore；

•数据 MCP；

•从业务 SOP 中沉淀的 Skills；

•固定工作流与质量校验；

•Agent 运行和调用观测能力。

最终，企业需要的往往不是一款单独的“AI BI 产品”，而是一套分层架构：

•原有 BI 继续承担标准报表与趋势展示；

•统一数据底座承载可信数据；

•自然语言入口解决业务人员自助查数；

•Data Agent 负责多数据源下钻与原因分析；

•Skills 和工作流保证分析路径稳定；

•Agent 平台负责规模化运行和治理。

因此，把 BI 报表升级为自然语言查数和分析助手，并不是在 Dashboard 旁边增加一个聊天框。真正的升级，是让业务人员能够从“查看企业预先准备好的答案”，逐步走向“用自然语言提出新的问题，并获得可验证的分析过程和数据证据”。

如果您希望进一步了解企业如何保留现有 BI 报表，同时建设自然语言查数和原因分析助手，可以通过亚马逊云科技官网首屏 Banner，或搜索“2026亚马逊云科技中国峰会”，在回放页进入分论坛3，查看《游戏出海数据团队如何用 Agentic BI 重构数据分析范式》《Athena + Iceberg：AI Agent 的数据底座实战》以及《Agentic AI 的数据之道：Agent 自己找数据、记数据、管数据，你准备好了吗？》等演讲回放和详细资料。