从多云底座到 Agent-Ready：企业 DataAgent 架构升级与落地实践

从多云部署到 Agent-Ready，还缺什么

把数据平台部署到多朵云上，通常先解决引擎适配和环境部署。企业仍可能在不同区域各建一套数据中心，任务无法跨区域编排，指标口径分别维护，跨云传输还受专线带宽和数据合规约束。对数据平台来说，多云可用至少包括数据传输、稳定生产、资产共享、安全合规；仅仅“每朵云都能运行”，并没有解决这些问题。

DataAgent 会把底座的问题带进整个研发过程。以跨区调货异常损耗监控为例，探数时可能误用废弃临时表，建模时重复创建地区维表，开发时臆造字段或使多表 Join 发生 Fan-out，测试又缺乏可用于对账的基线。到了发布环节，Agent 不清楚下游依赖和改动范围；运维遇到引擎报错，若没有归因与修复路径，任务便只能终止。前四处更集中地暴露业务语义缺失，后两处分别指向执行控制和持续改进能力。

对应的技术要求可以归为四项：多云可用，支持异构引擎寻址与任务执行；语义可懂，让实体、指标和业务口径能够检索与复用；执行可控，把用户权限、生产审批和运行隔离落实到系统；效果可迭代，把失败转成可验证的规则与技能。四项要求共同决定 Agent 能否接入真实的数据生产流程。

管理放在中心，计算留在各个云

跨云运行首先要改造调度。数新智能采用中心管理、多区域执行的结构：管理中心负责数据开发、任务定义、统一调度、元数据和资产管理；私有云、华为云、AWS、阿里云及 GCP 等区域侧部署统一引擎网关，以插件方式接入 Hadoop、MRS、EMR、MaxCompute、BigQuery 等异构底座。任务在目标区域执行，执行状态和结果回传中心。区域数据中心主动与管理中心建立连接，完成双向通信。

更紧的约束来自跨云专线。以 DataX 同步任务为例，调度系统把带宽抽象为 Slot 槽位，按任务优先级和资源配额分配，运行中持续观察实际流量，再决定后续任务的放行节奏。Worker 每五秒采集 Pod 的收发流量并写入 Redis，为实时槽位决策提供数据；Prometheus 保留历史指标用于查询。观测指标过期时，调度按默认槽位回退，避免监测链路故障直接阻塞同步任务。

任务统一管理之后，资产口径还要保持一致。管理中心定义集团指标、逻辑数据实体和数仓逻辑模型，模型在各个数据中心物化为本地物理表，由本地生产任务执行；产生的元数据再回传中心，形成逻辑实体、模型、物理表及字段之间的血缘。这样既能保留不同区域的生产能力，也能集中管理跨区域的指标与规则。

这套方式采用“集散控制”：标准集中制定，计算和生产分布执行。底座对上提供逻辑访问入口，对下负责多云纳管、编排调度、异构数据集成、资产管理和跨源查询。面对不同引擎，网关先判断能力并尽量原生下推；不适配时按设计回退至 ANSI SQL 等兼容路径。Agent 无须为每个云分别维护一套任务流程，但执行仍遵守所在区域的实际条件。

SQL 生成之前，先找到正确的业务口径

企业问数的困难常在 SQL 之前：同一个指标可能关联多张表、多个维度和不同的业务定义。数新智能把自然语言查询拆成理解、检索、编译、交付几步。NLU 先识别查询意图与种子业务实体；检索阶段结合名称、同义词精确匹配，以及 Dense、BM25、ValueIndex 混合召回，锁定候选实体；再由 GraphRAG 扩展 Model、Dataset、Field、Metric 的关系，补全需要经过的 Join 路径，形成当前查询所需的语义子图。

拿到语义子图后，SQL 由确定性编译器处理结构校验、Join Path 求解、Fan-out 防护、行权限注入和目标方言渲染，产物还要经过语法与执行前校验。这里把大模型的主要职责放在理解意图，尽量减少它直接拼写生产 SQL 时引入的字段和口径错误。不过，语义建设尚不完备的早期阶段，也保留调用模型降级处理的路径；确定性编译是演进方向，并非所有查询都已经能够完全覆盖。

工具能执行，还要保住上下文与权限

规划阶段如果将八个后端 API 一对一包装成八次 MCP 调用，任意一步失败都可能拖累后续流程。数新智能把建表、挂依赖、配置调度等高频操作固化为服务端流程工具，让 Agent 用一次调用完成一组确定动作；稳定的操作规范沉淀为 Skill，底层能力则通过原子工具和 CLI 提供。工具不在启动时全量注入，而是通过 search_tools 按意图查找并加载；第三方 MCP 接入独立沙箱，经过鉴权、版本约束与输出清洗后再参与执行。

取数阶段容易出错的是上下文。长会话被常规摘要压缩后，dim_region_v2 可能只剩“区域维表”，时间字段 ship_dt、排除状态 REFUNDED 也可能丢失。用户随后要求把按天统计改为按月，Agent 便可能重新选择错误的表。系统采用异步笔记保存已经确认的表名、版本、过滤条件和统计粒度，后续追问只修改相关条件。检索先查本体与指标口径，再查样本值和历史成功 SQL；失败的中间 SQL 与报错留在任务沙箱，不进入组织长期记忆。

进入生产执行后，权限边界不能靠 Prompt 约束。Agent 继承发起人的身份与 RBAC 权限，行级限制由 SQL Guard 在编译期注入。执行链路设置输入、工具参数、SQL、容器沙箱、输出五层防护，分别检查越权意图、非法参数、数据访问边界、运行环境和脱敏审计。DROP、TRUNCATE、生产调度作业上下线等高危动作被拦截并触发 HITL 审批卡，负责人员确认影响范围后才能显式放行；不能把“有人审批”理解为 Agent 获得了自动提权能力。

失败要有去处，修复必须过评测

即使有权限和沙箱，Agent 仍会在语义、工具、引擎兼容或推理环节出错。系统保留 Token、工具调用和执行 Trace，再按原因分流：语义缺失时补本体、同义词及字段映射；操作流程欠缺时整理 SOP，形成 Skill 或服务端流程工具；引擎差异引起的问题则更新方言规则与兼容模板。修复项先进入检索、编译、端到端分层回归，评测通过后才灰度进入团队共享库，避免错误经验在后续任务中反复传播。

这些机制被组织在 CyberOS 产品体系内：CyberEngine 适配和纳管异构引擎，CyberData 与 CyberAI 分别承载数据及模型能力，CyberOntology 管理业务语义与图谱，CyberAgent 承接 DataAgent 等智能体任务，CyberAsset 统一管理数据集、模型、API、Skills、Agent 等资产。跨云管理、语义检索和任务执行由此使用同一组底座能力，不必在每个 Agent 内部重新实现。

企业级 DataAgent 的 Harness 采用三层结构。L3 以 CyberData、CyberKernel、CyberEngine 提供鉴权、元数据、数据集成、调度和异构计算；L2 容纳四类数据开发 AI 能力、按需加载的 Skills、LLM 网关、四层记忆以及任务级隔离沙箱；L1 处理交互、任务路由、身份传递和人工审批。架构中的 Input、Tool、SQL、Output 是四个 Guardrail 拦截面，容器沙箱另在运行层提供隔离，与执行链路的五层防护对应不同层次。

落地效果，必须放回具体项目和统计口径

在数新智能与华为云合作的跨云数据平台项目中，客户原有 AWS 与阿里云平台分别建设、独立调度。迁移后以新加坡华为云为主节点，俄罗斯华为云和印度 AWS 为两个卫星节点，统一纳管跨区域任务、元数据和计算引擎。迁移覆盖元数据、任务与数据，采用新旧平台双跑及数据校验；项目披露，85% 的脚本迁移后无须人工修改。

某顶级奢侈品集团面临海外云和阿里云之间的数据发现分散、访问审批依赖人工、跨境传输不透明等问题。跨云管理平台统一收集元数据和授权信息，将数据发现、跨租户授权、审批与工作流调度纳入线上流程。数据同步采用项目级带宽配额，并配置监控、告警、限流和排队，避免不同业务任务无序占用专线。

安踏集团采用的是另一类多云组织方式。IDC 及不同云上的数据集成、开发、服务和生产任务留在各区域运行，集团层集中定义数据标准、指标口径、质量与安全规则，再把规则和逻辑模型下发到各区域物化、执行。中心负责统一治理，本地承担稳定生产；上层对接选品、库存、营销等数据与 AI 应用。

DataAgent 的效果统计来自某全球头部高端零售集团。六个研发环节分别记录了不同指标：探数环节约 70% 为定性评估；建模环节有 1.2 次至 3.5 次的复用相关记录；开发环节在 200 条标准评测集上的代码准确率由 30% 升至 90%；测试环节核心资产表规则覆盖率为 90%；发布环节有三个月统计值低于 5%；运维环节另有人工事后打标的约 50% 改善指标。这些数值的衡量对象并不相同，不能合并称为“Agent 准确率”。端到端从需求提出到报表投产，由约 10 个工作日缩至 3 个工作日内，交付周期减少约 70%。

一条脱敏任务链把流程进一步落到具体动作：用户要求统计北美区近 30 天各渠道退货损耗，Agent 找到 return_loss 指标和 dim_region_v2 维表，并提出目标表、Join 路径及状态过滤方案；开发人员确认后，编译器生成 SparkSQL，再经过 Fan-out 检查、语法校验、行级权限注入、Dry-run 和发布审批。这个单项任务披露的耗时由约 3 天降至 30 分钟。

先补语义，再逐步扩大自动化范围

适合率先使用 DataAgent 的场景通常具备几个条件：指标口径已基本定义，有存量 SQL 可以复用，内部研发人员能够参与确认，且存在多引擎开发、SQL 纠错或质量规则生成等明确需求。对于口径尚未形成的冷启动项目、面向外部用户且零人工介入的强实时服务，或缺乏沙箱和回归评测的生产环境，自动执行需要更谨慎。实践顺序是先补语义，再从高频、低风险任务切入，任何修复和能力扩展都要经过评测门禁。

后续的递归改进重点放在 Agent 下次执行所依赖的 Skill、语义图谱和调度策略上，而非直接修改模型权重。数据生产越复杂，越需要把口径、权限、引擎能力和失败处理交给可检查的系统机制；模型可以参与理解与决策，但能否安全进入生产，仍取决于这些机制是否可用。

从多云架构升级到 DataAgent 落地，企业需要解决的不只是模型能力问题，更包括业务语义、跨云调度、执行安全和持续评测。高端零售项目的实践表明，当这些能力逐步完善，Agent 才能真正参与数据开发与生产流程。

DataAgent 的落地不必追求一步到位的全自动化。从高频、成熟的业务场景切入，在实践中积累语义资产、执行规则与可复用的 Skill，逐步扩大应用范围。未来，数据底座的价值不仅在于管理和处理数据，更在于让 Agent 能够准确理解业务、安全执行任务，并持续改进。这也是企业走向 Agent-Ready 的关键。