北京
（原标题：从数据到 Context：MIP 如何让 AI 真正理解企业）
让 AI 理解企业，需要把业务定义带入它读取数据、执行查询和解释结果的过程。一份销售分析采用哪些订单、使用什么口径、依据哪些记录判断原因，都应当有据可查。
例如，业务人员交给 Agent 一项任务：分析华东区本周销售额下降的主要原因，并给出下一步建议
订单、库存、流量和活动记录提供了分析材料。开始查询前，Agent 还需要明确：“华东区”包含哪些门店，“销售额”是否扣除退款，本周应与上周还是去年同期比较。
这些定义影响选表、过滤、关联和计算，也决定结果能否与业务报表对得上。MIP 围绕这条分析链路，将企业数据、业务语义和相关上下文连接起来，供 Data Agent 与企业已有的 Agent 使用。
一、业务定义需要进入查询过程
同一批订单，按下单金额或扣除退款后的金额计算，会得到不同的销售额。两套口径可以分别服务运营和财务分析，Agent 需要先确认任务采用的定义，再选择字段与计算方式。
跨表分析也有类似要求。比较商品销量与库存，需要明确商品编码的对应关系，以及订单和库存的统计时点；按门店分析，还需要区分门店库存和仓库库存。
业务定义应成为查询的输入。指标公式、关联关系和统计粒度进入查询过程后，团队才有明确依据核对计算方式与结果。
企业级 Text-to-SQL 的公开评测也将这些环节作为独立任务考察：BEAVER 把查询过程拆为多表检索、连接键识别、字段映射、领域知识提取和查询分解，并通过补充子任务标注的实验，展示相关信息对执行准确率的影响。对企业实践而言，查询核验可以沿这些环节展开，将结果差异定位到数据选择、业务定义或计算步骤。
二、Context 把事实、定义与方法组织到任务中
在企业数据分析中，Context（上下文）是 Agent 完成任务时使用的数据、定义、说明与相关记录。围绕华东区销售分析，可以按五类信息组织：
五类信息按任务中的用途区分。一份退款规则文档属于知识，其中影响销售额计算的规则，需要落实为可执行的指标定义；一次排查记录可以进入记忆，经验证并整理为通用步骤后，也可以用于完善技能。
知识库负责保存和维护材料，RAG 负责检索相关内容并提供给模型，语义层负责将业务名称与计算规则对应起来。例如，Agent 可以通过检索了解某渠道的退款政策，再依据适用的净销售额定义计算结果。
数据记录业务事实，语义明确业务含义，Context 将这些内容与知识、经验和方法组织到具体任务中。任务使用哪些内容，还要结合适用时间、访问权限和确认状态选择。
三、多套 Agent，需要共享的业务基础
销售 Agent 和供应链 Agent 都可能使用商品、门店与区域定义。如果两边分别维护，门店划分调整后就需要更新两套配置；定义生效时间不同，同一地区的销售与库存统计也可能出现差异。
随着应用增加，重复建设可能出现在三个环节：为每个 Agent 配置数据连接，分别维护相同指标，以及反复解释结果差异来自哪套定义。当业务规则分散在各自的提示词、代码和工作流中维护时，这些定义容易形成难以同步的“语义孤岛”。
共享的基础应当包括数据访问、业务定义和核验依据。销售分析与库存分析仍可保留各自的目标和步骤，但共用的商品、门店和区域定义可以集中维护；财务与运营的不同口径则分别标明用途、版本和适用条件。
MIP 将可复用的数据与业务语义放在平台层维护，再提供给不同 Agent 调用。 MirrorPilot 提供内置的数据任务入口，企业已有的 Agent 则可通过接口接入这套基础。
四、MIP：One Engine. Unified Semantics. Every Agent.
MIP 是镜舟科技的企业级 AI 数据平台，将统一数据底座、业务语义与 Context、Data Agent 连接成一条分析链路。三个部分分别承担数据访问与计算、业务定义与背景组织，以及任务调用与分析。
（一）One Engine：统一数据访问与计算
MirrorData 是 MIP 的统一数据底座，本身包含对象存储、开放湖仓和实时分析引擎能力。企业可以基于已有数据布局，组织实时数仓、Iceberg 等开放湖表以及已接入业务系统中的数据，形成分析所需的数据范围。
统一入口支持跨存储的数据使用。在华东区销售分析中，近期订单与库存更新可以来自实时分析系统，历史记录可以保存在开放湖仓，活动说明和日志则补充业务背景；实际访问范围由数据源适配、更新链路和权限配置确定。
分析材料也可以包括文档、日志与 Trace，以及图片、音频、视频的元数据和经过处理的标签、文本或向量表示。结构化指标计算使用 SQL，文档内容可通过全文检索查找，语义相似内容可通过向量检索召回；具体路径取决于数据形态、预处理和索引配置。
（二）Unified Semantics：让业务定义进入执行路径
MirrorMind 组织业务语义、知识、记忆和技能，为分析提供适用的 Context。其中，用于计算的业务定义通过数据引擎中的 Semantic View 进入查询过程。
Semantic View 把企业已确认的业务定义变成查询可引用、执行可检查的对象。在已公开的技术示例中，Agent 依据定义选择指标与维度，数据库按声明的关系和计算规则展开查询，分析人员可以通过 EXPLAIN INLINE 查看展开后的 SQL。
从业务问题到 Semantic View，再到 SQL 执行与核验
对应到销售分析，团队先明确净销售额的计算公式、门店与区域的关系，以及时间和订单状态等过滤条件。Agent 引用这些定义组织查询，计算过程再接受与参考查询、业务报表的核对。
口径制定原因、促销安排和历史修正记录由相关知识与任务记录补充。计算规则与解释材料各有用途，共同支撑结果判断。
（三）Every Agent：让不同入口复用数据与语义
MirrorPilot 是 MIP 自带的 Data Agent，提供问数与分析入口。它根据问题选择适用的指标、维度和关系，调用数据能力完成查询，再结合相关 Context 解释结果。
企业自建 Agent、行业 Agent 和 Copilot 也可以通过接口接入 MIP，在完成适配与授权后，使用相应的数据、语义和 Context。企业可以保留已有的交互入口和业务流程，将共用的数据定义放在平台侧维护。
例如，销售 Agent 关注收入变化，供应链 Agent 关注库存与补货，两者可以引用同一套商品和门店定义。各自任务中的指标、工具和分析步骤仍按业务需要配置。
五、从 Data 到 Understanding：结果与依据一起交付
回到“华东区本周销售额下降”这项任务。在数据、定义与工具完成配置后，分析先确定区域范围、净销售额口径和可比较的时间段，再按渠道、门店和商品拆解变化，随后结合库存、流量、活动安排与历史记录逐项核查。
交付给业务人员的结果，应同时说明“发生了什么”和“依据是什么”。以下展示一种结果组织方式，便于区分计算结果、相关线索和待验证原因。
销售额减少61万元是按商品拆解得到的计算结果。要估计其中有多少由缺货造成，还需要结合可售时段、流量和其他相关因素继续分析。
Beyond Answers. Toward Understanding. 在这个任务中，“理解”可以通过四项内容核验：
数据来源：用了哪些记录，更新到什么时间，覆盖哪些门店。
业务定义：采用哪套指标公式、区域范围和比较基准。
计算过程：如何关联数据、设置条件、汇总和比较结果。
判断边界：哪些属于已观察事实，哪些属于推断，哪些需要补充验证。
计算准确性通过同口径对账检查，解释依靠相关记录支撑，追溯则依赖保留的数据来源、定义和执行信息。业务人员由此可以沿着结果返回计算与判断过程，继续核验具体问题。
六、模型持续迭代，企业的 Context 持续积累
模型、Agent 框架和业务应用会升级，企业对客户、商品、收入和风险的定义仍需持续维护。将这些定义与任务经验独立保存、记录适用条件并建立复用方式，有助于企业在工具变化时保留已有积累。
一次销售分析可以留下几类具体成果：经确认的指标修正、可复用的查询方法、带有时间与范围的异常记录，以及经过验证的检查步骤。例如，团队确认内部订单应从某项指标中排除，可以更新对应定义，并用参考查询核验结果。
这些积累的价值可以通过任务过程观察：新增分析的配置周期是否缩短，共用定义的复用率是否提高，相同口径下的结果是否一致，以及问题定位和人工核验耗时如何变化。新规则的生效时间、历史记录的适用范围和失效内容的处理，也需要有人维护。
对于 MirrorMind，持续积累的内容就是企业确认过的定义、知识、经验与方法。后续 Agent 可以引用这些内容，再依据当前数据和任务条件验证其适用性。
七、结语
从 StarRocks 到 MIP，镜舟沿着数据查询与分析能力，继续向业务语义和 Context 延展。MirrorData 提供统一数据基础，MirrorMind 组织企业定义与相关经验，MirrorPilot 及对外接口将这些能力用于具体任务。
从数据到理解，这条路径需要可持续维护的业务定义、可检查的计算过程，以及可复用的分析依据。MIP 将它们连接起来，让企业已有的数据投入与业务积累，继续服务新的 AI 应用。
