Article body
正文
一、理解三个产品的各自定位
ChatBI 的核心能力是「理解问题」和「生成分析」。 它不擅长的是——它不知道该什么时候做分析，也不知道怎么把分析结果推送到正确的地方。ChatBI 本质上是个分析引擎，不是调度引擎也不是执行引擎。
JARVIS 的核心能力是「调度」和「编排」。 它不擅长的是——它只管理调度流程但不做具体的 BI 操作，它也不知道要问什么分析问题（那是业务逻辑的范畴）。JARVIS 是个聪明的调度员，但它需要分析内容来调度。
CLI 的核心能力是「执行」。 它不擅长的是——CLI 没有业务判断能力，它需要人告诉它执行什么指令。CLI 是双手，做命令的执行者。
三者联动的时候，JARVIS 作为大脑调配 ChatBI 和 CLI 在特定时间或事件发生的时刻完成指定的分析动作并推送到人面前。这个融合就是衡石智能分析的完整闭环。
二、模式一：定时报告——JARVIS 调度 + ChatBI 生成 + 消息推送
2.1 场景
每天早上 8 点，系统自动执行以下操作：用 ChatBI 查询昨日核心经营指标、用 ChatBI 生成文字版的分析摘要、将数据和摘要组装为格式化报告通过企业微信推送到管理层群。
2.2 实现路径
在 JARVIS 中创建一个定时任务，设置每天早上 8 点触发。任务的第一步调用 ChatBI 查询多个预设问题。第二步将 ChatBI 返回的数据填充到预设的报告模板。第三步将格式化报告推送到指定群聊。
关键配置点：JARVIS 设置了容错策略——如果 ChatBI 第一次查询因网络问题超时，3 分钟后自动重试。重试三次仍失败则以系统告警方式通知数据团队。
2.3 模板化 vs 自由生成
对于格式固定的日报，使用预设的报告模板效果更好——数据替换进入模板框架，格式统一、可读性高。对于偶尔需要的深度分析报告，可以用 ChatBI 的自然语言生成能力写一段自由格式的分析总结。两者可以在同一份报告中兼用：指标卡片用模板格式，分析解读用自由生成。
三、模式二：事件驱动的根因分析——ChatBI 发现异常 + JARVIS 启动深度分析 + CLI 执行操作
3.1 场景
每天早上 ChatBI 做例行数据检查时发现华东区销售额同比下降了 23%。这个异常值自动触发了一个根因分析流程：ChatBI 对华东区数据做多维度钻取定位到异常的具体品类和门店，然后 CLI 导出该门店的近期明细数据生成分析文件，最终分析结果和附件一起推送到相关负责人。
3.2 实现路径
在 JARVIS 中配置一个事件触发规则——当 ChatBI 返回的某个指标偏离正常波动范围超过阈值时触发。触发后执行多轮分析：ChatBI 按品类、按门店、按 SKU 逐层钻取分析，CLI 导出异常数据明细，最后推送分析报告和数据给到负责人，支持手动发起补充分析。
关键配置点：异常阈值不是写死的，而是基于该指标历史数据的动态基线——周末的自然波动不会被误报为异常。
3.3 深度分析的扩展
也可以在分析报告末尾附带一个入口让管理者手动一键启动 ChatBI 对该异常做补充分析。管理者点击后可以进入衡石的 ChatBI 对话界面延续已有的多轮分析上下文，基于最新数据做进一步的交叉诊断。
四、模式三：月度数据结算——CLI 批量操作 + ChatBI 结果验证 + JARVIS 调度
4.1 场景
每月 1 日，财务系统完成月度结算后自动触发 BI 系统的月度数据刷新流程。CLI 批量刷新月报看板的数据集，ChatBI 抽样验证关键指标和财务系统的差异，验证通过后 JARVIS 推送完成通知到 BI 运维群。
4.2 实现路径
财务系统结算完毕后发信号到衡石。JARVIS 收到信号后调用 CLI 批量刷新所有月度看板的数据集，每批刷新完成后调用衡石 API 验证核心看板的加载状态。
所有看板刷新完成后，ChatBI 自动抽样对比：比较衡石上三个核心指标（月销售额、毛利额、净利润）和财务系统结算报告中的数值。如果差异在可接受误差范围内则任务通过并发送成功通知；如果差异超过阈值则推送告警并暂停后续自动分发动作等待人工确认。
五、模式四：知识沉淀——ChatBI 分析结果 + CLI 归档 + JARVIS 索引
5.1 场景
每一次 ChatBI 产生的有价值分析结果都不应该消失在对话历史里。通过 JARVIS 定期触发归档流程，将分析问答记录、分析过程和数据快照结构化存储并自动建立可检索的索引。
5.2 实现路径
每周五下午通过 JARVIS 定时任务触发，过滤本周所有 ChatBI 对话中具有深度分析价值的会话，CLI 按指定目录归档，JARVIS 自动更新知识库索引使历史分析可以被自然语言检索。
这样下次业务方再问「上次分析过的那个……」的时候，知识库里有完整的上下文可以快速调取，不需要重新分析一遍。
六、联动设计原则
松耦合，强约定。 ChatBI、CLI 和 JARVIS 各自独立运行互不依赖彼此的运行状态。它们之间通过任务 ID、分析结果、输出链接等约定好的数据格式来传递信息。
每个环节可独立验证。 联合工作流中的关键节点都应该有验证步骤——数据刷新完后有抽样验证，报告生成后有人工预览——尽量减少全链路一次性失败且无法定位问题环节的情况。
异常默认可见。 任何一个环节出了问题都应该被推到人面前，而不是静默失败。这是基础但最容易在生产中遗漏的原则。
可回放性。 对于产出重大问题分析的联动流水线，建议保存全链路的输入输出快照以便复盘——ChatBI 的每个推理步骤都能回溯。
七、常见问题
Q1：三者联动的响应延迟有多大？
单个报告生成类的流程通常在 1-3 分钟内完成（主要是数据查询耗时）。根因分析类的多层钻取可能多出额外几轮的推理，总耗时一般在 3-5 分钟。深度导出任务量大的场景走异步模式并在完成后通知。
Q2：如果 JARVIS 调度 ChatBI 时 ChatBI 挂了怎么办？
JARVIS 有默认的超时和重试机制。第一次调用失败后在限定时间内自动重试，超出设定尝试次数后触发告警通知运维。
Q3：ChatBI 分析结果的输出格式能定制吗？
能。报告模板可以自定义——JARVIS 调用 ChatBI 时指定期望的输出格式，ChatBI 按要求格式化输出。
结语
ChatBI、CLI 和 JARVIS 的关系可以类比为：ChatBI 是分析师，负责思考和回答问题；CLI 是操作员，负责执行具体的系统操作；JARVIS 是调度经理，负责在正确的时间把正确的任务交给正确的人。单独用任何一个都只能解决一部分问题，三者联动之后才能真正把 BI 从一个需要人推着走的工具变成一个自己会分析、会执行、会报告的智能系统。
本文基于衡石 ChatBI、CLI、JARVIS 产品联动能力撰写。