Data Agent 落地的下半场:让企业学会与 AI 协作

简介: Data Agent 落地的上半场,是建设 AI-Ready Data;下半场,是建设 Agent-Ready Organization。上半场决定 Agent 能不能进入企业,下半场决定 Agent 能不能真正融入工作、形成规模,并持续创造价值。

过去一年多,围绕 DataAgent,我们经常讨论一个问题:怎么让大模型懂大数据,让 AI 听得懂企业问题?

大模型懂自然语言,但不天然理解企业的大数据体系。一个人在问题中提到"收入""活跃客户"或者"高价值商品",大模型能够理解这些词的通常含义,却不知道它们在这家企业中的准确口径,更不知道背后对应哪些数据、计算逻辑和业务规则。

所以,我们一直强调语义层、知识库,强调 Trusted Context。它们要解决的,都是如何把企业的数据、业务语言和经验,转化成 AI 可以理解和执行的企业上下文。

但最近,随着我们的 Data Agent 产品在一些企业真正上线并开始被业务人员使用,我越来越明显地感受到一个新的问题已经出现。

过去,我们担心的是 AI 不懂员工、不懂企业;现在,我们开始需要面对另外一个问题:企业中的员工,是否已经学会如何与 AI 协作?

如果把 Data Agent 的企业落地分成上下半场,上半场是让 AI 读懂企业,下半场则是让企业学会与 AI 协作。

我这里说进入下半场,并不意味着语义层、Trusted Context 的问题已经解决。恰恰相反,正是因为这些能力开始进入真实工作,过去隐藏在技术后面的组织问题才第一次变得清晰。

01 "答案不对",究竟是谁的问题?

最近,我们在与一家大型零售企业合作时,客户从真实工作中整理了一批业务问题,用来测试 Data Agent。

测试结束以后,业务人员认为其中很多回答"不正确"。如果只看测试结果,很容易得出结论:Agent 还不够聪明,很多问题答不出来。

但双方项目团队把这些问题逐条复盘以后,发现事情没有这么简单。例如,有一类问题可以被抽象成:

今年某次重点营销活动中,哪个产品系列增长最好?

这个问题听起来很清楚。但真正开始分析时,会发现里面隐藏了大量没有被表达出来的信息:活动的起止时间是什么?应该与去年同期比较,还是与上一次活动比较?"增长最好"指销售额、销量还是购买人数?比较的是增长金额还是增长率?产品系列又应该按照企业内部哪套口径分类?

如果接收任务的是一位有经验的数据分析师,他通常不会马上开始取数,而是会先沟通和追问。他可能知道公司默认使用哪套财年日历,也可能了解业务部门平时如何定义"增长最好";如果仍然不确定,他会继续确认,直到双方明确要完成的是同一项任务。

人与人之间的协作,本来就包含大量主动询问、背景判断和相互学习。很多没有说出来的信息,会被经验、组织常识和持续互动补充完整。

但当同样的问题被交给 Data Agent 时,双方的行为都变了。

业务人员容易把 AI 当成一个无所不能的"许愿机"。既然 AI 看起来什么都懂,那么我只要说出一句话,它就应该知道我真正想要什么。把潜意识中的背景、约束和判断标准完整表达出来,本身是有成本的,人天然倾向于省略这些信息。

与此同时,今天的很多 Agent 也急于回答。它可能自主判断选择一个时间范围,自动把销售额理解成"增长",再自动使用一套产品分类。等结果出来以后,业务人员才发现,这不是自己想要的答案。

一个没有完全说清楚,另一个没有进一步问清楚,双方却都认为任务已经明确。这可能才是很多"答案不对"的真实来源。

从项目复盘看,这些问题里既有查询路径不一致等明确的产品问题,也有企业知识和指标口径没有沉淀的问题,还有相当一部分是任务本身存在歧义,但用户和 Agent 没有通过互动完成确认。

它们最后都会被归结为一句话:"Agent 答错了。"但从落地角度看,这是性质完全不同的几类问题。

AI 能力越强,人们越容易高估它对隐性上下文的理解能力。Data Agent 进入企业以后,首先需要打破的,可能正是"AI 应该天然懂我"的预期。

02 能用、敢用之后,企业还要解决"会用"

最近与一位大型跨国企业 CIO 交流时,我们把 Data Agent 的用户侧挑战概括成三个层次:能用、敢用和会用。

能用,是 Data Agent 能不能真正交付任务价值。它需要理解企业语言,找到正确的数据,并按照正确的业务逻辑完成分析。这里的主要瓶颈在 Context,背后是语义、知识和数据能力。

敢用,是用户能不能信任并采纳 Agent 的结果。企业数据分析不能只给出一个看起来合理的答案,还要能够展示任务链和数据链,做到可复现、可追溯、可审计。这需要 Agent 在产品上具备可信能力。

会用,则是人和 Agent 能不能形成有效互动。用户要逐渐理解 Agent 的能力边界,知道如何提出任务、补充背景和验收结果;Agent 也要能够主动反问,在工作中学习企业的规则和偏好,做到边干边问、边问边学、一学就会。

过去,我们更多讨论的是 Data Agent 能不能用、企业敢不敢用。随着产品进入真实业务,"会不会用"开始成为新的瓶颈。

这不能被简单理解成用户不会写 Prompt。员工不需要理解模型原理,也没有必要都成为 Prompt 工程师。模型会继续进步,很多提示词技巧也会被产品逐步吸收。企业真正需要建立的,是人与数字员工之间新的协作认知和工作习惯。

同样,"会用"也不能全部成为用户的责任。未来优秀的 Data Agent 不能只是更快地给出答案,还应该更善于发现歧义、主动澄清和持续学习。越成熟的产品,越应该替用户承担更多协作成本。

但无论产品多聪明,一个数字员工进入一家企业,也仍然需要了解这家企业的语言、规则和工作方式。产品侧要建设可信、可成长的 Agent,企业侧要持续建设和维护企业上下文,并做好用户预期管理和使用运营。

因此,Data Agent 进入企业,不只是一次软件上线,也是一个数字员工逐步融入组织的过程。

03 从 0 到 1、从 1 到 10,不能操之过急

类似的事情,在企业数字化转型过程中已经发生过一次。

Tableau、Power BI、Looker 等敏捷 BI 工具出现后,越来越多的数据分析能力被交到业务人员手中,企业也随之提出"人人都是数据分析师"、"企业数字公民"和"数据文化"等理念。

但工具变得容易使用,并不意味着所有员工自然就会使用数据。

过去一些数据文化建设做得好的企业,不只是采购工具和开展培训,还会组织数据分析竞赛、评选优秀案例、培养内部数据达人,通过激励和招聘强化数据能力,并逐渐把"用数据说话"变成组织能力的一部分。

也有一些企业采购了工具、开通了账号、完成了培训,但数据分析仍然停留在少数专业人员手中。数据文化从来不是通过一堂工具培训课建立起来的,Agent 协作文化同样不会通过一堂 Prompt 课程自然产生。

企业在推广 Data Agent 时,需要首先接受一个现实:圈定一批员工,并不意味着这些员工都能够很快形成稳定、规模化的使用习惯。

任何一项新技术进入组织,都一定会先由少数人真正掌握。这些人可能更愿意尝试,更善于表达问题也更能够从结果中总结方法。当他们在真实任务中获得明确效果以后,就会成为企业内部最早的 KOL。

这是 Data Agent 从 0 到 1 的关键。不是先追求覆盖多少人,而是先找到一批合适的人和任务,让他们真正把 Agent 用起来,形成可验证、可复用的成功案例。

从 1 到 10,则需要让这些 KOL 带动更多员工。企业可以通过培训、案例分享、竞赛评选和激励机制逐步扩散,但这个过程需要时间,不能简单地按照账号开通数量和短期活跃度强行推进。

对于企业级 Data Agent 厂商而言,责任也不能停留在交付产品和完成技术上线。

厂商能不能帮助客户找到合适的首批任务,陪伴首批用户跑通工作闭环,培养内部 KOL,再把成功经验从 0 到 1、从 1 到 10 地复制出去,会成为 Data Agent 落地能力的重要组成部分。

这不是产品之外可有可无的服务,而是企业级 Data Agent 厂商的一项核心能力,也应该成为甲方评价和选择厂商的重要标准。

04 从 AI-Ready Data 走向 Agent-Ready Organization

企业数字化转型解决的是人如何更好地使用数据,企业 AI 转型进一步要解决的是如何组织员工与智能体共同工作。

如果说敏捷 BI 时代的愿景是"人人都是数据分析师",那么 Data Agent 时代的愿景可能是"人人都有一位数字分析师"。但拥有一位数字分析师,并不等于已经具备与这位数字分析师协作的能力。

过去,我们通过语义层、知识库,让 AI 读懂企业;接下来,企业还需要通过新的协作方式、组织运营和组织文化,让员工学会与 AI 共同工作。

Data Agent 落地的上半场,是建设 AI-Ready Data;下半场,是建设 Agent-Ready Organization。上半场决定 Agent 能不能进入企业,下半场决定 Agent 能不能真正融入工作、形成规模,并持续创造价值。

只有当技术和组织两方面同时准备好,Data Agent 才不再只是一个看起来聪明的工具,而会真正成为企业中可信、可成长、可托付的数字员工。

相关文章
|
22天前
|
SQL 存储 人工智能
Ossie ,会不会成为“开源 Palantir”的起点?
如果企业未来确实需要走向本体论,语义层很可能不是一个迟早要被替换掉的过渡方案,而是一条更现实的建设起点。
|
5月前
|
SQL 人工智能 自然语言处理
|
14天前
|
人工智能
日志查询如何避免同名记录混淆 0915
讨论“日志查询如何避免同名记录混淆”,重点不是增加记录数量,而是让下一次使用资料的人能够看懂这条记录解决了什么问题。下面从问题范围、过程依据和结果复核三个方面整理方法。这份笔记由AI辅助撰写,配图为自制示意图。
日志查询如何避免同名记录混淆 0915
|
5天前
|
存储 弹性计算 固态存储
阿里云服务器多少钱一年?轻量200M带宽38元/年、ECS服务器99元/年、2核4G5M带宽199元/年
本文详解2026年阿里云服务器最新价格:轻量应用服务器200M带宽仅38元/年,ECS经济型99元/年,企业级2核4G+5M带宽199元/年;涵盖包年包月、按量付费、抢占式实例三种计费模式,并解析ECS实例规格、带宽及系统盘详细收费标准。(239字)
|
27天前
|
数据采集 Web App开发 人工智能
6大AI引擎引用偏好实测:从45条数据看平台分发机制差异
本文基于2026年Q1对六款主流AI引擎的引用源实测,揭示其平台分发偏好差异:豆包偏爱CSDN(34%)、今日头条;DeepSeek聚焦技术社区;Kimi倾向财经媒体;秘塔专注学术源。提出可复现的“平台地图绘制法”与分平台内容适配公式,并强调AI发现依赖平台推荐算法,需60–90天内容积累期,且须坚守真实性底线。
229 1
|
26天前
|
人工智能 NoSQL 定位技术
Palantir 爆火后,为什么 AI Agent 落地绕不开「本体论」?
Palantir 爆火后,「本体论」被反复提及,却常被误读成替代信息化、甚至等同于 Agent。本文用「阿杰+老陈」双视角讲清:本体论本质是连接 Agent 与企业知识库/业务系统的一座桥,对 IT 人而言,它就是 DDD 及业务规则的沉淀方法论。还剖析了 Palantir 为何自带本体论实施工具,以及国内复刻者稀少时,企业 IT 如何用自己的方式吃透核心概念落地。
210 0
|
2月前
|
SQL NoSQL Java
团队暂时没有条件部署 SkyWalking
本文详解APM链路追踪核心实践:先定位慢在哪一跳。通过SkyWalking开箱即用方案(Java零侵入Agent接入)或自研轻量方案(MDC+AOP日志埋点),快速生成耗时瀑布图,将3.2秒慢请求精准定位至2.35秒SQL,大幅提升性能排查效率。(239字)
191 1
|
2月前
|
人工智能 搜索推荐 知识图谱
2026 GEO实战指南:让AI搜索引擎正确引用你的技术文章
GEO(生成式引擎优化)是面向LLM检索-推理-生成链路的信息组织工程,聚焦语义分块、结构化数据(Schema)、引用可信度与实体关系构建,提升内容在AI搜索引擎中的召回率与引用率,非SEO替代品,而是机器可读性的新基础设施。
391 1
|
2月前
|
SQL 自然语言处理 安全
怎样的 PoC,才能支撑分析 Agent 的采购决策?
PoC 的核心不是“考供应商”,而是一场严谨的“采购决策实验”。
|
2月前
|
SQL JSON 运维
一条SQL同时处理结构化条件和非结构化语义匹配。
本文对比智能客服场景下向量检索的两种架构:独立向量库 vs 内置向量的关系型数据库。结合5万知识库、日增数百条、QPS 20+的实际需求,剖析二者在数据一致性、运维成本、查询性能与扩展性上的真实差异,指出多数创业团队无需“为技术而技术”,关系库向量化已足够成熟可靠。(239字)
163 0