从数据工程到模型部署，腾讯云 DataBuddy 如何让 Agent 进入数据工作流？

由此延伸出三个更深层的问题：数据质量跟不上，模型能力怎样兑现为业务价值？数据平台与 AI 平台为何长期各自运行、反复搬运数据？当工具越来越强，为什么工程师、分析师和算法专家仍在承担大量机械性工作？

此次腾讯云发布的 DataBuddy，是继 CodeBuddy、WorkBuddy 之后推出的又一款 Buddy 产品，定位为 Agent Native 大数据智能体工作台。它的关注点已不止于自然语言问数或 SQL 生成，而是让 Agent 参与数据工程、数据治理、数据分析和模型开发，并通过一条完整的电商业务链路，展示这些能力如何进入同一套工作流。

让 Agent 进入平台，而不只是给数据平台加一个助手

David 在开场中反复提到“原生”。传统数据平台通过不断增加采集、存储、计算、开发、治理和报表模块，形成了较为完整的工具体系，操作链路也随之变长。大模型兴起后，部分平台在外围增加智能助手，帮助用户写代码、查数据；但助手能否理解企业的业务定义、访问真实数据资产，并进一步调度底层任务，仍是落地中的难点。

DataBuddy 选择将 Agent 纳入平台的任务执行过程。用户提出目标后，Agent 先结合已有数据资产理解需求、制定实施方案，再调用开发、治理、分析或模型相关能力推进工作。遇到需要专业判断的步骤，仍可回到 Studio、Notebook 或图形化界面检查、修改；生成的代码与任务资产也对使用者开放。

从产品架构看，DataBuddy 将存储计算底座、统一的 Data+AI 平台和 Agent 交互层组织为三个层次。数据处理与模型开发不再完全依赖两套相互割裂的系统；在上层，用户既可以通过自然语言交付任务，也能进入熟悉的开发界面自行处理。Agent 因而不只是对话入口，还承担了串联平台能力的工作。

变化首先发生在工作流的组织方式上。以经营分析为例，过去通常要先由工程师准备数据，再由分析师定义指标、制作报表，必要时还要转给算法团队开发模型。DataBuddy 希望让 Agent 顺着这些环节持续执行，将业务规则的确定、关键节点的审批以及最终结果的判断留给人。

这并不意味着企业必须先迁移全部数据。David 特别提到，DataBuddy 可以基于既有数据引擎提供部分语义与分析能力；需要完整的数据工程和模型开发链路时，再考虑使用统一存算底座。这两种接入方式的能力边界，在分享后半段得到了进一步说明。

三类专项 Agent 与数据科学平台能力，分别承担数据团队的哪些工作？

随后，齐芳芳将 DataBuddy 的能力拆解为三类专项 Agent：数据工程、数据治理和数据分析，以及数据科学平台能力。它们分别对应数据从生产、管理到消费和建模的关键环节，也为后面的端到端演示铺开了具体场景。

数据工程最繁重的部分，往往不在某一段 ETL 代码，而在整条任务链的搭建与维护。数仓要分层，数据源要接入，转换任务涉及依赖、调度、告警和重试，一处变更还可能造成下游连锁失败。数据工程 Agent 可以先探查环境、生成数仓方案，再创建 SQL 任务与 Pipeline；发生故障后，结合运行日志定位原因，并在获得授权后执行修复和重跑。

数据治理则要持续回答另一组问题：哪些表存在质量风险，敏感字段分布在哪里，一次异常会影响哪些下游资产？这些工作如果依靠人工逐表排查，成本很高。治理 Agent 可以围绕指定数据范围检查元数据、血缘、质量与安全状态，输出报告和处理建议；经确认后，再创建质量规则、配置监控、添加敏感标签或生成清洗任务，并在告警后辅助排查影响范围。

到了数据分析环节，业务人员感受到的往往是等待：一个指标要先解释口径、提交需求、等开发排期，复杂报告还需要反复改图。数据分析 Agent 则尝试直接理解自然语言需求，找到可用指标与维度，完成取数、图表规划和报表生成，并支持定时刷新与异常归因。齐芳芳在现场给出了分析耗时下降、整体效率提升等效果数据，其中“5—10 倍”属于发布会披露的产品口径，仍需结合具体应用场景理解。

数据科学面对的主要障碍，是数据与模型开发环境之间的割裂。数据留在数仓，训练和部署却发生在另一套平台，特征、版本和开发产物不得不反复同步。DataBuddy 尝试把数据准备、特征处理、训练、评估和部署衔接起来，在 Notebook 中借助 Agent 生成代码、辅助探索和组织建模任务，让算法人员把精力放在模型设计与效果调优上。发布会称，相关场景中的模型上线周期可从 30 天缩短至 7 天。这是厂商给出的效果数据，并不代表所有项目都能达到同样周期。

单独看，每类 Agent 都有明确的工作范围。它们能否跨环节协同，则要看实际任务如何从一个阶段交付到下一个阶段。蓝琪随后演示的一条电商业务链路，正好提供了观察窗口。

从建数仓到部署推荐模型，电商 Demo 如何跑通？

演示从一家刚上线新业务线的电商企业开始：订单和客户数据不断产生，数仓尚未建立，经营指标与 BI 看板也无从谈起。第一次经营会上，管理者提出三个问题：新业务表现如何？为什么客户满意度和复购率低于预期？接下来能采取什么措施？

要回答这些问题，团队通常需要先接入、清洗业务数据，建立统一指标和分析报表，再进一步开发推荐等业务服务。蓝琪试图展示的，是三类专项 Agent 与数据科学平台能力 能否沿着这条链路连续交付，而不是各自完成一个孤立任务。

第一步是建设数仓，并验证故障恢复能力。蓝琪向数据工程 Agent 下达需求：连接现有业务数据库，准备销售趋势、客户购买与复购行为、卖家及商品表现所需的数据，安排每天早上自动更新。业务目标和指标规则仍由人明确，Agent 负责将这些要求落实为可执行的工程方案。

接到任务后，Agent 并未马上写 SQL，而是先查看现有表、字段、实体关系以及可复用代码，再提出一份等待审核的数仓设计。方案采用 ODS、DWD、DWS、ADS 四层架构：ODS 接入原始业务数据，DWD 完成清洗和明细关联，DWS 负责主题聚合，ADS 输出面向业务消费的数据。表结构、字段类型、业务含义和 ER 图一并生成，让开发者能够在真正建表前检查数据关系与加工路径。

方案获批后，Agent 先创建 9 个离线数据接入任务，再生成 9 个 SQL 加工任务，最终把它们编排成一条包含 18 个节点的 Pipeline。上下游依赖、调度时间与运行条件同步配置完成；SQL 既能在产物栏查看，也能进入 Studio 继续编辑。交付结果因此不止是一组代码建议，而是可以执行、检查和维护的数据工作流。

随后，蓝琪故意切换到故障场景：9 个 ODS 同步任务均已成功，下游 DWD、DWS 和 ADS 任务却接连失败。他把失败运行 ID 交给 Agent，请它诊断问题。Agent 综合工作流配置、任务代码与执行日志，定位到工作流运行异常，于是列出受影响的任务和数据表。修复并未直接发生在生产环境中：系统先提交方案，等待人工批准，再修改、重新发布并重跑失败任务。演示中的新运行记录最终恢复成功。

第二步是数据质量检查与语义建模。数仓能够运行，只说明数据管线已经打通，距离“经营数字可信”还有一步。蓝琪让治理 Agent 对指定表做质量诊断。系统通过数据画像识别唯一性、一致性等风险，给出 8 条监控规则和相应 SQL 模板；用户确认后，质量监控与治理报告随之建立。对于异常数据，Agent 还能在 Studio 中生成清洗 SQL，辅助完成去重、修复和必要的分层重算。

监控触发告警后，治理 Agent 还可以沿数据血缘追查来源，识别受影响的下游表，并给出修复建议。在此基础上，蓝琪继续要求建立业务语义模型，定义 30 天复购率、客单价和转化率三个指标。Agent 从 Catalog 中识别分层事实表及订单、客户、卖家等实体关系，整理指标口径、维度映射、来源字段、业务说明和负责人，待确认后创建模型。这样，后续报表引用的指标就有了可追溯的数据来源和统一定义。

第三步是生成经营看板。管理者希望每天早上查看最新的经营表现，蓝琪便直接向数据分析 Agent 提出创建“零售运营 AI 报表”的需求。Agent 根据前面建立的指标，分析订单、客户、商品、财务、满意度等领域的 45 个字段，自行规划核心 KPI、对比周期、分析维度与图表形式，生成可交互的 BI 仪表盘。

现场生成的看板包括 9 张图表、7 种可视化类型，覆盖收入、趋势、区域、商品、渠道和满意度等方面，并可随数据更新自动刷新。用户还能够查看每项指标的计算定义、来源表与字段、聚合维度、刷新时间及对应 SQL。对企业而言，这些溯源信息与生成速度同样重要：报表上的数字不仅要能看，还要说得清从哪里来。

第四步进入推荐模型的开发与上线。看板能展示经营现状，却不能仅凭相关性断定复购率下降的原因。演示提出一个待验证的业务假设：部分客户首次购买后，未能继续发现感兴趣的商品。团队据此尝试构建推荐服务，并计划通过后续的转化率、复购率评估干预效果。这里的推荐策略是一项实验方向，并非已经证实的业务归因。

蓝琪使用电商数据集搭建了一个基于物品协同过滤的推荐模型。上传本地数据后，Agent 在 Notebook 中辅助生成代码，将商品、订单、客户与特征表登记为 Catalog 资产；随后在 Notebook 中处理用户与商品交互数据，完成长尾过滤、相似度计算和 Top-N 推荐函数，并配合测试与推理预览。原本分散的数据准备和建模操作，由此衔接进同一开发环境。

模型运行接入实验追踪，参数、指标和产物都可以回看与比较。通过测试后，选定模型注册到统一 Catalog，与数据表、指标一样记录版本、运行环境和负责人。演示最后将特征表发布为在线表，把模型部署为可通过 API 调用的在线服务，并配置推理结果记录和质量检查，覆盖完备性、有效性、一致性及时效性等维度。

这条演示链路最终回应了开场的三个问题：经营现状交给可追溯的看板呈现；复购率问题被转化为可检验的业务假设；行动方案则落到推荐模型的训练、部署和后续指标评估上。需要注意，演示证明的是一套工作流程能够贯通，并未给出推荐服务上线后带来多少复购增长的独立实测数据。

Agent 进入生产环境，还需要语义、安全和统一底座

电商 Demo 展示了“能做什么”，齐芳芳随后转向“为什么能够这样做”。企业要把真实任务交给 Agent，至少要解决三个问题：它是否理解业务口径，是否拥有受控且可审计的执行权限，数据处理和模型开发是否能在一套环境中衔接。围绕这些要求，DataBuddy 提出了业务语义层、Agent Runtime 和 OneOps 三项底层能力。

业务语义层首先解决“读懂数据”的问题。比如要求分析高价值客户流失，系统必须知道什么样的客户算“高价值”、怎样界定“流失”，以及客户、订单与指标之间如何关联。缺少这些前提，SQL 即便执行成功，结果也可能偏离业务口径。DataBuddy 的业务语义中枢由本体建模和语义建模组成：本体描述业务对象、属性、关系、规则及可执行动作；语义模型统一指标定义与分析维度。二者都以 Catalog、元数据和数据血缘为基础。

齐芳芳在现场给出一组对比：基于语义层的分析准确率为 95.9%，纯自然语言转 SQL 的准确率为 83.5%。这组数字突出了业务语义的重要性，但测试数据集、任务范围等条件还需以正式资料为准。语义层也不是建好就能永久使用。指标口径会变，底层表结构也会调整，因此治理 Agent 需要持续检查语义定义与实际数据是否一致，防止 Agent 依赖过期规则作出判断。

Agent Runtime 解决的是执行边界。Agent 在生产环境里能够做什么、看到哪些数据，出了问题能否追溯，都不能只靠模型自行判断。齐芳芳把运行时保障分为行为安全、数据安全和审计留痕三部分。行为安全针对提示词注入、越权调用以及高风险 SQL 等问题，在工具执行前进行意图校验和风险检查，并将 Agent 权限与真实用户身份绑定。数据安全进一步覆盖库表授权、行列级访问控制、敏感字段识别和动态脱敏，避免 Agent 通过工具取得用户本不该访问的数据。

运行时还包括业务隔离、会话沙箱及全链路操作记录。对企业而言，一次任务是否执行成功只是结果的一部分；谁批准了操作、Agent 修改过哪些资产、发生异常时如何追查，同样决定系统能否进入生产流程。发布会也提及 GDPR 和欧盟 AI 相关法规，但具体法律适用、合规义务与处罚标准，需要依据正式法规和企业实际业务单独判断。

第三项是OneOps，处理的是数据与 AI 工作环境长期分离的问题。它尝试将 DataOps、MLOps 和 AIOps 组织到同一平台，减少跨系统搬运数据和维护衔接代码的负担。齐芳芳用三个“One”概括这套设计：One Environment，让数据任务和 AI 任务共享工作环境；One Workflow，将数据开发、治理、特征训练、评估、推理和监控串成连续流程；One Data + AI，以统一的存储计算底座支持不同任务协同运行。

电商演示恰好串起了这三项能力：数据接入后，依次经过质量治理、指标定义、模型训练与在线推理，相关数据和模型资产都纳入 Catalog。Agent 面对的不再是一段孤立 SQL 或一份 Notebook，而是一条具有上下游依赖、可以人工检查的交付链路。发布会还披露了特征复用率、研发效率等改进数据；这些效果仍需放回具体业务规模和对比基线中评估。

已有数据平台如何接入？两条路径走向 Data+AI 工作台

除了平台内部的三类专项 Agent，DataBuddy 还在向企业已有的工作入口延伸。齐芳芳宣布，DataBuddy 的数据分析能力已通过专家能力和连接器接入 WorkBuddy。比如用户询问“这个月华东区销售额为什么下降”，系统可以先完成数据分析，再衔接周报编写、汇报材料生成和消息通知。这样，数据洞察有机会进一步进入日常办公流程，而不必停在一份独立报告里。发布会还提到，未来会继续通过标准连接器扩展其他工作入口。

对已有数据基础设施的企业来说，更现实的问题是：接入 DataBuddy 是否必须更换引擎、迁移数据？产品提供了两种模式。一种是直连现有数据引擎，数据留在原处，Agent 在既有资产上构建语义并完成分析，适合希望先引入分析能力的团队。另一种是采用 DataBuddy 统一存算引擎，将数据工程、治理、分析三类专项 Agent 及数据科学平台能力 放进同一环境，覆盖从数据接入到模型部署的完整链路。两种模式能获得的能力范围不同，选择取决于企业现有架构和实际目标。

部署区域同样会影响企业选择。齐芳芳介绍，DataBuddy 已在上海、北京、广州、曼谷、首尔和雅加达等区域提供服务，北美、欧洲、南美等更多区域也在持续部署。企业可结合数据驻留要求、业务分布及访问权限选择落地位置；跨地区使用时，仍需具体评估数据流向和相应的合规约束。

为了说明这两条路径，发布会提出了两类假设场景。第一类是业务分布在欧洲和东南亚、已有数据引擎的零售企业，可优先考虑直连模式，在不大规模迁移数据的前提下建设业务语义和分析能力。第二类是数据散落在招生、教务、学习行为和财务系统中的教育企业，可从统一存算底座起步，逐步搭建数据接入、治理、分析和模型开发流程。这些是用于说明实施方式的示例，并非经过独立验证的客户案例。

分享收尾时，齐芳芳再次给出三组产品效果数据：基于语义层的分析准确率 95.9%，数据工程、治理和分析相关工作的整体效率提升 5—10 倍，模型上线周期由 30 天缩短至 7 天。它们反映了发布会展示的目标与效果口径，具体项目能否复现，还取决于数据质量、原有技术栈、流程复杂度和评估方法。

从数据工程师深夜处理故障，到业务人员等待指标，再到电商场景中数仓、治理、报表与模型服务的连续交付，整场分享实际上围绕同一个问题展开：当 Agent 能直接参与数据工作流，人的职责将如何变化？DataBuddy 展示的路径是，由人提出业务目标、设定规则并审查关键操作，由 Agent 承担可自动化的执行与衔接工作；最终生成的任务、指标和模型资产，仍要能够被检查、追溯与复用。

点个在看你最好看

SPRING HAS ARRIVED