为什么我们不再喊“ChatBI”

过去两年，“对话式BI”、“ChatBI”、“Text-to-SQL”几乎成了标配能力：只要接上大模型、能把自然语言翻成SQL，再加一个聊天界面，就可以对外宣称是“AI分析助手”。

问题在于，真正落到企业一线场景时，一个“大而全的ChatBot”往往难以支撑完整的业务分析闭环。很多项目在PoC和演示阶段看起来“能回答问题”，但要真正嵌入日常经营决策，还需要考虑场景覆盖、分析深度、可靠性和数据治理等一整套体系。

因此，接下来这篇文章不会再纠结“要不要做ChatBI”，而是尝试回答一个更关键的问题：如何利用Amazon Quick Suite、Amazon Bedrock AgentCore和Snowflake Cortex Agents，把“能聊天的BI”升级为“能协同工作的数据智能中台”，并满足企业级落地的要求。

ChatBI模式的现实挑战

即便已经接入大模型，很多企业内部的ChatBI项目，最终都停留在Demo或小范围试点阶段，主要有几类共性问题：

单Agent能力有限，遇到复杂问题容易“聊崩”

简单的取数问答还可以应付，一旦问题涉及多个指标、关联多个系统或需要追问，单一ChatBot很难自己规划步骤、拆解子任务。

缺乏业务语义与治理上下文，回答不够“敢用”

模型可以生成SQL，但如果不知道企业内部的指标口径、权限边界和合规要求，要么回答含糊，要么给出看似“对”，但没人敢直接采纳的结论。

难以串起“从问题到行动”的全链路

多数ChatBI只能停留在“回答一个问题”，很难进一步自动联动报表、工单、通知或其它业务系统，导致分析和执行之间仍然靠人工接力。

体验与运维都难规模化

初期的Demo可以靠项目组手工调参数、写prompt，一旦推广到多个业务线，不同场景下的提示词、工具组合和模型选择，很难在一个单体ChatBot里维护。

真正的突破点，不是再造一个更聪明的ChatBot，而是引入多Agent协同和标准化工具编排，让“问问题的人”始终面对一个简单对话界面，后台则由一组专职Agent分工合作，去完成从理解意图、访问数据到生成结论乃至触发后续动作的整个闭环。

从ChatBI到多Agent分析中台

基于前文提到的这些限制，本文结合Amazon Quick Suite、Amazon Bedrock AgentCore和Snowflake Cortex AI，设计了一套满足企业级落地条件的多Agent对话式分析方案。

这套方案既能够沿用现有的BI和数据治理体系，又通过多Agent协同，让企业更快速、准确地构建可以在生产环境长期运行的分析助手，在不改变企业原有数据与治理体系的前提下，用多Agent协同和统一前台体验，把“对话问数”升级为可在生产环境长期运行的分析中台。

本方案采用了一个相对“传统”但在Agentic AI语境下重新被激活的三层解耦架构：交互层、编排层、执行层。

不同的是，团队在每一层都注入了多Agent与治理的设计理念。

交互层：Amazon Quick Suite

交互层直接面对业务用户，核心组件是Amazon Quick Suite。

Chat Agent对话界面

基于大语言模型的Chat Agent，支持多轮对话和上下文理解，让用户可以用自然语言持续追问、细化分析需求。

MCP协议集成

通过Model Context Protocol（MCP）与后端的工具和Agent建立标准化连接，为后续扩展更多能力预留空间。

智能路由入口

根据用户意图自动选择走Dashboard预构建分析路径，还是走实时Text-to-SQL路径，避免所有问题都“硬上大模型”。

统一工作空间

在同一个界面中集成Dashboard可视化、工作流自动化和对话记录，让业务用户有一个完整的分析与协作空间。

这一层的设计目标，可以简单概括为：把多Agent的复杂协同，压缩成业务侧感知到的一句“我就跟它聊天”。

编排层：Amazon Bedrock AgentCore

编排层是整套方案的“神经中枢”，由Amazon Bedrock AgentCore承担：

Gateway组件

负责MCP协议与底层RESTful API之间的协议转换，让后端的Snowflake Cortex Agents、Lambda函数等都能以统一方式被调用。

认证与鉴权

基于Amazon Cognito的JWT Token机制，将前台用户身份与后端调用串联起来，确保每一次数据访问都能被追踪和控制。

语义工具选择

AgentCore利用任务上下文和提示信息，动态选择最合适的工具或Agent，而不是事先写死调用顺序。

统一工具接入

支持OpenAPI、Smithy、Lambda等多种工具类型的标准化接入，方便后续逐步扩展更多企业内部系统与第三方服务。

如果说交互层解决的是“用户怎么问”的问题，那么编排层解决的就是：在一堆能力里，如何自动选择“该用谁、以什么顺序用、用到什么程度就可以停”。

执行层：Snowflake Cortex AI

执行层是这套架构的“算力与数据”交汇点，由Snowflake Cortex AI提供：

Cortex Analyst（Text-to-SQL引擎）

基于LLM的Text-to-SQL服务，结合语义模型，支持复杂业务查询语义理解与高质量SQL生成。

Cortex Agents（多Agent协同执行）

面向不同分析任务定义专职Agent，负责自动分解和协调复杂分析流程，如分步取数、对比分析、结果摘要等。

语义模型（YAML业务元数据层）

使用YAML定义业务术语、指标口径、实体关系和常见问法，为Text-to-SQL和多Agent推理提供统一“业务词典”。

数据治理与安全

所有查询都在Snowflake内部执行，配合RBAC、行列级权限控制和审计，确保数据不出治理边界。

这意味着，从前台看似“聊了几句天”，实质上是多个Cortex Agent在Snowflake内部轮番登场，各自完成一段工作，再把结果拼成一个可信的答案。

核心技术实现

多Agent协同的关键机制

在上述三层架构之上，本方案重点落地了三类关键机制，让整个链路既“跑得起来”，又“跑得稳”。

双路径智能路由：

Dashboard+Text-to-SQL

系统首先会根据查询特征，在两条路径之间做智能路由：

路径一：Dashboard预构建查询

流程：用户查询→Chat Agent意图识别→Amazon QuickSight Dashboard→返回结果。

适用场景：基于固定报表的预定义分析，例如“本月销售额是多少”、“Top10客户有哪些”。

优点：响应秒级、口径一致、易于被管理。

路径二：实时Text-to-SQL

流程：用户查询→MCP协议→AgentCore Gateway→Lambda函数→Snowflake Cortex Agents→SQL执行→返回结果。

适用场景：灵活的临时查询，例如“区域环比增长前5的产品SKU是哪些”。

优点：无须为每个问题单独建报表，真正支持ad-hoc分析。

通过这套设计，用户可以避免“要么全靠报表，要么所有问题都走LLM”的极端模式，而是让系统在稳定性和灵活性之间自动找到平衡点。

异步处理架构：兼顾复杂查询与前台体验

在企业实战中，不少查询本身就具有高复杂度：多表JOIN、大时间跨度明细拉取、复杂聚合与排序等。如果一味追求同步返回，要么牺牲系统稳定性，要么被迫大幅缩减业务问题的表达空间。

因此，本方案采用了同步+异步双模式：

简单同步模式

Lambda函数直接调用Cortex Agents，实时执行查询并将结果返回给前台，适合秒级可返回的场景。

复杂异步轮询模式

工具1：启动查询，生成query_id，并将状态写入Amazon DynamoDB等存储。

工具2：根据query_id周期性轮询查询状态，完成后将结果推送给前台或供前台主动拉取。

这样，业务侧看到的仍然是一个自然的对话过程：“我帮你跑一个复杂分析，稍后把结果发给你”，而后端则可以在可控的资源与时延范围内，稳妥完成真正重型的分析任务。

语义模型驱动的Text-to-SQL

多Agent能否靠谱，很大程度上取决于：Agent是否真正理解了企业内部的业务语义。在这点上，Snowflake的语义模型扮演了关键角色。

具体做法是：

• 使用YAML文件定义“业务词典”，为常见指标（如“销售额”、“毛利率”）和维度（如“区域”、“渠道”）建立到数据库字段、表关系的清晰映射。

• 记录表之间关联关系、过滤条件习惯、时间逻辑等，让Text-to-SQL不再“凭感觉”乱JOIN。

• 配置常见问法与业务别名，将多种说法统一映射到同一指标口径之上。

核心思路可以一句话概括为：告诉AI“业务在说什么”和“数据长什么样”，而不是让AI自己瞎猜。这个“业务词典”就像给AI配了一个懂行的翻译，大幅提升了SQL生成的准确率和稳定性。

适用场景与实践建议

结合目前的实践经验，这套多Agent分析助手方案尤其适合以下场景：

希望快速赋能业务人员自助分析

销售、运营、市场等团队临时分析需求多、节奏快，希望真正做到“自己问、自己看”。

对数据安全和治理有严格要求的企业

金融、零售、互联网等行业，希望所有分析都在Snowflake内完成，不愿意将数据大规模暴露给外部服务。

希望降低数据团队重复性工作负担

数据团队不再被大量“帮我拉这个数”、“帮我改一下这个指标”的工单占满，可以把更多时间投入到策略分析与数据产品建设上。

实践落地时，可以考虑按以下节奏推进：

• 选定一个高价值的“灯塔场景”，例如“销售业务分析助手”，先从一个业务域做深做透。

• 在真实使用中迭代语义模型和路由规则，确保回答质量、口径一致性和业务体验都达标。

• 再逐步复制到其它业务域（如供应链、会员运营、财务分析），形成可复用的多Agent分析中台。

写在最后

从“能聊天”到“敢决策”

本文并不是要否定ChatBI，而是希望回答一个更现实的问题：

在企业已经有数据仓库、BI报表和治理体系的前提下，如何让“对话式体验”真正进入业务主战场，而不是停留在Demo？

通过Amazon Quick Suite、Amazon Bedrock AgentCore与Snowflake Cortex AI的深度集成，这套多Agent对话式分析方案给出了一条可行路径：在不突破数据治理边界的前提下，让业务同学用自然语言完成从提问到行动的全链路，让数据团队从“报表工厂”升级为“智能分析中枢”。

值得一提的是，Snowflake AI数据云已经正式登陆亚马逊云科技Marketplace中国区，国内企业可以更便捷地在本地合规环境中部署和使用上述能力，加速从“会聊”走向“敢用”的过程。

新用户注册海外区域账户，可获得最高200美元服务抵扣金，覆盖Amazon Bedrock生成式AI相关服务。“免费计划”账户类型，确保零花费，安心试用。

星标不迷路，开发更极速！

关注后记得星标「亚马逊云开发者」

听说，点完下面4个按钮

就不会碰到bug了！

点击阅读原文查看博客！获得更详细内容！