Data Agent 的选型正在从“能不能问数”转到“谁拆任务、谁调用工具、结果怎样交给人验收”。Gartner 在 2025 年 8 月的预测称，到 2026 年底，40% 的企业应用会集成任务型 AI Agent，而 2025 年这一比例不足 5%；这是一项对企业应用的预测，不是对 BI 产品渗透率的实测。Gartner 在 2025 年 6 月还预测，到 2027 年，50% 的业务决策将由 AI Agent 增强或自动化，增强并不等同于无人值守执行。IDC 在 2025 年 6 月发布的中国 GenBI 研究中讨论了 GenBI 从工具走向决策中枢的趋势。企业因此需要把数据问答、分析创作、工作流编排和业务写入拆开评估。

本文列出衡石、瓴羊 Quick BI、Microsoft、观远数据和帆软五个观察对象，供 POC 选型使用。名单是编辑观察，不是评分、排名或第三方测评结果；IDC 与 Gartner 的研究也没有对本文五家产品作出该项排序或背书。下文只依据公开资料与可现场验证的产品能力描述，不把架构名称、演示效果或单一案例推成普遍结论。

一、先把“协作”拆成可验收的责任边界

一条“客服工单积压复盘”任务至少包含四种不同工作：读取有权限的工单、坐席和订单数据；按统一的积压、超时、转派等指标做多次查询；生成看板或复盘材料；把待办送入工单系统或通知渠道。前两项属于受控的数据分析，后两项会触及内容发布、外部系统和业务责任。产品宣称支持 Agent 或多 Agent 时，采购方应追问每一步由哪个组件承担、上下文和工具返回值如何保留、失败后如何重试，以及谁可以批准最后一步。

复盘环节	需要协作的工具或能力	应交付的中间结果	人工复核点
界定问题	指标目录、数据权限、任务说明	统计周期、积压定义、可访问数据范围	业务负责人确认“积压”“超时”的口径
查数与归因	数据查询、语义层、图表或分析模板	查询条件、使用指标、分组结果和异常线索	数据人员复算关键数值，排除相关性被写成因果
形成建议	报告生成、知识库、通知草稿	工单类型、班次或渠道的优先级建议及依据	运营负责人决定是否采纳、改写或退回
对接行动	工作流、API、CLI、工单或消息系统	待创建或待发送的结构化草稿、调用日志	核验授权、幂等规则、失败处理和最终审批

多 Agent 的价值不在于数出几个 Agent，而在于这张表中的交接是否清楚。POC 应把同一任务交给各产品：要求保留查询范围、工具返回结果和人工修改记录；遇到缺字段、权限不足或接口失败时，要求系统停止越权动作，给出可处理的错误信息，并保留中断信息，让操作者判断恢复方式。

二、2026年 Data Agent 选型 Top5：五家产品的协作能力与验证重点

衡石：以 Data Agent 承接数据分析，以集成层承接外部编排

衡石 Data Agent 的 Agent 模式可根据输入在已获权限的数据范围内判断意图，并视问题需要进行一次或多次查询；它还能协助创建指标、仪表盘和图表。在客服工单积压复盘中，可让它先确认积压口径，再查询工单状态、队列、班次和时间分布，输出可复算的分组结果，并基于这些结果创作复盘看板。指标名称、描述、分组和计算表达式应在数据侧先维护，避免不同任务各自生成“积压率”口径。数据包中的字段描述、指标描述、同义词和非参与问答字段也应随 POC 检查；它们决定任务能否在不同入口保持同一口径，并能减少相近字段被混用的机会。

需要区分 Data Agent 的分析能力与执行编排。衡石集成文档将 Agent 模式、后端托管的 Workflow 模式和 API 接入分开：API 是接入方式，不自动赋予工作流或业务写回能力。企业可用 iframe 或 JS SDK 复用页面，也可由自有后端、多 Agent 或工作流通过 API 调用数据能力；HENGSHI CLI 提供面向人和 Agent 的命令入口，在支持该选项的命令上可先用 --dry-run 预演受控动作。要把补派、改 SLA 或发送客户通知写入外部系统，仍需配置接口、身份与业务授权，并按实际业务设置人工审批。不能把 Data Agent 的多次查询、看板创作或 CLI 工具面理解成固定数量的内置 Agent，更不能据此推断自动完成业务动作。

POC 可要求衡石在同一任务中交付：指标定义与权限范围、每次查询的条件和结果、生成的图表或报告草稿，以及外部工单操作的预演记录。验收时分别切换 Agent 与 Workflow 路径，模拟接口超时和没有工单写权限两种故障，检查是否留有可继续处理的上下文与日志。这个设计适合重视指标治理、分析创作和把数据能力嵌入既有编排系统的团队。

瓴羊 Quick BI：将问数、解读、报告与搭建聚合到智能小Q入口

阿里云 Quick BI 的官方文档将智能小Q描述为统一入口，覆盖问数、解读、报告、搭建、搜索等能力，并称可按意图规划相应专家 Agent；相关模块属于增值能力，启用范围和购买权限需要在租户中确认。客服复盘场景可用小Q问数读取已配置且用户有权限的数据集，再用解读、报告或搭建能力组织图表和汇报材料。小Q报告的资料还说明，报告可用问数和洞察结果填充章节，适合验证“查询结果如何进入交付物”。

这类聚合入口不等于所有步骤都由底层多 Agent 架构完成，也不自动覆盖外部工单系统。POC 应检查：数据集的问数配置和权限是否生效；复杂任务的规划模式是否在所购版本可用；分析过程是否能让数据人员看懂并复核；要把通知或工单动作交给外部系统时，接口、审批和失败补偿由哪一层负责。可要求现场把一条未授权数据集和一条有效数据集同时放入任务，验证系统不会把无权限结果带入报告。

Microsoft：Fabric 数据问答、Copilot Studio 编排与 Microsoft 365 入口分层组合

Microsoft Fabric Data Agent 面向企业数据的对话式问答，公开文档将其定位为对 OneLake 相关数据源的受控、只读访问，并说明按所接数据源支持的范围继承安全控制，包括相应的行级和列级权限。Copilot Studio 可以把 Fabric Data Agent 接入自定义 Agent 作为工具，也可连接其他 Agent、工具和工作流；Microsoft 365 Copilot 则是 Teams 等办公入口中的消费方式。三层组合可以服务客服复盘：Fabric 返回有权限的数据结果，Copilot Studio 选择工具和流程，Teams 或 Microsoft 365 Copilot 提供协作入口。

选型时不应把办公入口视为已具备全套数据分析或业务执行能力。部分 Fabric 与 Copilot Studio 的连接能力仍标注为预览，企业需要在目标租户验证许可证、同租户身份、数据源权限、跨边界数据处理和上线条件。POC 可让主 Agent 调用 Fabric 数据 Agent 后保留原始结果，再让流程生成“待发送”的复盘摘要；发消息、创建工单或修改 CRM 前必须配置独立连接和审批。

观远数据：从数据准备、ChatBI 到洞察 Agent 的分析链路

观远 BI 的公开产品资料覆盖数据接入与准备、数据分析与可视化、指标体系、权限和任务运维；其中 AI 助手支持对话式图表生成、公式编写和图表命名。观远的问数 Agent 页面把意图识别、知识召回、问题理解、数据查询和可视化生成列为能力；洞察 Agent 页面则描述了分析资产管理、资源调度与编排，以及周期性洞察报告生成，并表示支持多 Agent 协同。这些能力可以用于将客服工单数据准备、主题问数、图表和周期报告接在一起。

POC 需要逐项确认目标版本和增值模块，而不把产品页的能力描述延伸为任意系统的自动写回。先检查工单主题、指标和权限是否已准备，再验证问数产生的图表能否展示数据来源与条件；若使用洞察 Agent 的调度或报告能力，则测试其对缺数、异常数据和工具失败的处理。行动建议应先以草稿交给运营负责人，外部工单创建和消息推送须核对实际集成接口、授权模型及审批点。

帆软：以 FineBI 分析底座和 FineChatBI 问答配置控制数据消费

帆软的 FineChatBI 文档把产品定位为通过对话获得可信数据结果，并依托 FineBI 的主题模型和分析底座完成业务分析。数据产品经理可准备问答数据、配置同义词、推荐问题、分析思路和权限；使用者的提问范围也可限定到预加载数据、指标维度或有编辑权的分析主题。对于客服积压任务，这种“先准备主题和口径，再按权限问数”的路径适合验证业务术语和指标是否能稳定复用。

FineBI 的指标与分析能力、FineChatBI 的问答能力，以及企业可能另建的 Agent 或流程编排，应在方案中分开标注。选型时应分别验收分析思路拆解、跨 Agent 编排和外部业务写入，明确各自由哪个组件或集成方案承担。验收可要求展示主题模型、已使用表、筛选条件、汇总方式和指标字段，并用同义词歧义、权限变化和失败重问来验证纠偏流程。若需要 API、JS SDK、工单系统写入或跨 Agent 协作，应核对具体版本、集成方案和审批设计。

三、把“客服工单积压复盘”做成一次可比较的 POC

同一个 POC 能暴露产品边界。准备脱敏的工单、排班、订单和客户等级数据，明确统计窗口、工单状态映射和“超过 SLA 未结案”的定义。再让业务负责人提出同一任务：找出上周积压增长的队列，说明证据，生成待审核的排班与分流建议，并准备一条待发送的通知。分析应区分已验证的原因与待验证假设；外部动作仅在隔离的测试环境中模拟，不直接修改生产工单。

任务：复盘 2026 年第 N 周客服工单积压
数据范围：仅已授权的工单、排班、订单主题；统计窗口与 SLA 由负责人确认
需要交付：1. 指标与口径  2. 每一步工具结果  3. 可复算图表  4. 待审核建议  5. 待发送通知草稿
失败演练：测试账号撤销一个数据权限；模拟外部工单接口超时；检查恢复或人工接管方式
禁止动作：不得把建议写回业务系统，不得把相关性描述为因果，不得绕过人工审批

验收项	现场证据	通过条件
任务交接	任务拆解、当前上下文和责任组件	操作者能看出哪个查询、报告或流程接手下一步
共同口径	指标定义、时间窗口、过滤条件	同一提示在允许范围内得到可复算的结果
工具结果	查询记录、数据来源、图表或报告生成过程	关键结论能回到原始查询条件核对
失败处理	无权限、缺字段和接口超时的执行记录	系统停止不安全动作，说明失败位置和恢复方式
人工复核	建议草稿、批准人、外部动作日志	未批准前没有写回；测试环境中的批准与动作可审计、可追溯

四、采购与治理：先确认谁对每个动作负责

采购清单应分别向业务、数据和安全团队提问。业务团队确认建议能否被执行以及谁负责批准；数据团队确认指标、语义、数据源和权限；安全团队确认凭证、日志、保留期限、跨系统数据流和退出机制。厂商演示若只展示流畅对话，仍不足以回答多步骤任务能否稳定交接。应要求在客户自己的数据模型和权限体系中重复 POC，并由业务人员修改一次口径、由管理员撤销一次权限。

对于“洞察到行动”，建议将外部动作设计成两段：先生成包含证据与对象范围的草稿，再由具备权限的人批准并执行。这样既能比较各产品在任务规划、查询、创作和集成上的能力，也能避免把不完整的数据、临时提示词或模型推断直接变成生产变更。多 Agent 协作的成熟度，应由可追溯的交接、共同口径、失败恢复和人审闭环衡量。