文 / 镜舟科技 CEO 孙文现
回看 StarRocks 最初面对的客户问题，最直接的感受是：企业产生的数据越来越多，理解和使用数据的速度却没有同步提高。报表要等，复杂查询要等，业务人员提出一个问题后，还要经过数据加工、查询和分析，才能拿到结果。
当时，一个突出的瓶颈是性能。我们首先投入实时分析，希望让数据在业务需要的时候用得上。BI、用户画像和应用内分析，都是这种需求的具体体现。查询快一些，业务就有机会多问一个问题、多做一次验证。
后来，越来越多的数据进入对象存储和开放数据湖，分析需要覆盖湖与仓。企业既要使用近期更新的数据，也要分析长期积累的历史记录。我们继续投入湖仓建设，把分析引擎、湖和对象存储纳入完整的数据基础设施，减少数据使用过程中的割裂。
我们一直用一个标准看待这些投入：它们有没有缩短企业从数据到业务价值的距离。查询速度是其中的重要一环，最终还要看数据能否帮助业务形成判断。
性能是我们最早解决的问题，但不是我们最终想解决的问题。我们真正关心的是，如何缩短企业从数据到业务价值的距离。
今天，AI 和 Agent 开始直接使用企业数据。模型可以生成 SQL，Agent 可以拆解问题、连续查询，再把结果交给其他应用。与此同时，数据平台还要回答：它采用了哪套业务定义，是否用对了数据，结果能否找到依据？
StarRocks 重点解决的是数据如何被更快地查询，MIP 要进一步解决企业数据如何被 AI 正确地理解和使用。对我而言，这是沿着数据价值链继续向上生长。StarRocks 的分析能力，以及围绕它建设的统一数据底座，是这项工作的出发点。
1. 客户的问题，逐渐超出了查询性能
从 2024、2025 年开始，我在客户交流中越来越多地听到一些新的问题。大家关心已有的数据平台怎样服务 AI，也在追问落地后的具体要求：
-
数据访问：AI 怎样使用已有数据，文档和结构化数据能否一起分析？
-
业务口径：同一个指标，怎样让 AI 采用适合当前任务的定义？
-
权限与核验：不同角色能看哪些数据，答案出现偏差后能否找到原因？
这类问题在不同客户的讨论中反复出现。我们也去了解较早开展实践的团队怎样处理，MIP 的方向是在这个过程中逐渐形成的。
金融客户就和我们讨论过一种困扰：AI 能为指标变化生成分析，但业务解释会出现偏差。用于经营讨论时，管理者需要知道变化来自哪里，团队却还要重新查数据、找口径，核对 AI 给出的理由。
以这类任务为例，某项利润指标上升，分析需要先确认采用哪个利润口径、比较哪个期间、两期是否覆盖相同机构，再拆解收入与成本。如果当前查询包含了新增机构，而比较期没有纳入同样范围，把增长直接解释为经营效率改善，就可能产生误导。SQL 可以执行成功，两个数也都算对了，但比较的业务对象并不一致。
归因还要再向前一步。哪项收入增加、哪项成本下降，可以用数据核对；为什么变化，则需要业务记录或其他证据。模型生成一段读起来顺畅的解释，和获得足以支持判断的依据，是两项不同的工作。
SQL 正确，不代表业务理解正确。 这是我们在早期问数实践中持续关注的问题，也改变了我对数据平台下一阶段价值的判断。
另一个信号来自较早探索企业 Agent 的团队。有先行客户尝试过较广的应用范围，后来选择在 BI 分析、广告投放等业务领域分别沉淀知识，增加语义约束，在关键环节保留人工确认，并把验证过的分析过程整理成可复用的方法。
这让我们更重视应用范围和业务定义的关系。同样叫"效果"，经营分析与广告投放关注的指标、目标和时间窗口可能不同。先把一个业务域做清楚，才容易判断答案是否可用，经验是否值得复用。
我对数据平台的判断也由此多了一层：除了把 SQL 跑得更快，还要帮助 AI 在正确的业务上下文里使用数据。客户最终要用这些结果讨论经营、安排生产，甚至推动后续流程。
2. 当数据的使用者扩展到 Agent
过去，人通常通过 BI、SQL 或业务应用使用数据。现在，企业多了一条新的使用路径：人 → Agent → 企业数据 → 后续分析或业务流程。
使用者的变化，增加了数据平台需要承担的工作。人看到异常结果时，可以停下来追问口径、核对来源；Agent 则可能连续发起查询，组合不同结果，再把结论交给另一个 Agent。如果没有安排核验环节，前一步的理解偏差就可能进入后续任务。
Agent 可能把一次错误查询的风险，放大为后续自动化分析与决策的风险。
因此，我们希望把一部分工作提前到分析开始之前：明确业务定义，确认数据范围，让当前身份和权限进入数据使用过程。同时保留查询与执行记录，便于核验；涉及采购提交、库存调整等业务操作时，还要另行检查操作权限和审批要求。
这些安排各有作用。语义定义帮助 Agent 选择口径，上下文补充任务所需的业务信息，权限约束数据和操作范围，执行记录帮助查明过程。定义工作不能代替过程治理，事后追踪也无法替企业决定"可用库存"应该怎样计算。
过去数据库解决的是"能不能查"；Agent 时代还要解决"AI 有没有理解对"。
AI 也扩大了值得分析的数据范围。调研中，我们谈到过金融机构保存的音视频、扫描文档等材料，它们过去主要用于存证。要把这些材料用于分析，往往需要先完成识别、信息提取和数据整理。多模态能力为缩短这段准备工作提供了新的可能。
可以设想一个服务复盘任务：业务团队想知道，某类申请为什么反复退回补充材料。结构化记录能告诉我们退回次数和处理时间，具体缺少什么、沟通中哪里产生歧义，则可能留在扫描材料、录音或处理备注里。分析需要按申请编号、材料版本和时间把它们对应起来，再区分系统记录、工作人员说明和模型推测，并保留原文或录音位置供复核。
这类任务让我们看到，企业过去保存的数据有机会参与更多业务。但能够读取材料之后，仍要处理业务含义、访问权限和证据核验。模型能力越丰富，数据基础设施越需要把这些使用条件准备好。
3. 数据统一之后，更难的是统一理解
以一个产品生产的例子展开。如果把"还有多少库存"放回生产现场，问题可能是："A 工厂明早 8 点要生产 80 台设备，能不能按时齐套开工？"业务要知道的是指定任务在指定时间能否获得所需物料。
下面用一组假设数据展开这个场景。按已确认的物料清单，每台设备需要 2 个同规格控制模块，因此这张生产订单需要 160 个。其他物料已经齐套，当前只需核对这个模块；各系统的数据时点已对齐，也没有需要扣除的其他限制。
这类约束在业务系统中有具体含义。例如，库存预留规则区分为特定订单保留的数量；其库存状态规则也明确，冻结库存仍属于实物库存，但不能用于生产订单等业务。
如果 Agent 只汇总三个在库批次，会得到 240 个，再与需求的 160 个比较，得出"库存充足"。即使排除了冻结和其他订单占用，算出两地合计可分配的 140 个，也仍然没有回答能否在 A 工厂明早 8 点开工。
在库、可分配、能按时到达产线，是不同的业务状态。 在这个场景里，当前能确认支持目标时点的只有 A 工厂的 70 个，距需求还差 90 个。供应商预计到货的 60 个，可以作为待确认的补充来源，但不能直接当作已经放行、可投入生产的库存。
Agent 要回答这个问题，需要先把生产订单、物料清单、仓库批次、订单预留、质量状态和到货计划对应起来。预留给本订单的数量应算入本订单供给，预留给其他订单的数量则要扣除；异地有货，还要检查运输、收货和送达产线的时间。只看字段名或做一次数量汇总，无法代替这些判断。
一个有用的答案，需要同时交代确定的部分和仍待确认的条件：
按当前已确认条件，明早 8 点可供本订单使用的控制模块为 70 个，需求为 160 个，尚有 90 个缺口。B 工厂可申请调拨 70 个，但当前到线时间晚于开工时间；供应商在途的 60 个尚未确认质量放行时间，因此暂不能确认按时齐套。
若 B 工厂的 70 个能获批调拨并提前送达，仍有 20 个缺口，需要进一步确认在途批次能否在开工前完成收货、检验与入库。
这里的条件也决定了下一步该找谁确认：物流团队确认调拨到线时间，质量团队确认检验与放行安排，计划人员决定是否调整生产任务。Agent 可以整理依据、提示缺口和比较方案；释放其他订单的预留、解除质量冻结或修改排产，仍要经过相应授权和审批。
这是我们所说的"理解"：把"够不够"还原为对哪张订单、在哪个地点、什么时间、满足哪些条件的可用性判断。它需要企业明确的业务定义，也需要及时、完整的数据；语义层不会让延迟的物流提前到达，也不能代替质量人员作出放行决定。
同一批物料，在财务盘点中仍然是在库资产，在仓库视角下可能可以分配，在生产计划视角下却未必赶得上开工。统一语义需要保留这些合理差异，并让人和 Agent 知道每种定义适用于什么任务。 问题没有给出订单、工厂或时间时，就需要补充确认。
统一语义，是让不同的人、不同应用和不同 Agent，对同一个业务概念有共同的定义可以依据。
Semantic View 的价值在于让指标、维度和对象关系进入可计算的定义。订单占用怎样区分、冻结状态怎样处理，可以成为查询依据；检验安排、调拨说明等信息，则需要相关业务知识与上下文补充。结果应能够回溯到所用的物料清单版本、库存时点、预留明细和计划记录，使用者才有条件核对结论。
4. 我们为什么从企业数据往上构建理解
对话入口可以让使用更方便，模型和 Agent 框架也会继续发展，但一家企业怎样定义客户、库存、收入和履约，需要从自己的业务中整理出来。
我们的判断是：Chat 容易复制，企业自己的 Context 需要长期积累。以"可使用库存"为例，通用模型能够解释库存管理的概念，但哪些预订有效、何时释放、谁能批准调拨，要依据这家企业的流程。
模型会变，Agent 会变，但企业自己的数据、语义和规则不会由模型替你定义。
将规则写进某个应用的 Prompt，可以帮助解决眼前的问题。随着应用增多，同一条规则可能出现在不同位置，调整后需要逐一检查。更值得长期建设的，是由企业维护业务定义、适用范围和版本，再让不同应用使用这些经过确认的知识。
企业 AI 真正长期的资产不是 Prompt，而是数据和业务语义。
这里的积累还包括分析经验。检查生产任务能否按期备料，需要确认物料需求和使用时间，再看库存、预订及到货计划；发现缺口后，要区分缺货、到货偏晚和状态待确认。这套经过业务人员验证的步骤，可以连同适用条件一起沉淀为 Skill，供后续 Agent 使用。
我希望这类知识能持续留在企业手里。更换模型或应用时，团队可以在已有定义和分析方法上验证新系统，而不必重新解释一遍业务。能否正确调用、是否遵守权限，仍然需要检验。
我们不是从聊天框往下找数据，而是从企业数据往上构建理解。
基于这些调研和判断，我们选择建设 MIP。它是镜舟面向企业 AI 的数据平台，从 StarRocks 的分析能力出发，向业务语义、企业上下文和 Agent 使用延展。
AI 要使用更多类型的数据、连续发起分析，对数据时效、执行效率和资源管理的要求也会继续存在。MIP 的三层关系，沿着数据被使用的过程展开：
-
统一数据底座：提供任务所需的数据和分析执行能力。
-
业务语义与上下文：明确数据在这家企业、这个任务中的含义，并提供相关业务依据。
-
Agent 使用：依据前两层开展分析，让结果采用的口径和数据能够核对。
One Engine. Unified Semantics. Every Agent. 这句话概括了我们希望建立的关系：用统一引擎和业务语义，为不同 Agent 使用企业数据提供基础。
对于应用范围，我们的态度同样明确。现阶段，把企业全部数据交给一个缺少边界的 Agent，再期待它自动成为熟悉业务的分析师太过于理想化。先在口径清楚的数据域里验证，保留必要的人工确认，依据实际效果扩大范围，是我们更愿意和客户一起推进的方式。
5. 让客户已有的投入继续服务 AI
从数据与语义出发，也与我们服务的客户有关。他们已经建设了 StarRocks 集群、数据湖、表结构、SQL、物化视图和权限体系。数据团队还在长期工作中确认了指标、分析方法与运维方式，这些都应该成为 AI 应用的起点。
MIP 的目标，不是让客户为了 AI 再建设一套数据平台，而是让过去的数据投入开始服务 AI。
我们希望尽可能在已有基础设施上增加语义、上下文和 Agent 能力。具体到项目中，需要先梳理现有资产：哪些 SQL 已经包含确认过的指标口径，哪些物化视图服务于日常分析，哪些权限规则需要传递到新的使用入口。能够复用的部分继续使用，需要调整的部分明确范围。
以库存分析为例，可以先选择一个仓库或一类物料，沿用库存、出入库和预订数据，把"可使用库存"的定义整理出来。验证时，既看正常问题，也看容易出错的情况：在库充足但已被占用、出库尚未同步、预计到货晚于使用时间、当前角色无权查看某个仓库。
业务人员核对结果，数据团队检查口径与查询，AI 团队验证任务执行和异常处理。除了答案是否正确，还应记录团队为纠正答案付出了多少额外工作。对客户来说，少花多少时间查表、找人确认和反复解释，是判断这项投入的具体依据。
这也要求镜舟进一步积累业务能力。过去服务 BI 和分析应用时，我们接触过客户的数据模型、指标和分析方法。接下来，需要与客户一起整理其中可复用的经验，将它们转化为经过确认的定义、分析方法与核验样例，让一次实施留下后续还可以使用的成果。
企业各自的规则仍然需要由企业确认。镜舟和伙伴提供的工具、方法与行业经验，应该帮助客户更好地完成这项工作，并让积累能够持续维护。
6. 把企业实践带回开放生态
从 StarRocks 向上生长，也意味着继续承担对社区和生态的责任。StarRocks 社区解决通用的数据基础设施问题，镜舟则有机会把企业使用中遇到的新需求带回产品和社区。
Agent 连续发起分析时，怎样与日常报表合理分配资源；一个任务同时需要结构化查询和文档检索时，底层怎样提供适用的数据访问能力；湖仓中的数据怎样更方便地用于分析，这些都是值得共同推进的工程问题。通用能力在开放生态中得到完善，会让更多开发者和应用受益。
企业 AI 的使用过程也需要不同伙伴参与。仓储系统维护物料状态，BI 工具承载既有报表，行业应用处理领用和审批，Agent 框架负责组织任务。MIP 提供数据与业务语义基础，希望通过清晰的接口，让这些工具在各自职责范围内协作。
这种开放还应保留企业的选择空间。客户可以继续使用熟悉的分析工具，也可以由伙伴开发生产计划等领域的 Agent。不同应用如果能依据经过确认的业务定义工作，就可以减少各自重新整理一套口径的工作。
商业投入则需要把企业落地做深：组织权限如何适配，业务规则如何维护，行业经验如何沉淀为 Skill，以及实施完成后怎样持续提供服务。这些需要长期的产品与工程投入。
开源决定技术能走多远，商业化决定企业级能力能做多深。
对我而言，这两项工作需要相互支撑。社区、客户、伙伴和商业公司在各自擅长的部分持续投入，企业才有条件在已有生态中逐步用好 AI。
结语
如果三年后回看今天的选择，我希望客户能感受到一项具体变化：过去回答一个业务问题，需要分别找数据、确认口径、组织查询和分析；现在可以用业务语言提出问题，更快得到基于真实数据、采用明确业务定义、能够追溯依据的结果。
从"查得快"走向"理解得快"，是我对 MIP 的期待，也是 The Fastest Path from Data to Understanding 所要表达的方向。数据平台帮助企业更快形成有依据的业务判断，决策仍然由企业自己作出。
MIP 没有替企业做决定，但它应该让企业更快、更有依据地理解业务。