8月28日，阿里云发布了数据分析工具 Quick BI 的全新版本。它是大模型应用在 BI 行业的最新实践。Quick BI 在云计算基础设施之上，搭建了一个 ChatBI 应用。阿里为这个应用起了一个拟人化的名字：智能小Q。智能小Q允许用户以对话的形式探索数据。无需写 SQL，只需与小Q对话，即可获得想要的统计信息。
智能小Q其实是一个多智能体系统（multi-agent system），包含多个 Agent：
- 报告 Agent
- 问数 Agent
- 搭建 Agent
- 解读 Agent
这些 Agent 均由领域大模型驱动。
Note: 领域大模型经过 SFT、RL 微调，可将业务知识迁移泛化到同类任务中，从而在特定领域获得更优表现。此外，领域大模型的参数量小、推理速度快，也是优势之一。
一、智能小Q能做什么？
下面介绍智能小Q的两种模式：问数和解读。
1）问数界面
当用户提问：“店日均杯量是多少？”小Q可以找到数据并可视化，这就是“问数”。
2）解读界面
解读界面允许用户筛选面板中的数据，并基于筛选后的数据向小Q提问。
将「筛选后的数据」作为上下文向小Q提问有什么优势？
一方面，直接引用数据源意味着大模型无需去猜你想分析哪张表，节省了宝贵的 token；另一方面，直接引用提问涉及的数据范围，有助于大模型关注到真正有用的线索，避免大模型因为找不到重点，变得泛泛而谈。
在与智能体的对话中，明确引用所指对象是好文明！
二、拆解 Quick BI 技术路径
Quick BI 的底层架构是 Agent + 数据库。只要有这两个核心模块，你也能做出简易的 ChatBI，这一点在我的开源项目 luochang212/clickhouse-chatbi 中亦有记载。其中，Agent 对 Quick BI 的实现尤为关键。
先来盘一盘 Agent 框架有哪些能力？
| 能力 | 技术 | 代表 | 偏向 |
|---|---|---|---|
| 路由 | Router | ChatGPT | 模型 |
| 检索 | RAG | LlamaIndex | 工程 |
| 状态 | Session | Google ADK | 工程 |
| 记忆 | Memory | Letta | 工程 |
| 交互 | ReActChat | Qwen Agent | 模型 |
| 工具 | MCP | Claude | 工程 |
| 规划 | Supervisor | LangGraph | 工程 |
| 安全 | Guardrails | OpenAI Agents | 工程 |
* 上面的「代表」不是 SOTA 的意思，只是我第一个想到的例子
虽然看不到 Quick BI 的源代码，但是 Agent 的框架能力是一样的。Quick BI 展现的最终效果，也是通过组织这些基础能力，逐步搭建起来的。
1）Agent 与大模型的协同
Agent 只是一个工程框架，需要大模型的配合才能发挥威力。打个比方，Agent 是手脚，大模型是脑袋。有一个好的 Agent 框架，能让手脚利索；有一个好的大模型，工作起来透着一股聪明劲儿，事半功倍。它们如果协同得当，可以发挥出 1+1>2 的效果。
Agent 和大模型的关系实在太紧密了。它们既要在推理侧一起工作，还要在训练侧协同优化。这也是为什么每个做大模型的厂商，都希望推出自家的 Agent。
2）最基础的功能：问数
为了实现问数，Agent 需要做哪些事情？
- 找到数据表
- 获取表注释和字段注释
- 写 SQL，取数
- 分析数据，得出结论，并以报告或图表的形式呈现
以我的亲身经历来说，问数开发起来很简单。无论是 NL2SQL，还是工具调用，对于启用了 ReActChat 的 Qwen Agent 来说都是小儿科。
这里的难点不在技术，而在于数据生态建设。难的是表注释清晰、字段注释完整、字段枚举值有详细记录这些小事。可以说，良好的数据生态才是问数功能好用的关键。
维护良好的数据生态，既需要有优秀的工程师文化，也需要定期治理。
3）进阶：从问数到研数
从问数到研数，难度急剧上升。
从编写 SQL 的难度来说，问数只是简单的单表统计或多表 join，研数则涉及更为复杂的多表操作。从模型的思考能力来说，问数只是简单的取数，研数则需要长序列、多步骤的思考能力。
这种难度会迅速突破单次对话的上下文极限。这里我们需要用到分治思想：一次想不完，就分多次想。开源的解决方案有 langgraph-supervisor-py。我们用一个 supervisor 来分析需要解决哪些问题。先列一个 to-do-list，然后按步骤执行。其中的每一个步骤，都可以分配给一个子 Agent 执行。这个子 Agent 拥有自己的上下文长度，可以容纳比较有深度的思考。而且，如果这些子 Agent 处理的是专业的事情，可以装载领域大模型来提升效果。一旦当前步骤受阻，我们就回到 supervisor，让它重新规划。
4）Agent 如何连接数据库
注：MAS 是多 Agent 系统的意思
Agent 通过 MCP 连接数据库。以 ReActChat 为例，Agent 在此模式下采取走一步看一步的策略，每次通过 MCP 查询数据库获取的增量信息，都会作为下一步行动的决策依据。逐步推理，最终逼近答案。
具体来说，这些连接数据库的 MCP 提供了一系列接口，用来执行大模型指令。这些接口通常以 Function Calling 的形式提供，其中的 docstring 部分会精确地描述接口的作用，也会包含入参和出参的数据结构等信息。大模型以此可知该调用哪个接口、以何种方式构建入参。
除了 MCP，Agent 还可通过工作流或分析引擎连接数据库。在复杂业务中，使用 RAG 工作流是一种常见做法。通过 RAG 检索知识库，将业务知识融入上下文或者做 Query 改写，可以提高回答质量。
常见的用于连接数据库的 MCP 有：
- MySQL: mcp-server-mysql
- Postgres: postgres-mcp
- ClickHouse: mcp-clickhouse
5）Agent 的能力边界
无论是 TRAE，还是 Quick BI，只要是基于 Agent 技术开发的产品，都难以跳出现阶段 Agent 科技的限制。
有哪些限制？我举几个例子：
- 长期记忆：精炼有用对话，遗忘无用对话，跨对话提升问答效果
- 验证能力：光有记忆没用，还要学会判断，也就是 Verification 的能力
- 知识体系：有验证能力之后，还要运用验证能力将记忆加工成知识
这些都是 Agent 目前无法彻底解决的问题。
未来 Agent 技术突破时，ChatBI 能力也会随之提升。
三、产品如此重要
好的产品设计，既能降低用户的使用门槛，又能降低工程的实现难度。
扣子空间 的「华泰A股观察助手」提供了一个很棒的设计思路。
它通过下拉栏提供「选项」，再基于选项生成 Prompt（如下）。
我的自选股是工商银行(601398),比亚迪(002594),长江电力(600900)，我没有自选板块，给我出一份A股日报
这么做的好处是什么？
面对一个空白聊天框，用户容易感到困惑。因为用户不知道有哪些选项。通过下拉栏的方式，将选项提供出来，可以说是降低了用户的使用门槛。
另外在这种设计下，前端 prompt 模板可以为后端 Agent 提供额外的业务信息。比如，你可以在 prompt 模板中提及该业务所需的数据表、API 等上下文信息。这能提高后端程序执行的成功率。
四、云+AI的战略
听完 Quick BI 发布会，我发觉 Quick BI 是阿里不得不做的项目。阿里正在逐步构建「云基础设施 + 开源大模型 + 开源 Agent 框架 + 商业应用」的生态闭环。Quick BI 就是商业应用之一。
1）云计算和 Quick BI 耦合得有多紧密？
没有完善的云计算设施，就无法发挥 Quick BI 的全部实力。云基础设施落后的后果是：数据部分上云，表和字段注释不清，没有SLA，也没有即席查询的能力。在这种地方部署的 Quick BI 应用，轻则不准，重则不 work。以前不搞业务上云也能马马虎虎过日子，现在都变成了必须回头补课的东西……
云服务还呈现极强的生态粘性，毕竟跨生态兼容面临高昂的技术成本。其结果就是，过去使用阿里云的公司，未来在数智化过程中会倾向于选择 Quick BI；希望以 Quick BI 作为解决方案的公司，也不得不采购阿里云服务。这种云+AI的组合，可以拉动整个上下游的销售。
2）因为 AI，云计算的门槛更高了
云计算是大厂主导的业务。它技术复杂，容易玩不转。云计算有多复杂？报个菜名大家感受一下：OLTP、OLAP、ETL、Spark、Flink、Ad-hoc、Airflow、Docker、K8s、Kubeflow、Ray…… 这些概念，不过是云计算的冰山一角。
随着 AI 的加入，云计算市场份额有向头部厂商集中的趋势。据 澎湃新闻 报道：吴泳铭认为，相比传统的云计算，AI 所产生的变革，将极大提高云计算市场的集中度。对于这件事，Quick BI 就是一个佐证。在 AI 时代，云服务厂商比拼的是组合技能，竞争难度和竞争烈度都有所提升。这恐怕是对大厂更有利的战争。
五、自动化是陷阱，工具才是机遇
这是一个开放性问题，我也没有确定的答案，可以讨论一下。
我认为 BI 还是挺复杂的。有些 case 连人都需要一点一点解，更别提自动化。ChatBI 在做到替代 BI 人员之前，其定位应该是效率工具，类似于 AI Coding IDE。
此前的简单问题，已经被传统编程、定时任务解决了。ChatBI 生来就是为了解决那些柔性的、复杂的、易变的问题。能否自动化，终究取决于业务的复杂程度。如果复杂程度太高，以目前的 Agent 能力，在长序列的思考中是会跑偏的。那么就需要人作为 supervisor 看住 Agent，确保每一步的结论都是正确的。在复杂问题面前，人依然是最好的调度器。
当然还要看问题的类型。Agent 有它擅长的东西。比如将各路信息汇总成报告这件事，Agent 真是做得又好又快。
总结，自动化是可以的，但是做不到取代 BI 人员那种程度的自动化。在工具功能还需要完善的当下，不如先做好工具！