当数据走向理解，如何重构一个企业级 AI 数据平台？

本文整理自作者于 10 月 20 日镜舟 MIP 产品发布会上的演讲。10 月 20 日，镜舟科技举办 MIP 产品发布会，宣布产品战略从实时分析走向统一的数据分析与智能平台，并正式发布极速统一的企业级 AI 数据平台 MIP。MIP 以 StarRocks 为技术基础，将统一数据底座、企业级语义层和可信 Data Agent 连接起来，由贯穿全平台的治理能力支撑，帮助企业让 AI 按业务口径使用数据，结果可核对、可追溯。

作者|董颖婷，镜舟科技产品负责人

出品|产业家

企业落地AI Agent的三个问题

Agent进入企业的真实业务之后，会绕不开数据、口径和知识的问题。结合我们自己的实践，我们总结了三个比较普遍的问题，并在每个问题后面写出我们的思路。

问题一：数据多模态且分散。

一个Agent处理任务时，可能同时访问二维业务表、非结构化文档、图片和向量数据。这些数据往往存在不同的存储介质和系统里，取回之后还要进一步关联分析。这给AI Agent系统的搭建带来了难题。

我们的思路是：多类数据要能在SQL中关联。业务表上的数据、湖上的数据、对象存储上的非结构化数据，都能统一检索和查询，查询出来的结果还能继续分析。数据存在不同的地方是常态，但搬迁的代价高，所以让计算去找数据，分散的问题就可以在查询层得到解决。

问题二：口径需要反复解释。

以数据分析为例，"销售额怎么算""哪些订单参与计算"，都要先定义清楚。但这些知识往往散落在历史SQL、文档，甚至分析师的个人经验里。于是同一个问题容易出现不同的答案。

我们的思路是：把业务口径定义在数据库里。这样的定义可以直接转换成可执行的计算。我们通过Semantic View把指标对应到明确的表达式，查询结果可以追溯到对应的公式、统计范围和最终执行的SQL，方便统一解释口径。

问题三：搭建过程大量重复。

搭建多个Agent时，会面临不同的数据接入，需要重新整理相关的知识和上下文。有修正时，不同Agent之间也难以同步，这导致Agent建设过程中产生很多重复工作。

我们的思路是：以数据库承载可复用企业上下文的管理能力，由MirrorMind统一组织知识及其关联、版本和访问权限，供多个Agent按需使用；会话与任务运行状态由MirrorPilot管理。

三个问题指向同一个根源：数据、口径和上下文，缺少统一的载体。

10月20日，镜舟科技产品发布会上，我们正式推出了MIP——极速统一的企业级AI数据平台。以数据库为核心，它的架构设计沿着两个方向展开，向下：为数据库加入AI能力，升级数据底座；向上：数据库for AI，让企业的知识和AI Agent能力，服务更多的业务。

数据在哪里，理解与计算就应该在哪里。把数据、口径和上下文放进数据库，是因为这三件事缺的能力，恰好都要从数据库里长出来。

三层架构：MIP把数据与知识组织成共享能力

MIP把企业的数据与知识组织成三层，形成一套共享能力。

底层是MirrorData，一个以开源StarRocks为核心的企业级数据查询引擎，提供极速查询检索和多模态分析能力。

中间层是MirrorMind，以Semantic View为核心，把相关领域的业务知识和分析师的个人经验关联起来，供Agent按需使用。

上层是MirrorPilot，业务Agent的运行环境。

三层之上，是各类业务应用。企业经营中常用的经营分析、售后诊断、商品选型，都可以用这套统一的底座来搭建。

后面的章节会逐层展开这三层，展示整套底座的使用方式。

• 用“售后图片”展示MirrorData多模态检索与业务关联

• 用“活动预算对照”说明MirrorMind中语义定义的作用

• 以“零售经营分析”串起配置、查询、分析与报告的完整使用流程。

MirrorData：统一的数据底座

标准SQL接入，一套计算能力服务所有应用

MirrorData是MIP的数据底座，核心是一个查询引擎。

上层的BI报表、交互式分析、数据应用和Agent，都可以通过标准SQL接入。同一套计算能力服务不同的应用，MirrorData作为统一的查询入口。

查询引擎延续了StarRocks的高性能查询能力。在此基础上，我们做了企业级增强：权限管理、资源管控和资源隔离。

支持统一访问内表、湖表与多模态内容

数据侧的接入有三种方式。

1.传统内表。内表承载业务字段、JSON、文本和向量等可查询数据；对于图片、文档等内容，可通过文件引用和业务对象ID，与其派生表示及业务记录建立关联。

2.湖上数据。很多客户的数据已经沉淀在数据湖上。MirrorData通过外部Catalog统一接入，支持Paimon、Iceberg、Hive等主流湖表格式，提供高效的湖表访问能力。

3.未利用的历史文件。企业已有的图片、文档和音视频，往往难以直接参与业务分析。原始文件可以保留在对象存储中，按任务需要完成解析和向量生成后，将文件引用、提取的文本及向量写入表，与业务字段关联。MirrorData统一组合检索、过滤、关联与聚合。

一条SQL，完成混合检索

在极速分析和数据湖查询的基础上，MirrorData进一步扩展多模态检索与关联分析。同一个业务对象可以同时具有结构化字段、JSON属性、文本、Embedding和文件引用，通过业务对象ID连接内容与业务事实，使检索结果能够继续参与分析。

底层是三类查询能力：

• 结构化数据：结合分区裁剪和列式扫描，完成极速分析。

• 全文检索：基于倒排索引进行词项匹配，例如通过MATCH_ANY匹配描述中包含“开箱”或“拆箱”的记录。

• 向量检索：按相似度或距离，查找相关内容。

一条SQL可以把三者串联起来，具体的访问路径，取决于查询方式和索引方式。

演示：售后订单查询

为了直观展示SQL与查询结果，我们制作了一个售后检索操作页。用户上传一张屏幕破损照片，寻找近期破损形态相似的售后记录，再关联订单、批次、承运商和退款信息，为后续分析提供依据。

先将参考照片转换为查询向量，作为参数供检索SQL使用。随后在SQL中计算图片相似度，通过售后单和订单明细的关联关系补充批次、承运商与退款信息，并加入时间、品类以及“开箱／拆箱”全文条件。

这些条件最终组成一条完整的SQL。也就是说，一条SQL就能完成结构化和非结构化数据的统一检索。

订单图片检索

MirrorMind：让Agent用对口径

数据能查到之后，下一步：Agent得理解企业的业务定义和背景知识。MirrorMind以Semantic View为核心，解决的就是这个问题。

如需详细了解，可进一步阅读Semantic View系列文章

•Semantic View技术解析（一）

•Semantic View技术解析（二）

• Semantic View技术解析（三）

Semantic View里定义什么

Semantic View记录Agent理解业务所需的结构化定义，包括：

• 表和关联：定义数据表的范围，以及表之间的关联关系。

• 维度：指标可以按哪些维度上卷、下钻。比如活动预算按渠道、活动类型拆，或按日期汇总。

• 指标：每个指标的计算表达式和说明。除了原子指标，也可以定义衍生指标，以及窗口函数这类复杂的计算逻辑。

• 同义词：为指标维护业务名称、别名和说明，例如“市场总预算”“促销补贴总额”。Agent可以结合这些定义识别用户所指的指标，减少不同表达习惯带来的理解偏差。

Agent拿到一个问题，先在Semantic View里找到适用的定义，再按这个口径转成执行语句，交给数据库执行。

对比：有没有Semantic View

用同一个问题做对比："公司的活动预算是多少？"

没有Semantic View时，Agent直接查询底表。表里有四个金额字段，Agent不理解哪一个才是活动预算，于是把所有金额字段加总，得到约29,161,800元。这个结果是错的，不相关的字段也被算了进去。

在演示使用的campaign_analytics中，“活动总预算”对应total_bbbb_amount，计算表达式为SUM(bbbb_amount)。Agent读取这份定义后，选择对应字段求和，得到1,980,000元；没有把其他金额字段一并加入。录像中最终执行的仍然是底表SQL，Semantic View提供了选择和计算指标的业务依据。

Semantic View把业务名称、指标公式和分析维度组织成可复用的定义，让不同Agent使用共同的计算依据，减少各自解释字段和拼接口径带来的偏差。查询结果可以结合指标定义与执行SQL进行核查。

示例：零售客户的订单域

以一个零售客户的订单分析为例。在订单域里，需要先区分订单和订单明细。一笔订单可能包含多条明细商品，两者的统计粒度并不相同。Semantic View按订单与商品明细建立业务主题：

• 订单主题定义"订单数"和"取消率"，按门店、月份分析；

• 销售明细主题定义"折后实收金额"，按渠道、品类、商品分析。

两个主题的统计边界也在定义里写清楚：销售额统计已支付订单，用销售明细主题的折后实收金额；取消率则是取消订单数除以全部订单数。

Semantic View定义指标怎样计算、可以按哪些维度分析；业务规则补充统计边界和例外；业务资料提供政策、事件与原文依据；分析方法规定拆解与核查步骤；任务记忆保留已确认的条件与结论。这些内容可独立维护，由MirrorMind统一管理关联、来源、版本和访问权限，再由Agent按任务组合使用。这样能够说明Context不只有Semantic View，也能支撑业务上持续的知识迭代。

像管理代码一样管理知识

Agent需要的上下文，不止涉及一个Semantic View。比如分析一次指标异动，往往还要关联业务知识和标准的分析流程。我们把它统称为企业上下文。MirrorMind把这些上下文统一管理：内容的关联、来源与版本、访问权限。

管理方式和代码很像，我们借鉴了Git的思路：知识可以创建分支，每个分支上有不同的版本；可以按版本回溯，查看任意版本在某个时间的快照；经过业务确认后，正确的版本再上线。业务在迭代，知识也在迭代，但每个Agent拿到的，都是经业务确认、已上线的版本。用户的反馈会留下完整的trace记录，成为下一轮知识迭代的输入。

多个任务复用经确认的业务定义与背景知识，减少口径漂移；知识更新经过验证后采纳，并保留版本与修订依据，供后续任务复用和回溯。

MirrorPilot：Agent的运行与交付环境

数据能查到，口径可信，最后一步是把它们组织成Agent，交付给业务。这是MirrorPilot的职责。它是企业的Agent运行和交付环境，向下串联MirrorData和MirrorMind，对外交付结果。

四步完成一次任务

用户侧有两条使用路径下达任务。一条是直接对话，通过产品工作台完成分析；另一条是通过API接入原有的业务系统，复用Agent的能力。

一次任务的执行分为四步。先理解目标；再结合上下文和现有Skill，组织执行方案；然后调用工具，比如查询Semantic View里的具体定义；最后处理结果。简单任务到这里就直接交付，复杂任务会重复检索、多步执行，再把最终结果返回给业务。

MirrorMind按任务的需要提供上下文，MirrorData负责结果的查询和佐证。围绕运行本身的还有一整套周边管理：会话管理、任务状态、资源范围、预算、超时和运行记录，都内置在MirrorPilot里。

交付的不只是答案

MirrorPilot的交付物，可以是一段回答，也可以是报表和API。执行过程会严格留痕：这次计算用的是哪条SQL、口径规则是什么，都清晰可查。用户可以继续追问，也可以对整个任务溯源。

开放接入，能力沉淀

接入是开放的。MirrorPilot提供Agent API，企业可以从已有BI、经营门户或业务系统发起任务，经服务端鉴权后获取任务结果或会话链接，并按现有应用的交互方式完成集成。自定义Skill用于扩展分析步骤，MCP用于接入外部工具。

能力是会沉淀的。已有分析逻辑可以沉淀为SQL模板，同类问题按时间、维度等参数复用查询逻辑，执行后返回结果，减少重复生成查询的工作。业务知识、SQL模板和Skill都能持续复用与迭代，也支持自定义Skill的接入和管理。

因此，MirrorPilot既可以独立运行，也可以接入企业原有的应用，逐步扩展分析能力。

MirrorControl：配套的管理控制后台

与MirrorPilot配套的，是MirrorControl管理控制后台。

配置Agent时，在这里选择数据范围、知识库，以及要用到的Semantic View和Skill。它还提供知识检索能力，比如"取消率在企业内部是如何定义的"，输入问题就能得到定义和提示。

示例：一个零售客户的经营分析Agent

最后用一个脱敏案例，把三层串起来：某客户用MIP配置了自己的经营分析Agent。

配置：先圈定范围

配置Agent的第一步，是定义业务范围：Agent所需的数据范围是什么，业务域相关的Semantic View是哪些，相关知识库在哪里。圈定范围的目的，是缩小Agent的检索范围，避免知识混淆，造成错误的答案。

然后是角色、回答规则和Skill的配置。比如追问和下钻时走什么标准流程，输出报告用什么样式，都在这里定义。查询和检索工具内置在Agent里，可以直接检索企业内部知识和Semantic View。

演示：从一个问题到一份报告

配置完成后，看一次完整的使用过程。

进入平台，先选择Agent，它的分析范围在配置时已经圈定。直接用自然语言提问，比如让Agent按渠道拆分销售额。Agent会给出每个渠道的分析结果，附带图表和原始SQL。

涉及数据查询的回答，用户可以查看相关查询语句、指标与时间范围，并结合计算口径核查结果。保留查询和知识来源，使分析过程更容易追溯。

接着追问："这个指标正常吗？按部门拆解合理吗？"Agent会调用企业上下文里的标准流程和SOP，比如对订单取消率做异常识别。异常判定规则与分析方法由MirrorMind作为企业上下文统一管理，MirrorPilot在任务中读取相关知识、组织步骤，并调用MirrorData执行查询。

若再追问一句："为什么会飙升？" Agent按分析方法继续检查品类、品牌和商品，并检索仓储事件及库存记录。它把这些信息与门店取消率变化结合起来，提出可能原因、相关证据和建议动作，供业务人员进一步核查。

分析完成后，用户可以继续通过对话要求生成管理层报告。Agent将当前任务中的数据、图表、业务资料与分析结论整理成可打开、可下载的HTML报告，供业务部门讨论和核查。

演示视频

回到开头的三个问题

MirrorData让检索结果能够继续参与SQL关联与分析；MirrorMind集中维护业务口径与企业知识，让多个Agent复用共同的定义和依据；MirrorPilot将数据、Context与分析方法组织成业务任务，交付可核查、可追溯的答案与报告。

三个问题落在同一个底座上，这个底座就是MIP。