导读数据工程师每天被 cron 格式、页面切换、语法试错等琐事打断真正用于建模、质量校验的注意力被持续稀释。云器科技产品负责人王贯扬近日在直播中分享了团队自研的命令行工具 cz-cli——一个让 AI 编程工具真正理解数据工程的 agent 工具。本文基于云器 Lakehouse 产品负责人王贯扬老师的分享梳理 cz-cli 的设计思路、工程决策及典型场景探讨如何通过专业 agent 将数据开发从“杂活驱动”转向“注意力驱动”。注意力数据工程师最稀缺的资源记 cron 格式、切页面、查文档、试语法——这些动作单次耗时不过几十秒却构成了高频率的上下文切换。演讲中引用了一个直观对比同一个日报表搭建任务人工操作需在多页面间反复跳转而通过 cz-cli agent 执行从建表、配置凌晨两点调度到上线验证整个过程无需人工介入。团队在内部调研中发现数据开发过程中真正消耗精力的并非复杂业务逻辑而是“平台配置差异、语法方言、不同页面间的来回切换”。这些琐事本身不构成技术挑战但它们持续打断心流让注意力无法锚定在建模、数据质量、业务需求思考上。cz-cli 的起点正是对这一痛点的回应把杂活扛过来把注意力还给工程师。从裸用大模型到专业 agent一条必经的工程化路径在决定构建专用 agent 之前项目组尝试了三条技术路线每一条都暴露了通用方案在数据工程领域的局限。第一条大模型直接调用 JDBC/SDK API。 问题很快浮现——查询返回几千行数据时上下文窗口迅速被撑爆频繁的 token 消耗让任务执行变得不可控。更关键的是模型在处理海量中间结果时容易“失焦”原本要完成的数据操作被淹没在响应体中。第二条将能力封装为轻量级 skill 嵌入主 agent。 随着 agent 中 skill 数量增加调用稳定性开始下降。复杂任务中模型有一定概率调用非预期 skill即使正确调用也难以严格遵循 skill 中预设的步骤和经验约束。“skill 并不是一个能稳定发挥的形态。”第三条MCPModel Context Protocol方案。 多 MCP 并存时冷启动阶段读取所有 tool 描述的成本显著拉高且 MCP 作为通用协议注意力不够集中。最终团队选择了第四条路构建一个专注数据开发的专用 agent命名为 cz-cli。它可以独立运行也能作为子 agent 被主 agent 调用。当主 agent 遇到数仓相关任务时直接将控制权转交给 cz-cli——后者拥有足够聚焦的上下文和内置知识能够稳定执行工程级的数据操作。37 个 skill不止是方法集合而是一套规范数仓的 harnesscz-cli 的核心资产并非大模型的通用推理能力而是内置的 37 个 skill。每个 skill 标注了三个维度正确做法、平台限制、常见坑。覆盖范围从基础连接、数据管道搭建到计算资源规划、数据建模、治理运维以及上层业务集成。“不是 37 个零散的方法而是一整套驾驭 LLM 搭建规范数仓的 harness。”每一个 skill 在执行时都会主动校验中间结果——例如完成一层 DWD 建设后自动触发数据验证确认无误后再进入下一层。这种“每层验证”的机制避免了错误逐层累积到最后才发现、再回滚重算的代价。团队也强调cz-cli 不仅适用于云器 Lakehouse也可用于其他数据引擎核心价值在于提升数据开发的工程化输出质量。典型场景从血缘分析到 schema change 影响面评估数据血缘分析给定一张表cz-cli 自动加载血缘 skill逐级向上追溯上游依赖。它不只查询单一来源而是综合调度任务依赖、DDL 语句、job history 等多源信息交叉验证后输出完整血缘关系图。演示中一张表的四层血缘每层包含哪些上游表、任务节点全部自动绘制。调度任务巡检日常巡检是高频且重复的工作。将整条链路的巡检任务交给 cz-cli 后它会拉取任务列表、状态、调度时间甚至识别出耗时异常的任务并生成可读的报告。更有趣的是通过 IM飞书、企微调用子 agent工程师在移动端就能完成巡检——输入一句“帮我看下这条链路的调度任务有没有异常”几分钟后收到结构化报告。Pipeline 搭建与 schema change 分析接收一个“建三层 pipeline”的需求后cz-cli 首先查询原表结构规划任务步骤逐层建表并刷新数据每层完成后主动验证。若遇到语法错误例如平台特有的方言差异它内置的产品知识库会检索正确语法并自动修正。schema change 场景则更具挑战上游表新增一个 key-value 类型下游会受哪些影响cz-cli 先分析整条链路的血缘和依赖格式再推理出风险表、脆弱依赖项甚至给出兼容性变更方案和上线次序建议。业务人员也能 DIY从需求方到自主取数者一个意外的发现来自公司内部的财务团队。财务人员需要分析账户成本但不会写 SQL也不熟悉数仓操作。团队给财务同学配置了主 agent cz-cli 子 agent 费用账单业务说明文档。结果财务同学自己生成了一份天猫报表——维度拆分清晰、可一键导出 CSV、可直接粘贴到 IM 分享。这个案例让项目组意识到cz-cli 不仅提升了数据工程师的效率还改变了业务人员的角色——从“提需求”转向“用工具”而数据团队则从“接需求做表”转向“建平台、建能力”。增量计算让 AI 掌握生产级细节增量计算是云器 Lakehouse 的特色能力但团队发现 AI 在构建增量链路时容易遗漏细节——不是不知道语法而是无法兼顾工程化的完整性。例如状态表的生命周期、维表 join 的决策、如何加 hint 避免存储膨胀等。为此cz-cli 集成了增量计算专用 skill补齐了大模型容易遗忘的细节风险识别、增量合规检查、join 策略选择等。演示中一个原有的四层 pipeline数据新鲜度 1.5 小时被要求改造为 10 分钟级增量链路。cz-cli 先读取 DT 表 creator 的参考文档策略、限制、踩坑记录、最佳实践然后逐层分析现有 MV 是否可以增量最终输出改造方案——包括每层的原表与目标表、变更情况、约束条件、改造后架构图、风险与预期效果。这个方案已经接近生产级后续只需按 plan 细化 DDL 和链路配置即可执行。让注意力的支配权回到工程师手中回顾整个设计历程一个核心判断贯穿始终数据开发中的重复琐事不应由人的注意力来承担。cz-cli 不是为了让工程师变成更快的“SQL 手写员”而是把注意力的支配权还给人——留给工程师的是真正需要判断的事数据怎么建模、口径怎么对齐、质量标准怎么定。对业务人员它提供了自主探索数据、按需取数、生成交付的能力对增量计算的迁移与搭建它让原本需要数周梳理的链路改造变得可自动化推进。项目组透露cz-cli 目前仍在打磨细节首批试用用户将获赠 token做到“安装即用、无需操心配置”。感兴趣的同学可加入官方交流群获取最新进展与使用技巧。Q137个skill模型怎么知道该调哪个会不会调错王贯扬关键就是别让一个agent干所有事。我们把 cz-cli 做成专门的子 agent只负责数仓skill 范围很窄模型自然不容易选错。每个 skill 的描述也写得短而精详细内容等选中后再加载。另外我们有测试流程新 skill 上线前会检查会不会跟其他的搞混。给大家的建议skill 多了就拆成子 agent别让一个模型记几十个工具。Q22000行SQL、几十张表AI真能看懂吗王贯扬一次性读完肯定吃不消。我们的做法是先把 SQL 当代码管理放代码库里让模型分步读。再用 coding graph 画出表依赖关系用 speck 工具把长 SQL 切成小段。最关键的是 skill 里强制了流程先拆 plan一步一步执行每步做完验证数据对不对。不是靠“读”懂2000行而是靠“拆”和“验”驾驭它。Q3生产环境用AI万一出错了怎么办王贯扬幻觉避免不了靠工程兜底。两个习惯一是生产环境 agent 默认只有只读权限人确认没问题才放开写操作。二是改东西先搭临时链路和原链路并行跑自动校验数据一致没问题了再按步骤人工确认切换错了用 time travel 回滚。核心思路让幻觉只影响临时环境且有回滚按钮。Q4几千张表、没怎么治理AI能找对表吗王贯扬别想一口吃成胖子。从最常用的核心链路开始让 cz-cli 做血缘分析把依赖图谱存下来。一条一条链路沉淀覆盖80%业务查询就够了。另外给容易混淆的表加 semantic view写清楚业务含义模型就能准确定位。先挑重要的做越用越顺。Q5业务人员用的时候很多表长得像模型怎么知道用哪张王贯扬最靠谱的还是加 semantic view——花几分钟写明表是日粒度还是实时、适合什么场景。模型读到就能准确匹配。如果没有标注模型会看数据新鲜度、行数来猜但不一定准。建议核心表把 semantic view 补上业务人员自己用 agent 取数就省心多了。点击获取完整资料云器科技官网 - 改变数据的使用方式更多内容欢迎关注「云器科技」官网云器科技-多云及一体化数据平台提供