大模型买了，Agent 搭了，为什么业务还是没变化

本文发表于： &{ new Date(1783526400000).toLocaleDateString() }

40% 的 Agent 项目正在被悄悄叫停

Gartner 在 2026 年初给出过一个判断，让很多人不太好受：到 2027 年，全球将有超过 40% 的企业级 AI Agent 项目被取消或无限期搁置。

事实上，很多企业已经采购了大模型 API，搭建了 Agent 框架，也做了内部演示，却在推向真实业务的那一刻，项目陷入停滞。

问题出在哪里？是模型不够强？是开发团队能力不足？还是企业数字化基础太差？

我们过去一年和不少企业聊下来，看到的情况很接近：模型层的投入走得很快，数据层和系统层的建设跟得慢，项目一进真实环境，问题就会集中冒出来。

演示跑得很好，一到生产环境就开始掉链子

大多数企业在推进 AI 落地时，会依次遭遇以下五种落差：

第一，LLM 幻觉。 大模型天然具有“创造性”，这既是它的能力，也是它的风险。当模型找不到足够准确的上下文时，它不会告诉你“我不知道”，而是生成一个听起来合理但完全错误的答案。在客服、合规、财务分析等对准确性高度敏感的场景下，这种幻觉是致命的。

第二，自然语言查询口径不可信。 用户问“上个月的销售额是多少”，这句话里藏着无数歧义：是哪个口径的销售额？是下单金额还是收款金额？是全渠道还是线上渠道？口径没有统一，模型生成的 SQL 就算语法正确，结果也是错的。不同部门对同一指标的理解不同，这不是模型问题，是元数据治理问题。

第三，Agent 执行无法落地。 Agent 在测试环境里表现出色，但连接真实系统时，数据接口不通、权限未授权、数据格式不匹配……每一个细节都可能让整条链路断掉。很多 Agent 项目死在从 PoC到生产环境的最后一公里。

第四，数据孤岛导致天级延迟。 企业数据分散在数十个系统里：ERP、CRM、业务数据库、日志平台……数据整合需要几十个 ETL 任务，跑完一遍要半天到一天。当用户问“今天上午的订单转化率是多少”，系统给出的却是昨天的数据，这类系统本质上还是查询系统，只是多了自然语言入口。

第五，并发压力门槛。 演示环境里数据规模小、查询并发低、业务逻辑简单。但真实的生产环境里，一次 Agent 请求背后可能触发几十到上百次数据查询，任何一个环节的性能瓶颈都会让整个链路崩溃。

三个误区，正在消耗你的 AI 预算

在上述落差背后，存在三个系统性认知误区：

误区一：有大模型 = 有 AI 能力。

大模型是推理引擎，不是数据系统。它能理解语言、生成文字、构建逻辑，但它本身不存储数据、不保证数据一致性、不提供实时查询。把大模型直接接到业务系统上，就像给汽车装了一个智能导航，但路本身不存在——方向盘转得再好也没用。

误区二：最强的模型 = 解决业务问题。

很多团队习惯性地用最新、最贵的模型做 benchmark，却发现业务结果并没有随着模型升级而改善。原因在于，制约业务效果的不是模型推理能力，而是模型能拿到的上下文质量——也就是数据本身的准确性、时效性、覆盖度。喂给模型的是脏数据，再聪明的模型也给不出正确答案。

误区三：工具强 = 不需要数据能力。

Agent 框架、向量数据库、RAG 管道……这些工具本身没有问题，但它们是在假设“底层数据已经就绪”的前提下工作的。数据工程、数据治理、元数据管理，这些听起来“旧”的能力，恰恰是 AI 落地不可绕过的前提。

模型之外，还有三层基础工作

要理解 AI 落地的完整架构，可以用人体打个比方。

大模型是大脑，负责理解、推理、决策。它处理输入的信息，生成响应。这是大多数企业唯一投入的地方。

Data Platform（数据平台）是生命支持系统，对应人体的循环系统（数据流通）、神经系统（数据传导）、免疫系统（数据安全与治理）和代谢系统（数据更新与清洗）。没有这套系统，大脑再强也无法运转——没有血液供氧，神经无法传导信号。

Agent 是四肢，负责执行具体动作：调用 API、查询数据库、触发业务流程。四肢的动作能否精准执行，取决于大脑和神经系统的协调。

Knowledge（知识）是记忆，包括企业的历史数据、业务规则、领域经验、用户偏好。没有记忆，每次对话都是“失忆”的重新开始，无法积累业务认知。

这四个要素缺一不可。而当前大多数企业的 AI 投入，90% 集中在“大脑”上，其余三个要素几乎是空白。

在这里，有一个值得重视的概念：Context Rot（上下文腐烂）。当数据延迟、口径不一、知识库过时时，模型接收到的上下文是“腐烂”的——表面上信息完整，但已经失去了业务价值。Context Rot 是大多数 AI 项目效果差的根本原因，却很少被识别出来。

传统数仓为什么撑不住 AI 时代

很多企业的第一反应是：把现有数仓接上大模型不就行了吗？

传统数仓的设计假设与 AI 时代的需求落地之间，通常会遇到六类问题：

一、链路冗长，T+1 延迟成为常态。 

数据从业务系统到可查询状态，往往需要经历采集、清洗、建模、聚合等多道 ETL 流程。T+1（即今天的数据明天才能查）已经是最优情况，更多时候是 T+几小时。AI Agent 需要的是实时或准实时数据，T+1 的数仓无法支撑这类需求。

二、人工建模迭代慢，无法响应灵活需求。 

传统数仓里，每新增一个分析维度，都需要数据工程师介入、建模、上线，周期以周计算。但 AI 时代，业务用户的查询需求是即时的、随机的、高度个性化的——固定的数据模型无法支撑这种灵活性。

三、元数据口径分散，无法构建可信的语义层。

同一个“销售额”，在不同业务系统、不同团队的定义可能截然不同。当自然语言查询被转化为 SQL 时，这些歧义会被放大，导致结果不可信。

四、能力与 AI 割裂，向量检索和全文搜索需要另建系统。

AI 应用普遍需要向量相似度检索（用于 RAG、语义搜索）和全文检索，而传统数仓完全不具备这类能力，企业只能另外引入向量数据库和搜索引擎，系统复杂度急剧上升。

五、固定报表模式无法满足 Ad-hoc（即席）查询需求。

传统数仓为固定报表优化，查询模式相对固定。但 AI 时代的用户会用自然语言提出千变万化的问题，每一个都可能是全新的查询模式，传统数仓的性能模型无法应对。

六、Agent 并发压力剧增。 

用户通过自然语言向 Agent 发起一个看似简单的请求，背后可能触发几十到上百次数据查询——召回上下文、查历史记录、验证业务规则、生成报告……这种并发压力是传统数仓从未设计过的。

新七层架构：为 AI 时代重建数据基础

解法是什么？我们在实践里跑出来了一套七层架构。在传统数仓的数据采集、存储计算、数据治理、数据服务、应用层五层架构上，补齐三层 AI 相关能力：

第五层：Knowledge & Memory 层。

这是 AI 系统的“记忆中枢”。知识体系包含四个维度：结构化数据知识（数据字典、指标口径）、非结构化文档知识（产品手册、政策文件）、图谱知识（业务实体关系）和向量化知识（用于语义检索）。记忆体系同样分为四类：工作记忆（当前对话上下文）、情节记忆（历史交互记录）、语义记忆（业务规则和领域知识）和程序记忆（可复用的操作流程）。

这一层的核心作用是解决 Context Rot 问题——确保模型每次推理时拿到的上下文是新鲜的、准确的、有业务意义的。

第六层：Data Agent 层。

这一层是数据系统与 AI 能力之间的“翻译官”。包含六类专项 Agent：元数据 Agent（负责理解数据结构和口径）、查询生成 Agent（将自然语言转为准确的 SQL）、数据质量 Agent（实时监控数据异常）、数据血缘 Agent（追踪数据来源和变更）、优化 Agent（自动调优查询性能）和监控 Agent（系统健康状态管理）。

第七层：User Agent 层。

这是面向最终用户的交互层，支持自然语言对话、ChatBI 自助分析、报告自动生成，以及与业务流程的深度融合——将数据分析能力直接嵌入业务系统，而不是独立的分析工具。

安全与治理贯穿全程。 从数据采集到用户交互，每一层都需要统一的权限管理、数据脱敏、操作审计和合规控制。AI 时代的数据治理比以往更复杂，因为 Agent 的自主性引入了传统系统从未面对的权限边界问题。

从真实项目探索理论到落地实践

案例一：某城商行——从“查不了”到“随时查”

该行核心问题是数据口径混乱。全行有超过 30 个业务系统，每个系统对“存款余额”“不良率”等核心指标的定义各不相同，导致各部门报数经常打架。数据分析师的大量时间用于对数口径，而非真正的分析工作。

我们的切入点是构建统一语义层：将全行核心指标的口径定义集中管理，所有查询通过统一的语义接口转换，确保无论用什么表达方式，最终执行的都是同一套业务逻辑。在此基础上接入 ChatBI 能力，业务人员可以用自然语言直接查询数据。

结果： ChatBI 自助分析覆盖率从不足 20% 提升至超过 80%；取数响应时间从天级缩短至分钟级；数据分析师从对口径的工作中解放，转向更高价值的分析任务。

案例二：某 ERP SaaS 厂商——从复杂拼接到一体化引擎

该公司原有数据架构典型地反映了“工具堆砌”问题：实时流处理用 Flink，批量计算用 Spark，OLAP 查询用 ClickHouse，全文检索用 Elasticsearch，向量检索另建独立服务……4 到 6 个组件各司其职，但联动困难、运维成本极高，数据从产生到可查询要经过多道管道，延迟最长达到天级。

通过引入一体化实时 OLAP 引擎，将多个系统的功能整合为统一的存储计算层，原生支持向量检索、全文检索、结构化查询，并直接对接实时数据流。

结果： 替代了原有 4 到 6 个独立组件；数据延迟从天级降至秒级；系统运维成本降低约 50%；同时为后续 AI Agent 的接入提供了统一的数据访问层。

案例三：StarRocks 内置自治运维 Agent——让数据库“管好自己”

这是我们在自身产品中的落地实践。数据库运维是高度专业、高度重复的工作，传统模式下，一旦发生性能问题，DBA 需要登录系统、排查日志、分析执行计划、手动调优，MTTR（平均故障修复时间）以小时计。

我们在 StarRocks 中内置了三类自治运维 Agent：Assistant Agent 负责日常 SQL 问答和操作指导，让开发人员不再需要查文档；Table Optimization Agent 持续监控表的访问模式，自动执行分区优化、索引调整等维护任务；AI Copilot MCP 支持通过自然语言直接发起运维操作，并在 MCP（Model Context Protocol）框架下与主流 AI 开发工具集成。

结果： MTTR 从小时级降至 10 分钟以内；DBA 在例行运维上的工作量降低约 70%；性能问题的识别和处置从被动响应转变为主动预防。

推进 AI 项目，可以先从这几步开始

如果现在开始做，可以先分三个阶段推进。

短期（3 到 6 个月）：夯实数据底座。

重点任务是盘点现有数据资产，识别核心业务数据的质量问题；建立统一语义层，收敛指标口径；评估现有数据平台是否具备实时能力和 AI 集成能力。这个阶段的目标不是上线 AI 功能，而是把地基打稳。

中期（6 到 12 个月）：选点突破，Agent 落地速赢。

选择 1 到 2 个高价值、高痛点的业务场景，完整走通从数据到 Agent 到用户的链路。成功案例会建立内部信心，失败案例会暴露真实问题——两者都是宝贵的资产。这个阶段的关键指标是：Agent 的答案是否可信，用户是否真的在用，业务流程是否真的改变了。

长期（1 到 3 年）：全面赋能，构建 AI 数据资产。

将数据平台升级为 AI-Ready 的统一基础设施，逐步覆盖更多业务场景，构建企业专属的知识图谱和业务智能层。这个阶段的价值不仅是效率提升，更是数据资产的积累——这些资产会成为企业在 AI 时代的核心竞争壁垒。

ROI 参考： 根据已落地项目的实测数据，典型的提升区间包括：计算资源利用率提升 40% 以上（得益于查询优化和工作负载管理），人力投入降低 50% 以上（数据工程和运维层面），需求响应速度从周级提升至分钟级。

数据能力，是 AI 项目的地基

2026 年，AI 不缺热度，不缺资本，不缺工具。真正稀缺的，是能让 AI 真正运转起来的数据基础。

大模型是推理能力，Agent 是执行能力，而数据平台是两者之间的连接器。忽视这个连接器，投入再多在模型和框架上，最终也只能停留在演示阶段。

那些已经在 AI 落地上取得真实业务成果的企业，共同点不是用了最新的模型，而是在数据工程、数据治理、实时能力上提前做了扎实的投资。这些工作不显眼，但决定项目能不能走到生产环境。

如果你正在经历上述的困境，不妨先回头看一看：你的数据基础，真的 AI-Ready 了吗？