data agent

在现有看板上继续分析：衡石 Data Agent 的页面上下文与创作边界摘要：业务人员在看板上看到逾期交货、销售下滑或库存异常时，下一步往往不是从空白对话框重新提问，而是沿用眼前的数据口径继续拆分、解释和调整呈现。HENGSHI SENSE 的 Data Agent 可以读取登录账号和正在浏览的页面信息，在数据包、数据集和仪表盘等页面内参与查询、可视化辅助创作、指标辅助创作与智能解读。要把这项能力用稳，团队需要先分清页面上下文、会话上下文和已保存资产各自保存什么，再为追问、失败恢复和权限复核留出明确操作。

一个门户只保留一个智能助理：衡石嵌入式 Data Agent 的运行与渲染边界摘要：很多 SaaS 门户把衡石仪表盘放进 iframe，又在门户右侧部署自己的 Copilot。用户打开仪表盘后会看到两套入口、两段会话和两种上下文：父页面的助手知道业务页面，iframe 内的助手知道图表。随后，用户点“智能解读”时不知道该问谁，研发也很难判断一次失败发生在登录态、跨域通信、会话运行还是图表渲染。本文以一个嵌入仪表盘的 SaaS 门户为例，说明如何用父页面 Copilot JS SDK 接管 iframe 内的智能助理，并把运行方式、页面渲染、权限和后端编排拆成可验证的边界。本文以 6

Metric Layer 建设指南：如何先从核心指标层启动企业语义工程很多企业已经建设了指标体系、指标平台或指标管理台账，但真正进入使用环节后，仍然会遇到同样的问题：指标定义写在文档里，计算逻辑落在 SQL 里，维度关系藏在宽表里，业务限定依赖分析师经验，最终 BI、接口和 AI 问数仍然各自实现一套查询逻辑。此时，企业虽然“有指标”，却没有真正形成 Metric Layer。真正的 Metric Layer 应位于数据模型与消费端之间，把指标定义、计算逻辑、维度关系、业务对象、权限规则和查询接口统一表达为机器可执行的语义模型。

BI Agent Inside：让分析成为业务系统能力伙伴在 CRM、ERP、行业 SaaS 等业务产品里加入分析能力，目标是让用户在完成业务动作时获得可追溯的数据依据。产品团队需要同时交付问答入口、结果呈现、指标口径和权限边界，并把它们放进已有的业务流程。

让问数更自然：衡石 Data Agent 实践自然语言正在成为企业使用数据的新入口。但真正可用的 AI 问数，不是把一句问题直接交给模型，而是让问题落在准备充分的数据、清晰的业务口径和正确的权限范围内。衡石 Data Agent 基于对话式交互，帮助用户完成业务数据分析、指标创建和仪表盘生成等工作。本文从能力边界、数据与指标准备、权限管理和落地步骤出发，说明企业如何把“问得自然”落到“答得可靠”。

极昆仑智慧

智能问数零售行业场景9-新品孵化与爆款补货：30天生死窗口的信号识别、四类根因归因与行动包自动派单本文从Data Agent视角拆解零售新品孵化场景的落地实现：爆款信号与滞销预警如何在 7 天窗口内识别、四类根因如何归因到商品级、行动包如何自动生成并派单到采购系统与 WMS，以及效果如何对照验证。

语义层和SQL Copilot：一个降低写SQL门槛，一个统一业务逻辑语义层与 SQL Copilot 解决的是企业数据分析中的两个不同问题。SQL Copilot 利用大模型理解自然语言、数据库 Schema 和查询上下文，辅助用户生成、修改、解释或优化 SQL，主要降低数据查询的技术门槛；语义层则将指标定义、维度关系、业务对象、时间语义、权限和计算规则统一建模，解决不同人员、BI 工具和 Agent 是否按照同一业务逻辑分析数据。

极昆仑智慧

智能问数零售行业场景3-缺货损失量化与智能补货：缺货没有“账本“，怎么把损失量化成数字？一个 Data Agent 的实现思路本文从技术视角拆解零售缺货问题的落地实现：缺货损失如何量化、根因如何自动归因、补货规则如何动态生成，以及效果如何做对照验证。数据口径为行业研报常见区间的推演值，仅供方案设计参考。

极昆仑智慧

智能问数零售行业场景4-供应商履约监控与采购成本优化：多源数据融合 + 证据链，把采购谈判从“凭经验“变成“有据可依“本文从Data Agent技术视角拆解零售采购场景的落地实现：供应商履约怎么自动监控、异常怎么自动归因、谈判怎么做到"有证据、有方案"，以及收益如何量化与验证。数据口径为行业研报常见区间的推演值，仅供方案设计参考。

极昆仑智慧

智能问数零售行业场景2：滞销库存与跨店错配的自动化处置——从全连锁交叉匹配到调拨清仓派单的工程实现，示例口径一次性盘活/止损约420-620万库存周转天数行业公开口径 30-60 天，滞销是零售最大降本点之一，而"A 店滞销、B 店缺货"的跨店错配最隐蔽。本文从工程角度拆解极昆仑智能问数（极昆仑iInsight）如何把"每日巡检→根因归因→分级处置→验证复盘"四步自动化：全连锁库存怎么拉通做交叉错配匹配、五类错配根因怎么拆、调拨工单怎么派单 WMS、分阶段清仓定价规则怎么设计、T+30 对照实验怎么设计，以及战略品红线如何在架构里硬编码。文末附自家数据自算公式。

极昆仑智慧

智能问数零售行业场景1：生鲜损耗管理的自动化落地——从每日巡检、五类归因到分级降价派单的工程实现，示例口径年化减少损耗约500-1100万生鲜损耗是连锁商超头号降本点（行业公开口径损耗率 15-30%，CCFA 数据）。本文从工程角度拆解极昆仑智能问数（极昆仑iInsight）如何把"每日巡检→根因归因→分级处置→验证复盘"四步方法自动化：巡检调度与阈值规则怎么设计、五类根因怎么从结构化+非结构化数据里拆出来、分级降价怎么变成派单到价签/POS 的工作流、T+30 对照实验怎么设计，以及民生品价格红线如何在架构里硬编码。文末附自家数据自算公式。

指标平台与 Data Agent 协同指南：如何让 AI 问数调用可信指标让 AI 问数真正可信的关键，不是提升模型把自然语言翻译成 SQL 的能力，而是让它优先调用指标平台中已经被定义、治理和验证过的可信指标。只有当指标平台与 Data Agent 通过统一语义层协同工作，AI 问数才可能同时满足口径一致、动态分析、结果可解释和企业级治理要求。

DatI：给AI接入数据库，Agent时代的NL2SQL问数与多维表格应该怎么做我的前两段职业经历都是围绕BI。开始主要是给一线业务做报表，有过用SQL写数据服务，高代码开发看板，也有使用Tableau、PowerBI、永洪BI做自助分析。第二段工作就转向自建BI系统，适逢大模型风起云涌，后来产品聚焦在智能问数（ChatBI）方向上，不过问数能力可以做出吸引人的Demo，但是没法真正让业务深入使用。主要问题有两点：

语义治理 vs 知识治理：AI 数据分析需要业务知识库还是可执行语义层语义治理与知识治理解决的是企业 AI 数据分析中的两个不同问题。知识治理管理制度文档、业务经验、分析方法、流程规则和历史案例，帮助 AI 理解企业上下文；语义治理管理指标定义、维度关系、业务对象、计算口径和权限规则，使 AI 能够基于统一业务语言执行查询、归因和分析。只有知识治理，AI 可能熟悉业务话术，却无法稳定算对指标；只有语义治理，AI 可以获得准确数据，却可能缺少场景背景和经验解释。企业级 Data Agent 需要知识库提供上下文、语义层提供可执行口径、Skill 沉淀分析方法。

Ossie 会不会成为“开源 Palantir”的起点？2026 年年初，我写了《从 SQL 到 OSI》的两篇文章，最近重新看已经进入 Apache 的 Ossie（前身就是 OSI ），我发现这个问题又往前走了一步，它正在定义的东西不再只有指标、维度和数据关系，而是开始出现 Customer、Order、Product 这样的业务概念，以及这些概念之间的关系和业务规则。

阿里云大数据AI技术

数据平台开始“支撑 Agent”：DataWorks Data Agent 如何重构企业数据生产方式作者：闫建丽 - 阿里云智能集团高级产品专家大模型已经能够生成 SQL，但在企业数据环境中，“会写代码”并不等于“能完成工作”。真正的数据任务还需要理解业务口径、读取元数据与血缘、探查源表、调用计算资源、遵守权限，并在发布生产等关键环节接受人工确认。DataWorks Data Agent 的目标并不是在数据平台上增加一个聊天入口，而是把数据平台改造成能够同时服务人和 Agent 的执行底座，让数据生产从人机交互走向人与 Agent 协同。

语义层 vs MCP 工具层：Agent 调用数据时，语义应该放在哪一层语义层与 MCP 工具层解决的不是同一个问题：MCP 工具层负责将数据库、API、指标服务和计算能力以标准接口暴露给 Agent，解决“如何连接和调用”；语义层则统一指标定义、维度关系、业务对象、权限规则和计算口径，解决“调用什么、如何计算、结果是否可信”。

极昆仑智慧

NL2SQL vs NL2语义层：智能问数两条技术路线的深度对比摘要：NL2SQL和NL2语义层是智能问数领域两条核心的技术路线。前者让大模型直接生成SQL，门槛低但可控性差；后者在LLM和SQL之间插入语义层作为确定性中间件，实施成本高但推理可追溯。2025年行业还在争论"谁才是未来"，到了2026年，纯NL2SQL路线已被头部厂商普遍放弃。但争论并未结束——它演变成了一个更深层的问题：当多条升级路线（语义层、BI底座Tools化、多Agent校验、多路径并行、多路径投票）并存时，选型的本质变成了评估"约束层"的深度和成熟度。本文从架构原理、推理可追溯性、上下文持续

极昆仑智慧

智能问数技术路线深度分析：纯NL2SQL退场后，五种架构路线谁主沉浮？摘要：2025年行业还在争论"NL2SQL和NL2语义层谁才是未来"，到了2026年，纯NL2SQL路线已被主流厂商普遍放弃或升级。当前行业形成了五条差异化的技术演进路径：NL2语义层+确定性编译、BI底座Tools化、统一指标模型+多智能体双轮驱动、多路线并行+混合模型、多路径并行投票。本文从准确率保障、推理可追溯性、上下文持续性、学习机制、架构天花板五个维度对五种路线进行技术深度分析。

Text2SQL 系列博客 02：技术原理深度剖析 - 从自然语言到 SQL 的完整链路系列目录（共 15 篇）：关键词：Text2SQL 技术原理、NL2SQL 链路、Schema Linking、SQL 生成、SQL 校验、意图识别、实体抽取、向量检索