在上一篇文章中，我们已经从整体架构的角度，梳理了企业级 AI 落地的一条核心链路：

数仓 / 数据库 → 搜索与 RAG → Workflow / Agent

并明确了一个前提事实：

模型能否应用，不取决于模型本身，而取决于数据是否真正进入了模型的执行链路。

这篇文章我们继续向前推进，聚焦真实落地场景：

在 AI 加持的新一代数仓体系下，RAG + Workflow / Agent 在真实企业环境中，究竟是如何跑起来的？

下图为完整运行链路：

数据在数仓中完成 AI 化处理后，通过搜索与 RAG 转译为模型可理解的上下文，再由 Workflow 编排为可执行的 Agent 流程，支撑真实业务场景运行。

一、当数据开始直接参与模型使用

当 LLM 成为新的“数据使用者”后，传统以 SQL、报表和指标为中心的数据使用方式，已经无法直接适配模型需求。

这一变化在实际工程实践中已经显现，本篇不再重复展开。

接下来更值得讨论的，是在真实系统中如何一步步把这件事做出来：

如何让数据以模型可用的方式被处理、被检索，并最终参与任务执行？

从这一刻开始，问题已经从“为什么”转向了“怎么做”。

二、AI 加持下的数仓：从分析引擎到 AI 数据底座

在真实企业环境中，RAG 和 Agent 从来不是从零开始构建的，它们往往建立在成熟的数据底座之上。

例如基于MaxCompute 的计算引擎平台，担任着企业数仓 / 数据底座的角色：

• 汇聚来自业务系统、日志系统、外部数据源的数据
• 通过 ODS / DWD / DWS 分层，统一口径与版本
• 在大规模数据集上提供稳定的计算与分析能力

不同的是，在 AI 场景下，数仓不再只是“分析终点”。

通过 MaxCompute AI Function 等能力，AI 开始直接参与数据处理过程：

• 在 SQL 流程中完成文本理解、分类、标签生成
• 在数据建模阶段引入语义信息与智能特征
• 在大规模数据集上进行智能处理，而无需离开熟悉的 SQL 环境

传统数仓的形态已经发生改变：

数仓开始从“分析引擎”演进为“AI 数据底座”，成为 AI 能力的起点，而不是终点。

三、搜索工程前移：为模型构建稳定的“数据入口”

当数仓开始演进为 AI 数据底座后，模型并不能直接使用数仓中的数据。

在真实业务场景中，无论是表结构，还是 SQL 结果集，本质上仍然都是以人理解为导向。

模型真正需要的，是一个可控、可筛选、可追溯的数据入口。

这也是为什么，在企业级 AI 架构中，搜索系统承担着连接数仓与模型的“数据入口层”角色。

在这一层，AI搜索（OpenSearch / Elasticsearch） 扮演的是：

• 数仓数据的可检索化出口
• 非结构化与半结构化数据的统一入口
• 模型可控访问数据的第一道关口

与传统“面向用户搜索”不同，这里的搜索设计，目标不再是“搜索体验”，而是：

• 召回是否稳定
• 命中是否可解释
• 结果是否可追溯

也正是在这一阶段，搜索工程开始明显前移，成为 AI 系统中不可或缺的一环。

四、搜索/RAG 落地后的第一个工程瓶颈：上下文开始“失控”

当搜索与 RAG 真正进入生产环境后，很快出现系统不是“答不出来”，而是“越来越不稳定”的问题。

这并不是模型能力问题，而是 RAG 在工程层面开始暴露出新的瓶颈：

• 同一个问题，不同时间命中不同上下文
• 上下文内容逐渐变长，token 成本不可控
• 数据来源混杂，结果难以复核

这意味着，RAG 在生产环境中面对的，已经不再是“能不能检索到数据”，而是：如何长期、稳定、可控地构建模型上下文。

因此，在这一阶段，RAG 的工程重心自然发生转移：

• 从“拼接检索结果”
• 转向“上下文生命周期管理”

包括但不限于：

• 上下文长度控制与裁剪策略
• 多来源数据的合并与优先级
• 版本与来源的显式约束
• 不同业务场景的上下文模板化

这一层的复杂度，已经明显高于单纯的检索工程，也直接决定了系统是否具备长期运行能力。

五、从 RAG 失控到流程化治理：Workflow/ Agent 是如何被“逼”出来的？

当 RAG 在生产环境中开始暴露出上下文不稳定、结果不可复核等问题时，一个现实情况出现：

单次调用层面的优化，已经不足以解决系统级的不稳定。

在初期实践中，尝试通过以下方式解决问题：

• 调整检索参数（BM25权重等）
• 优化 prompt
• 增加过滤条件（位置/行业等过滤项）

但无法从根本上解决多步骤调用之间的上下文失控、不同阶段使用不同数据口径以及中间结果无法被复用或审计等问题。

也正是在这一阶段，Workflow 的价值开始显现。Workflow 并不是为了“多跑几步”，而是为了把原本隐式的模型调用过程，显式拆解为一组可控的执行步骤：

• 第一步做什么检索
• 使用哪一类数据
• 中间结果是否需要固化
• 是否基于结果决定下一步

在工程实践中，这意味着：

• RAG 不再是一次性行为，而是被嵌入到流程节点中
• 上下文不再自由增长，而是受流程边界约束
• 模型调用开始具备明确的输入、输出与阶段划分

也正是通过这种方式，Agent 才真正“跑”了起来——不是作为一个“更聪明的模型”，而是作为一个遵循流程约束的执行体。

五、Workflow / Agent 跑起来之后，数据系统被“反向要求”什么？

当 Workflow / Agent 真正开始跑业务任务时，会出现另一个变化：数据系统开始被执行链路反向约束。

在 Agent 场景中，数据不再只是“被查一次”，而是：

• 在同一任务中被多次调用
• 作为条件判断的依据
• 决定任务是否继续或终止

这对数据系统提出了一些过去并不显性的要求：

• 数据接口是否具备幂等性
• 同一查询在任务周期内是否结果一致
• 数据版本是否明确、可冻结
• 数据调用是否具备权限与范围控制

也正是在这一阶段，Workflow 才真正显现出它的工程价值：它不是让模型“更聪明”，而是让数据调用变得可控。

从业务视角看，Agent 并不是替代原有数据系统，而是将原本“隐式”的数据使用方式，显式地组织为可审计、可复现的执行流程。

这些被 Agent 多次调用、参与决策的数据，是否还适合和分析型数据放在同一套数仓模型中？

当数据开始服务于执行而非仅用于分析，传统数仓的使用方式，以及传统数据开发的工程范式，或许都需要重新审视。

下一篇文章，我会就从这个问题出发，继续展开讨论～

欢迎点赞、关注、转发，大家的支持是我更新的最大动力。

另外感兴趣的小伙伴可关注我的微信公众号：小友数研，将为大家分享更多 Data + AI 的实战。