摘要一个完整的 BI 分析链路从数据准备到指标建模再到可视化交付涉及的技能栈跨度极大。单一大模型 Agent 难以胜任这种多环节、多角色的复杂流程。衡石 Data Agent Family 的三个 Agent——数据问答 Agent、建模 Agent、可视化创作 Agent——通过「分职协作」的设计各自深耕一个环节又通过统一的指标语义层和工具协议无缝衔接。本文以真实业务场景为线索拆解三 Agent 协作的完整链路并探讨与 Dify、Coze 等外部 Agent 平台的集成模式。一、单 Agent 的边界为什么 BI 场景需要「拆分」在 ChatBI 的早期实践中一个常见假设是一个足够聪明的通用 Agent 可以处理所有的数据分析需求。但实际落地中这个假设在多个层面受到挑战。首先是技能栈的冲突。准备数据需要理解数据库 Schema、处理缺失值和异常值——这是数据工程的技能。定义指标需要理解业务口径、建立计算逻辑和血缘关系——这是数据治理的技能。做可视化需要考虑图表类型选择、布局设计和交互逻辑——这是数据可视化和前端开发的技能。这三个技能栈在一个人身上都很难融合更不用说塞进一个 Agent 了。其次是上下文污染。如果让一个 Agent 同时处理数据 ETL、指标建模和看板设计它的上下文窗口会充斥各种不同领域的指令和中间结果。每多一个环节有效信息的密度就会下降推理质量也跟着下降。第三是可靠性问题。单 Agent 架构中任何一个环节的失误都会导致整个链路失败且失败时很难定位是哪个环节出了问题。多 Agent 架构中每个 Agent 独立运行故障被天然隔离出问题时可以快速定位到具体 Agent 进行针对性优化。衡石的答案是不是做一个「超级 Agent」而是培养三个各有所长的「专业 Agent」让它们像一支配合默契的小团队一样协作。二、三 Agent 角色定义分工不是切流程是切「认知层级」2.1 数据问答 Agent数据世界的「翻译官」数据问答 AgentAgent 01的核心职责是把业务人员的自然语言需求翻译为数据层面的操作指令。它理解的不是「这段 SQL 怎么写」而是「用户想要什么数据、这些数据在哪里、应该怎么取」。它的典型工作流程是用户说「我要看最近半年的销售趋势」Agent 不是直接去想 SQL而是先识别出「销售」对应哪些指标销售额、销售量、客单价等然后理解「最近半年」的时间语义从当前日期回推 180 天还是 6 个自然月接着判断数据所在的表和字段最后调用工具执行查询。数据问答 Agent 不负责生成最终的分析结论或可视化图表。它只管一件事——准确、安全地拿到正确的数据。拿到数据后把结果交给其他 Agent 或直接返回给用户由下游继续加工。2.2 建模 Agent指标体系的「建筑师」建模 AgentAgent 03的任务是帮助用户建立和维护指标体系。这里的「建模」不是机器学习建模而是 BI 领域的数据建模——定义指标的计算逻辑、维度的层级关系、指标之间的血缘关系。比如用户说「帮我定义一个新指标——客户生命周期价值」建模 Agent 会引导用户思考CLV 的定义是什么是历史累计消费额还是预测价值计算周期多长全生命周期还是最近 12 个月数据来源是哪些表和字段和其他指标有什么关系CLV 是否基于客单价和复购率计算建模 Agent 的产出不是看板或报表而是结构化的指标定义。这些定义被写入指标语义层成为后续所有分析无论是 ChatBI 问答、仪表盘还是报表的统一口径。可以说建模 Agent 是整个 Data Agent 体系的「地基施工队」——模型建得好不好直接决定了上层建筑能盖多高。2.3 可视化创作 Agent分析成果的「化妆师」可视化创作 AgentAgent 02负责将分析成果以最佳的可视化形式呈现给用户。它的核心能力包括根据数据类型和分析目标推荐最合适的图表类型时间序列用折线图、分类对比用柱状图、占比用饼图、相关性用散点图自动设计仪表盘的布局指标卡片放顶部、趋势图放中间、明细表放底部支持用户以自然语言调整图表样式和布局。它的独特价值在于降低了可视化的门槛。传统 BI 中做一张好看的仪表盘需要同时具备数据分析能力和设计能力——这种人很难找。可视化创作 Agent 让业务人员只需要描述想看到什么Agent 来操心怎么展示。三、协作模式一串行流水线——从数据到看板的端到端链路这是最经典的协作模式适用于需要从零开始完成一个完整分析任务的场景。场景案例 市场总监要求「帮我做一份华东区 Q2 销售业绩分析看板」。协作流程第一步可视化创作 Agent 收到用户的创作需求但它发现自己没有现成的数据——它需要先确保数据就绪。于是它向数据问答 Agent 发起协作请求「请准备华东区 Q2 销售数据集包含销售额、订单量、客单价按区域和品类拆分。」第二步数据问答 Agent 解析这个请求。它查询数据目录找到销售明细表和区域维度表。它确认当前用户有华东区数据的查看权限。它调用查询工具按区域为华东、时间为 Q24月-6月的条件拉取数据并按区域和品类做聚合。第三步数据问答 Agent 将准备好的数据集返回给可视化创作 Agent。数据以结构化的表格形式传递——这就好比建模 Agent 把「砖块」递给了可视化创作 Agent。第四步可视化创作 Agent 拿到数据后开始分析。它发现数据包含时间序列月度趋势和分类数据区域和品类于是规划了仪表盘布局顶部放月度销售额趋势折线图中间左侧放各品类销售额柱状图、右侧放区域销售占比饼图底部放明细表格。第五步可视化创作 Agent 渲染仪表盘并向用户展示初版同时发起交互「这是华东区 Q2 的业绩看板初版需要调整图表样式或布局吗」用户可以继续用自然语言微调如「把柱状图改成横向的」「给折线图加上目标线」。整个流程中用户只提了一次需求三个 Agent 中有两个参与了协作第三个 Agent建模 Agent虽然没有直接上阵但它之前建好的指标定义销售额、客单价等为整个流程提供了口径保障。四、协作模式二星型调度——以建模 Agent 为中心的指标体系建设这种模式适用于正处于指标体系搭建阶段的企业建模 Agent 是核心节点其他 Agent 辅助配合。场景案例 某零售企业 CIO 推动「AI-Ready 数据」项目要在衡石平台上建立统一的指标口径。协作流程建模 Agent 作为主导者先和数据问答 Agent 协作了解当前有哪些数据源、哪些表字段、哪些现有指标。数据问答 Agent 通过 Schema 探测功能扫描数据源并返回结构化的数据目录。然后建模 Agent 和业务负责人对话逐个定义核心指标。比如「销售额」的口径是「已支付订单的金额汇总、不含退款、不含运费」。每定义一个指标建模 Agent 会自动检查其依赖关系——如果「客单价」定义为「销售额除以订单数」那它自动关联到销售额和订单数两个指标的现有定义。在指标定义完成后可视化创作 Agent 被调用来生成指标概览仪表盘展示新建立的指标体系全景方便业务方验收和确认。这种协作模式的特点是建模 Agent 始终掌握主动权其他 Agent 各司其职提供辅助。它不是流程驱动而是目标驱动——目标是把指标体系建好至于需要谁配合、怎么配合由建模 Agent 根据实际情况动态决策。五、协作模式三与外部 Agent 平台Dify/Coze的联邦协作衡石 Data Agent 和 HENGSHI CLI 的组合本质上可以被视为一个「BI 执行终端」。这个终端可以嵌入更大的 Agent 生态中作为 Dify、Coze 等外部 Agent 平台的工具节点。5.1 集成架构外部 Agent 平台如 Dify 工作流负责理解用户的宏观意图和编排业务流程衡石 Data Agent 负责 BI 领域的专业分析和数据操作。两者通过 API 或 CLI 接口连接衡石侧暴露出「查询数据」「创建看板」「定义指标」等标准工具外部 Agent 平台像调用其他工具一样调用这些能力。5.2 实战案例智能运营分析工作流假设一个企业用 Dify 搭建了一个「智能运营分析」工作流第一步Dify 工作流被定时触发比如每天早上 8 点。第二步Dify 调用衡石 Data Agent 的数据问答工具拉取昨日全渠道的销售、流量、转化数据。第三步Dify 拿到数据后将数据传给内部的「异常检测」模块可能是规则引擎或 AI 模型识别出异常指标。第四步如果检测到异常Dify 再次调用衡石 Data Agent「华东区昨日销售额同比下降 30%请做根因分析」。第五步衡石 Data Agent 执行多维度钻取——按品类拆、按门店拆、按时段拆——找到异常关键点比如发现是「某大型门店因系统故障导致数据缺失」返回分析结论。第六步Dify 将分析结果格式化为日报通过企业微信推送给相关负责人。这个案例中衡石 Data Agent 不是主控者而是专家节点——它不需要理解邮件发送逻辑不需要理解定时触发机制它只专注于做好 BI 分析这一件事。六、多 Agent 协作的关键技术机制6.1 统一的指标语义层Agent 之间的「通用语」三个 Agent 能够无缝协作最关键的基础设施是指标语义层。它扮演了 Agent 之间「通用语」的角色。数据问答 Agent 拿到的数据按指标口径标注建模 Agent 定义的指标被语义层持久化可视化创作 Agent 展示的图表自动关联指标定义。三个 Agent 不需要理解彼此的「方言」它们都讲「指标」这门通用语言。6.2 共享分析状态Agent 之间的「交接单」Agent 之间传递的不只是数据还有「分析状态」。当前在分析哪个业务域、应用了哪些筛选条件、用户关注的重点是什么——这些元信息在 Agent 交接时一并传递。好比医院的挂号单不同科室的医生看了挂号单就知道前面的医生做了什么检查、初步诊断是什么不需要从头问病人一遍。6.3 故障隔离与优雅降级多 Agent 架构的一个关键优势是故障隔离。如果可视化创作 Agent 遇到性能问题不影响数据问答 Agent 继续提供查询服务。如果建模 Agent 在维护中用户仍然可以通过数据问答 Agent 查询已有指标。系统不会因为一个 Agent 的异常而整体宕机这对企业级应用至关重要。七、对技术团队的启示如何规划自己的 Agent 架构如果你正在评估或自建 BI Agent 系统从衡石的多 Agent 设计中可以提炼出几个可参考的原则。第一按认知层级拆分而非按功能模块拆分。数据问答、建模、可视化的拆分不是按照数据库表、ETL 管道、图表引擎这些技术模块来划分的而是按照「理解数据」「定义逻辑」「呈现结果」这三个认知层级来划分的。每个 Agent 对应的是一个人的认知角色而不是一个技术组件的包装壳。第二为每个 Agent 定义明确的「不会做」边界。数据问答 Agent 不会尝试建指标建模 Agent 不会尝试画图可视化创作 Agent 不会尝试改数据口径。这种「能力约束」不是缺陷而是保障协作可靠性的前提。第三用共享语义层而非共享代码来实现互操作。三个 Agent 不共享代码库不共享内存它们之间的互操作通过指标语义层、标准工具协议和分析状态来完成。耦合度越低每个 Agent 的独立演进空间越大。八、常见问题Q1多 Agent 协作会不会增加延迟多 Agent 协同确实会比单 Agent 简单的单步回答多几次内部通信但这些通信通常控制在毫秒级。整体延迟的主导因素仍然是数据查询时间而非 Agent 通信。实际上由于每个 Agent 专注自己的领域、上下文更精简单 Agent 的推理速度反而可能更快。Q2如果只需要数据问答功能必须要部署三个 Agent 吗不需要。衡石 Data Agent 的三个 Agent 是独立可部署的。如果你目前只有数据问答的需求只部署数据问答 Agent 即可。前提是你的数据已经有清晰的指标语义层可以通过建模 Agent 搭建也可以手动定义。Q3Dify 工作流中能否把衡石的多个 Agent 作为独立节点调用可以。衡石 Data Agent 的三个 Agent 都可以作为独立的工具节点注册到 Dify 中。你可以设计一个 Dify 工作流在第一步调用数据问答 Agent、第二步调用可视化创作 Agent完全按你的业务逻辑定制编排。Q4三个 Agent 由谁来发起协作看场景。流水线模式如先取数后画图由可视化创作 Agent 发起调度。探索式分析如指标建模加验证由建模 Agent 主导。用户直接问答场景由数据问答 Agent 响应并判断是否需要其他 Agent 参与。没有固定的「主 Agent」谁更适合当前任务谁来调度。结语多 Agent 协作不是技术炫技而是对 BI 分析链路过长、技能栈过杂这一客观现实的工程回应。衡石 Data Agent Family 的实践表明让三个各有所长的 Agent「分职协作」比试图训练一个全能的超级 Agent 更可行、更可靠、也更容易被企业客户理解和信任。在 Agent 架构的设计中「拆得对」比「做得多」更重要。