QCon 2026·网易智企：从 Copilot 到 DataAgent——企业级智能数据开发治理平台的技术演进和实践
主讲：李卓豪（网易智企，数帆 EasyData 技术负责人）
时长：约 47 分钟
数据开发治理平台的 AI 演进四阶段：从单点操作到 DataAgent，以及为什么选择 CLI 而非 MCP（Token 效率差 35 倍）。重点分享了 SQL 生成的三阶段流程（问题改写→表识别→生成校验）和优先做智能运维而非数据开发的决策逻辑。
开场说明
本来今天要讲的是我们 BI 方向的分享，但同事因为不可抗力没能来，我来替他分享一个不同的话题——数据开发治理平台的 AI 演进。以后还会有机会分享 BI 那个方向，大家可以保持关注。
今天的结构：背景 → 技术架构 → 关键实现 → 落地挑战 → 未来展望。
一、背景：部门业务与痛点
部门定位
我们部门分三层：
- 底层：基础设施平台，统一 AI 能力
- 中层：数据开发治理平台（EasyData），今天分享的重点
- 上层：数据应用场景，包括 BI、智能数分等，过去一年重点在数智金融方向
三层之间有业务关联：中层的标准化数仓建设，是上层 BI 和智能数分的基础；中层做好了，上层才能快速体现 AI 价值。我们也在规划把这个平台打造成对外的 AI 应用门户。
我们不只服务网易内部，还有大量对外的 to B 客户，覆盖各行各业。
AI 浪潮下的需求爆发
痛点一：to B 实施效率
不断有新项目合作，如何提高实施效率、压缩成本？包括批量数据标准挖掘、批量入仓、核心指标发现。
痛点二：核心业务基线保障
重点业务（音乐、团队等）如何在承接新任务或业务调整后，保证数据产出时间不变？系统性降低风险。
痛点三：资源治理
硬件价格持续上涨，每年做运动式治理（Spark 迁移、资源下线），但上任务容易下人难，持续有难点。
痛点四：研发效率
新人如何快速熟悉数据架构？数仓同学遇到问题时，不应该还要去关注 Spark 特性、底层存储架构——这些对数仓同学太不友好了，知识负担太重。
二、平台 AI 演进的四个阶段
阶段一（2024 年）：短链路单一场景
用自然语言快速实现单点操作：表权限申请、表的服务 API 创建等。在数据开发的表单页面上直接嵌入，减少操作切换。
阶段二：深度开发提效
数仓开发一直在模仿服务端开发的链路。当时 AI Coding 很火，我们也尝试了模型微调，做整个数据开发内容的补全提示。
阶段三：具体场景独立解决
在具体场景下实现独立解决：SQL 生成、优化建议，数据指标任务配置自动生成，词典提取等。这个阶段投入比较多。
同时做了模板化数仓构建（AutoDM）：针对标准化的业务场景（比如财务数仓），实施同学已经非常熟练，流程很清晰——从财务系统把表拿出来、做分析、建指标，一套固定流程。我们把这个流程模板化，在 Excel 里描述字段映射和加工模式，当遇到新的数据源系统时，通过 AI 做语义等价替换，快速把 A 场景迁到 B 场景。在 to B 的 PoC 场景上得到了大量应用。
阶段四（今年）：DataAgent
今年明显感受到 Agent 需求爆发：
- 业务自建冲动：我们之前开放了 OpenAI API 和部分 MCP，业务部门开始自建 AI 应用，包括做 Vibe Coding 和 SDD 的尝试
- 场景爆发：以前只有技术部门用，现在职能部门也需要——周报自动生成、报表自动构建、数据分析 API，各种比赛和分享也在推动
- 产品内嵌的必要性：
- 通过 MCP 挂外部客户端，无法把所有产品功能开放出来
- 金融、国企客户对安全要求非常严格，外部客户端不可接受
- 需要端到端的场景应用
三、DataAgent 技术架构
整体分层
- 应用层：各产品业务入口
- 接入层（对话层）：通过 SSE 做流式展示，做一层框架无关的抽象（不绑定特定框架，便于未来切换更强的框架），处理安全、权限、上下文管理
- 工具层：大量工具抽象，渐进式加载（比直接全量注入 token 消耗更低、效果更好）
核心能力模块
SQL 生成（最大投入）
质量任务规则自动生成 + 标准分层
元数据智能描述：以前描述基于表，但业务人员问问题时用的是业务黑话和行话，传统方式效果不好
数据安全：敏感字段识别，自动数据分类分级
智能运维：任务出错时自动诊断失败原因，给出优化建议
知识库体系
知识库是效果好坏的核心，分两部分：
用户知识（用户维护）：
- 行业数据定义（不同业务部门对 DAU 的定义可能不同）
- 业务流程知识（可以用工具或 AI 从现有文档中抓取）
- SQL 模板（有些用户对 SQL 格式有强偏执，必须按特定模板）
- 时间参数等自定义配置
系统知识（自动生成）：
整个平台所有数据业务都跑在平台上，我们可以自动生成系统知识库。最初希望靠数据治理人员来完善，但实践发现根本推不动，最终还是靠机器自动化生成。
具体做法：
- 从业务数据中自动抓取，做搜索片段化
- 多表关联、表名数据结合指标的分析
- 系统内置函数和系统字典
知识库更新：定期 + 实时双链路（表变更、任务调整都能感知到）。
更新后推送到召回管理，统计用户评价和召回情况，反哺召回策略。同时推一份到 ES，用于关键词匹配。
四、为什么选择 CLI 化
在设计 DataAgent 时，我们花了很多时间考虑：要不要做 CLI？
为什么不用 GUI 方案：
- GUI 识别能力弱，虽然现在有工具能基于页面元素做识别，但还是不够好
- CLI 在输入控制、token 消耗、让模型发挥主动性方面都更好。以 50 台设备管理场景为例，MCP 方案约需 4,150 tokens，CLI 方案约需 800 tokens，差距约 35 倍
为什么不直接用 MCP：
- MCP 一上来就把所有工具描述全部拉回来，上下文消耗大
- 每次调用都重新拉取，网络调用量大
我们的方案：先把 CLI client 做好，然后：
- 可以把 CLI 挂到 OpenAI 或 Claude Code 上，做质量基线对比
- 对结构化组织要求很高——接口参数虽然嵌套，但要维护这种嵌套结构（打平后验证效果不好）
- CLI 的描述（help text）要写得非常好，这是让 AI 学习的关键
验证时间点：我们内部讨论完不久，钉钉、飞书、企业微信在 72 小时内争相把自己的方案切换到了 CLI 化——这印证了我们的判断。
CLI 设计：分成约 10 个模块，高频操作做短平快的封装，同时维护前端 API 管理（非正式版，用于典型场景验证，稳定后再转成正式版）。做好缓存管理，定期刷新，必要时做实时更新。
五、SQL 生成的关键实现
为什么要做 SQL 片段提取
直接用真实 SQL 学习，有几个问题：
- 会生成不存在的表名和字段（幻觉）
- 大模型训练是通用的，不了解内部数据、业务关系、业务规则
- 无法感知新业务变动（数据架构调整、表关联关系迁移）
解决方案：从真实 SQL 中提取结构化的 SQL 片段。
SQL 片段提取流程
- 使用线上真实 SQL：平台数据在我们这里，这是优势
- 裁剪：去掉注释、测试相关片段，只保留核心逻辑，索引关系打散，控制在合理长度
- 关联元数据：解析 SQL 中的表，了解上下游血缘关系，知道哪些表会受影响
- 富化描述：用大模型对 SQL 片段做描述补充，完善注释（原始 SQL 可能有业务描述但不完整）
- 去运行态信息：最终得到结构化的数据服务，而不是嘈杂的原始结构
SQL 生成流程
三个阶段：
阶段一：问题明确与改写
- 判断问题是否全面：表信息是否挖掘充分，参数是否足够
- 风险规避：某些岗位的查询如果做全表扫描会消耗大量资源，要提前识别
- 访问控制：结合业务改写模板对问题进行改进
阶段二：表识别与参数提取
- 做语义 + 关键词双路召回
- 找到业务上血缘关系更近的表
- 从指标关联关系推导计算公式
阶段三：SQL 生成与校验
- 生成 SQL 后不直接使用，先做语法判断
- 不同引擎（Spark/Hive）语法特性不同，需要注入引擎差异，自动纠错
- 最终做完整校验
示例：用户问一个复杂的数据查询问题 → 改写为标准查询意图 → 生成处理条件 → 做假设性回复验证 → 识别所需表 → 召回关联表和计算公式 → 生成 SQL → 语法纠错 → 输出。
六、DataAgent 落地的优先级选择
我们先做智能运维，而不是数据开发，原因：
智能运维的使用频率和闭环价值比数据开发现阶段更高。
典型场景：数据开发同学值班，晚上某个 Spark 任务报警挂了，下游差 3 个小时。以前需要打开电脑排查，现在通过 Agent 自动判断——评估任务在平台上的重要性，自动调用接口获取日志，和底层 Spark 做交互，给出推荐的处理类型，自动调整。
以前运维同学晚上睡觉手机开震动，随时可能被叫起来处理。现在这部分工作越来越多地被 Agent 接管，随着场景不断完善，Agent 处理的比例会越来越高。
七、未来展望
CLI 化是基础：所有能力都要 CLI 化，让 AI Agent 能方便调用。
DataAgent 的核心价值：不只是 Copilot（辅助），而是能端到端交付——这才是 to B 客户的决策者真正想看到的。很多客户不在乎技术细节，他们要的是”数字员工”能直接交付结果。
Skill 的持续抽象：把数据开发治理领域的各种能力不断抽象成可复用的 Skill，构建数据开发治理领域的 Skill 生态。
自动化评估体系：人工做回归成本太高，必须建立自动化评估体系，这是整个 AI 效果持续提升的关键环节。
