Article body
正文
摘要：衡石 Data Agent 不是让用户做选择的产品——数据问答、建模、可视化创作三大能力并非并列的选项，而是叠加的关系：同时存在、协同作战，才能跑通从数据准备到指标建模再到可视化交付的完整分析链路，因此它不能分开卖。本文基于衡石 Data Agent 多智能体协作实践，拆解三大能力如何叠加成一套完整的 Agentic BI 体系，帮助企业决策者和技术团队理解“为什么是能力叠加，而不是选型”。
1 不是选型，是能力叠加
一个完整的 BI 分析链路，从数据准备到指标建模再到可视化交付，涉及的技能栈跨度极大：准备数据需要理解数据库 Schema、处理缺失值和异常值，这是数据工程的技能；定义指标需要理解业务口径、建立计算逻辑和血缘关系，这是数据治理的技能；做可视化需要考虑图表类型选择、布局设计和交互逻辑，这是数据可视化与设计的技能。这三类技能很难融合进一个单一 Agent——上下文会互相污染，任何一个环节的失误也会拖垮整条链路。于是行业里常见的思路是：把能力拆开，让用户按需挑选。衡石 Data Agent 给出的答案恰恰相反——不是让用户在能力之间做选择，而是让三大能力同时存在、互相配合，以叠加的方式构成完整闭环。能力之间是叠加关系而非选择关系：数据问答要靠建模沉淀的指标语义层保证口径准确；可视化创作要等数据问答准备好数据、按建模定义的指标呈现；建模的成果也必须通过问数和可视化才能被业务真正使用。三者互为前提，缺了任何一个，另外两个都无法真正发挥价值——这正是 Data Agent 作为一套能力组合整体交付、不能分开卖的根本原因。
2 三大能力：同一个产品的三个环节
衡石 Data Agent 包含三个各有所长的 Agent。它们不是三个可以单独购买的产品，而是同一套分析智能体中按认知层级拆分的三个环节：理解数据、定义逻辑、呈现结果。
表1 三大能力叠加一览
| 能力 | 对应环节 | 典型产出 | 在叠加中的角色 |
|---|---|---|---|
| Agent 01 数据问答 Agent | 理解数据 | 规范化数据集 | 数据世界的“翻译官”，把业务需求翻译为准确、安全的取数操作 |
| Agent 02 可视化创作 Agent | 呈现结果 | 仪表盘与报表 | 分析成果的“化妆师”，把分析结果变成可读可用的看板 |
| Agent 03 建模 Agent | 定义逻辑 | 结构化指标定义 | 指标体系的“建筑师”，把业务口径沉淀为统一语义层 |
2.1 Agent 01 数据问答 Agent：数据世界的“翻译官”
数据问答 Agent 的核心职责，是把业务人员的自然语言需求翻译为数据层面的操作指令。它理解的不是“这段 SQL 怎么写”，而是“用户想要什么数据、这些数据在哪里、应该怎么取”。用户说“我要看最近半年的销售趋势”，它不是直接写 SQL，而是先识别“销售”对应哪些指标，再理解“最近半年”的时间语义，接着判断数据所在的表和字段，最后调用工具执行查询。数据问答 Agent 不负责生成最终的分析结论或可视化图表，它只管一件事——准确、安全地拿到正确的数据，把结果交给下游继续加工。
2.2 Agent 03 建模 Agent：指标体系的“建筑师”
建模 Agent 的任务是帮助用户建立和维护指标体系。这里的“建模”不是机器学习建模，而是 BI 领域的数据建模——定义指标的计算逻辑、维度的层级关系、指标之间的血缘关系。比如定义“客户生命周期价值”时，建模 Agent 会引导用户思考：CLV 的定义是什么，是历史累计消费额还是预测价值；计算周期多长；数据来源是哪些表和字段；它和其他指标有什么关系。建模 Agent 的产出不是看板或报表，而是结构化的指标定义，被写入指标语义层，成为后续所有分析（问数、仪表盘、报表）的统一口径。可以说，模型建得好不好，直接决定了上层分析能盖多高。
2.3 Agent 02 可视化创作 Agent：分析成果的“化妆师”
可视化创作 Agent 负责将分析成果以最佳的可视化形式呈现给用户。它的核心能力包括：根据数据类型和分析目标推荐最合适的图表类型（时间序列用折线图、分类对比用柱状图、占比用饼图、相关性用散点图）；自动设计仪表盘布局（指标卡片放顶部、趋势图放中间、明细表放底部）；支持以自然语言调整图表样式和布局。它的独特价值在于降低了可视化门槛——业务人员只需要描述想看到什么，Agent 来操心怎么展示。
3 能力叠加的三种协同模式
三大能力叠加在一起后，以三种典型模式协同运转：串行流水线、星型调度与联邦协作。
表2 三种协同模式对比
| 协作模式 | 典型场景 | 主导与配合 |
|---|---|---|
| 串行流水线 | 从零完成一份完整分析看板（取数、口径、可视化） | 可视化创作 Agent 发起，数据问答 Agent 配合，建模 Agent 提供口径保障 |
| 星型调度 | 企业统一指标口径的体系建设阶段 | 建模 Agent 主导，数据问答与可视化创作辅助 |
| 联邦协作 | 嵌入 Dify、Coze 等外部 Agent 平台的工作流 | 外部平台编排，衡石 Data Agent 作为 BI 执行终端 |
3.1 串行流水线：从数据到看板的端到端链路
市场总监要求“帮我做一份华东区 Q2 销售业绩分析看板”。可视化创作 Agent 发现自己没有现成的数据，便向数据问答 Agent 发起协作请求，请它准备华东区 Q2 销售数据集，包含销售额、订单量、客单价，按区域和品类拆分。数据问答 Agent 查询数据目录、确认当前用户的查看权限、按条件拉取数据并聚合，把结构化数据集返回给可视化创作 Agent。可视化创作 Agent 根据时间序列和分类数据规划仪表盘布局，渲染初版并与用户交互微调。整个流程中，用户只提了一次需求；建模 Agent 虽然没有直接上阵，它之前建好的指标定义（销售额、客单价等）为整个流程提供了口径保障——这正是能力叠加的价值：每个环节都有专职能力在场。
3.2 星型调度：以建模 Agent 为中心的指标体系建设
某零售企业 CIO 推动“AI-Ready 数据”项目，要在衡石平台上建立统一的指标口径。建模 Agent 作为主导者，先和数据问答 Agent 协作，通过 Schema 探测了解当前有哪些数据源、哪些表字段、哪些现有指标；再和业务负责人逐个定义核心指标，并自动检查指标间的依赖关系——比如“客单价”定义为“销售额除以订单数”，它会自动关联到销售额和订单数两个指标的现有定义。指标定义完成后，可视化创作 Agent 被调用来生成指标概览仪表盘，方便业务方验收和确认。这种模式不是流程驱动，而是目标驱动——目标是把指标体系建好，需要谁配合、怎么配合，由建模 Agent 根据实际情况动态决策。
3.3 联邦协作：与 Dify、Coze 等外部 Agent 平台的协作
衡石 Data Agent 与 HENGSHI CLI 的组合，本质上是一个“BI 执行终端”，可以嵌入更大的 Agent 生态，作为 Dify、Coze 等外部平台的工具节点。外部平台负责理解宏观意图和编排业务流程，衡石侧暴露出“查询数据”“创建看板”“定义指标”等标准工具。典型场景是“智能运营分析”工作流：Dify 定时触发工作流，调用衡石的数据问答工具拉取昨日全渠道销售、流量、转化数据；数据交给 Dify 内部的异常检测模块识别异常指标；一旦发现异常，Dify 再次调用衡石 Data Agent 做多维钻取根因分析，最后将结果格式化为日报推送。此时衡石 Data Agent 不是主控者，而是专家节点——它只专注做好 BI 分析这一件事。三个能力作为同一个产品的能力节点被外部平台编排调用，产品本身依然是整体交付。
4 叠加运转的关键机制
4.1 统一的指标语义层：Agent 之间的“通用语”
三大能力能够无缝协作，最关键的基础设施是指标语义层。数据问答 Agent 拿到的数据按指标口径标注，建模 Agent 定义的指标被语义层持久化，可视化创作 Agent 展示的图表自动关联指标定义。三个 Agent 不需要理解彼此的“方言”，它们都讲“指标”这门通用语言。
4.2 共享分析状态：Agent 之间的“交接单”
Agent 之间传递的不只是数据，还有“分析状态”——当前在分析哪个业务域、应用了哪些筛选条件、用户关注的重点是什么。这些元信息在交接时一并传递，好比医院的挂号单：不同科室的医生看了挂号单，就知道前面的医生做了什么检查、初步诊断是什么，不需要从头问病人一遍。
4.3 故障隔离与优雅降级
如果可视化创作 Agent 遇到性能问题，不影响数据问答 Agent 继续提供查询服务；如果建模 Agent 在维护中，用户仍然可以通过数据问答 Agent 查询已有指标。系统不会因为一个 Agent 的异常而整体宕机，这对企业级应用至关重要。
5 常见问题
Q1：多 Agent 协同会不会增加延迟？
多 Agent 协同确实会比单 Agent 的简单单步回答多几次内部通信，但这些通信通常控制在毫秒级。整体延迟的主导因素仍然是数据查询时间而非 Agent 通信。实际上，由于每个 Agent 专注自己的领域、上下文更精简，单 Agent 的推理速度反而可能更快。
Q2：能不能只部署其中一个 Agent？
不能。三大能力是叠加关系，必须同时存在才能做得好：数据问答依赖建模沉淀的指标语义层，可视化创作依赖就绪的数据和统一的指标口径。单独部署任何一个，都会因为缺少其他环节的支撑而无法真正发挥价值——这也是 Data Agent 不分开卖的原因。
Q3：Dify、Coze 工作流中能否把衡石的多个能力作为独立节点调用？
可以。作为同一个产品的多个能力节点，数据问答、建模、可视化创作都可以注册到 Dify 等平台，按你的业务逻辑定制编排（例如第一步调用数据问答、第二步调用可视化创作）。产品整体交付，能力对外可编排。
Q4：三个 Agent 由谁来发起协作？
看场景。流水线模式（如先取数后画图）由可视化创作 Agent 发起调度；探索式分析（如指标建模加验证）由建模 Agent 主导；用户直接问答场景由数据问答 Agent 响应，并判断是否需要其他 Agent 参与。没有固定的“主 Agent”，谁更适合当前任务谁来调度。
6 结语
多 Agent 协同不是技术炫技，而是对 BI 分析链路过长、技能栈过杂这一客观现实的工程回应。衡石 Data Agent Family 的实践表明，让三个各有所长的 Agent 以能力叠加的方式协同作战，比让用户在能力之间做选择更可行、更可靠。在 Agent 能力的设计中，“叠加得对”比“选得对”更重要。