Article body
正文
摘要：数据问答、建模、可视化创作是衡石 Data Agent Family 的三类核心能力。它们在完整分析链路中相互支撑：数据准备、指标建模与可视化交付需要统一的业务口径和协作方式。企业可按业务阶段先从单点或组合能力切入，再逐步扩展至全链路。本文说明三类能力的协同关系，以及设计和交付时应确认的边界条件。
1 不是选型，是能力叠加
一个完整的 BI 分析链路，从数据准备到指标建模再到可视化交付，涉及的技能栈跨度极大：准备数据需要理解数据库 Schema、处理缺失值和异常值；定义指标需要理解业务口径、计算逻辑和血缘关系；做可视化需要考虑图表选择、布局设计和交互逻辑。三类能力应共享统一的指标语义和权限边界，才能在端到端场景中形成稳定协作。数据问答可利用建模沉淀的指标语义层保持口径一致；可视化创作可基于已准备的数据和指标定义呈现结果；建模成果也需要通过问数和可视化被业务使用。能力之间存在依赖关系，但这不等同于要求所有企业在同一阶段同时启用全部能力；组合与启用节奏应由业务目标、数据基础和交付方案决定。
2 三大能力：同一个产品的三个环节
衡石 Data Agent Family 覆盖数据问答、建模、可视化创作等能力，用于理解数据、定义逻辑和呈现结果。三类能力可在全链路方案中协同，也可按企业当前的业务瓶颈和建设阶段选择切入组合；具体可用能力与交付方式应以当前产品版本和项目方案为准。
表1 三大能力叠加一览
| 能力 | 对应环节 | 典型产出 | 在叠加中的角色 |
|---|---|---|---|
| Agent 01 数据问答 Agent | 理解数据 | 规范化数据集 | 数据世界的“翻译官”，把业务需求翻译为准确、安全的取数操作 |
| Agent 02 可视化创作 Agent | 呈现结果 | 仪表盘与报表 | 分析成果的“化妆师”，把分析结果变成可读可用的看板 |
| Agent 03 建模 Agent | 定义逻辑 | 结构化指标定义 | 指标体系的“建筑师”，把业务口径沉淀为统一语义层 |
2.1 Agent 01 数据问答 Agent：数据世界的“翻译官”
数据问答 Agent 用于辅助把自然语言需求转化为数据分析任务。以“最近半年的销售趋势”为例，分析过程需要结合已定义的业务指标、时间范围、数据可见权限和实际数据资产确定取数方式。它可作为数据准备与问数分析的一环；具体查询过程、结果形态以及是否衔接后续能力，应以产品配置和交付方案为准。
2.2 Agent 03 建模 Agent：指标体系的“建筑师”
建模 Agent 用于辅助建立和维护指标体系。这里的“建模”指 BI 领域的数据建模，例如梳理指标计算逻辑、维度层级和指标关系。定义“客户生命周期价值”时，团队仍需确认其业务定义、计算周期、数据来源及与其他指标的关系。建模产出可沉淀为结构化的指标定义，并作为后续分析的统一口径；实际保存位置、引用范围和工作流以产品配置与交付方案为准。
2.3 Agent 02 可视化创作 Agent：分析成果的“化妆师”
可视化创作 Agent 用于辅助将分析成果呈现为仪表盘、报表或其他可视化资产。图表选择、布局和交互应结合数据特征、分析目标与业务使用方式共同确认；自然语言交互可作为创作与调整的入口之一，具体能力范围以当前产品版本为准。其价值在于降低可视化创作门槛，同时保留业务人员的审核与确认。
3 能力叠加的三种协同模式
在全链路方案中，可参考三种协同设计模式：串行流水线、以指标建设为中心的协作，以及与外部 Agent 平台的联邦协作。它们是方案设计模式，不是对所有项目默认运行方式的承诺。
表2 三种协同模式对比
| 协作模式 | 典型场景 | 主导与配合 |
|---|---|---|
| 串行流水线 | 从零完成一份完整分析看板（取数、口径、可视化） | 按工作流约定衔接数据准备、指标定义和可视化创作 |
| 指标建设协作 | 企业统一指标口径的体系建设阶段 | 以指标建模为中心，按需引入数据准备与可视化验证 |
| 联邦协作 | 与 Dify、Coze 等外部 Agent 平台协作的工作流 | 由外部平台与衡石侧按集成方案分工编排 |
3.1 串行流水线：从数据到看板的端到端链路
以“华东区 Q2 销售业绩分析看板”为例，交付方案可先确认销售额、订单量、客单价等指标的口径与当前用户的数据权限，再准备按区域和品类拆分的数据集，最后完成仪表盘初版与业务确认。建模沉淀的指标定义可以为数据准备和可视化提供统一口径。这个示例说明能力如何配合，不代表各能力间存在固定的内部调用顺序或默认调度者。
3.2 星型调度：以建模 Agent 为中心的指标体系建设
在统一指标体系建设中，可先盘点数据源、表字段和既有指标，再与业务负责人确认核心指标的定义及依赖关系。例如“客单价”可明确为“销售额除以订单数”，并在指标体系中维护其相关定义。完成后可通过指标概览或分析看板辅助业务验收。参与能力、协作顺序和自动化程度应在项目方案中明确，而不应假设由某个 Agent 自动决定。
3.3 联邦协作：与 Dify、Coze 等外部 Agent 平台的协作
衡石 Data Agent 支持与 Dify、Coze 等 Agent 平台调度协作，并可通过 API、SDK、iFrame 等方式适配既有应用。外部平台与衡石侧如何拆分意图理解、工作流编排和 BI 执行，应以当前接口能力和交付方案为准。以“智能运营分析”为例，方案可以把数据获取、指标分析和结果呈现接入既有工作流；是否使用定时触发、异常检测或日报推送，以及各能力是否作为独立节点暴露，都需要在集成设计和验收中确认。
4 叠加运转的关键机制
4.1 统一的指标语义层：Agent 之间的“通用语”
指标语义层是三类能力协同的重要基础。建模形成的指标定义可作为数据问答和可视化的共同口径，减少同一业务问题在不同分析入口中出现定义不一致的风险。实际的元数据关联和资产引用方式应以产品配置与交付方案为准。
4.2 共享分析状态：Agent 之间的“交接单”
当多个能力需要协作时，业务域、已应用的筛选条件和用户关注点等上下文应被显式传递和管理。企业不应把“共享分析状态”视为无需配置的默认能力；交接边界、权限继承和状态保存方式需要在工作流或集成方案中明确。
4.3 可用性与降级需要方案化设计
不同能力的角色划分本身不等同于已实现的故障隔离或服务可用性承诺。若业务要求在部分能力不可用时仍保留查询或已有指标的使用，应在部署、依赖、监控和降级策略中明确设计，并在上线前验证。
5 常见问题
Q1：多 Agent 协同会不会增加延迟？
多 Agent 协同会增加编排和交互环节，实际延迟受数据源、模型、工作流复杂度、并发和部署方式共同影响，不能用固定的毫秒级结论概括。上线前应针对目标场景测试端到端时延，并据此决定是否需要异步、缓存或人工确认环节。
Q2：能不能只部署其中一个 Agent？
可以按业务阶段从单点或组合能力切入。例如，指标体系尚未建立时，可优先建设建模能力并与可视化创作形成最小闭环；数据准备复杂时，再引入数据问答能力。完整链路通常能带来更强的协同价值，但实际启用范围、授权和交付方式应由项目方案确认。
Q3：Dify、Coze 工作流中能否把衡石的多个能力作为独立节点调用？
衡石支持与 Dify、Coze 等平台调度协作。是否能将某项能力作为独立节点调用、可用的接口和参数，以及权限如何传递，应以当前产品版本、集成文档和项目验收结果为准。
Q4：三个 Agent 由谁来发起协作？
应由工作流或集成方案定义协作发起方和编排责任。数据准备、指标建模和可视化可以按不同业务场景组成不同顺序，但不应将某个 Agent 是默认“主 Agent”或自动调度者视为既定产品承诺。
6 结语
多 Agent 协同是对 BI 分析链路长、技能栈多样的一种工程组织方式。衡石 Data Agent Family 提供数据问答、建模、可视化创作等能力，企业可按当前瓶颈选择单点或组合切入，并在指标语义、权限治理和集成边界清晰后逐步扩展。能力是否需要叠加、如何叠加，取决于业务目标和可验证的交付方案。