过去一年，AI 领域的新闻几乎每天都在刷新：更强的大模型、更低成本的推理、更复杂的 Agent、更标准化的 MCP 工具调用。TechCrunch 近期对 AI 的持续报道也反映出一个趋势：AI 行业正在从“展示模型能力”走向“解决真实工作流问题”。

但站在企业数据工程师的角度看，真正的难点往往不是模型本身。

很多企业做 AI 数据应用时，第一步通常是：接一个大模型，让它根据自然语言生成 SQL，或者让 Agent 调用数据库查询接口。Demo 阶段看起来很顺利，但一进入真实企业环境，问题就会暴露出来：

“销售额”到底来自订单表、发票表，还是财务确认表？
“客户”在 CRM、合同、回款、售后系统里是不是同一个对象？
两个表字段名都叫 customer_id，它们真的能直接关联吗？
历史表、临时表、汇总表、明细表同时存在时，模型该选哪一个？

这些问题并不是 prompt 能完全解决的。因为大模型擅长理解语言，但它并不天然理解企业内部复杂的数据关系。

所以，企业级 AI 数据智能应用的第一层能力，不应该是“让模型直接猜 SQL”，而应该是先把企业数据底座整理清楚。这里面至少包括三件事：

第一，元数据要可用。
模型需要知道有哪些数据源、哪些表、哪些字段、字段类型是什么、哪些表可以参与分析。如果没有稳定的元数据层，模型只能在不完整的上下文里推断。

第二，表间关系要可信。
企业数据库中并不是所有关系都会通过外键显式声明。很多真实关系隐藏在字段值、命名习惯、业务规则和历史系统迁移中。比如客户名称、合同编号、项目编码、组织编码等字段，可能跨多个系统重复出现，但是否能关联，需要通过数据值和统计关系来判断。

第三，业务语义要被治理。
业务人员问“库存余额”“重点客户”“项目工时”“利润贡献”，这些并不是简单字段名，而是带有口径、维度、时间范围和权限边界的业务概念。没有语义层，AI 生成的 SQL 很容易“语法正确、业务错误”。

从这个角度看，企业 AI 数据应用的落地路径应该是：

数据源接入 → 元数据提取 → 数据关系发现 → 业务语义定义 → 自然语言查询 → SQL 生成与校验 → 结果解释与反馈闭环。

Intalink 与 Arisyn 的协同正好对应这个路径。Intalink 更像底层的数据关系发现引擎，负责识别数据源、表、字段以及潜在的表间关系；Arisyn 则在这个基础上做自然语言理解、语义映射、SQL 生成、多步推理和结果展示。

对工程团队来说，这种分层架构的价值不在于“又多了一个平台”，而在于把不确定性拆开了：

数据关系由关系发现引擎提供；
业务口径由语义层治理；
模型负责理解问题、组织查询和解释结果；
执行结果再反向补充知识库和语义规则。

这比单纯依赖大模型“直接生成 SQL”要稳得多。

未来企业 AI 的竞争，可能不会只发生在模型参数量上，而会发生在谁能更好地连接企业真实系统、理解企业数据结构、沉淀业务语义和持续修正查询结果上。

换句话说，企业 AI 的落地不是从“模型”开始的，而是从“让模型拥有可靠的数据上下文”开始的。

如果说大模型是新的计算界面，那么元数据、数据血缘、语义层和关系发现，就是这个界面真正可用的地基。