当数据走向理解，如何重构一个企业级 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 记录 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。