2025年算是Agent元年，回望这一年，我们听到最多的企业内部需求，大概是这样的：

“能不能做个智能体，让业务同事直接问？”
“我们也想上大模型，把知识库、报表全串起来。”
“视频、IoT、日志、告警都在，就是没人能‘一口气’看完一件事。”

再往下问一句：
你们是不是已经有一套还算完整的数据中台了？
——有的，数仓有了，指标有了，报表有了，数据中台也上线好多年了。

问题就出在这里：
看上去“齐活”的数据基础设施，遇到 AI 项目的时候，却越来越“不顺手”。

这不是某一家企业的特例，而是很多头部企业在今年共同遇到的现实。
多模态数据中台，不是哪个厂商的新品类，而是被这些现实一点点“逼”出来的结果。

一、项目一个接一个，为什么“好用的 AI”依然很少？

如果把技术名词先放一边，只看业务一线在日常中遇到的那些烦恼，基本可以归结为三类。

第一类：问题本身，已经不是几张表能说清的了。

投诉率上升，是产品问题，还是服务问题，还是运营动作出了偏差？
一条产线良率波动，是设备状态变差了，还是某个班组操作习惯改了，抑或原材料批次有差异？
一个片区的安全事件频率变高，是人流结构变化了，还是设施老化，还是历史事件叠加影响？

这些问题的线索，散落在录音文本、服务记录、工单流转、IoT 时序曲线、告警日志、监控视频、轨迹数据、甚至三维场景里。
但在大多数企业的系统版图里，它们是这样的：

• 表格在数仓和中台；
• 日志在监控系统；
• IoT 在边缘平台；
• 文档在知识库；
• 视频在安防系统或第三方云。

一个问题，天然跨多个系统。
而传统数据中台，更多还是围绕结构化数据在组织世界。

第二类：数据“都在”，但真正用起来总有点别扭。

你去问数据团队，大概率会得到这样的回答：
“有，这个字段在某某表；那个数据要从日志库拉；视频要去另外一个平台查；IoT 在边缘那边。”

于是，每做一个新的 AI 场景——
智能客服、智能质检、预测性维护、智能风控、风险研判、智能问数与归因分析……
都要从头打一条“专用数据链路”：
从五六个系统里各拎一段，再临时拼在一起。

做好一个项目不难，难的是：
几个项目之后，大家发现手上有的是一堆“各自为战”的小链路，而不是一块越来越厚的数据地基。

第三类：智能总是“停在屏幕里”，很难进入日常工作。

企业对 AI 的期待，其实很朴素：

• 业务能直接问；
• 不用切十个系统；
• 能看懂“为什么是这个结论”；
• 能把智能变成流程的一部分，而不是一次演示。

现实却往往是：
报表在一套系统，知识问答在一套系统，流程机器人在另一套系统；
每个“智能助手”背后连的是不同的数据源、不同的口径，能力不统一，体验也割裂。

久而久之，管理层会问一句：
我们到底是“有很多 AI 项目”，还是“真的多了一个和我们一起工作的智能同事”？

二、沿着这些烦恼往下拆，企业真正缺的是什么？

如果不从“我要不要上一个多模态数据中台”出发，而是老老实实从用户的烦恼往下拆，很快会发现：
企业想要的，不是更多的“点状应用”，而是一块可复用的 Data+AI 地基。

这块地基，要帮企业做三件事。

第一件事：让业务问题可以被完整地“摊开”。

“投诉率为什么上升”这个问题，背后需要的，不只是投诉表和订单表；
“良率为什么波动”，需要的不只是工单和生产记录。

如果企业内部没有一处地方，能围绕“客户、设备、订单、工单、门店、产线、场站”等对象，把结构化数据、日志、文本、音视频、时序、空间位置这些信息收拢在一起，那么任何一个 AI 模型，看到的都只是一块块碎片。

你很难指望一个模型，在看不到录音和工单的前提下，对投诉原因做出什么可靠判断。
你也很难指望一个模型，在看不到工艺曲线和设备历史后，对良率问题给出负责任的建议。

换句话说，如果问题本身是多模态的，数据视图却还是单模态的，那么所有智能，天然就被“打了折扣”。

第二件事：让数据治理这件事，不再是“一次性的体力活”。

数据团队并不怕辛苦做一遍数据治理，怕的是永远在做同一件事：

• 为了客服智能质检，清洗了一轮录音与文本；
• 为了质检优化，又清洗了一轮生产日志和视频；
• 为了城市治理，又清洗了一轮时空轨迹与告警事件。

每一轮都像是新品类，缺乏统一的标准和资产视角，项目一结束，这些成果就“躺”在各自专用库里，很难被后续场景继承。

如果有一块工具，能把结构化数据、日志、文档、音视频、IoT、时空数据，以及 Embedding、标签这类“AI 产物”，统统纳入统一的元数据、血缘、权限和质量框架之中；
那每一次项目做完，企业的数据家底都会实实在在“厚”一截，而不是只多一套 Demo。

第三件事：让智能有机会变成“默认存在”，而不是“偶尔出现”。

所谓“默认存在”，就是：

• 业务习惯了把问题直接抛给一个入口；
• 这个入口背后，能够自动把相关的数据、文档、案例、场景调度起来；
• 智能体给出的结论，可以被追问“为什么”，也可以在事后通过效果数据验证“对不对”。

要做到这一点，底层工具必须天然考虑：模型和智能体不是“外部调用者”，而是它的核心用户之一。
它要提供的不只是数据查询接口，而是一整套为 AI 准备好的特征服务、向量服务、语义检索、算子编排能力。

说到底，企业缺的不是一个“下一代中台”的名字，而是这么一块东西：

能看懂业务问题是多模态的，
能让数据治理变成一件长期有复利的事，
能让 AI 站在它上面，成为日常工作的一部分。

叫“地基”也好，叫“操作系统”也好，本质就是这三件事。

三、顺着这条线往下走，那块地基自然会长成“多模态数据中台”

现在再回头看传统数据中台，它的价值并没有消失，只是边界暴露得越来越清晰。

对结构化世界来说，它做得已经够好：
帮企业把“谁、在哪、做了什么、结果如何”这样的数字，收拢、建模、标准化，形成可被全公司共享的指标体系和分析框架。

问题在于，业务世界已经不只是一堆数字了。

客户在通话里的情绪、工程师在工单里的备注、生产线上某段视频里的异常动作、某个设备在空间里的位置变化、某条路线的拥堵模式……
这些东西，越来越频繁地出现在“关键问题”的证据链条上。

如果企业的地基仍然只为结构化数据设计，那么所有这些多模态线索，要么被挂在附件里，要么孤立在专用平台中，AI 想用，就得一次次“单飞”。

沿着用户的问题继续往下走，能看到一个更清晰的图景：

• 在建模视角上，那块地基必须把“对象、事件、时空关系”当成核心事项，而不是只把表和字段当成世界的基本单元；
• 在治理视角上，它必须同时管理结构化、非结构化、时空数据和 AI 产物，让任何一条智能链路都可以被追溯、被评估；
• 在服务视角上，它必须把模型和智能体视为首要服务对象，提供适合它们的特征、向量、语义与编排能力。

当这些要求放在一起，你自然会得到这样一个结论：
这块地基，长出来的样子，很像一个“多模态数据智能中台”。

它不是简单地“加几种数据源”，而是回答了三个问题：

• 业务问题能不能被完整描述？
• 数据资产能不能持续积累？
• AI 能不能站在这块地基上迭代，而不是每次旁路重造？

名字可以有很多，逻辑只有一个。
从这个意义上讲，多模态数据中台并不是某个厂商的新故事，而是企业在 Data+AI 实践中，被一次次逼出来的共同答案。

四、袋鼠云为什么会走到这一步？

这时候再看袋鼠云，就会发现它的那条路其实并不复杂：
从大数据基础软件起步，先帮企业把结构化的那部分地基打牢；
随着客户在 AI、智能体、数字孪生等业务场景上的需求越来越多，逐渐意识到：
如果底层不能理解多模态，不能为 AI 提供原生的数据供给，再强的上层能力都会显得吃力。

于是，“数栈”开始往多模态方向延展：
一头兼容日志、文档、图像、音视频、IoT、时空数据，把它们纳入统一的元数据和治理框架；
一头与智能指标平台、智能体开发应用平台、空间智能产品家族打通，让智能问数、业务 Agent、数字孪生、空间智能、场景推演这些东西，都能站在同一块地基上生长。

你可以把它看成一个厂商的产品演进；
也可以把它看成，是一批真实项目累积之后，对“那块缺席的地基”做的一次系统回应。

先承认世界是多模态的，再谈怎么做 AI

回头看过去几年，很多企业在 AI 上的挫折感，其实来自一个很简单的错位：

• 业务提出的问题，天然是多模态的；
• 引进的模型，天然能处理多模态；
• 唯独数据基础设施，仍然是“表格世界”的设计。

在这样的前提下，再谈“知识问答”“智能体”“世界模型”，多少都有点“离地”。

所以，也许更现实的顺序是：

先承认业务世界就是多模态的；
再承认现有的数据地基对这件事准备不足；
然后，再思考一块怎样的基础设施，能把这两头重新接起来。

多模态数据中台，恰好是对这三个判断的同一个回答。
它不是终点，只是一块起点——
但如果没有这块起点，后面的 Data+AI，很难真正走得远。