Article body
正文
摘要：一个完整的 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：数据世界的「翻译官」
数据问答 Agent（Agent 01）的核心职责是把业务人员的自然语言需求翻译为数据层面的操作指令。它理解的不是「这段 SQL 怎么写」，而是「用户想要什么数据、这些数据在哪里、应该怎么取」。
它的典型工作流程是：用户说「我要看最近半年的销售趋势」，Agent 不是直接去想 SQL，而是先识别出「销售」对应哪些指标（销售额、销售量、客单价等），然后理解「最近半年」的时间语义，接着判断数据所在的表和字段，最后调用工具执行查询。
数据问答 Agent 不负责生成最终的分析结论或可视化图表。它只管一件事——准确、安全地拿到正确的数据。
2.2 建模 Agent：指标体系的「建筑师」
建模 Agent（Agent 03）的任务是帮助用户建立和维护指标体系。这里的「建模」不是机器学习建模，而是 BI 领域的数据建模——定义指标的计算逻辑、维度的层级关系、指标之间的血缘关系。
比如用户说「帮我定义一个新指标——客户生命周期价值」，建模 Agent 会引导用户思考：CLV 的定义是什么？计算周期多长？数据来源是哪些表和字段？和其他指标有什么关系？
建模 Agent 的产出不是看板或报表，而是结构化的指标定义。这些定义被写入指标语义层，成为后续所有分析的统一口径。可以说，建模 Agent 是整个 Data Agent 体系的「地基施工队」。
2.3 可视化创作 Agent：分析成果的「化妆师」
可视化创作 Agent（Agent 02）负责将分析成果以最佳的可视化形式呈现给用户。它的核心能力包括：根据数据类型和分析目标推荐最合适的图表类型，自动设计仪表盘的布局，支持用户以自然语言调整图表样式和布局。
它的独特价值在于降低了可视化的门槛。传统 BI 中，做一张好看的仪表盘需要同时具备数据分析能力和设计能力——这种人很难找。可视化创作 Agent 让业务人员只需要描述想看到什么，Agent 来操心怎么展示。
三、协作模式一：串行流水线——从数据到看板的端到端链路
这是最经典的协作模式，适用于需要从零开始完成一个完整分析任务的场景。
场景案例： 市场总监要求「帮我做一份华东区 Q2 销售业绩分析看板」。
协作流程：
第一步，可视化创作 Agent 收到用户的创作需求，但它发现自己没有现成的数据——它需要先确保数据就绪。于是它向数据问答 Agent 发起协作请求：「请准备华东区 Q2 销售数据集，包含销售额、订单量、客单价，按区域和品类拆分。」
第二步，数据问答 Agent 解析这个请求。它查询数据目录，找到销售明细表和区域维度表。它确认当前用户有华东区数据的查看权限。它调用查询工具，按区域为华东、时间为 Q2（4月-6月）的条件拉取数据，并按区域和品类做聚合。
第三步，数据问答 Agent 将准备好的数据集返回给可视化创作 Agent。数据以结构化的表格形式传递。
第四步，可视化创作 Agent 拿到数据后开始分析。它发现数据包含时间序列（月度趋势）和分类数据（区域和品类），于是规划了仪表盘布局：顶部放月度销售额趋势折线图，中间左侧放各品类销售额柱状图、右侧放区域销售占比饼图，底部放明细表格。
第五步，可视化创作 Agent 渲染仪表盘，并向用户展示初版，同时发起交互：「这是华东区 Q2 的业绩看板初版，需要调整图表样式或布局吗？」
四、协作模式二：星型调度——以建模 Agent 为中心的指标体系建设
这种模式适用于正处于指标体系搭建阶段的企业，建模 Agent 是核心节点，其他 Agent 辅助配合。
场景案例： 某零售企业 CIO 推动「AI-Ready 数据」项目，要在衡石平台上建立统一的指标口径。
协作流程：
建模 Agent 作为主导者，先和数据问答 Agent 协作，了解当前有哪些数据源、哪些表字段、哪些现有指标。数据问答 Agent 通过 Schema 探测功能，扫描数据源并返回结构化的数据目录。
然后建模 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 拿到数据后，将数据传给内部的「异常检测」模块，识别出异常指标。
第四步，如果检测到异常，Dify 再次调用衡石 Data Agent：「华东区昨日销售额同比下降 30%，请做根因分析」。
第五步，衡石 Data Agent 执行多维度钻取，找到异常关键点，返回分析结论。
第六步，Dify 将分析结果格式化为日报，通过企业微信推送给相关负责人。
这个案例中，衡石 Data Agent 不是主控者，而是专家节点——它不需要理解邮件发送逻辑，不需要理解定时触发机制，它只专注于做好 BI 分析这一件事。
六、多 Agent 协作的关键技术机制
6.1 统一的指标语义层：Agent 之间的「通用语」
三个 Agent 能够无缝协作，最关键的基础设施是指标语义层。它扮演了 Agent 之间「通用语」的角色。数据问答 Agent 拿到的数据按指标口径标注，建模 Agent 定义的指标被语义层持久化，可视化创作 Agent 展示的图表自动关联指标定义。
6.2 共享分析状态：Agent 之间的「交接单」
Agent 之间传递的不只是数据，还有「分析状态」。当前在分析哪个业务域、应用了哪些筛选条件、用户关注的重点是什么——这些元信息在 Agent 交接时一并传递。
6.3 故障隔离与优雅降级
多 Agent 架构的一个关键优势是故障隔离。如果可视化创作 Agent 遇到性能问题，不影响数据问答 Agent 继续提供查询服务。如果建模 Agent 在维护中，用户仍然可以通过数据问答 Agent 查询已有指标。
七、对技术团队的启示：如何规划自己的 Agent 架构
第一，按认知层级拆分，而非按功能模块拆分。 数据问答、建模、可视化的拆分不是按照数据库表、ETL 管道、图表引擎这些技术模块来划分的，而是按照「理解数据」「定义逻辑」「呈现结果」这三个认知层级来划分的。
第二，为每个 Agent 定义明确的「不会做」边界。 数据问答 Agent 不会尝试建指标，建模 Agent 不会尝试画图，可视化创作 Agent 不会尝试改数据口径。这种「能力约束」不是缺陷，而是保障协作可靠性的前提。
第三，用共享语义层而非共享代码来实现互操作。 三个 Agent 不共享代码库，不共享内存，它们之间的互操作通过指标语义层、标准工具协议和分析状态来完成。耦合度越低，每个 Agent 的独立演进空间越大。
八、常见问题
Q1：多 Agent 协作会不会增加延迟？
多 Agent 协同确实会比单 Agent 简单的单步回答多几次内部通信，但这些通信通常控制在毫秒级。整体延迟的主导因素仍然是数据查询时间而非 Agent 通信。
Q2：如果只需要数据问答功能，必须要部署三个 Agent 吗？
不需要。衡石 Data Agent 的三个 Agent 是独立可部署的。如果你目前只有数据问答的需求，只部署数据问答 Agent 即可。
Q3：Dify 工作流中能否把衡石的多个 Agent 作为独立节点调用？
可以。衡石 Data Agent 的三个 Agent 都可以作为独立的工具节点注册到 Dify 中。你可以设计一个 Dify 工作流，在第一步调用数据问答 Agent、第二步调用可视化创作 Agent，完全按你的业务逻辑定制编排。
Q4：三个 Agent 由谁来发起协作？
看场景。流水线模式（如先取数后画图）由可视化创作 Agent 发起调度。探索式分析（如指标建模加验证）由建模 Agent 主导。用户直接问答场景由数据问答 Agent 响应并判断是否需要其他 Agent 参与。没有固定的「主 Agent」，谁更适合当前任务谁来调度。
结语
多 Agent 协作不是技术炫技，而是对 BI 分析链路过长、技能栈过杂这一客观现实的工程回应。衡石 Data Agent Family 的实践表明，让三个各有所长的 Agent「分职协作」，比试图训练一个全能的超级 Agent 更可行、更可靠、也更容易被企业客户理解和信任。
在 Agent 架构的设计中，「拆得对」比「做得多」更重要。