Article body
正文
经营分析常丢失的不是数字，而是它抵达下一位同事时的条件：指标口径、预算版本、数据时间，以及已验证结论和待业务确认假设。若这些内容只留在一次对话或截图中，团队仍会重新提问、取数和解释。
衡石公开产品信息显示，Data Agent Family 覆盖建模、报表创作、问数洞察，以及数据解读、报告生成等能力；ChatBI 以 NL2Metrics 与建模语义层为基础。将这些能力放进经营场景，重点不是把每一个环节都称为“智能体协作”，而是把分析组织为可核验、可交接的任务。本文以 HENGSHI SENSE 7.0 的产品边界为基线，说明如何让问数、分析解释、BI 资源操作与外部业务处置各自交付清楚的输入和输出。
1 经营问题为何总在交接处失真
“华东区本月销售额为什么低于预算？”至少隐含四个条件：含税口径、预算版本、时间周期和区域归属。若临时问数再转发图表，原有过滤条件和数据刷新时间很容易消失。
可复用的经营分析应同时交出事实范围和解释范围。前者包括指标、维度、筛选、时间和数据状态；后者包括已被数据支持的拆分结论、待业务补证的假设和下一位责任人。自然语言问题应尽量落到受治理的指标与语义上，不能直接等同于一段任意 SQL。
因此，本文将“协作”定义为交接质量，而不是多个模型同时作答。问数交出事实范围；分析交出证据和待验证项；BI 资源操作交出被确认的变更；业务负责人交出最终决策。产品中的问数（Ask）和操作（Act）是两种执行模式，不是彼此独立的多个 Agent，也不是把 API 当成 Workflow 的另一种叫法。
2 先写任务单，再开始分析
一条经营问题不需要被写成很长的需求文档，但每次交接至少要保留最小信息集。下表既可作为例会分析的任务单，也适合映射到企业自己的工单或待办系统。
| 交接对象 | 必须说明 | 交付物 | 仍需人工确认 |
|---|---|---|---|
| 问题范围 | 指标、比较对象、时间、组织或业务范围 | 可执行的问题描述 | 指标口径是否正确 |
| 数据条件 | 应用/数据包或主题域、刷新时间、过滤条件 | 查询范围与结果 | 数据是否足以支持比较 |
| 分析解释 | 已验证的拆分维度、证据、未验证假设 | 洞察摘要与待核对项 | 业务原因是否成立 |
| BI 资产 | 要创建或修改的图表、仪表盘、指标及目标资源 | 变更计划或已保存资产 | 是否具备编辑与发布条件 |
| 外部处置 | 建议下一步、责任人、外部系统位置 | 工单、待办或决策记录 | 有权人是否批准动作 |
例如，“比较华东区 7 月净销售额与预算，并按渠道、品类拆分差异；以销售应用为范围；记录数据刷新时间；输出前三项已验证差异和待确认原因”，已经足以把一次模糊追问转化为可复现的任务。范围、口径和证据不清楚时，应先补齐数据资产的名称、说明、关系、同义词和业务规则。
3 从发现到交接：四个可独立验收的步骤
3.1 用 Ask 取得事实，不把问数写成操作
在 7.0 中，独立 ChatBI 和全局 Data Agent 的问数模式都属于只读 Ask。新建问数对话可限定在一个应用/数据包、一个指标主题域或一个已保存仪表盘；未选范围时，系统只在当前用户有权访问的资源中定位业务对象，多个可能匹配需用户确认。切换范围须新建对话，因此结果应交代使用范围与数据状态，而不只转发图表。
第一份输出应该足够克制：指标名称、时间范围、过滤条件、结果、实际使用的应用或数据集，以及数据刷新时间。若“净销售额”已有发布口径，就应从该定义出发；若用户输入“回款”“动销”等口语，则应记录实际命中的指标或字段。这样，下一位读者可以判断结果能否复用，也能判断是否需要退回建模处理。
3.2 让解释带证据，不把相关性写成因果
发现环比下降后，常见错误是立刻把“促销不足”或“客户流失”写成结论。更稳妥的办法，是将原因拆成可检验的维度：渠道、品类、客户层级、订单数、单价、退货，以及预算版本或区域归属是否变化。每一项拆分都应能回答两件事：它对总差异贡献多少；该结果对应什么筛选条件。
已保存仪表盘可发起只读的智能解读对话，分析参考可见过滤条件；有未保存的页面改动时应先保存。过滤条件只是分析提示，不能绕过服务端数据权限，也不能把未保存页面状态变成访问或修改能力。本例只把智能解读用于已有事实的描述、分解和下钻材料：它可以帮助整理“差异在哪里”，却不能仅凭关联就断言“为什么发生”，更不能替企业批准补货、调价或营销动作。
3.3 口径有缺口时，切换到 Act 并建立新对话
有些问题不能靠多问几次解决。例如“预算达成率”在两个报表中分母不同，或“渠道”同时存在签约渠道与发货渠道。此时问题已从“答案不对”变为“资产是否足够表达业务问题”。应将分析退回数据准备与治理，补充字段说明、关系、默认过滤和指标定义；需要创建或修改 BI 资源时，再从 Ask 切换到 Act。模式切换会创建新对话，避免把只读取数语境和写入语境混在同一条任务链中。
Act 可在当前用户权限内完成 BI 资源的创建、修改和配置，不扩大账号权限。创建执行计划需要用户确认，并重新检查权限、资源、内容和有效期；发布、分享、导出、权限、凭据和永久删除等高风险动作不属于通用操作能力。正式经营口径仍应遵循团队已有的定义、审核与发布流程。
这一步的交付物不应是“已修复”，而应是变更说明：新建或调整了什么资源，适用范围是什么，哪些历史分析需要重新核对。将资产变化与经营结论分开记录，团队才可以判断差异究竟来自业务变化还是口径变化。
3.4 把确认后的结果沉淀为正式资产
报告或仪表盘的目标不是让结论看起来更像定论，而是让读者看到结论的依据。一个适合经营会议的结果包，至少包含结论、关键数字、比较基准、拆分路径、数据时间和待确认项。
在桌面端的独立 ChatBI 中，用户可将回答中的图表添加到已有正式仪表盘，或从对话创建正式仪表盘；必须选择可编辑的目标资源，并在保存前核对指标、过滤条件和主题。应用集市已发布应用、分享链接和应用门户属于只读消费场景。完整 UI SDK 当前也只支持只读问数，默认不展示仪表盘写入入口；集成方需显式承接写入动作，并满足目标资源编辑条件。
下面是一份交接协议的设计示例，非衡石 API 或 schema。它说明团队可以传递什么信息；字段名、传输位置、鉴权方式和审批流程都应按实际系统设计并验证。
{
"task": "核对华东区7月净销售额与预算的差异",
"facts": {
"metric": "净销售额（已发布口径）",
"scope": "华东区；2026-07；预算版本V3",
"data_as_of": "以运行时结果中的数据刷新时间为准"
},
"evidence": ["按渠道、品类拆分的差异结果"],
"open_questions": ["退货入账跨期是否影响本月比较"],
"next_owner": "区域经营负责人",
"action": "人工确认原因后，决定是否创建业务工单"
}4 一个零售经营例子：把“销售下滑”交给正确的人
假设一家零售企业的区域经理发现华东区净销售额低于预算。以下是任务设计示例，不是客户案例，也不代表产品会自动执行其中的业务动作。
区域经理先在独立 ChatBI 中提出比较问题，范围限定为销售应用、华东区、当月和已发布预算版本。Ask 结果先作为事实层：差异金额、所用指标、时间和过滤条件。分析人员随后按渠道和品类拆分差异，发现下降集中在两个经销渠道、三个 SKU。这里能得出的结论仅是“差异在哪里”；退货是否跨期、发货是否延迟、政策是否变化，都应作为待核对项交给渠道负责人。
若拆分时发现“经销渠道”字段在不同数据集中含义不一致，分析任务应停止扩写结论，转入 Act 所承接的 BI 资产调整或正常的数据治理流程：明确字段描述、数据关系或指标定义，并标注受影响的历史报告。资产审核完成后，再保存确认后的图表或仪表盘内容。是否调整促销、是否补货、是否向客户沟通，仍由企业的外部业务系统、审批流程和授权人决定。
这个例子中的协作不要求多个角色同时给答案。它要求每个交接点保留证据：Ask 交出事实范围，分析交出拆分和假设，Act 交出变更状态，业务交出决策记录。任何一步都可以暂停、复核或退回，也因此不会把一条分析结果误当成一项已获批准的经营动作。
5 接入能力不等于替企业编排业务流程
7.0 的 iframe、完整 UI SDK、数据客户端 SDK 和 HTTP API 都调用统一的服务端 conversation 服务：服务端运行模型与工具循环、校验权限、保存历史和管理任务。接入形态决定谁负责页面、会话事件和状态恢复，不等于定义企业的任务协议或审批人。
iframe 适合复用完整 ChatBI 页面；完整 UI SDK 适合嵌入完整只读聊天界面；数据客户端 SDK 适合完全自定义界面；HTTP API 适合由业务后端或其他系统调用。API 是接入与调用边界，不是 Workflow，也不会因为外部编排而自动获得用户身份、指标口径或业务审批权限。集成方仍要定义身份映射、事件消费、失败恢复、结果回写和人工确认。
权限也是任务协议的一部分。Data Agent 按当前用户的已配置权限执行；SDK 的资源 ID、clientContext 或模式参数都不能增加权限。外部页面需要建立正确的登录态或短期授权，并在实际环境中验证用户是否能访问目标应用、数据包、指标主题域和仪表盘。产品页所列的 SDK、API、iframe 及 Dify、Coze 等协作方向，提供的是接入与调度选择；组织仍须自行定义任务协议与审批边界。
6 让协作可靠的三个检查点
开始时检查事实：问题是否命中已发布指标，数据是否覆盖所需时间、范围与粒度，结果是否带有范围、过滤条件和刷新时间。
交接时检查解释：每个“原因”是否有拆分结果或业务证据支持，哪些仍是待验证假设，发生口径变化时是否明确标注影响范围。
落地时检查责任：谁保存或发布 BI 资产，谁决定外部业务动作，谁管理日志、审计和留存。产品提供分析、操作与集成能力，但完整业务闭环仍由企业按自身权限、治理和流程实现。
一次好的经营分析，关键是每次交接保留足够的事实和边界。这样，Data Agent 才能在企业分析协作中成为可验证的一环；管理者也能清楚地区分：哪些内容已经由数据支持，哪些仍需要人作出决定。