Article body
正文
引言
ChatBI 解决的是「问」——用自然语言把数据问出来。Data Agent 解决的是「做」——自主规划、调用工具、把分析任务执行完。两者单独看都很强，但企业真实的诉求往往是连贯的：我问一句，不只是想要个数字，而是想顺带把这件事办妥。
比如业务人员说「帮我看一下上个月华东区销量下滑的原因，做个复盘发给我领导」。这句话里既有「问」（销量为什么下滑），也有「做」（归因分析、生成复盘报告、推送给领导）。如果 ChatBI 只给个数字、Data Agent 只等明确指令，这个连贯诉求就被割裂了。
衡石把 ChatBI 和 Data Agent 打通成一条端到端闭环：ChatBI 负责「听懂意图、澄清歧义、呈现结果」，Data Agent 负责「把意图拆解成任务、自主执行、交付成果并回流」。两者在同一会话、同一语义层上协作。 本文将拆解这条闭环的技术实现。
一、为什么要让两个引擎协同
1.1 单打独斗的局限
ChatBI alone：擅长交互式探索，但缺乏「自主执行力」。用户问「下滑原因」，ChatBI 能给出初步洞察，但「深入分析每个可能原因、生成报告、定时跟踪」这类需要多步自主执行的事，它做不了。
Data Agent alone：擅长自主执行，但需要明确的任务输入。如果让用户用自然语言把「归因 + 报告 + 推送」完整描述成 Agent 能直接执行的任务，门槛太高——这正是 ChatBI 擅长的「把模糊口语转成结构化意图」的能力。
1.2 协同的价值
协同后，用户用最自然的语言提一个「带目标的描述」，ChatBI 先把它澄清、结构化，再交给 Data Agent 自主执行，执行结果回流给 ChatBI 以用户能懂的方式呈现。用户只管「说目标」，中间的「理解—规划—执行—呈现」全自动。
二、闭环的五个阶段
2.1 阶段一：意图澄清（ChatBI 主导）
用户说出目标后，ChatBI 先做语义理解和歧义消解（详见 ChatBI 语义理解文章）：
- 识别这是「单次问数」还是「带执行目标的复合任务」。
- 若是复合任务，澄清关键要素：分析对象（华东销量）、时间（上月）、目标（归因 + 复盘 + 推送）、接收人（领导）。
澄清不是多余的客套，而是避免 Data Agent 「跑偏」的第一道闸——目标清楚了，执行才不会南辕北辙。
2.2 阶段二：任务结构化（ChatBI → Agent 交接）
澄清后的意图，被 ChatBI 转成一份结构化任务书（Task Spec），而非自然语言。任务书包含：
- 目标描述
- 分解的子任务（归因分析、报告生成、推送）
- 每个子任务的输入约束（数据源、口径、时间窗）
- 交付要求（格式、接收人、时效）
这份任务书是 ChatBI 和 Data Agent 之间的「契约」——ChatBI 用自己擅长的语义理解产出它，Data Agent 用自己擅长的执行能力消费它。两者解耦，各自演进。
2.3 阶段三：自主执行（Data Agent 主导）
Data Agent 拿到任务书后，进入之前文章拆解的「规划 → 工具调用 → 反思 → 验证」循环：
- 把「归因分析」拆成多步：取华东销量趋势、对比各产品/渠道贡献、识别异常维度、下钻定位根因。
- 调用相应工具（查询、聚合、异常检测、可视化）。
- 每步自我反思与纠错（详见自我纠错文章）。
- 产出归因结论。
执行过程对用户透明——用户可在 ChatBI 界面看到「Agent 正在：分析各渠道贡献…」的进度，而非黑盒等待。
2.4 阶段四：成果呈现（Agent → ChatBI 回流）
Data Agent 执行完，把结构化成果（结论、图表数据、报告文档）回传给 ChatBI。ChatBI 负责「翻译」：
- 把技术结论转成业务可读的自然语言。
- 用合适的图表呈现（趋势用折线、占比用饼图）。
- 附口径说明和数据溯源（详见可解释性文章），让用户信得过。
这一步确保「机器算出来的」变成「人能看懂、敢信的」。
2.5 阶段五：交付与跟踪（闭环收口）
对于「推送领导」这类动作，闭环还包括交付环节：
- 报告生成后，按任务书指定的接收人和渠道（邮件、IM、系统消息）推送。
- 若是周期性目标（「每周复盘一次」），Agent 注册定时任务，后续自动执行并推送，形成持续闭环。
- 用户收到后可继续追问（「那个渠道下滑具体是什么原因」），闭环回到阶段一，在同一上下文中延续。
三、协同的技术底座
3.1 共享语义层
闭环能跑通，前提是 ChatBI 和 Data Agent 共用同一份语义层。ChatBI 理解的「销量」「华东」，和 Data Agent 调用的指标、维度，必须是同一套定义。否则 ChatBI 澄清的是 A 口径，Agent 执行的是 B 口径，闭环从根上断裂。
语义层是闭环的「通用语言」，也是之前多篇文章反复强调的衡石核心资产。
3.2 统一对话状态
多轮对话文章中我们讲了 ChatBI 的对话状态。在闭环里，这个状态要扩展为跨引擎的会话上下文：ChatBI 的澄清结果、Agent 的执行进度、中间结论，都写在同一个状态里。用户从问数切到「让 Agent 办」，上下文不丢、焦点不偏。
3.3 统一的权限与安全
ChatBI 的问数权限、Data Agent 的执行权限，遵循同一套权限模型（见 ChatBI 权限文章）。Agent 在执行归因分析时，自动继承用户的数据权限，不会因「自主执行」就绕过围栏。推送动作也受接收人权限约束——不能把用户无权看的数据推给别人。
3.4 Trace 贯通
ChatBI 的理解步骤、Agent 的执行步骤、回流的呈现步骤，全部写入同一条 Trace（见可观测性文章）。一次闭环出问题，运维能从头到尾回放：是 ChatBI 澄清错了、Agent 规划偏了、还是呈现翻译歪了，定位一目了然。
四、典型闭环场景
4.1 异常归因闭环
用户：「昨天转化率突然跌了，帮我查明原因。」
- ChatBI：澄清「转化率、昨日、跌、归因」。
- Agent：取昨日转化率、对比前日/同期、拆解流量/落地页/活动维度、定位异常源（如某渠道落地页故障）、验证假设。
- ChatBI：呈现「主因是 X 渠道落地页加载失败，导致该渠道转化降 60%」，附数据佐证。
- 交付：生成简报推送给运营负责人，并建议设置该指标的实时监控。
4.2 周期复盘闭环
用户：「以后每周一给我发上周销售复盘。」
- ChatBI：澄清周期（每周一）、对象（上周销售）、交付（复盘报告 + 推送）。
- Agent：注册周一定时任务，每周自动跑「销售概览 + 异常识别 + Top/bottom 分析」，生成报告。
- ChatBI：格式化报告并推送。
- 跟踪：用户可随时追问某周细节，闭环延续。
4.3 决策支撑闭环
用户：「下半年要在华东加开门店，帮我评估下可行性。」
- ChatBI：澄清目标（华东开店可行性评估）、所需支撑（客流、竞品、历史门店表现）。
- Agent：跨多源取数（销售、客流、选址），做选址评分模型、回本测算、敏感性分析。
- ChatBI：呈现可行性结论与关键假设，标注数据来源与置信度。
- 交付：导出评估文档供决策会讨论。
五、协同的设计原则
5.1 各司其职，不越界
ChatBI 不做复杂的自主多步执行（那是 Agent 的活），Data Agent 不做模糊意图的口语澄清（那是 ChatBI 的活）。边界清晰，各自优化，通过任务书契约解耦。
5.2 人在环中（Human-in-the-loop）
闭环不是「全自动替你决策」。在关键节点（目标确认、重大结论、对外推送前），系统主动请人确认。Agent 的自主执行有边界，人的判断始终在环内——这与 Data Agent 行业落地的方法论一致。
5.3 渐进式自动化
企业落地不必一步到位。可以从「ChatBI 问数 + Agent 辅助执行简单子任务」起步，逐步扩展到「完整闭环 + 周期自动化」。衡石支持按场景配置自动化程度，而非强推全自主。
六、技术对比
| 能力 | ChatBI only | Agent only | 协同闭环（衡石） |
|---|---|---|---|
| 模糊意图理解 | 强 | 弱 | 强（ChatBI） |
| 自主多步执行 | 弱 | 强 | 强（Agent） |
| 业务可读呈现 | 强 | 中 | 强（ChatBI） |
| 持续跟踪 | 无 | 有（定时） | 有（闭环） |
| 上下文延续 | 单轮/多轮 | 任务内 | 跨引擎贯通 |
七、FAQ
Q1：协同后，响应会不会变慢？
澄清和交接是轻量步骤（毫秒到百毫秒级），主要耗时在 Agent 执行（本就需时）。且用户对「办成一件事」的耐心远高于「等一个数字」，体验反而更好。复杂任务还能走异步推送，不阻塞。
Q2：Agent 执行错了会连累 ChatBI 的呈现吗？
会体现在呈现里，但可解释性机制保证「错的也是标注清楚的错」——ChatBI 呈现时会带口径和置信度，Agent 的错误在终态验证阶段多被拦下。即便漏过，用户基于透明标注也能识别。
Q3：小企业用得上这么重的协同吗？
协同分程度。小团队可先用 ChatBI 问数 + Agent 做单步辅助（如自动出图、导出），不必上完整周期闭环。能力按需开启，不强制全套。
八、总结
ChatBI 和 Data Agent 不是两个孤岛，而是分析闭环的两端：一端把人的意图「翻译」成机器能执行的任务，另一端把机器的执行「翻译」回人能懂的结论。语义层是它们的通用语言，对话状态是它们的共享记忆，权限与安全是它们共同的底线。
核心认知是：真正的智能分析，不是「问得巧」或「做得快」任一端的极致，而是「从一句目标到一份办妥的结果」之间那段无缝的自动化。 当企业员工只需说「帮我看下滑原因并复盘」，剩下的理解与执行自动流转，数据分析才真正从「技能」变成「基础设施」。