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 才不再只是一个看起来聪明的工具,而会真正成为企业中可信、可成长、可托付的数字员工。

相关文章
|
6天前
|
人工智能 运维 监控
CC Switch路由代理全教程:零代码让Codex CLI兼容DeepSeek等主流大模型
当下命令行AI开发工具Codex CLI凭借脚本生成、代码调试、日志解析、自动化运维等能力,成为大量后端、运维开发者日常刚需。但该工具底层仅原生适配OpenAI Responses API交互协议,而市面上DeepSeek、Kimi、MiniMax、通义千问等绝大多数商用、开源大模型统一采用Chat Completions API标准,两套协议在请求结构、参数字段、流式分片、错误回调、会话管理上完全不互通。开发者直接在Codex CLI填入第三方模型接口地址,会出现404访问失败、参数解析报错、对话流式输出中断、模型列表加载异常等各类故障,极大限制命令行工具的模型选择空间。
160 0
|
1月前
|
存储 人工智能 测试技术
Hermes Agent:深度技术剖析报告
Hermes Agent 是Nous Research于2026年开源的自主AI智能体框架,首创“闭环学习回路”,通过五层记忆系统、自主技能生成(Skill)、辩证式用户建模(Honcho)与FTS5跨会话搜索,解决LLM“失忆症”。MIT许可,Python构建,支持多平台、多模型Provider及MCP双向集成,GitHub星标超1.7万。
760 1
|
1月前
|
人工智能 自然语言处理 API
阿里云百炼大模型服务平台主要模型介绍:文本生成、图像与视频、音频与语音等热门模型与能力简介
阿里云百炼是阿里云推出的一站式大模型开发与应用平台,集成千问(Qwen)全系列及DeepSeek、Kimi、GLM、MiniMax等主流第三方大模型,覆盖文本、图像、音频、视频、向量等多模态能力。开发者可通过OpenAI兼容API直接调用模型,业务人员则可借助可视化工具快速搭建智能体、知识库问答等AI应用,无需自行部署运维。新用户注册开通即可获赠超7000万tokens免费额度,支持从模型体验到应用落地的流程服务,显著降低AI应用开发门槛。
|
1月前
|
人工智能 数据挖掘 BI
本体论 vs 语义层:两种 AI 业务语义底座的区别、场景与建设路径
本体论和语义层并不是互斥关系,也不是简单的“谁替代谁”。本体论表达了企业 AI 的高阶目标,语义层提供了多数企业更容易落地的起点。
|
3月前
|
人工智能 语音技术 开发工具
AI电影解说:基于narrator-ai-cli与 Skill工作流深度实操与解读
本文详解如何用开源命令行工具 `narrator-ai-cli` 与 `narrator-ai-cli-skill`,构建本地优先、Agent 驱动的电影解说工作流:从零安装、配置、单条出片,到接入小龙虾/ Windsurf 等 Agent,支持爆款风格学习、TTS停顿控制、语音克隆及团队配额管理——全程不上传原片,兼顾隐私、效率与可控性。(239字)
|
3月前
|
人工智能 自然语言处理 文字识别
《别再把QClaw当聊天AI用了!Skills才是它真正的灵魂》
本文从真实使用体验出发,深度解析QClaw中Skills技能的本质价值,指出其并非普通插件,而是与核心引擎深度融合的执行单元,是让AI从“聊天”走向“实干”的关键。文章详细说明第三方技能的安装、导入、启用与管理方法,强调安全筛选、合理精简、按需配置的重要性,并结合办公、文档处理、自动化工作流等真实场景,讲解技能自动调用、指定调用与组合串联的实用思路。全文侧重技术思考与高效实践,帮助读者真正用好技能生态,大幅提升AI执行效率与工作生产力。
630 1
|
4月前
|
机器学习/深度学习 传感器 算法
锂离子电池二阶RC参数辨识(HPPC工况)、递推贝叶斯算法(RB),可替换数据 附Matlab代码
🌿 往期回顾可以关注主页,点击搜索 智能优化算法 神经网络预测 雷达通信 无线传感器 电力系统 信号处理 图像处理 路径规划 元胞自动机 无人机 物理应用 机器学习系列 车间调度系列 滤波跟踪系列 数据分析系列 图像处理系列 ✅作者简介:热爱科研的Matlab仿真开发者,擅长毕业设计辅导、数学建模、数据处理、建模仿真、程序设计、完整代码获取、论文复现及科研仿真。 🍎 往期回顾关注个人主页:
419 10
|
4月前
|
容灾 关系型数据库 MySQL
从 0 到 1 落地异地多活:单元化、数据同步与流量调度的核心壁垒全击穿
本文系统阐述异地多活架构核心实践:定义其为跨地域对等单元、独立闭环、秒级容灾的高可用方案;详解单元化设计三大原则(数据封闭、单元对等、路由一致);剖析数据同步(Canal+MQ为主)与流量调度(GSLB+路由校验)关键技术;并提供ID生成、分片策略及落地避坑指南。
460 2
|
3月前
|
自然语言处理 安全 调度
《吃透QClaw原生运行逻辑:解决指令无响应、权限阻塞、上下文断层的独家实操避坑指南》
本文针对QClaw使用中高频出现的指令无响应、执行中断、多轮上下文断层等核心痛点,基于作者近半年的深度实践与反复验证,跳出“优化指令、更换模型”的常规误区,拆解了QClaw指令流转全链路、双轨权限模型、任务型上下文生命周期的底层设计逻辑,精准定位了表层异常背后的认知错位根源。文章同步给出适配原生逻辑的指令拆解、权限边界测绘、上下文锚定等可落地方案,核心传递“理解工具底层逻辑优先于技巧堆砌”的实践思路。
453 0