信飞科技是一家深耕信贷科技与数据智能的金融科技服务商，2020 年前后启动海外展业，目前已覆盖东南亚、拉美等多个市场。随着出海国家持续增加，数仓团队面临的核心问题从"能不能建"变为"能不能快速、可控地复制到每一个新国家"——各国监管、时区、流程和指标口径不同，代码可以参考却无法照搬，国家越多，重复建设的人力成本越高。
引入 DataWorks Data Agent 后，信飞科技将数据接入、任务开发、质量配置、血缘分析和发布验证收敛到平台内部，通过 Skill 和企业语义层处理批量任务与业务差异，新国家数仓上线周期从 2—3 个月缩短到约 2 周。更关键的是，数仓团队第一次拥有了一套能够随国家数量扩展的交付方式。
01
信飞科技长期深耕国内互联网金融领域，进入海外市场后，单个国家体量有限，必须通过多国共同形成规模；但各国的监管环境、服务供应商、人审比例、放款链路、数据源和业务参数并不一致。因此，B 国可以参考 A 国，D 国可以从 C 国复制，却无法把"Copy"理解为整套代码直接迁移。
以贷后业务为例，A 国可能拥有自营催收团队，C 国则没有；将 A 国代码迁移到 C 国后，部分贷后指标会天然为空，需要明确标记或移除。人审比例、放款链路、数据源、业务参数和时区也会影响任务设计。共性决定了代码有复用价值，细节差异则要求数仓团队逐项确认。
"采、建、管、用"四个环节同时承压：
采集：一张 ODS 表从接入到上线，人工约需 2 小时；新国家首批可能接入 20 个系统、100 多张表，MySQL、MongoDB、Kafka 等多源配置难以模板化，跨国时区进一步增加配置错误风险。
建设：大量 DWD 任务与 ODS 逻辑接近，仍需逐个创建、发布和配置依赖；DWS、ADS 指标相似，各国口径却不完全一致。
管理：多国需求并发容易造成 DQC 漏配，敏感字段识别、权限配置、慢任务和存储治理依赖人工。
使用：业务人员不一定熟悉 SQL，数据异常出现后还要沿 ODS→DWD→DWS→ADS 逐层追溯。
02
信飞科技的智能化演进经历了三个阶段。最初没有 AI，所有动作靠人工搬运，一个新国家的数仓建设通常需要约三个月。随后团队引入私有化部署的 Dify，用工作流复制代码、输入修改要求、由模型生成结果，再放到 DataWorks 试跑；局部效率有所提升，但团队意识到，问题的瓶颈不在模型生成能力，而在生成之后的试跑、验证、发布和依赖配置仍需人工串联。如果 Agent 不能直接操作数据平台，效率提升就始终卡在"最后一公里"。基于这一判断，团队转向 DataWorks Data Agent。
转向 DataWorks Data Agent 后，任务生成、修改、试跑、发布、下线、血缘分析和结果检查在平台内连续完成。Agent 能够调用 DataWorks 的真实能力，把过去"复制代码—AI 修改—粘回平台—人工试跑—人工上线"的链路，收敛为平台内的任务闭环。
03
任务分类：两套路径，各司其职
团队首先将数仓工作分为两类：
|
类型 |
典型场景 |
实现方式 |
|
通用型任务 |
数据接入、任务发布与下线、血缘分析、简单 DWD、DQC 配置、慢任务分析、增全量合并 |
提示词 + 模型；批量高频场景封装为 Skill |
|
业务语义任务 |
指标查询、口径探查、数据问题分析、报表生成、基于业务语言的需求开发 |
提示词 + 企业语义层 + 模型 |
实践一：ODS 批量接入封装为 Skill
ODS 接入是最典型的批量任务。新国家首批可能同时接入 100 多张表，按人工约 2 小时/表计算，仅第一批就需要约 200 小时。
团队将表结构读取、类型映射、任务生成、验证和发布封装为 Skill，使 DataWorks Data Agent 按固定流程批量执行。实践中，一次性提交 100 张表会导致上下文过长和执行超时。团队没有继续堆长上下文，而是先识别 Agent 边界，再在 Skill 中拆分任务——每批约 10 张表，由 Skill 循环处理。对使用者仍是一次提交，执行端则被拆为多个可控批次。采集配置从人工约 2 小时/表缩短到约 5 分钟/批。
实践二：从真实业务问题中构建企业语义层
企业语义层解决的不是"模型是否理解中文"，而是 "模型是否理解这家公司的业务语言"。
例如，业务人员提出查看"金刚位"的埋点数据，大模型可能知道它是 App 中的资源位置，却不知道应查询哪张表、哪个字段和哪套埋点口径。再如同一个"新客"，在风险场景中按是否发生过提现或借款判断，在营销场景中则按是否注册判断——词相同，业务定义却不同。
信飞团队没有先设计一套完整而抽象的知识体系，而是直接收集真实需求：群聊中的一句话、需求链接、产品文档、数据问题以及会议记录，都可以作为测试输入。Data Agent 结合知识库和 Skills 执行，人工验证结果，再持续修正。经过约两个月实践，知识库至少迭代了两版。
迭代过程重点寻找三类问题：
盲点：知识库未覆盖的业务术语或数据对象（如"金刚位"无法映射到具体埋点链路）；
断点：Agent 分析到一半无法继续（如不知道下一步该查哪张表），通过 Skill 串联查询路径；
限制点：批量任务超时、上下文过长等能力边界，通过控制输入、拆分批次解决。
在这个过程中，知识库重点覆盖 ODS、ADS 和关键 DWD 层信息，其他中间任务由 Agent 结合血缘关系和任务代码自行读取——既保留核心业务语义，也避免文档规模过大。
实践三：治理能力延伸到存量国家
DataWorks Data Agent 不仅用于新国家建设，也用于慢任务、无效任务、孤岛任务和存储治理。团队上半年开展存储治理后，治理成本显著降低。对于数据问题，Agent 结合血缘和任务代码辅助定位根因，减少人工逐层查表的时间。
04
数据开发环节
质量、排障与需求交付
DQC 覆盖率：由不足 40% 提升到 95% 以上，通用 DQC 在生成任务时同步配置，质量管理从被动响应转向主动预警；
需求交付：由 3—5 天缩短到小时级；
问题排查：由人工逐层追踪数小时缩短到分钟级；
报表开发：由 1—3 天缩短到约 30 分钟。
国家级交付
新国家数仓上线周期从 2—3 个月缩短到约 2 周，整体提效约 6 倍。 这一结果来自最近一个月内连续上线两个国家的实际过程。
需要强调的是：DataWorks Data Agent 并未取消人工验证，而是把人从大量机械操作中释放出来，使审核集中在差异口径和关键风险上。
05
效率侧，团队将持续建设企业知识库，按营销、催收、风险、运营、资产保险等业务域逐步完善；同时对数仓任务持续分类，为更多场景建设 Skills。
质量侧，将引入定时巡检、代码审查和资产保鲜机制。未来的代码审查不再依赖工程师从头逐行比对，而是先由 AI 整理改动位置、内容和风险点，再由人工确认。
06
信飞科技的实践证明，DataWorks Data Agent 的目标不是替代数仓工程师，而是把可重复、可验证的流程交给 Agent，把人的精力留给业务语义、复杂口径和上线审核。从三个月到两周，改变的不仅是交付周期，更是数仓团队面对多国扩展时的生产方式。
/ END /
领票链接 >> https://yunqi.aliyun.com/2026/ticket?activityId=NjY3OQ==&ticketId=MTQz&channelId=NDczNA==
阿里云大数据 AI 平台邀您到场，共同参与 Agentic AI 时代 Data+AI 新篇章！
点击「阅读原文」跳转链接，免费领票～